<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 4:22 PM, Jiří Stránský <span dir="ltr"><<a href="mailto:jistr@redhat.com" target="_blank">jistr@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 18.8.2017 13:18, Sofer Athlan-Guyot wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
We may have missing packages when the user is adding a new role to its<br>
roles_data file and the base image is coming from previous version.<br>
<br>
The workflow would be this one:<br>
  - install newton<br>
  - upgrade to ocata<br>
  - add collectd to roles_data and redeploy the stack<br>
<br>
For instance if one is adding<br>
OS::TripleO::Services::Collect<wbr>dservices::collectd in an ocata env coming<br>
from an upgraded newton env, he/she won't have the necessary packages<br>
(for instance collectd-disk).  The puppet manifest will fail has the<br>
package is missing and puppet doesn't install package.  The upgrade<br>
task[1] is useless as the new role wasn't added during the upgrade but<br>
after.<br>
</blockquote>
<br></span>
Right, but the package could be added during the upgrade. The upgrade_tasks could/should make the set of installed overcloud RPMs on par with the overcloud-full image of the respective release, ideally. So you'd have collectd RPMs installed always, both on freshly deployed and upgraded envs, regardless if you actually use collectd or not. We already did some package installs/uninstalls as part of upgrades and updates, but probably didn't have 100% coverage.<span class="gmail-"><br>
<br></span></blockquote><div><br></div><div>yeah +1 to this except where would those upgrade_tasks go? Taking the given example, upgrade_tasks in collectd-disk.yaml wont be executed because during the upgrade, the operator didn't have that enabled as a service (it is default off, and new so they couldn't deploy it before). </div><div><br></div><div>So we may have to use some 'central place' (this is what Sofer was advocating earlier on irc) like in the tripleo-packages.yaml and have tasks there. The problem then becomes however that we don't _know_ which services we need to download packages for? Oh.. no you're saying we can use the current release package list (e.g. do you mean from something in <a href="https://github.com/openstack/tripleo-puppet-elements">https://github.com/openstack/tripleo-puppet-elements</a> pkg-maps? ). </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I don't see any easy way to solve this.  Basically we need a way to keep<br>
in sync base image between release without using the upgrade_tasks,<br>
maybe in the tripleo-package one ?<br>
</blockquote>
<br></span>
Given that released code is affected, we may treat it as a bug that requires a minor update, and in addition to upgrade_tasks, we can add all the necessary package installs into minor update code (yum_update.sh) too. Again this shouldn't depend on what services are actually enabled, just unconditionally sync with latest content of overcloud-full image of the respective release.<br>
<br>
I guess the time consuming part will be preparing the envs that will allow comparing a fresh deploy vs. an upgraded one to get the `rpm -qa | sort` difference. Or we could try a shortcut and see what changes went into tripleo-puppet-elements in each release.<span class="gmail-"><br>
<br></span></blockquote><div><br></div><div>yeah based on what you said, am thinking <a href="https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/pkg-map">https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/pkg-map</a> for example , or some parsing of the combined element pkg maps... :/ still likely need some tooling to do that though </div><div><br></div><div>thanks, marios</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This shouldn't be a problem with container, but everything before pike<br>
is affected.<br>
</blockquote>
<br></span>
Indeed. There will still be some basic baremetal host content management as long as we're not using Atomic, but the room for potential problems will be much smaller.<br>
<br>
Jirka<span class="gmail-im gmail-HOEnZb"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Originially seen there[2]<br>
<br>
[1] <a href="https://github.com/openstack/tripleo-heat-templates/blob/stable/ocata/puppet/services/metrics/collectd.yaml#L130..L134" rel="noreferrer" target="_blank">https://github.com/openstack/t<wbr>ripleo-heat-templates/blob/sta<wbr>ble/ocata/puppet/services/metr<wbr>ics/collectd.yaml#L130..L134</a><br>
[2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1455065" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1455065</a><br>
<br>
</blockquote>
<br>
<br></span><div class="gmail-HOEnZb"><div class="gmail-h5">
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>