Sorting?
Do you mean like namespacing them based on OS? (I wouldn't call that sorting, but I remember that discussion).
The latter is problematic, and I can explain if needed.
I was thinking of separating snippets by breed they're meant for, so /var/lib/cobbler/snippets is the base directory.
the current pre_install_network_config could then become redhat/pre/network_config for example
And Debian or any other distro could have it's own snippets that could live under their respective breeds.
But yes, this is problematic because moving snippets around breaks people. It's just my opinion that sooner or later we'll need more structure in that directory. If we're going to ship a cobbler version that takes a little effort to upgrade to anyway, then it would be a good moment to introduce such a change as well.
-Jasper
I understand adding an optional feature to search such a path for snippets, but I think it would be entirely inappropriate to force users to adopt this strategy.
I moved to cobbler specifically to avoid redundant kickstart files. I write most of my snippets carefully to make sure the same snippet can be used under different distributions and releases if necessary to avoid maintaining redundant pieces of "code". Even when it comes to syntax or keyword differences between different versions of kickstart, I keep the redundant functionality in the same file with if/else statements so when I'm making a change for one distribution I won't forget to update the same code for the others, and as a result, every bug fix or update I make gets immediately inherited by all of our affected profiles, not just one distribution or version.
Bryan Schneiders bschneiders@woti.com 301-562-1900 ext 305
Jasper Capel wrote:
Sorting?
Do you mean like namespacing them based on OS? (I wouldn't call that sorting, but I remember that discussion).
The latter is problematic, and I can explain if needed.
I was thinking of separating snippets by breed they're meant for, so /var/lib/cobbler/snippets is the base directory.
the current pre_install_network_config could then become redhat/pre/network_config for example
And Debian or any other distro could have it's own snippets that could live under their respective breeds.
But yes, this is problematic because moving snippets around breaks people. It's just my opinion that sooner or later we'll need more structure in that directory. If we're going to ship a cobbler version that takes a little effort to upgrade to anyway, then it would be a good moment to introduce such a change as well.
-Jasper
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
On 05/15/2009 12:01 AM, Bryan Schneiders wrote:
I understand adding an optional feature to search such a path for snippets, but I think it would be entirely inappropriate to force users to adopt this strategy.
Oh of course, I agree. I'm just proposing a better way to sort the ones we ship. since we're shipping more and more lately. And when contributions for other distributions come (maybe a debian equivalent for the current network config stuff, for example), I just thought it would be nice to have it clear exactly what's meant for what. You could still use whatever you like, and this wouldn't prevent you from using any snippet in any kickstart, I wasn't talking about splitting up namespaces in cheetah or anything.
However, the pain it would cause is that our shipped snippets are suddenly somewhere else under /var/lib/cobbler/snippets, and that could break existing templates, which would have to reference the snippets at their new location, so this is the downside. If people don't think it's worth it, than that's fine by me as well. :)
-Jasper
On Thu, May 14, 2009 at 3:08 PM, Jasper Capel capel@stone-it.com wrote:
On 05/15/2009 12:01 AM, Bryan Schneiders wrote:
I understand adding an optional feature to search such a path for snippets, but I think it would be entirely inappropriate to force users to adopt this strategy.
Oh of course, I agree. I'm just proposing a better way to sort the ones we ship. since we're shipping more and more lately. And when contributions for other distributions come (maybe a debian equivalent for the current network config stuff, for example), I just thought it would be nice to have it clear exactly what's meant for what. You could still use whatever you like, and this wouldn't prevent you from using any snippet in any kickstart, I wasn't talking about splitting up namespaces in cheetah or anything.
I agree and disagree with you Jasper. In theory, the idea is fantastic. But the problems are somewhat obvious. Why not just include some sort of comment that says what "distribution-type" it is written for? If you wanted to be real crazy, make a machine readable magic comment so cobbler could (potentially) warn if you are using a debian snippet that hasn't been modified with a --breed=redhat host or whatnot?
Not that I'm a super huge fan of magic comments, but it could address a bit of both sides with less cons perhaps. An example would be the keep_ssh_keys snippet I submitted that uses "list-harddrives". With a fair amount of work list-harddrives could be removed and it could work on any generic distro. I chose to implement it for the platform we deploy however so list-harddrives is "good enough TM". Just another idea for you to chew on.
Jeff Schroeder wrote:
On Thu, May 14, 2009 at 3:08 PM, Jasper Capel capel@stone-it.com wrote:
On 05/15/2009 12:01 AM, Bryan Schneiders wrote:
I understand adding an optional feature to search such a path for snippets, but I think it would be entirely inappropriate to force users to adopt this strategy.
Oh of course, I agree. I'm just proposing a better way to sort the ones we ship. since we're shipping more and more lately. And when contributions for other distributions come (maybe a debian equivalent for the current network config stuff, for example), I just thought it would be nice to have it clear exactly what's meant for what. You could still use whatever you like, and this wouldn't prevent you from using any snippet in any kickstart, I wasn't talking about splitting up namespaces in cheetah or anything.
I agree and disagree with you Jasper. In theory, the idea is fantastic. But the problems are somewhat obvious. Why not just include some sort of comment that says what "distribution-type" it is written for? If you wanted to be real crazy, make a machine readable magic comment so cobbler could (potentially) warn if you are using a debian snippet that hasn't been modified with a --breed=redhat host or whatnot?
Not that I'm a super huge fan of magic comments, but it could address a bit of both sides with less cons perhaps. An example would be the keep_ssh_keys snippet I submitted that uses "list-harddrives". With a fair amount of work list-harddrives could be removed and it could work on any generic distro. I chose to implement it for the platform we deploy however so list-harddrives is "good enough TM". Just another idea for you to chew on
Moving them is possible -- If we move the snippets the RPM that moves them must forever carry cruft to symlink the new ones into the old names.
I'd like to see someone actually contribute some cross-distro snippets before we undertake that need though.
--Michael
Moving them is possible -- If we move the snippets the RPM that moves them must forever carry cruft to symlink the new ones into the old names.
I'd like to see someone actually contribute some cross-distro snippets before we undertake that need though.
I always say no time like the present, it's not going to get easier in the future.
It is possible that we could reorganize snippets by creating the new ones in subdirectories and not touch the existing ones, that way people could start migrating their kickstarts to the ones in subdirs.
One thing to consider is the fact that people (like myself) may already have created subdirectories for sorting things out, so there could be some conflict there.
James Cammarata wrote:
Moving them is possible -- If we move the snippets the RPM that moves them must forever carry cruft to symlink the new ones into the old names.
I'd like to see someone actually contribute some cross-distro snippets before we undertake that need though.
I always say no time like the present, it's not going to get easier in the future.
It is possible that we could reorganize snippets by creating the new ones in subdirectories and not touch the existing ones, that way people could start migrating their kickstarts to the ones in subdirs.
One thing to consider is the fact that people (like myself) may already have created subdirectories for sorting things out, so there could be some conflict there.
There's a lot going on with the release at the moment, I don't want to make more chaos than we need to for this.
Let's do this for 2.2.
--Michael
And another completely different angle would be to try and make the snippets multi-distro. That is also doable but might require us writing a KVM based test harness to not break things. I've done this before and it is totally doable for the smart people on this list.
An multiconditional if statement that looked for /etc/redhat-release, / etc/lsb-release, /etc/debian_version, or /etc/SuSE-release would cover all of the cobbler supported distributions right now.
This is a bit more work, but has the benefit of not canging anything and not needing symlink hacks in the rpm %post.
Sent from my iPhone
On May 14, 2009, at 5:56 PM, Michael DeHaan mdehaan@redhat.com wrote:
Jeff Schroeder wrote:
On Thu, May 14, 2009 at 3:08 PM, Jasper Capel capel@stone-it.com wrote:
On 05/15/2009 12:01 AM, Bryan Schneiders wrote:
I understand adding an optional feature to search such a path for snippets, but I think it would be entirely inappropriate to force users to adopt this strategy.
Oh of course, I agree. I'm just proposing a better way to sort the ones we ship. since we're shipping more and more lately. And when contributions for other distributions come (maybe a debian equivalent for the current network config stuff, for example), I just thought it would be nice to have it clear exactly what's meant for what. You could still use whatever you like, and this wouldn't prevent you from using any snippet in any kickstart, I wasn't talking about splitting up namespaces in cheetah or anything.
I agree and disagree with you Jasper. In theory, the idea is fantastic. But the problems are somewhat obvious. Why not just include some sort of comment that says what "distribution-type" it is written for? If you wanted to be real crazy, make a machine readable magic comment so cobbler could (potentially) warn if you are using a debian snippet that hasn't been modified with a --breed=redhat host or whatnot?
Not that I'm a super huge fan of magic comments, but it could address a bit of both sides with less cons perhaps. An example would be the keep_ssh_keys snippet I submitted that uses "list-harddrives". With a fair amount of work list-harddrives could be removed and it could work on any generic distro. I chose to implement it for the platform we deploy however so list-harddrives is "good enough TM". Just another idea for you to chew on
Moving them is possible -- If we move the snippets the RPM that moves them must forever carry cruft to symlink the new ones into the old names.
I'd like to see someone actually contribute some cross-distro snippets before we undertake that need though.
--Michael
On 05/15/2009 06:28 AM, Jeff Schroeder wrote:
And another completely different angle would be to try and make the snippets multi-distro. That is also doable but might require us writing a KVM based test harness to not break things. I've done this before and it is totally doable for the smart people on this list.
I thought of that, but some snippets are pretty complex as they are already. I'd hate to have to increase the complexity in post_install_network_config for example, so I'd rather have one for each distro as this would save us from the very likely scenario that while someone's fixing debian functionality, he (unintentionally of course :P) breaks it for Red Hat. And the more distros one snippet is going to support, the harder it gets.
An multiconditional if statement that looked for /etc/redhat-release, / etc/lsb-release, /etc/debian_version, or /etc/SuSE-release would cover all of the cobbler supported distributions right now.
This is a bit more work, but has the benefit of not canging anything and not needing symlink hacks in the rpm %post.
Sent from my iPhone
Jasper Capel wrote:
On 05/15/2009 06:28 AM, Jeff Schroeder wrote:
And another completely different angle would be to try and make the snippets multi-distro. That is also doable but might require us writing a KVM based test harness to not break things. I've done this before and it is totally doable for the smart people on this list.
I thought of that, but some snippets are pretty complex as they are already. I'd hate to have to increase the complexity in post_install_network_config for example, so I'd rather have one for each distro as this would save us from the very likely scenario that while someone's fixing debian functionality, he (unintentionally of course :P) breaks it for Red Hat. And the more distros one snippet is going to support, the harder it gets.
Complexity can be reduced in the snipppet code merely by having them include other snippets with implementation specific details in them. Even if the top level snippets are just "if redhat include", that's ok.
That all being said /way/ too much is going in already, so I don't want to dot his /now/ since every fork in the road we take there is more to polish up and test. At this point, we're not even done with the five or so things we've already started ... easier field additions, Django, and network objects (which all need a fair amount of work yet) would be plenty.
--Michael
cobbler-devel@lists.fedorahosted.org