On Fri, Aug 18, 2017 at 4:22 PM, Jiří Stránský <ji...@redhat.com> wrote:
> On 18.8.2017 13:18, Sofer Athlan-Guyot wrote: > >> Hi, >> >> We may have missing packages when the user is adding a new role to its >> roles_data file and the base image is coming from previous version. >> >> The workflow would be this one: >> - install newton >> - upgrade to ocata >> - add collectd to roles_data and redeploy the stack >> >> For instance if one is adding >> OS::TripleO::Services::Collectdservices::collectd in an ocata env coming >> from an upgraded newton env, he/she won't have the necessary packages >> (for instance collectd-disk). The puppet manifest will fail has the >> package is missing and puppet doesn't install package. The upgrade >> task[1] is useless as the new role wasn't added during the upgrade but >> after. >> > > 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. > > 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). 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 https://github.com/openstack/tripleo-puppet-elements pkg-maps? ). > >> I don't see any easy way to solve this. Basically we need a way to keep >> in sync base image between release without using the upgrade_tasks, >> maybe in the tripleo-package one ? >> > > 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. > > 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. > > yeah based on what you said, am thinking https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/pkg-map for example , or some parsing of the combined element pkg maps... :/ still likely need some tooling to do that though thanks, marios > >> This shouldn't be a problem with container, but everything before pike >> is affected. >> > > 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. > > Jirka > > >> Originially seen there[2] >> >> [1] https://github.com/openstack/tripleo-heat-templates/blob/sta >> ble/ocata/puppet/services/metrics/collectd.yaml#L130..L134 >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1455065 >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
