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



_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

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 .

--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

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.
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

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


_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

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
>



--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
_______________________________________________
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.
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

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.

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
We waste more time by 8:00 in the morning than other companies do all
day.

_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

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 mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure