Re: [openstack-dev] [tripleo] validating overcloud config changes on a redeploy
Hi Ade, To the best of my knowledge the closest place where we do similar sequence of actions (post deployment build and append environment files to the deploy command and re-run overcloud deploy on top of an already deployed overcloud) is tripleo-upgrade. As we discussed on IRC I was reluctant to adding these kind of tests to tripleo-upgrade since it was initially created to cover only the minor update and major upgrades use cases. Nevertheless, thinking more about your use case I realized that configuration changes tests could fit quite well in tripleo-upgrade for several reasons: - we already have a mechanism[1] in place for attaching extra environment files to the deploy command - we already have tests that can be run during the stack update which applies the config changes; this could be useful to validate that configuration changes do not break the data plane(e.g to validate that a neutron config change doesn't not leave instances without networking during the stack update) - we can easily segregate the config changes plays into their own directory as we do with update/upgrade[2] and add the reusable ones in the common directory - upgrades might benefit from the config changes tests by running them in a pre/post minor update/major upgrade step and catch potential parameters changes between releases I'd like to hear what others think about this and see if there could be a better place where to host these kind of tests but personally I'm ok with adding them to tripleo-upgrade. Best regards, Marius [1] http://git.openstack.org/cgit/openstack/tripleo-upgrade/tree/tasks/upgrade/step_upgrade.yml [2] http://git.openstack.org/cgit/openstack/tripleo-upgrade/tree/tasks On Fri, Apr 27, 2018 at 11:49 AM, Ade Lee wrote: > Hi, > > Recently I starting looking at how we implement password changes in an > existing deployment, and found that there were issues. This made me > wonder whether we needed a test job to confirm that password changes > (and other config changes) are in fact executed properly. > > As far as I understand it, the way to do password changes is to - > 1) Create a yaml file containing the parameters to be changed and >their new values > 2) call openstack overcloud deploy and append -e new_params.yaml > > Note that the above steps can really describe the testing of setting > any config changes (not just passwords). > > Of course, if we do change passwords, we'll want to validate that the > config files have changed, the keystone/dbusers have been modified, the > mistral plan has been updated, services are still running etc. > > After talking with many folks, it seems there is no clear consensus > where code to do the above tasks should live. Should it be in tripleo- > upgrades, or in tripleo-validations or in a separate repo? > > Is there anyone already doing something similar? > > If we end up creating a role to do this, ideally it should be > deployment tool agnostic - usable by both infrared or quickstart or > others. > > Whats the best way to do this? > > Thanks, > Ade > > __ > 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
Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits
Thanks everyone for your trust and support. On Mon, Apr 23, 2018 at 5:35 PM, Emilien Macchi wrote: > Thanks everyone for your positive feedback. > I've updated Gerrit! > > Welcome Marius and thanks again for your hard work! > > On Mon, Apr 23, 2018 at 4:55 AM, James Slagle > wrote: >> >> On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi >> wrote: >> > Greetings, >> > >> > As you probably know mcornea on IRC, Marius Cornea has been contributing >> > on >> > TripleO for a while, specially on the upgrade bits. >> > Part of the quality team, he's always testing real customer scenarios >> > and >> > brings a lot of good feedback in his reviews, and quite often takes care >> > of >> > fixing complex bugs when it comes to advanced upgrades scenarios. >> > He's very involved in tripleo-upgrade repository where he's already >> > core, >> > but I think it's time to let him +2 on other tripleo repos for the >> > patches >> > related to upgrades (we trust people's judgement for reviews). >> > >> > As usual, we'll vote! >> > >> > Thanks everyone for your feedback and thanks Marius for your hard work >> > and >> > involvement in the project. >> >> +1 >> >> >> -- >> -- James Slagle >> -- >> >> __ >> 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 > > > > > -- > Emilien Macchi > > __ > 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
Re: [openstack-dev] [tripleo] tripleo-upgrade pike branch
On Fri, Jan 19, 2018 at 4:47 PM, John Trowbridge wrote: > > > On Fri, Jan 19, 2018 at 10:21 AM, Wesley Hayutin > wrote: >> >> Thanks Marius for sending this out and kicking off a conversation. >> >> On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea wrote: >>> >>> Hi everyone and Happy New Year! >>> >>> As the migration of tripleo-upgrade repo to the openstack namespace is >>> now complete I think it's the time to create a Pike branch to capture >>> the current state so we can use it for Pike testing and keep the >>> master branch for Queens changes. The update/upgrade steps are >>> changing between versions and the aim of branching the repo is to keep >>> the update/upgrade steps clean per branch to avoid using conditionals >>> based on release. Also tripleo-upgrade should be compatible with >>> different tools used for deployment(tripleo-quickstart, infrared, >>> manual deployments) which use different vars for the version release >>> so in case of using conditionals we would need extra steps to >>> normalize these variables. >> >> >> I understand the desire to create a branch to protect the work that has >> been done previously. >> The interesting thing is that you guys are proposing to use a branched >> ansible role with >> a branchless upstream project. I want to make sure we have enough review >> so that we don't hit issues >> in the future. Maybe that is OK, but I have at least one concern. >> >> My conern is about gating the tripleo-upgrade role and it's branches. >> When tripleo-quickstart is changed >> which is branchless we will be have to kick off a job for each >> tripleo-upgrade branch? That immediately doubles >> the load on gates. > > > I do not think CI repos should be branched. Even more than the concern Wes > brought up about a larger gate matrix. Think > about how much would need to get backported. To start you would just have > the 2 branches, but eventually you will have 3. > Likely all 3 will have slight differences in how different pieces of the > upgrade are called (otherwise why branch), so when > you need to fix something on all branches the backports have a high > potential to be non-trivial too. Once we release we expect the upgrade/update process to be stable and no changes required to the process so I expect the backports to be minimal, mostly for scenarios that we missed in testing at release time. > Release conditionals are not perfect, but I dont think compatibility is > really a major issue. Just document how to set the > release, and the different CI tools that use your role will just have to > adapt to that. >> >> >> It's extemely important to properly gate this role against the versions of >> TripleO and OSP. I see very limited >> check jobs and gate jobs on tripleo-upgrades atm. I have only found [1]. >> I think we need to see some external and internal >> jobs checking and gating this role with comments posted to changes. >> >> [1] >> https://review.rdoproject.org/jenkins/job/gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike/ >> >> >>> >>> >>> I wanted to bring this topic up for discussion to see if branching is >>> the proper thing to do here. >>> >>> Thanks, >>> Marius >>> >>> >>> __ >>> 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 > __ 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
Re: [openstack-dev] [tripleo] tripleo-upgrade pike branch
On Fri, Jan 19, 2018 at 4:21 PM, Wesley Hayutin wrote: > Thanks Marius for sending this out and kicking off a conversation. > > On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea wrote: >> >> Hi everyone and Happy New Year! >> >> As the migration of tripleo-upgrade repo to the openstack namespace is >> now complete I think it's the time to create a Pike branch to capture >> the current state so we can use it for Pike testing and keep the >> master branch for Queens changes. The update/upgrade steps are >> changing between versions and the aim of branching the repo is to keep >> the update/upgrade steps clean per branch to avoid using conditionals >> based on release. Also tripleo-upgrade should be compatible with >> different tools used for deployment(tripleo-quickstart, infrared, >> manual deployments) which use different vars for the version release >> so in case of using conditionals we would need extra steps to >> normalize these variables. > > > I understand the desire to create a branch to protect the work that has been > done previously. > The interesting thing is that you guys are proposing to use a branched > ansible role with > a branchless upstream project. I want to make sure we have enough review so > that we don't hit issues > in the future. Maybe that is OK, but I have at least one concern. > > My conern is about gating the tripleo-upgrade role and it's branches. When > tripleo-quickstart is changed > which is branchless we will be have to kick off a job for each > tripleo-upgrade branch? That immediately doubles > the load on gates. I think it would probably be the same when using multiple release conditionals, we'd still have to trigger one job/release if we wanted full coverage. > It's extemely important to properly gate this role against the versions of > TripleO and OSP. I see very limited > check jobs and gate jobs on tripleo-upgrades atm. I have only found [1]. > I think we need to see some external and internal > jobs checking and gating this role with comments posted to changes. > > [1] > https://review.rdoproject.org/jenkins/job/gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike/ > > >> >> >> I wanted to bring this topic up for discussion to see if branching is >> the proper thing to do here. >> >> Thanks, >> Marius >> >> __ >> 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 > __ 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-dev] [tripleo] tripleo-upgrade pike branch
Hi everyone and Happy New Year! As the migration of tripleo-upgrade repo to the openstack namespace is now complete I think it's the time to create a Pike branch to capture the current state so we can use it for Pike testing and keep the master branch for Queens changes. The update/upgrade steps are changing between versions and the aim of branching the repo is to keep the update/upgrade steps clean per branch to avoid using conditionals based on release. Also tripleo-upgrade should be compatible with different tools used for deployment(tripleo-quickstart, infrared, manual deployments) which use different vars for the version release so in case of using conditionals we would need extra steps to normalize these variables. I wanted to bring this topic up for discussion to see if branching is the proper thing to do here. Thanks, Marius __ 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
Re: [openstack-dev] [tripleo] Help needed on debugging upgrade jobs on Pike
On Sat, Nov 4, 2017 at 2:27 AM, Emilien Macchi wrote: > Since we've got promotion, we can now properly test upgrades from ocata to > pike. > It's now failing for various reasons, as you can see on: > https://review.openstack.org/#/c/500625/ > > I haven't filled bug yet but this is the kind of thing I see now: > http://logs.openstack.org/25/500625/20/check/legacy-tripleo-ci-centos-7-scenario002-multinode-oooq-container-upgrades/62e7f14/logs/undercloud/home/zuul/overcloud_upgrade_console.log.txt.gz#_2017-11-04_00_14_17 I think this is related to https://review.openstack.org/#/c/510577/ which introduced running os-net-config during the major upgrade composable step. In case of environments without network isolation /etc/os-net-config/config.json doesn't exist so the os-net-config command fails. I filed https://bugs.launchpad.net/tripleo/+bug/1730328 to keep track of it. > I'm requesting some help from the upgrades squad, if they already saw > the failures, etc. It would be great to have the jobs passing at some > point, now the framework is in place and we had promotion. > > Thanks, > -- > Emilien Macchi __ 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-dev] [tripleo] Roles count and flavors inside Heat environment file
Hello everyone, In Newton we've deprecated the *-scale and *-flavor deploy command arguments in favor of using Heat environment files. In the context of testing the composable roles where the custom roles' node count and flavor need to be passed inside an environment file I would like to build the test plan by using an environment containing all nodes count and flavors, including the preexisting roles. A deploy command example would look like: openstack overcloud deploy --stack cloudy --templates -e nodes.yaml where the nodes environment file contains something like: parameter_defaults: ControllerCount: 3 ComputeCount: 2 CephStorageCount: 3 ServiceApiCount: 3 OvercloudControlFlavor: controller OvercloudComputeFlavor: compute OvercloudCephStorageFlavor: ceph OvercloudServiceApiFlavor: serviceapi I would like to get some feedback about this approach. I think it's better to keep all the roles count/flavors in the same place for consistency reasons. Thank you, Marius __ 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-dev] [tripleo] tripleo-common docs
Hi everyone, The tripleo-common readme[1] points to a broken documentation link[2]. What is the correct link for the docs? Thanks [1] https://github.com/openstack/tripleo-common/blob/master/README.rst [2] http://docs.openstack.org/developer/tripleo-common __ 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
