> <services> > <service name="service1"> > <scripts> > <script href="...."></script> > <script> > <contents><![CDATA[ > #!/bin/bash > ... > ]]</contents> > </script> > </scripts> > <parameter type="string" name="redmine_admin"> > <value>#{admin_user}</value> > </parameter> > <return name="http_port"/> > </service> > </services> I was talking with asalkeld about this recently, and one of the things he mentioned is that the XML for services probably needs to include information about 'how to start and stop the service', since there may be different ways to do so.

Is that what you're referring to via the<script> tag? If so, what does it mean for the script to be referred to via an href? Or would the href there always be a local filesystem reference? <contents> I would assume then is optional, since the script being used to start/stop the service might be pre-installed (it could be a standard lsb init script or a resource agent installed with the Matahari Services Agent) Just some thoughts... As you get into the services definition, just make sure to keep sdake/asalkeld/beekhof in the loop since they can probably be of assistance here since we deal with services all the time in other HA contexts :) Cheers, Perry

On Wed, 2011-06-08 at 14:59 +0200, Andrew Beekhof wrote: > On 06/03/2011 05:57 PM, Perry Myers wrote: >>> <services> >>> <service name="service1"> >>> <scripts> >>> <script href="...."></script> >>> <script> >>> <contents><![CDATA[ >>> #!/bin/bash >>> ... >>> ]]</contents> >>> </script> >>> </scripts> >>> <parameter type="string" name="redmine_admin"> >>> <value>#{admin_user}</value> >>> </parameter> >>> <return name="http_port"/> >>> </service> >>> </services> >> >> I was talking with asalkeld about this recently, and one of the things >> he mentioned is that the XML for services probably needs to include >> information about 'how to start and stop the service', since there may >> be different ways to do so. > > Could someone expand on this? Does this not cover it? https://fedorahosted.org/pipermail/aeolus-devel/2011-June/002071.html Perhaps the confusion here is over the term "service" We're not using that term here to mean an init script It is simply a boot-time configuration script which can do everything from changing some config files, installing some packages, enabling some init services etc. (Yes, I think "service" is a poor name for this)

On 06/08/2011 04:16 PM, Mark McLoughlin wrote: > On Wed, 2011-06-08 at 14:59 +0200, Andrew Beekhof wrote: >> On 06/03/2011 05:57 PM, Perry Myers wrote: >>>> <services> >>>> <service name="service1"> >>>> <scripts> >>>> <script href="...."></script> >>>> <script> >>>> <contents><![CDATA[ >>>> #!/bin/bash >>>> ... >>>> ]]</contents> >>>> </script> >>>> </scripts> >>>> <parameter type="string" name="redmine_admin"> >>>> <value>#{admin_user}</value> >>>> </parameter> >>>> <return name="http_port"/> >>>> </service> >>>> </services> >>> >>> I was talking with asalkeld about this recently, and one of the things >>> he mentioned is that the XML for services probably needs to include >>> information about 'how to start and stop the service', since there may >>> be different ways to do so. >> >> Could someone expand on this? > > Does this not cover it? > > https://fedorahosted.org/pipermail/aeolus-devel/2011-June/002071.html > > Perhaps the confusion here is over the term "service" > > We're not using that term here to mean an init script > > It is simply a boot-time configuration script which can do everything > from changing some config files, installing some packages, enabling > some init services etc. > > (Yes, I think "service" is a poor name for this) wow, yes, that is an exceedingly bad name What are we going to call true services later in this XML?

I've got Deployable with 3 Assemblies, and I want to monitor specific services/daemons for availability (a web server, a database, etc) The template defines things like "install httpd on this assembly" and the build/boot 'services' may do things like "configure httpd to run on the assembly", but nowhere is there a specification for * what daemons/services to I continually monitor on the running VM? * what script do I use to monitor that daemon/service? + by default might be an init script on Linux, but could also be a Resource Agent + By default would be 'net status' command on Windows, but might need a different command for certain applications So it seems like what we need are 3 things: * build time configuration scripts (called 'services' already) * post-boot configuration scripts (called 'services' already) * runtime services that need to be monitored for availability + this could be called a service or a resource, so if we want to differentiate here we could just use the term resource which is what it's called in most cluster stacks anyhow)

gOn Thu, 2011-06-09 at 08:45 -0400, Perry Myers wrote: > I've got Deployable with 3 Assemblies, and I want to monitor specific > services/daemons for availability (a web server, a database, etc) > > The template defines things like "install httpd on this assembly" and > the build/boot 'services' may do things like "configure httpd to run on > the assembly", but nowhere is there a specification for > > * what daemons/services to I continually monitor on the running VM? > * what script do I use to monitor that daemon/service? > + by default might be an init script on Linux, but could also be a > Resource Agent > + By default would be 'net status' command on Windows, but might need > a different command for certain applications > > So it seems like what we need are 3 things: > > * build time configuration scripts (called 'services' already) > * post-boot configuration scripts (called 'services' already) > * runtime services that need to be monitored for availability > + this could be called a service or a resource, so if we want to > differentiate here we could just use the term resource which is > what it's called in most cluster stacks anyhow) I've never heard runtime system service availability monitoring discussed in the context of deployables or templates before now. Am I missing some context here?

Cheers, Mark. _______________________________________________ aeolus-devel mailing list aeolus-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel

On 06/09/2011 10:58 AM, Steven Dake wrote: > On 06/09/2011 05:56 AM, Mark McLoughlin wrote: >>> gOn Thu, 2011-06-09 at 08:45 -0400, Perry Myers wrote: >>>>> I've got Deployable with 3 Assemblies, and I want to monitor specific >>>>> services/daemons for availability (a web server, a database, etc) >>>>> >>>>> The template defines things like "install httpd on this assembly" and >>>>> the build/boot 'services' may do things like "configure httpd to run on >>>>> the assembly", but nowhere is there a specification for >>>>> >>>>> * what daemons/services to I continually monitor on the running VM? >>>>> * what script do I use to monitor that daemon/service? >>>>> + by default might be an init script on Linux, but could also be a >>>>> Resource Agent >>>>> + By default would be 'net status' command on Windows, but might need >>>>> a different command for certain applications >>>>> >>>>> So it seems like what we need are 3 things: >>>>> >>>>> * build time configuration scripts (called 'services' already) >>>>> * post-boot configuration scripts (called 'services' already) >>>>> * runtime services that need to be monitored for availability >>>>> + this could be called a service or a resource, so if we want to >>>>> differentiate here we could just use the term resource which is >>>>> what it's called in most cluster stacks anyhow) >>> >>> I've never heard runtime system service availability monitoring >>> discussed in the context of deployables or templates before now. >>> >>> Am I missing some context here? >>> > Active monitoring of services, assemblies, and deployables is a critical > feature... > > Have a look at: > > http://www.pacemaker-cloud.org > I.e. Steven should be able to add an HA 'service' descriptor to assemblies and deployable indicating this deployable is HA or conforms to one of the policies on slide 28 of the deck at the link.

I.e. once the info is there for post boot, he should be able to define his service types and then add in the testing of his HA pieces. Steve also needs the DeltaCloudAPI integrated onto Conductor. Carl. _______________________________________________ aeolus-devel mailing list aeolus-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel

On Wed, 2011-06-08 at 14:59 +0200, Andrew Beekhof wrote: > On 06/03/2011 05:57 PM, Perry Myers wrote: >>> <services> >>> <service name="service1"> >>> <scripts> >>> <script href="...."></script> >>> <script> >>> <contents><![CDATA[ >>> #!/bin/bash >>> ... >>> ]]</contents> >>> </script> >>> </scripts> >>> <parameter type="string" name="redmine_admin"> >>> <value>#{admin_user}</value> >>> </parameter> >>> <return name="http_port"/> >>> </service> >>> </services> >> >> I was talking with asalkeld about this recently, and one of the things >> he mentioned is that the XML for services probably needs to include >> information about 'how to start and stop the service', since there may >> be different ways to do so. > > Could someone expand on this? Does this not cover it? https://fedorahosted.org/pipermail/aeolus-devel/2011-June/002071.html

Perhaps the confusion here is over the term "service"

We're not using that term here to mean an init script It is simply a boot-time configuration script which can do everything from changing some config files, installing some packages, enabling some init services etc. (Yes, I think "service" is a poor name for this)

On 06/03/11 - 10:28:09AM, Scott Seago wrote: > So between Mark's earlier writeup and > http://www.aeolusproject.org/page/Audrey_Overview I've come up with some > initial ideas around what to expect in a Deployable definition XML file. > > The first iteration of this (which is all we'll support in the context > of this sprint) will not support parameters, return values, or services > (i.e. all of the audrey-oriented configuration bits). For this first > iteration, a deployable simply has a name, a description, and a list of > embedded assemblies, each of which includes a name, a hardware profile, > and an image (or image build) reference: > > <deployable name="Redmine"> > <description>Redmine is a web-based project management > application</description> > <assemblies> > <assembly name="frontend" hwp="small"> > <image id="11abf870-894c-4336-bc9f-37904c394924"> > </image> > </assembly> > <assembly name="backend" hwp="medium"> > <image id="11abf870-894c-4336-bc9f-37904c394924" build="be2a8e6"> > </image> > </assembly> > </assemblies> > </deployable> Right. Going back and reading Mark's earlier proposals here, I think we should start off simply here and just embed the assemblies in the deployables for now. We can always go back later and add in the "references" to external assemblies. > > The next step will be to build in support for the audrey config bits -- > which brings in parameters, services, and return values. Here's an > example of that -- this is a lot more preliminary, as I'm still not > entirely clear on the interactions of the various levels of params, etc, > but what follows may at least be a starting point for discussion: > > <deployable name="Redmine"> > <description>Redmine is a web-based project management > application</description> > <assemblies> > <assembly name="frontend" hwp="small"> > <image id="11abf870-894c-4336-bc9f-37904c394924"> > <parameter type="string" name="redmine_admin"> > <value>#{admin_user}</value> > </parameter> > <return name="http_port"/> > </image> > <services> > <service name="service1"> > <scripts> > <script href="...."></script> > <script> > <contents><![CDATA[ > #!/bin/bash > ... > ]]</contents>

One thing I suggest here is a type field for the contents, i.e. <contents type='base64'> That way, you can drop the CDATA completely, and this also allows for injecting binary files (base64 encoded, of course).

On 06/03/11 - 10:28:09AM, Scott Seago wrote: > So between Mark's earlier writeup and > http://www.aeolusproject.org/page/Audrey_Overview I've come up with some > initial ideas around what to expect in a Deployable definition XML file. > > The first iteration of this (which is all we'll support in the context > of this sprint) will not support parameters, return values, or services > (i.e. all of the audrey-oriented configuration bits). For this first > iteration, a deployable simply has a name, a description, and a list of > embedded assemblies, each of which includes a name, a hardware profile, > and an image (or image build) reference: > > <deployable name="Redmine"> > <description>Redmine is a web-based project management > application</description> > <assemblies> > <assembly name="frontend" hwp="small"> > <image id="11abf870-894c-4336-bc9f-37904c394924"> > </image> > </assembly> > <assembly name="backend" hwp="medium"> > <image id="11abf870-894c-4336-bc9f-37904c394924" build="be2a8e6"> > </image> > </assembly> > </assemblies> > </deployable> Right. Going back and reading Mark's earlier proposals here, I think we should start off simply here and just embed the assemblies in the deployables for now. We can always go back later and add in the "references" to external assemblies. > > The next step will be to build in support for the audrey config bits -- > which brings in parameters, services, and return values. Here's an > example of that -- this is a lot more preliminary, as I'm still not > entirely clear on the interactions of the various levels of params, etc, > but what follows may at least be a starting point for discussion: > > <deployable name="Redmine"> > <description>Redmine is a web-based project management > application</description> > <assemblies> > <assembly name="frontend" hwp="small"> > <image id="11abf870-894c-4336-bc9f-37904c394924"> > <parameter type="string" name="redmine_admin"> > <value>#{admin_user}</value> > </parameter> > <return name="http_port"/> > </image> > <services> > <service name="service1"> > <scripts> > <script href="...."></script> > <script> > <contents><![CDATA[ > #!/bin/bash > ... > ]]</contents> One thing I suggest here is a type field for the contents, i.e. <contents type='base64'> That way, you can drop the CDATA completely, and this also allows for injecting binary files (base64 encoded, of course).

-- Chris Lalancette _______________________________________________ aeolus-devel mailing list aeolus-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel

<deployable name="Redmine"> <description>Redmine is a web-based project management application</description> <assemblies> <assembly name="frontend" hwp="small"> <image id="11abf870-894c-4336-bc9f-37904c394924"> <parameter type="string" name="redmine_admin"> <value>#{admin_user}</value> </parameter>

See: https://fedorahosted.org/pipermail/aeolus-devel/2011-May/001640.html A <value> element of a parameter or return may use Ruby's string interpolation to reference other parameter or return values e.g. <return> <description>URL of the Redmine project management system</description> <value>http://#{frontend.ip_address}:#{frontend.http_port}/</value> </return> or: <params> <param> <name>url</name> <value>http://#{hostname}:#{http_port + 100}/redmine/</value> </param> </params> Compare to Cloud Formations "intrinsic functions": http://docs.amazonwebservices.com/AWSCloudFormation/latest/UserGuide/inde... I hate the idea of adding a macro language for this, that's why I suggested the string interpolation approach

So between Mark's earlier writeup and http://www.aeolusproject.org/page/Audrey_Overview I've come up with some initial ideas around what to expect in a Deployable definition XML file. The first iteration of this (which is all we'll support in the context of this sprint) will not support parameters, return values, or services (i.e. all of the audrey-oriented configuration bits). For this first iteration, a deployable simply has a name, a description, and a list of embedded assemblies, each of which includes a name, a hardware profile, and an image (or image build) reference: <deployable name="Redmine"> <description>Redmine is a web-based project management application</description> <assemblies> <assembly name="frontend" hwp="small"> <image id="11abf870-894c-4336-bc9f-37904c394924"> </image> </assembly> <assembly name="backend" hwp="medium"> <image id="11abf870-894c-4336-bc9f-37904c394924" build="be2a8e6"> </image> </assembly> </assemblies> </deployable> The next step will be to build in support for the audrey config bits -- which brings in parameters, services, and return values. Here's an example of that -- this is a lot more preliminary, as I'm still not entirely clear on the interactions of the various levels of params, etc, but what follows may at least be a starting point for discussion: <deployable name="Redmine"> <description>Redmine is a web-based project management application</description> <assemblies> <assembly name="frontend" hwp="small"> <image id="11abf870-894c-4336-bc9f-37904c394924"> <parameter type="string" name="redmine_admin"> <value>#{admin_user}</value> </parameter> <return name="http_port"/> </image> <services> <service name="service1"> <scripts> <script href="...."></script> <script> <contents><![CDATA[ #!/bin/bash ... ]]</contents> </script> </scripts> <parameter type="string" name="redmine_admin"> <value>#{admin_user}</value> </parameter> <return name="http_port"/> </service> </services> </assembly> <assembly name="frontend" hwp="medium"> <image id="11abf870-894c-4336-bc9f-37904c394924" version="be2a8e6"> ... </image> </assembly> </assemblies> <parameter type="string" name="admin_user"> <description>Administrator's username</description> <value>admin</value> </parameter> <return name="url"> <description>URL of the Redmine project management system</description> <value>http://#{frontend.ip_address}:#{frontend.http_port}/</value> </return> </deployable> _______________________________________________ aeolus-devel mailing list aeolus-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel

On 06/08/2011 03:28 PM, Joseph VLcek wrote: > On Fri, 2011-06-03 at 10:28 -0400, Scott Seago wrote: >> So between Mark's earlier writeup and >> http://www.aeolusproject.org/page/Audrey_Overview I've come up with some >> initial ideas around what to expect in a Deployable definition XML file. >> >> The first iteration of this (which is all we'll support in the context >> of this sprint) will not support parameters, return values, or services >> (i.e. all of the audrey-oriented configuration bits). For this first >> iteration, a deployable simply has a name, a description, and a list of >> embedded assemblies, each of which includes a name, a hardware profile, >> and an image (or image build) reference: >> >> <deployable name="Redmine"> >> <description>Redmine is a web-based project management >> application</description> >> <assemblies> >> <assembly name="frontend" hwp="small"> >> <image id="11abf870-894c-4336-bc9f-37904c394924"> >> </image> >> </assembly> >> <assembly name="backend" hwp="medium"> >> <image id="11abf870-894c-4336-bc9f-37904c394924" build="be2a8e6"> >> </image> >> </assembly> >> </assemblies> >> </deployable> >> >> The next step will be to build in support for the audrey config bits -- >> which brings in parameters, services, and return values. Here's an >> example of that -- this is a lot more preliminary, as I'm still not >> entirely clear on the interactions of the various levels of params, etc, >> but what follows may at least be a starting point for discussion: >> >> <deployable name="Redmine"> >> <description>Redmine is a web-based project management >> application</description> >> <assemblies> >> <assembly name="frontend" hwp="small"> >> <image id="11abf870-894c-4336-bc9f-37904c394924"> >> <parameter type="string" name="redmine_admin"> >> <value>#{admin_user}</value> >> </parameter> >> <return name="http_port"/> >> </image> >> <services> >> <service name="service1"> >> <scripts> >> <script href="...."></script> >> <script> >> <contents><![CDATA[ >> #!/bin/bash >> ... >> ]]</contents> >> </script> >> </scripts> >> <parameter type="string" name="redmine_admin"> >> <value>#{admin_user}</value> >> </parameter> >> <return name="http_port"/> >> </service> >> </services> >> </assembly> >> <assembly name="frontend" hwp="medium"> >> <image id="11abf870-894c-4336-bc9f-37904c394924" version="be2a8e6"> >> ... >> </image> >> </assembly> >> </assemblies> >> <parameter type="string" name="admin_user"> >> <description>Administrator's username</description> >> <value>admin</value> >> </parameter> >> <return name="url"> >> <description>URL of the Redmine project management system</description> >> <value>http://#{frontend.ip_address}:#{frontend.http_port}/</value> >> </return> >> </deployable> >> >> >> _______________________________________________ >> aeolus-devel mailing list >> aeolus-devel(a)lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/aeolus-devel > I have a suggestion which I realize may go against what a cloud provider > is supposed to do but I'll toss it out anyway. > > I think it might be valuable if we could leave the door open to allow > for specifying that a service is to only run on a given provider or set > of providers. > > In playing with RHEV-m 2.2 it was necessary to have some special > processing to get Audrey test bits to be stood up , although only a > kludge. This made me realize that perhaps it would be valuable to allow > for a Cloud Provider(S) qualifier for each service. > > I may only be to manage boundary cases and it might not ever be > necessary but it might be good to make provisions for it. > > Do others see this as potentially valuable? > > Am I missing something? > > Thoughts? I would be more comfortable with a section in the service definition which had provider specifics or excludes if applicable, than to make it a top level concept. I can imagine their could be provider specifics for some services, especially around config. Carl.