<p dir="ltr"></p>
<p dir="ltr">On Jul 26, 2016 10:02 PM, "Emilien Macchi" <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br>
><br>
> I would love to hear some feedback about $topic, thanks.</p>
<p dir="ltr">Ian, Rhys, Jacob - this sounds like a big step in the right direction to me, what do you guys think?</p>
<p dir="ltr">-Hugh</p>
<p dir="ltr">><br>
> On Fri, Jul 15, 2016 at 11:31 AM, Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > Some people on the field brought interesting feedback:<br>
> ><br>
> > "As a TripleO User, I would like the deployment to stop immediately<br>
> > after an resource creation failure during a step of the deployment and<br>
> > be able to easily understand what service or resource failed to be<br>
> > installed".<br>
> ><br>
> > Example:<br>
> > If during step4 Puppet tries to deploy Neutron and OVS, but OVS fails<br>
> > to start for some reasons, deployment should stop at the end of the<br>
> > step.<br>
> ><br>
> > So there are 2 things in this user story:<br>
> ><br>
> > 1) Be able to run some service validation within a step deployment.<br>
> > Note about the implementation: make the validation composable per<br>
> > service (OVS, nova, etc) and not per role (compute, controller, etc).<br>
> ><br>
> > 2) Make this information readable and easy to access and understand<br>
> > for our users.<br>
> ><br>
> > I have a proof-of-concept for 1) and partially 2), with the example of<br>
> > OVS: <a href="https://review.openstack.org/#/c/342202/">https://review.openstack.org/#/c/342202/</a><br>
> > This patch will make sure OVS is actually usable at step 4 by running<br>
> > 'ovs-vsctl show' during the Puppet catalog and if it's working, it<br>
> > will create a Puppet anchor. This anchor is currently not useful but<br>
> > could be in future if we want to rely on it for orchestration.<br>
> > I wrote the service validation in Puppet 2 years ago when doing Spinal<br>
> > Stack with eNovance:<br>
> > <a href="https://github.com/openstack/puppet-openstacklib/blob/master/manifests/service_validation.pp">https://github.com/openstack/puppet-openstacklib/blob/master/manifests/service_validation.pp</a><br>
> > I think we could re-use it very easily, it has been proven to work.<br>
> > Also, the code is within our Puppet profiles, so it's by design<br>
> > composable and we don't need to make any connection with our current<br>
> > services with some magic. Validation will reside within Puppet<br>
> > manifests.<br>
> > If you look my PoC, this code could even live in puppet-vswitch itself<br>
> > (we already have this code for puppet-nova, and some others).<br>
> ><br>
> > Ok now, what if validation fails?<br>
> > I'm testing it here: <a href="https://review.openstack.org/#/c/342205/">https://review.openstack.org/#/c/342205/</a><br>
> > If you look at /var/log/messages, you'll see:<br>
> ><br>
> > Error: /Stage[main]/Tripleo::Profile::Base::Neutron::Ovs/Openstacklib::Service_validation[openvswitch]/Exec[execute<br>
> > openvswitch validation]/returns: change from notrun to 0 failed<br>
> ><br>
> > So it's pretty clear by looking at logs that openvswitch service<br>
> > validation failed and something is wrong. You'll also notice in the<br>
> > logs that deployed stopped at step 4 since OVS is not considered to<br>
> > run.<br>
> > It's partially addressing 2) because we need to make it more explicit<br>
> > and readable. Dan Prince had the idea to use<br>
> > <a href="https://github.com/ripienaar/puppet-reportprint">https://github.com/ripienaar/puppet-reportprint</a> to print a nice report<br>
> > of Puppet catalog result (we haven't tried it yet). We could also use<br>
> > Operational Tools later to monitor Puppet logs and find Service<br>
> > validation failures.<br>
> ><br>
> ><br>
> > So this email is a bootstrap of discussion, it's open for feedback.<br>
> > Don't take my PoC as something we'll implement. It's an idea and I<br>
> > think it's worth to look at it.<br>
> > I like it for 2 reasons:<br>
> > - the validation code reside within our profiles, so it's composable by design.<br>
> > - it's flexible and allow us to test everything. It can be a bash<br>
> > script, a shell command, a Puppet resource (provider, service, etc).<br>
> ><br>
> > Thanks for reading so far,<br>
> > --<br>
> > Emilien Macchi<br>
><br>
><br>
><br>
> --<br>
> Emilien Macchi<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></p>