"Multi-System" Profile Development / Deployment

[Aaron Lippold]

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

[brett lentz]

On Tue, Nov 10, 2009 at 1:03 PM, Aaron Lippold <lippold(a)gmail.com&gt; 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.

[Patrick Nixon]

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&gt; wrote:
>  On Tue, Nov 10, 2009 at 1:03 PM, Aaron Lippold
> <lippold(a)gmail.com&gt; 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
>

[Aaron Lippold]

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&gt; 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&gt; wrote:
> > On Tue, Nov 10, 2009 at 1:03 PM, Aaron Lippold <lippold(a)gmail.com&gt; 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
>

[brett lentz]

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&gt; 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&gt; 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&gt; wrote:
> >> On Tue, Nov 10, 2009 at 1:03 PM, Aaron Lippold <lippold(a)gmail.com&gt; 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
>