group tags in genshi bundles

[Martin Schwier <[email protected]…>]

I just migrated to bcfg2 1.0 and noticed that I can't use group tags in *.genshi Bundles. Is that intended?

I think it would be useful if I could use genshi in every Bundle without renaming it to *.genshi and adding the xmlns:py attribute.

Did you also notice that bcfg2-repo-validate has trouble with genshi Bundles?

[solj]

Grouping in genshi bundles is done using genshi syntax outlined at ​http://genshi.edgewall.org/wiki/Documentation/xml-templates.html. Genshi bundles are processed differently from normal bundles. What is repo-validate complaining about?

[Martin Schwier <…>]

Sorry, my fault: There is no problem with bcfg2-repo-validate.

But it would be really nice if we could use the <Group name='..'></Group> Tags also in genshi bundles in the future. I think this would be easier to read and more consistent with normal bundles. So converting from a normal bundle to a genshi bundle would be just a matter of renaming it to *.genshi and adding the xmlns:py attribute.

In my opinion it would be even better if all *.xml bundle would be processed by genshi, so the user don't has to differentiate between the two formats.

[somekool <…>]

there is another major difference between Bundler and SGenshi.

Bundler requires a mapping in Metadata, while SGenshi applies to all clients. so the grouping logic you might put in Metadata needs to be translated in py:if in the SGenshi bundle.

but I think you are right to think regular bundler grouping should be supported everywhere relevant. they would also be useful in Decision plugin, as stated in bug #664. Maybe if plugins would inherit of each other?

[solj]

Replying to Martin Schwier <[email protected]…>:

Sorry, my fault: There is no problem with bcfg2-repo-validate.

But it would be really nice if we could use the <Group name='..'></Group> Tags also in genshi bundles in the future. I think this would be easier to read and more consistent with normal bundles. So converting from a normal bundle to a genshi bundle would be just a matter of renaming it to *.genshi and adding the xmlns:py attribute.

In my opinion it would be even better if all *.xml bundle would be processed by genshi, so the user don't has to differentiate between the two formats.

I spoke with Narayan about this and I think we agree that this is probably not a good idea. Is there something you are having trouble expressing using the genshi control structures?

From IRC conversation: 09:13 < solj> desai: what do you think about ticket #813 09:16 < desai> i think it is not a good idea, from a design perspective 09:16 < desai> if we start to merge the bundle syntax with the genshi syntax, we will end up with a weird amalgamation that we need to write all of the doc for, and we'll need to make sense of merging different control flow mechanisms 09:16 < solj> yeah, i was thinking that the current way of just calling out to genshi is _much_ simpler than if we had to pre or post-process that 09:17 < desai> yeah 09:17 < desai> and it is scalable to other templating systems as well 09:17 < desai> s/scalable/portable/ 09:17 < bcfg2gozerbot> desai meant: and it is portable to other templating systems as well

[solj]

Whoops trac formatting threw that off...

09:13 < solj> desai: what do you think about ticket #813
09:16 < desai> i think it is not a good idea, from a design perspective
09:16 < desai> if we start to merge the bundle syntax with the genshi syntax, we will end up with a weird amalgamation that we need to write all of the doc for, and we'll need to make sense of merging different control flow mechanisms
09:16 < solj> yeah, i was thinking that the current way of just calling out to genshi is _much_ simpler than if we had to pre or post-process that
09:17 < desai> yeah
09:17 < desai> and it is scalable to other templating systems as well
09:17 < desai> s/scalable/portable/
09:17 < bcfg2gozerbot> desai meant: and it is portable to other templating systems as well

[Martin Schwier <…>]

I understand that you don't want to mix up the bundle syntax and the genshi syntax so that Bundler doesn't depend on genshi.

But why are the *.genshi files not processed by genshi and than handed out to the Bundler plugin as if they were normal xml bundles? So we could use the grouping in genshi templates.

From a user perspective it is hard to understand having to use two very different syntaxes in the Bundle, especially if you can't use a normal xml bundle together with a genshi bundle of the same name.

I'll give you a real world example from our deployment: We have a number of servers with exactly the same purpose which is described in a normal xml bundle file. Now there is one exception: One of them should run a special cron job, that must not exist on the others. Now I want to extend the (rather complex) bundle to contain the cronjob, but only for one specify hostname. I have to rewrite the entire bundle to the genshi syntax to do that. As there is much grouping in the bundle, in genshi syntax this is much worse readable than in bundle syntax.

[desai]

I really don't think this is going end up being workable. The Bundler syntax is really orthogonal to the way things are done in genshi bundles. Once it is worthwhile going with the superset of functionality in genshi bundles, there will need to be a bit of reworking on the bundle. Sorry.

[solj]

This functionality was added by Chris St. Pierre in 88d41171dc7c80a7be92689a59347c0f984562dc.