Modify

Ticket #813 (closed enhancement: wontfix)

Opened 13 years ago

Last modified 11 years ago

group tags in genshi bundles

Reported by: Martin Schwier <[email protected]…> Owned by: desai
Priority: minor Milestone: Bcfg2 1.2.0 Release
Component: bcfg2-server Version: 1.0
Keywords: Cc: [email protected]…, [email protected]…, [email protected]

Description

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?

Attachments

Change History

comment:1 Changed 13 years ago by 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?

comment:2 Changed 13 years ago by solj

comment:3 follow-up: ↓ 5 Changed 13 years ago by Martin Schwier <[email protected]…>

  • Cc [email protected] added
  • Priority changed from major to minor
  • Type changed from defect to enhancement
  • Milestone Bcfg2 1.1.0 Release deleted

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.

comment:4 Changed 13 years ago by somekool <[email protected]…>

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?

comment:5 in reply to: ↑ 3 Changed 13 years ago by 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

comment:6 Changed 13 years ago by 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

comment:7 Changed 13 years ago by Martin Schwier <[email protected]…>

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.

comment:8 Changed 13 years ago by dclark

comment:9 Changed 12 years ago by solj

comment:10 Changed 12 years ago by solj

  • Milestone set to Bcfg2 1.3.0 Release

comment:11 Changed 11 years ago by desai

  • Status changed from new to closed
  • Resolution set to wontfix

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.

comment:12 Changed 11 years ago by solj

  • Cc [email protected] removed
  • Milestone changed from Bcfg2 1.3.0 Release to Bcfg2 1.2.0 Release

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

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.