5:23 p.m.
I don't really see why you'd need to "chain install", but maybe I
don't have enough information about your environment to understand.
If you leave most/all of the config work to Puppet, it shouldn't
really matter what order you provision systems. As the other systems
come up, the configs will just "start working".
Though, with the cobbler API, you could easily hook into cobbler
and/or koan and just write yourself a script to provision systems in a
particular order.
Generally, I like to use load balancers, heartbeat, or dns trickery so
that all of my configs use VIPs, floating IPs, and/or CNAMEs that
point at the server pool for a given service.
That way, each server doesn't really need to know or care about how
many servers are in the pool. This leaves me free to add and subtract
individual servers from the pool without requiring config changes.
That tends to remove some of those chicken-and-egg issues, too.
---Brett.
On Fri, Nov 13, 2009 at 2:56 PM, Aaron Lippold <lippold(a)gmail.com> wrote:
Hi,
Sorry for not being more clear. What I was really trying to get at was
the idea of grouping a set of system profiles that build out my
capability. Like when you break out our database, webserver/app and
svn server on different vm/boxes but need then to provision in order x
and use info from one box or the other to setup or configure the other
boxes.
Like the db ips / hostname or the snv ips/hostname for the webapp when
it comes up.
A chained provision as it were so the developers can make a virt prod
clone to test out features or code, etc. Then tear it down, make
changes, stand it back up again.
I think Bretts approach from above could be used if I pulled data from
puppet and cobbler and passed it along to the next install in the
chain.
Thoughts All?
Aaron
On Tue, Nov 10, 2009 at 4:35 PM, Patrick Nixon <pnixon(a)gmail.com> wrote:
> I was just playing with something similar (APP/DB and PROD/TEST)
>
> Using profile Names APP-TEST DB-PROD I used pattern tests in the
> snippets to determine what should and shouldn't be included.
>
> This let me keep one kickstart file for our typical systems.
>
> --Patrick
>
> An Example:
> #import re
> #set profilepatt= $re.compile(".*PROD.*")
> #if $profilepatt.match($profile)
> key --skip
> #end if
>
>
> On Tue, Nov 10, 2009 at 4:11 PM, brett lentz <wakko666(a)gmail.com> wrote:
>> On Tue, Nov 10, 2009 at 1:03 PM, Aaron Lippold <lippold(a)gmail.com> wrote:
>>> Hello,
>>>
>>> I was wondering if anyone had suggestion and or lessons on building
>>> and deploying a "profile set" that has multiple systems / profiles.
I
>>> would assume this would be scripting the API or a set of inherited
>>> sub-profiles. The driver / use case for this is a deployment that has
>>> three to four machines ( app, db, svn, directory ) that combine to
>>> make the total deployment. This is easy on a single profile, has
>>> anyone looked at the "multi-machine" profile case?
>>>
>>> Thanks,
>>>
>>> Aaron
>>
>> The way we do it at $DAYJOB is to have a "base" package set that is a
>> snippet used across multiple profiles, then have puppet do the
>> role-specific configuration post-install.
>>
>> ---Brett.
>> _______________________________________________
>> cobbler-devel mailing list
>> cobbler-devel(a)lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/cobbler-devel
>>
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler-devel
>
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel