Ok this may seem silly, but after wading through a bunch of kickstarts today trying to find out which ones are for what.. could we standardize on a convention? We have a couple :).
I like this one:
<host type>-<os>-<os-release>-<special>
Examples. kvm-rhel-5-nfs xen-rhel-6-nohd hardware-rhel-5-xenserver hardware-rhel-5-nohd
Once we have a convention, I can go and rename stuff to meet it (maybe put the kickstarts under a git tree also?)
On Tue, 2011-03-01 at 17:13 -0700, Stephen John Smoogen wrote:
Ok this may seem silly, but after wading through a bunch of kickstarts today trying to find out which ones are for what.. could we standardize on a convention? We have a couple :).
I like this one:
<host type>-<os>-<os-release>-<special>
Examples. kvm-rhel-5-nfs xen-rhel-6-nohd hardware-rhel-5-xenserver hardware-rhel-5-nohd
Once we have a convention, I can go and rename stuff to meet it (maybe put the kickstarts under a git tree also?)
under a git, tree, sure - but do not, do not, do not, split the git tree into staging/production branches. There's no point in that for the kickstarts.
also - unless there is a compelling reason to - why don't we assume that all new builds are rhel6 - and therefore kvm?
-sv
On Tue, Mar 1, 2011 at 21:11, seth vidal skvidal@fedoraproject.org wrote:
On Tue, 2011-03-01 at 17:13 -0700, Stephen John Smoogen wrote:
Ok this may seem silly, but after wading through a bunch of kickstarts today trying to find out which ones are for what.. could we standardize on a convention? We have a couple :).
I like this one:
<host type>-<os>-<os-release>-<special>
Examples. kvm-rhel-5-nfs xen-rhel-6-nohd hardware-rhel-5-xenserver hardware-rhel-5-nohd
Once we have a convention, I can go and rename stuff to meet it (maybe put the kickstarts under a git tree also?)
under a git, tree, sure - but do not, do not, do not, split the git tree into staging/production branches. There's no point in that for the kickstarts.
also - unless there is a compelling reason to - why don't we assume that all new builds are rhel6 - and therefore kvm?
The compelling reason I see is that it will be about 6-12 months before we have converted all our el5's to el6's so its probably a good idea to keep the other naming scheme around til then. [And just in case EL7 decides to go use oracle btrfs containers.. might as well just put the name in the front so we don't get confused in 2-3 years time :).
On Tue, Mar 1, 2011 at 9:19 PM, Stephen John Smoogen smooge@gmail.com wrote:
On Tue, Mar 1, 2011 at 21:11, seth vidal skvidal@fedoraproject.org wrote:
On Tue, 2011-03-01 at 17:13 -0700, Stephen John Smoogen wrote:
Ok this may seem silly, but after wading through a bunch of kickstarts today trying to find out which ones are for what.. could we standardize on a convention? We have a couple :).
I like this one:
<host type>-<os>-<os-release>-<special>
Examples. kvm-rhel-5-nfs xen-rhel-6-nohd hardware-rhel-5-xenserver hardware-rhel-5-nohd
Once we have a convention, I can go and rename stuff to meet it (maybe put the kickstarts under a git tree also?)
under a git, tree, sure - but do not, do not, do not, split the git tree into staging/production branches. There's no point in that for the kickstarts.
also - unless there is a compelling reason to - why don't we assume that all new builds are rhel6 - and therefore kvm?
The compelling reason I see is that it will be about 6-12 months before we have converted all our el5's to el6's so its probably a good idea to keep the other naming scheme around til then. [And just in case EL7 decides to go use oracle btrfs containers.. might as well just put the name in the front so we don't get confused in 2-3 years time :).
Forgive the question if it's already in place. I haven't checked.
Are these hand-crafted kickstarts? If so, why not use Cobbler (which supports using Git to version control all of its config files already)?
I'm a big fan of being able to do 'koan --replace-self' on a system when it's time to upgrade/reprovision.
---Brett.
On Tue, 2011-03-01 at 21:23 -0800, brett lentz wrote:
On Tue, Mar 1, 2011 at 9:19 PM, Stephen John Smoogen smooge@gmail.com wrote:
On Tue, Mar 1, 2011 at 21:11, seth vidal skvidal@fedoraproject.org wrote:
On Tue, 2011-03-01 at 17:13 -0700, Stephen John Smoogen wrote:
Ok this may seem silly, but after wading through a bunch of kickstarts today trying to find out which ones are for what.. could we standardize on a convention? We have a couple :).
I like this one:
<host type>-<os>-<os-release>-<special>
Examples. kvm-rhel-5-nfs xen-rhel-6-nohd hardware-rhel-5-xenserver hardware-rhel-5-nohd
Once we have a convention, I can go and rename stuff to meet it (maybe put the kickstarts under a git tree also?)
under a git, tree, sure - but do not, do not, do not, split the git tree into staging/production branches. There's no point in that for the kickstarts.
also - unless there is a compelling reason to - why don't we assume that all new builds are rhel6 - and therefore kvm?
The compelling reason I see is that it will be about 6-12 months before we have converted all our el5's to el6's so its probably a good idea to keep the other naming scheme around til then. [And just in case EL7 decides to go use oracle btrfs containers.. might as well just put the name in the front so we don't get confused in 2-3 years time :).
Forgive the question if it's already in place. I haven't checked.
Are these hand-crafted kickstarts? If so, why not use Cobbler (which supports using Git to version control all of its config files already)?
I'm a big fan of being able to do 'koan --replace-self' on a system when it's time to upgrade/reprovision.
b/c setting up cobbler is one more piece of infrastructure we don't really need.
-sv
On Tue, Mar 1, 2011 at 22:23, brett lentz brett.lentz@gmail.com wrote:
On Tue, Mar 1, 2011 at 9:19 PM, Stephen John Smoogen smooge@gmail.com wrote:
Forgive the question if it's already in place. I haven't checked.
Are these hand-crafted kickstarts? If so, why not use Cobbler (which supports using Git to version control all of its config files already)?
I'm a big fan of being able to do 'koan --replace-self' on a system when it's time to upgrade/reprovision.
I am too, but have come to realize there are some things I have to live without :).
The main issue about cobbler is that it is way too much kitchen sink with trying to deal with dhcp/bind and other items. [That said, the one I set up at my former job is still running quite well for close to 2 years now without any intervention.]
---Brett. _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Tue, Mar 01, 2011 at 10:55:46PM -0700, Stephen John Smoogen wrote:
On Tue, Mar 1, 2011 at 22:23, brett lentz brett.lentz@gmail.com wrote:
On Tue, Mar 1, 2011 at 9:19 PM, Stephen John Smoogen smooge@gmail.com wrote:
Forgive the question if it's already in place. I haven't checked.
Are these hand-crafted kickstarts? If so, why not use Cobbler (which supports using Git to version control all of its config files already)?
I'm a big fan of being able to do 'koan --replace-self' on a system when it's time to upgrade/reprovision.
I am too, but have come to realize there are some things I have to live without :).
The main issue about cobbler is that it is way too much kitchen sink with trying to deal with dhcp/bind and other items. [That said, the one I set up at my former job is still running quite well for close to 2 years now without any intervention.]
How about The Foreman? It integrates with puppet but doesn't try to do DNS/DHCP by itself.
Chuck Anderson wrote:
How about The Foreman? It integrates with puppet but doesn't try to do DNS/DHCP by itself.
While foreman has some nice features (mainly it's puppet dashboard facilities), it's completely unacceptable for Fedora/EPEL packaging due to the bundled ruby libraries. I worked with Ohad (he's a very nice guy, I think he even works for Red Hat these days) a while back to fix up the packaging a bit, but the bundled libraries are still an ugly problem with most rails applications.
Oh, and it's ruby, which I think many in infrastructure want to avoid as much as possible -- puppet being the only notable exception.
On Wed, Mar 2, 2011 at 5:03 AM, Chuck Anderson cra@wpi.edu wrote:
On Tue, Mar 01, 2011 at 10:55:46PM -0700, Stephen John Smoogen wrote:
On Tue, Mar 1, 2011 at 22:23, brett lentz brett.lentz@gmail.com wrote:
On Tue, Mar 1, 2011 at 9:19 PM, Stephen John Smoogen smooge@gmail.com wrote:
Forgive the question if it's already in place. I haven't checked.
Are these hand-crafted kickstarts? If so, why not use Cobbler (which supports using Git to version control all of its config files already)?
I'm a big fan of being able to do 'koan --replace-self' on a system when it's time to upgrade/reprovision.
I am too, but have come to realize there are some things I have to live without :).
The main issue about cobbler is that it is way too much kitchen sink with trying to deal with dhcp/bind and other items. [That said, the one I set up at my former job is still running quite well for close to 2 years now without any intervention.]
How about The Foreman? It integrates with puppet but doesn't try to do DNS/DHCP by itself.
Cobbler doesn't require that it manages DNS or DHCP. Those are optional features, not hard requirements. At $dayjob, we're using Cobbler without the DNS and DHCP bits turned on. It just manages kickstarts and yum repos or us.
However, I think the issue of being overkill and/or being another moving part that there are few resources to maintain are both legitimate concerns.
---Brett.
infrastructure@lists.fedoraproject.org
-
brett lentz -
Chuck Anderson -
Seth Vidal -
Stephen John Smoogen -
Todd Zullinger