Re: [openstack-dev] [mistral] Help with test run
On Fri, Apr 27, 2018 at 5:23 AM András Kövi wrote: > Hi, > > Can someone please help me with why this build ended with TIMED_OUT? > http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/ > > I'm not seeing any particular reason for it. Is it happening consistently? > Thanks, > Andras > > __ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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
+1 from me! On Fri, Apr 20, 2018 at 8:04 AM Yolanda Robla Mota wrote: > +1, Marius has been a great help > > On Thu, Apr 19, 2018 at 7: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. >> -- >> 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 >> >> > > > -- > > Yolanda Robla Mota > > Principal Software Engineer, RHCE > > Red Hat > > <https://www.redhat.com> > > C/Avellana 213 > > Urb Portugal > > yrobl...@redhat.comM: +34605641639 > <http://redhatemailsignature-marketing.itos.redhat.com/> > <https://red.ht/sig> > __________ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] how to reproduce tripleo ci
On Tue, Feb 6, 2018 at 1:59 PM Wesley Hayutin wrote: > Greetings, > > The TripleO-CI team has added a recreate / reproduce script to all the > tripleo upstream ci jobs as an artifact [1-2] much like the devstack > reproduce.sh script. If you find yourself in need of recreating a tripleo > ci job please take a look at the instructions. > > At this time the reproduction of ci is only supported by using an > openstack cloud to provision test nodes, libvirt and other approaches are > not yet supported but are on the roadmap. > > Great work TripleO-CI team! I've already used this a number of times and it has functioned quite well! > Thank you! > > [1] > https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html > [2] http://tripleo.org/contributor/reproduce-ci.html > > __ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] [Release-job-failures][mistral][release][requirements] Pre-release of openstack/mistral-extra failed
On Mon, Jan 29, 2018 at 8:02 PM, Doug Hellmann wrote: > Excerpts from zuul's message of 2018-01-30 00:40:13 +: >> Build failed. >> >> - release-openstack-python >> http://logs.openstack.org/53/533a5ee424ebf6937f03d3b1d9d5b52e8ecb/pre-release/release-openstack-python/44f2fd4/ >> : FAILURE in 7m 58s >> - announce-release announce-release : SKIPPED >> - propose-update-constraints propose-update-constraints : SKIPPED >> > > This release appears to have failed because tox.ini is set up to use the > old style of constraints list management and mistral-extra appears in > the constraints list. > > I don't know why the tox environment is being used to build the package; > I thought we stopped doing that. > > One solution is to fix the tox.ini to put the constraints specification > in the "deps" field. The patch [1] to oslo.config making a similar > change should show you what is needed. > > Doug > > [1] https://review.openstack.org/#/c/524496/1/tox.ini > > __ > 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 Hopefully https://review.openstack.org/539204 fixes it. Brad __ 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] Blueprints moved out to Rocky
On Mon, Dec 11, 2017 at 5:20 PM Alex Schultz wrote: > On Mon, Dec 11, 2017 at 1:20 PM, Brad P. Crochet wrote: > > > > > > On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz wrote: > >> > >> Hey folks, > >> > >> So I went through the list of blueprints and moved some that were > >> either not updated or appeared to have a bunch of patches not in a > >> mergable state. > >> > >> Please take some time to review the list of blueprints currently > >> associated with Rocky[0] to see if your efforts have been moved. If > >> you believe you're close to implementing the feature in the next week > >> or two, let me know and we can move it back into Queens. If you think > >> it will take an extended period of time (more than 2 weeks) to land > >> but we need it in Queens, please submit an FFE. > >> > > > > I think these are in a close enough state to warrant inclusion in Queens: > > > > https://blueprints.launchpad.net/tripleo/+spec/get-networks-action > > > https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-list-available-roles-action > > > https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-select-roles-workflow > > https://blueprints.launchpad.net/tripleo/+spec/update-networks-action > > https://blueprints.launchpad.net/tripleo/+spec/validate-roles-networks > > https://blueprints.launchpad.net/tripleo/+spec/update-roles-action > > > > Ok I reviewed them and they do appear to have patches posted and are > getting reviews. I'll pull them back in to Queens and set the > milestone to queens-3. Please make sure to update us on the status > during this week and next week's IRC meetings. I would like to make > sure these land ASAP. Do you think they should be in a state to land > by the end of next week say 12/21? > > Thanks, > -Alex > > Yes. They will be in a state to land by 12/21. Thanks, Brad > > There is a good chance of these being completed in the coming week. > > > > Thanks, > > > > Brad > >> > >> > > -- > > Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS > > Principal Software Engineer > > (c) 704.236.9385 <(704)%20236-9385> > > > > > > > __ > > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] Blueprints moved out to Rocky
On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz wrote: > Hey folks, > > So I went through the list of blueprints and moved some that were > either not updated or appeared to have a bunch of patches not in a > mergable state. > > Please take some time to review the list of blueprints currently > associated with Rocky[0] to see if your efforts have been moved. If > you believe you're close to implementing the feature in the next week > or two, let me know and we can move it back into Queens. If you think > it will take an extended period of time (more than 2 weeks) to land > but we need it in Queens, please submit an FFE. > > I think these are in a close enough state to warrant inclusion in Queens: https://blueprints.launchpad.net/tripleo/+spec/get-networks-action https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-list-available-roles-action https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-select-roles-workflow https://blueprints.launchpad.net/tripleo/+spec/update-networks-action https://blueprints.launchpad.net/tripleo/+spec/validate-roles-networks https://blueprints.launchpad.net/tripleo/+spec/update-roles-action There is a good chance of these being completed in the coming week. Thanks, Brad > > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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 Ronelle Landy for Tripleo-Quickstart/Extras/CI core
definite +1 On Wed, Nov 29, 2017 at 2:35 PM John Trowbridge wrote: > I would like to propose Ronelle be given +2 for the above repos. She has > been a solid contributor to tripleo-quickstart and extras almost since the > beginning. She has solid review numbers, but more importantly has always > done quality reviews. She also has been working in the very intense rover > role on the CI squad in the past CI sprint, and has done very well in that > role. > __ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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 Wesley Hayutin core on TripleO CI
+1 On Wed, Dec 6, 2017 at 10:46 AM Emilien Macchi wrote: > Team, > > Wes has been consistently and heavily involved in TripleO CI work. > He has a very well understanding on how tripleo-quickstart and > tripleo-quickstart-extras work, his number and quality of reviews are > excellent so far. His experience with testing TripleO is more than > valuable. > Also, he's always here to help on TripleO CI issues or just > improvements (he's the guy filling bugs on a Saturday evening). > I think he would be a good addition to the TripleO CI core team > (tripleo-ci, t-q and t-q-e repos for now). > Anyway, thanks a lot Wes for your hard work on CI, I think it's time > to move on and get you +2 ;-) > > As usual, it's open for voting, feel free to bring any feedback. > Thanks everyone, > -- > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] Deployment workflow changes for ui/client
On Thu, Oct 19, 2017 at 4:56 PM James Slagle wrote: > I've been looking at how we can hook up the deployment changes for > config-download[1] with the existing deployment workflows in Mistral. > > However, it seems we have not sufficiently abstracted the logic to do > a "deployment" behind a given workflow(s). The existing things a > client (or UI) has to do is: > > - call tripleo.deployment.v1.deploy_plan > - poll for success/failure of that workflow > - poll for success/failure of in progress Heat stack (list events, etc) > - call tripleo.deployment.v1.overcloudrc > (probably more things too) > > If I want to make some changes to the deployment workflow, such that > after the Heat stack operation is complete, we run a config-download > action/workflow, then apply the generated ansible via > ansible-playbook, I can't really do that without requiring all clients > to also get updated to use those new steps (via calling new workflows, > etc). > > As a first attempt, I took a shot at creating a workflow that does every > step: > https://review.openstack.org/#/c/512876/ > But even that will require client changes as it necessitates a > behavior change in that the workflow has to wait for the stack to be > complete as opposed to returning as soon as the stack operation is > accepted by Heat. > > Thankfully we already have that capability. :) > I'd like to implement this in a way that minimizes the impact of > changes on both python-tripleoclient and tripleo-ui, but it's looking > as if some changes would be required to use this new ansible driven > approach. > > Thoughts or feedback on how to proceed? I'm guess I'm also wondering > if the existing API exposed by the workflows is easy to consume by the > UI, or if it would be better to be wrapped in a single workflow...at > least that way we could make logical implementation changes without > requiring ui/cilent changes. > > [1] https://blueprints.launchpad.net/tripleo/+spec/ansible-config-download > > +1 to all of this. I think from the CLI perspective, it should be a minimal impact. If anything, it will get rid of a lot of code that doesn't really belong. I can't say what the impact to the UI would be. However, one thing that we should make sure of is that we send messages back through Zaqar to keep the CLI and UI informed of what is occurring. That should happen already with most of the existing workflows. This is a great step in the right direction. The Workflows squad will be happy to assist in any way we can. We will start by reviewing what you have so far. > -- > -- 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] [stable][mistral] Asking for stable branch policy exception
On Wed, Oct 18, 2017 at 12:34 AM Renat Akhmerov wrote: > Dougal, > > I forgot to mention that explicitly but, yes, #1 is needed only not to > break the sequence of migrations. We can manually fix the migration number > in #2 just for stable/pike but I somewhat don’t like the idea of having > different migration numbers in different branches. > > It’s a good news that we’re not going to break TripleO. > > Thanks > > My thought is take both. Not backporting the migration will break future upgrades. We have literally been in this situation before. Brad > > Renat Akhmerov > @Nokia > > On 17 Oct 2017, 20:21 +0700, Dougal Matthews , wrote: > > > > On 17 October 2017 at 09:19, Renat Akhmerov > wrote: > >> Hi, >> >> We have two patches in Mistral that we need to back port to stable/pike. >> However, they are against of stable branch management policy because they >> slightly change the DB schema. The patches are the following: >> >>1. https://review.openstack.org/#/c/512528/ >>2. https://review.openstack.org/#/c/512256/ >> >> >> #2 is a critically important fix that fixes a problem of decreasing >> Mistral performance when DB becomes heavy (has lots of execution objects). >> This is a blocker issue for us (Nokia) preventing us using Mistral in >> production. It also seriously optimizes performance in general. >> >> So hereby I'm asking your advice on what we can do in this situation. Can >> we merge these patches if we make sure that we don't break anyone in the >> community? For example, TripleO. >> > > As far as I am aware, this wont be a problem for TripleO. These patches > are both additive (new db column and new db index). > > The first patch (512528) is only a candidate for backport to avoid > breaking the migration history order, it isn't otherwise needed in Pike. > How is this normally handled in other projects? i.e. we need to backport > migration 24 to Pike, but 23 is in master only. I assume this problem has > came up before and been solved, but I can't find any examples. > > > >> >> Thanks >> >> Renat Akhmerov >> @Nokia >> >> __ >> 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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][DIB] how create triplo overcloud image with latest kernel?
On Tue, Sep 26, 2017 at 2:58 PM Ben Nemec wrote: > > > On 09/26/2017 05:43 AM, Moshe Levi wrote: > > Hi all, > > > > As part of the OVS Hardware Offload [1] [2], we need to create new > > Centos/Redhat 7 image with latest kernel/ovs/iproute. > > > > We tried to use virsh-customize to install the packages and we were able > > to update iproute and ovs, but for the kernel there is no space. > > > > We also tried with virsh-customize to uninstall the old kenrel but we no > > luck. > > > > Is other ways to replace kernel package in existing image? > > Do you have to use an existing image? The easiest way to do this would > be to create a DIB element that installs what you want and just include > that in the image build in the first place. I don't think that would be > too difficult to do now that we're keeping the image definitions in > simple YAML files. > > If it is just packages, a DIB element wouldn't even be necessary. You could define a new yaml that just adds the packages that you want, and add that to the CLI when you build the images. > > > > [1] - https://review.openstack.org/#/c/504911/ > > < > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F504911%2F&data=02%7C01%7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329&sdata=6oEmh0LJacV3WPGGp3wW%2BhL3nPDxRh%2BzNPY67X09Blc%3D&reserved=0 > > > > > > > > [2] - https://review.openstack.org/#/c/502313/ > > < > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F502313%2F&data=02%7C01%7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329&sdata=EsydZ9EsUjkYcF92Gys569SJEvQ%2B%2Fu6uV8WAQJ0YMfc%3D&reserved=0 > > > > > > > > > > > > > __ > > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] add mistral to the auto-update package list for TripleO CI
On Thu, Aug 24, 2017 at 5:35 PM, Ben Nemec wrote: > I think I'm +0 on this. On the one hand we do have the gating job on > Mistral, on the other hand our gate jobs don't exercise all of the > functionality of some projects, especially Mistral. I know in the past > introspection has been broken by changes in Mistral, and that wouldn't be > caught by gate jobs. If we start using master all the time that becomes a > blocker for TripleO since it will prevent our OVB jobs from passing. > > So I can understand the desire to use master of a tightly coupled project > like Mistral, but it does open a hole in our promotion pipeline which I > don't feel great about. If we had an OVB job running on every patch (and > respected by the Mistral cores) I'd be +1 with no reservations. I am +1 on this. However, I do echo Ben's concerns. I will bring this up with the Mistral group at the PTG. We already have an experimental job available, but I'm guessing the major concern will be the amount of time it takes for a TripleO job to run. It would likely double the amount of time that a Mistral patch takes to get through CI. > > > On 08/24/2017 04:04 PM, Wesley Hayutin wrote: >> >> Greetings, >> >> I'd like to propose that the mistral project be added to the list of >> projects where in CI the very latest built packages are added to each CI run >> [1]. >> >> This will help get patches that depend on mistral patches to more quickly >> be tested and merged. For example Honza's patch [2] depends on a merged >> mistral change. The mistral change has not yet landed in a tripleo build >> and mistral is not on the auto-update list, so the patch fails. >> >> Please respond if you would like to see mistral added or have any comments >> or concerns. >> >> Note that we are able to consider mistral for auto-updates because the >> mistral project has a voting tripleo job [3] and the tripleo project can be >> assured that the latest mistral patches will not break tripleo-ci. >> >> I would encourage other projects to consider adding tripleo jobs to their >> project to enable auto-updates as well [4] >> >> [1] >> https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/master.yml#L54-L70 >> [2] https://review.openstack.org/#/c/469608/ >> [3] >> https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L11665 >> [4] >> https://docs.openstack.org/tripleo-docs/latest/contributor/check_gates.html >> >> >> __________ >> 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 >> > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer __ 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] [mistral] New CI Job definitions
On Tue, Apr 18, 2017 at 2:10 AM Ренат Ахмеров wrote: > Thanks Brad! > > So kombu gate is now non-apache, right? > > No. It would be running under mod_wsgi. We can make it non-apache if you like. Would be pretty easy to do so. > Thanks > > Renat Akhmerov > @Nokia > > On 17 Apr 2017, 22:17 +0700, Brad P. Crochet , wrote: > > Hi y'all... > > In the midst of trying to track down some errors being seen with tempest > tests whilst running under mod_wsgi/apache, I've made it so that the > devstack plugin is capable of also running with mod_wsgi/apache.[1] > > In doing so, It's become the default devstack job. I've also now created > some 'non-apache' jobs that basically are what the old jobs did, just > renamed. > > Also, I've consolidated the job definitions (the original and the kombu) > to simplify and DRY out the jobs. You can see the infra review here.[2] > > The list of jobs will be: > gate-mistral-devstack-dsvm-ubuntu-xenial-nv > gate-mistral-devstack-dsvm-non-apache-ubuntu-xenial-nv > gate-mistral-devstack-dsvm-kombu-ubuntu-xenial-nv > > Note that the trusty jobs have been eliminated. > > Essentially, I've added a '{special}' tag to the job definition, allowing > us to create special-cased devstack jobs. So, as you can see, I've migrated > the kombu job to be such a thing. It should also be possible to combine > them. > > [1] https://review.openstack.org/#/c/454710/ > [2] https://review.openstack.org/#/c/457106/ > -- > Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS > Principal Software Engineer > (c) 704.236.9385 <(704)%20236-9385> > > __ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] [mistral] New CI Job definitions
Hi y'all... In the midst of trying to track down some errors being seen with tempest tests whilst running under mod_wsgi/apache, I've made it so that the devstack plugin is capable of also running with mod_wsgi/apache.[1] In doing so, It's become the default devstack job. I've also now created some 'non-apache' jobs that basically are what the old jobs did, just renamed. Also, I've consolidated the job definitions (the original and the kombu) to simplify and DRY out the jobs. You can see the infra review here.[2] The list of jobs will be: gate-mistral-devstack-dsvm-ubuntu-xenial-nv gate-mistral-devstack-dsvm-non-apache-ubuntu-xenial-nv gate-mistral-devstack-dsvm-kombu-ubuntu-xenial-nv Note that the trusty jobs have been eliminated. Essentially, I've added a '{special}' tag to the job definition, allowing us to create special-cased devstack jobs. So, as you can see, I've migrated the kombu job to be such a thing. It should also be possible to combine them. [1] https://review.openstack.org/#/c/454710/ [2] https://review.openstack.org/#/c/457106/ -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] POC patch for using tripleo-repos for repo setup
On Wed, Nov 23, 2016 at 11:07 AM, Ben Nemec wrote: > > > On 11/22/2016 08:18 PM, Emilien Macchi wrote: >> >> Even if I was part of those who approved this feature, I still have >> some comments, inline: >> >> On Tue, Nov 22, 2016 at 1:30 PM, Alex Schultz wrote: >>> >>> On Tue, Nov 22, 2016 at 11:06 AM, Ben Nemec >>> wrote: On 11/21/2016 05:26 PM, Alex Schultz wrote: > > > On Mon, Nov 21, 2016 at 2:57 PM, Ben Nemec > wrote: >> >> >> Hi, >> >> I have a POC patch[1] up to demonstrate the use of the tripleo-repos >> tool >> [2] as a replacement for most of tripleo.sh --repo-setup. It has now >> passed >> all of the CI jobs so I wanted to solicit some feedback. >> >> There are a few changes related to repo naming because the tool names >> repo >> files based on the repo name rather than always calling them something >> generic like delorean.repo. I think it's less confusing to have the >> delorean-newton repo file named delorean-newton.repo, but I'm open to >> discussion on that. >> >> If no one has any major objections to how the tool looks/works right >> now, >> I'll proceed with the work to get it imported into the openstack >> namespace >> as part of TripleO. We can always iterate on it after import too, of >> course, so this isn't a speak now or forever hold your peace >> situation. >> :-) >> > > Why a python standalone application for the management of specifically > (and only?) tripleo repositories. It seems we should be trying to > leverage existing tooling and not hiding the problem behind a python > app. It's not that I enjoy the current method described in the spec > (3 curls, 1 sed, 1 bash thing, and a yum install) but it seems like to > write 586 lines of python and tests might be the wrong approach. > Would it be better to just devote some time to rpm generation for > these and deliver it in discrete RPMs? 'yum install > http://tripleo.org/repos-current.rpm' seems way more straight forward. That's essentially trading "curl ..." for "yum install ..." in the docs. The repo rpm would have to be part of the delorean build so you'd still have to be pointing people at a delorean repo. It would also still require code changes somewhere to handle the mixed current/current-tripleo setup that we run for development and test. Given how specific to tripleo that is I'm not sure how much sense it makes to implement it elsewhere. >>> >>> I'm asking because essentially we're delivering basically static repo >>> files. Which should really be done via RPM. Upgrades and cleanups are >>> already well established practices between RPMs. I'm not seeing the >>> reasoning why a python app. I thought about this further and I'm not >>> sure why this should be done on the client side via an app rather than >>> at repository build/promotion time. As long as we're including the >>> repo rpm, we can always create simple 302 redirects from a webserver >>> to get the latest version. I don't see why we should introduce a >>> client tool for this when the action is really on the repository >>> packaging side. This seems odd doing system configuration via a >>> python script rather than a configuration management tool like >>> ansible, puppet or even just packaging. >>> There are also optional ceph and opstool repos and at least ceph needs to match the version of OpenStack being installed. Sure, you could just document all that logic, but then the logic has to be reimplemented in CI anyway so you end up with code to maintain either way. At least with one tool the logic is shared between the user and dev/test paths, which is one of the primary motivations behind it. Pretty much every place that we have divergence between what users do and what developers do becomes a pain point for users because developers only fix the things they actually use. >>> >>> Yes we should not have a different path for dev/test vs operational >>> deployments, but I'm not convinced we need to add a custom python tool >>> to handle this only for tripleo. There are already established >>> patterns of repository rpm delivery and installation via existing >>> tools. What are we getting from this tool that can't already be done? >> >> >> That is true, here are some of them: >> - centos-release-ceph-(hammer|jewel) rpm that deploys repos. >> - since we are moving TripleO CI to use tripleo-quickstart, we could >> handle repository with Ansible, directly in the roles. > > > This is exactly what I'm trying to avoid here. I want us to be using the > same thing for repo management in CI and dev and real user environments. > Unless we're making quickstart the new API for TripleO this basically > defeats the whole purpose of red
Re: [openstack-dev] [tripleo] State of upgrade CLI commands
On Thu, Aug 18, 2016 at 4:25 AM, mathieu bultel wrote: > On 08/18/2016 09:29 AM, Marios Andreou wrote: >> On 17/08/16 15:46, Jiří Stránský wrote: >>> On 16.8.2016 21:08, Brad P. Crochet wrote: >>>> Hello TripleO-ians, >>>> >>>> I've started to look again at the introduced, but unused/undocumented >>>> upgrade commands. It seems to me that given the current state of the >>>> upgrade process (at least from Liberty -> Mitaka), these commands make >>>> a lot less sense. >>>> >>>> I see one of two directions to take on this. Of course I would love to >>>> hear other options. >>>> >>>> 1) Revert these commands immediately, and forget they ever existed. >>>> They don't exactly work, and as I said, were never officially >>>> documented, so I don't think a revert is out of the question. >>>> >>>> or >>>> >>>> 2) Do a major overhaul, and rethink the interface entirely. For >>>> instance, the L->M upgrade introduced a couple of new steps (the AODH >>>> migration and the Keystone migration). These would have either had to >>>> have completely new commands added, or have some type of override to >>>> the existing upgrade command to handle them. >>>> >>>> Personally, I would go for step 1. The 'overcloud deploy' command can >>>> accomplish all of the upgrade steps that involve Heat. In order for >>>> the new upgrade commands to work properly, there's a lot that needs to >>>> be refactored out of the deploy command itself so that it can be >>>> shared with deploy and upgrade, like passing of passwords and the >>>> like. I just don't see a need for discrete commands when we have an >>>> existing command that will do it for us. And with the addition of an >>>> answer file, it makes it even easier. >>>> >>>> Thoughts? >>>> >>> +1 for approach no. 1. Currently `overcloud deploy` meets the upgrade >>> needs and it gave us some flexibility to e.g. do migrations like AODH >>> and Keystone WSGI. I don't think we should have a special command for >>> upgrades at this point. >>> >>> The situation may change as we go towards upgrades of composable >>> services, and perhaps wrap upgrades in Mistral if/when applicable, but >>> then the potential upgrade command(s) would probably be different from >>> the current ones anyway, so +1 for removing them. >> +1 from me too, especially because this ^^^ (the workflow we currently >> have and use will change quite drastically I expect) >> >> thanks, sorry I didn't spot this earlier, >> marios > > +1 for me too, even if, I think for an end-user experience it's not > ideal and the CLI would be a better way for this point. >>> Jirka >>> I have proposed the following reverts: python-tripleoclient: https://review.openstack.org/#/c/357192/ https://review.openstack.org/#/c/357194/ https://review.openstack.org/#/c/357195/ tripleo-common: https://review.openstack.org/#/c/357219/ https://review.openstack.org/#/c/357220/ https://review.openstack.org/#/c/357221/ -- Brad __ 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] State of upgrade CLI commands
Hello TripleO-ians, I've started to look again at the introduced, but unused/undocumented upgrade commands. It seems to me that given the current state of the upgrade process (at least from Liberty -> Mitaka), these commands make a lot less sense. I see one of two directions to take on this. Of course I would love to hear other options. 1) Revert these commands immediately, and forget they ever existed. They don't exactly work, and as I said, were never officially documented, so I don't think a revert is out of the question. or 2) Do a major overhaul, and rethink the interface entirely. For instance, the L->M upgrade introduced a couple of new steps (the AODH migration and the Keystone migration). These would have either had to have completely new commands added, or have some type of override to the existing upgrade command to handle them. Personally, I would go for step 1. The 'overcloud deploy' command can accomplish all of the upgrade steps that involve Heat. In order for the new upgrade commands to work properly, there's a lot that needs to be refactored out of the deploy command itself so that it can be shared with deploy and upgrade, like passing of passwords and the like. I just don't see a need for discrete commands when we have an existing command that will do it for us. And with the addition of an answer file, it makes it even easier. Thoughts? -- Brad __ 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] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action
I have pushed up a draft of the spec. Let's move comments there. I tried to incorporate as much as I could from the discussion here. There was a lot of disjointed suggestions and was a bit difficult to follow. So I've taken what I can. It can be refined in the spec itself. https://review.openstack.org/247539 Thanks. On Wed, Nov 18, 2015 at 7:18 AM, Sam Betts (sambetts) wrote: > I think all the filtering etc that exists on the current CLI should move > over to OSC, I personally find things like --fields super useful. > > > +1 to removing "chassis show --nodes" and making it part of node list. > > > +1 to deploy, instead of activate. Jim also suggested provision. WDYT? > > > I'd only chosen boot and shutdown because they were the only 1 word synonyms > I could think of for power on and power off, if everyone else is happy with > poweron and poweroff, then so am I :) I'm also not sure what to do about > maintenance mode, maybe something like quarantine and unquarantine? I quite > like ignore, as its descriptive of whats actually happening, but I'm unsure > of the best antonym for it, I was thinking acknowledge or something like > that. > > > Heres a revised list of commands based on everyone's suggestions so far: > > > openstack baremetal [node/driver/chassis/port] list [For ports --node, For > nodes --chassis] > > openstack baremetal [node/driver/chassis/port] show UUID [For nodes > --states, For driver --properties] > > > openstack baremetal [node/chassis/port] create > > openstack baremetal [node/chassis/port] update UUID > > openstack baremetal [node/chassis/port] delete UUID > > > openstack baremetal node provide UUID > > openstack baremetal node deploy UUID > > openstack baremetal node rebuild UUID > > openstack baremetal node inspect UUID > > openstack baremetal node validate UUID > > openstack baremetal node manage UUID > > openstack baremetal node abort UUID > > openstack baremetal node poweron UUID > > openstack baremetal node poweroff UUID > > openstack baremetal node reboot UUID > > > openstack baremetal node ignore UUID > > openstack baremetal node acknowledge UUID > > > openstack baremetal node console [--enable, --disable] UUID > > openstack baremetal node boot-device [--supported, --set CDROM, PXE, DISK] > UUID > > > openstack baremetal [node/driver] vendor NAME_OR_UUID METHOD > > > WDYT? > > > Sam > > > __________ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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 Ian Wienand as core reviewer on diskimage-builder
On Tue, Nov 3, 2015 at 10:25 AM, Gregory Haynes wrote: > Hello everyone, > > I would like to propose adding Ian Wienand as a core reviewer on the > diskimage-builder project. Ian has been making a significant number of > contributions for some time to the project, and has been a great help in > reviews lately. Thus, I think we could benefit greatly by adding him as > a core reviewer. > > Current cores - Please respond with any approvals/objections by next Friday > (November 13th). > +1 > Cheers, > Greg > > __ > 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 -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Quick poll: OpenStackClient command for provision action
On Tue, Nov 10, 2015 at 10:53 AM, Dean Troyer wrote: > On Tue, Nov 10, 2015 at 9:32 AM, Brad P. Crochet wrote: >> >> In this case, the noun is actually 'baremetal provision state'. The >> 'action' is the states themselves. It doesn't fit exactly, but seems >> to at least be somewhat natural. > > > resource == provision state (add baremetal if namespacing is required) > action == set > value == --state x|y|z > > provision state set --state active|deleted|provide > > (note: I'd rethink those state names and see if they can feel more > consistent) > >> > Let's have a quick poll, which would you prefer and why: >> > >> > 1. openstack baremetal provision state --provide UUID >> > 2. openstack baremetal provision --provide UUID >> > 3. openstack baremetal provide UUID >> > 4. openstack baremetal set provision state --provide UUID >> > 5. openstack baremetal set state --provide UUID >> > 6. openstack baremetal action --provide UUID >> >> I think my vote would be for #4 (or #5 if 'state' alone is enough to >> convey the intent). I would love to get an OSC person's view on that >> one. (Question already asked in another post) > > > state by itself is not very meaningful. if 'baremetal state' is meaningful > to a user that might be OK. But what thing has that state? A node? I > don't know what 'provision state' also refers to, a node? a port? > There was some discussion on one of the patches about changing to 'baremetal node'. I was a little concerned by that since the original 'baremetal' commands have landed, but I think since they landed post-Liberty, we wouldn't need to worry about a deprecation period. Am I correct in thinking that? > dt > > -- > > Dean Troyer > dtro...@gmail.com > > ______ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Quick poll: OpenStackClient command for provision action
On Tue, Nov 10, 2015 at 4:09 AM, Dmitry Tantsur wrote: > Hi all! > > I'd like to seek consensus (or at least some opinions) on patch > https://review.openstack.org/#/c/206119/ > It proposed the following command: > I think it's time to actually just write up a spec on this. I think we would be better served to spell it out now, and then more people can contribute to both the spec and to the actual implementation once the spec is approved. WDYT? > openstack baremetal provision state --provide UUID > > (where --provide can also be --active, --deleted, --inspect, etc). > > I have several issues with this proposal: > > 1. IIUC the structure of an OSC command is "openstack noun verb". "provision > state" is not a verb. > 2. --active is not consistent with other options, which are verbs. > > Let's have a quick poll, which would you prefer and why: > > 1. openstack baremetal provision state --provide UUID > 2. openstack baremetal provision --provide UUID > 3. openstack baremetal provide UUID > 4. openstack baremetal set provision state --provide UUID > 5. openstack baremetal set state --provide UUID > 6. openstack baremetal action --provide UUID > > I vote for #3. Though it's much more versbose, it reads very easily, except > for "active". For active I'm thinking about changing it to "activate" or > "provision". > > My next candidate is #6. Though it's also not a verb, it reads pretty > easily. > > Thanks! > > __ > 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 -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action
On Tue, Nov 10, 2015 at 11:14 AM, Dean Troyer wrote: > On Tue, Nov 10, 2015 at 9:46 AM, Dmitry Tantsur wrote: >> >> inspect, manage, provide, active and abort are all provisioning verbs >> used in ironic API. they usually represent some complex operations on a >> node. Inspection is not related to showing, it's about fetching hardware >> properties from hardware itself and updating ironic database. manage sets a >> node to a specific ("manageable") state. etc. > > > inspect seems like a very specific action and is probably OK as-is. We > should sanity-check other resources in OpenStack that it might also be used > with down the road and how different the action might be. > > Those that are states of a resource should be handled with a set command. > >> >> boot and shutdown are natural opposites, aka power on and power off. > > > The analogous server commands (create/delete) may not make sense here > because, unlike with a server (VM), a resource is not being created or > deleted. But a user might expect to use the same commands in both places. > We need to consider which of those is more important. I like to break ties > on the side of user experience consistency. baremetal create (the current command) does something different. It creates the node in ironic. So I would agree that create/delete are not analogous to the way Nova uses those verbs. > > Honestly, at some point as a user, I'd like to forget whether my server is a > bare metal box or not and just use the same commands to manage it. > > Also, I'd LOVE to avoid using 'boot' at all just to get away from the nova > command's use of it. > > dt > > -- > > Dean Troyer > dtro...@gmail.com > > __ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Quick poll: OpenStackClient command for provision action
On Tue, Nov 10, 2015 at 4:09 AM, Dmitry Tantsur wrote: > Hi all! > > I'd like to seek consensus (or at least some opinions) on patch > https://review.openstack.org/#/c/206119/ > It proposed the following command: > > openstack baremetal provision state --provide UUID > > (where --provide can also be --active, --deleted, --inspect, etc). > > I have several issues with this proposal: > > 1. IIUC the structure of an OSC command is "openstack noun verb". "provision > state" is not a verb. > 2. --active is not consistent with other options, which are verbs. > In this case, the noun is actually 'baremetal provision state'. The 'action' is the states themselves. It doesn't fit exactly, but seems to at least be somewhat natural. > Let's have a quick poll, which would you prefer and why: > > 1. openstack baremetal provision state --provide UUID > 2. openstack baremetal provision --provide UUID > 3. openstack baremetal provide UUID > 4. openstack baremetal set provision state --provide UUID > 5. openstack baremetal set state --provide UUID > 6. openstack baremetal action --provide UUID I think my vote would be for #4 (or #5 if 'state' alone is enough to convey the intent). I would love to get an OSC person's view on that one. (Question already asked in another post) > > I vote for #3. Though it's much more versbose, it reads very easily, except > for "active". For active I'm thinking about changing it to "activate" or > "provision". #3 might pose some problems, because of how argparse would need to be used. I wouldn't want to have 7 different classes just to handle a single API call. I'd say it is *possible*, but probably not ideal. > > My next candidate is #6. Though it's also not a verb, it reads pretty > easily. Might be too generic for my tastes. > > Thanks! > > ______ > 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 -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action
On Tue, Nov 10, 2015 at 9:32 AM, Steve Martinelli wrote: > > So I don't know the intricacies of the baremetal APIs, but hopefully I can > shed some light on best practices. > > Do try to reuse the existing actions > (http://docs.openstack.org/developer/python-openstackclient/commands.html#actions) > Do use "create", "delete", "set", "show" and "list" for basic CRUD. > Do try to have natural opposites - like issue/revoke, resume/suspend, > add/remove. > > > So looking at the list below, I'd say: > Don't use "update" - use "set". > Originally, I had gone down the path of using set for most of these operations. However, there was concern that the 'openstack baremetal set' command was crossing too many APIs. Would it be out of bounds to use something like 'openstack baremetal set power --on/off' or 'openstack baremetal set provision state --active/etc'. Then they can be discrete commands without a bunch of if statements in the code. > > What's the point of "inspect"? Can you use "show"? If it's a HEAD call, how > about "check"? > > What's "manage" does it update a resource? Can you use "set" instead? > > What are the natural opposites between provide/activate/abort/boot/shutdown? > > reboot and rebuild seem good > > /rant > > Steve > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Let's stop hijacking other projects' OSC namespaces
On Mon, Nov 9, 2015 at 7:44 AM, Dmitry Tantsur wrote: > Hi OOO'ers, hopefully the subject caught your attentions :) > > Currently, tripleoclient exposes several commands in "openstack baremetal" > and "openstack baremetal introspection" namespaces belonging to ironic and > ironic-inspector accordingly. TL;DR of this email is to deprecate them and > move to TripleO-specific namespaces. Read on to know why. > +100. __ 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] [Ironic] Let's stop hijacking other projects' OSC namespaces
On Tue, Nov 10, 2015 at 8:42 AM, Lennart Regebro wrote: > These changes are fine to me. > > I'm not so sure about the idea that we can't "hijack" other projects > namespaces. If only ironic is allowed to use the prefix "baremetal", > then the prefix should not have been "baremetal" in the first place, > it should have been "ironic". Which of course means it would just be a > replacement for the ironic client, making these whole namespaces > pointless. Actually, the 'baremetal' namespace is exactly what it should be, based on other OSC clients. For instance, Neutron uses 'network', Nova uses 'server', etc. The idea is that the client should use the service type, not the codename of the project that implements it. __ 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] appropriate location for docker image uploading
On Tue, Nov 3, 2015 at 2:54 PM, Jeff Peeler wrote: > I'm looking at introducing the ability for tripleoclient to upload > docker images into a docker registry (planning for it to be installed > in the undercloud [1]). I wanted to make sure something like this > would be accepted or get suggestions on an alternate approach. > Ultimately may end up looking something like the patch below, which > I'm still waiting for further feedback on: > https://review.openstack.org/#/c/239090/ > > > [1] https://review.openstack.org/#/c/238238/ Rather than continue on that code path, I would rather see the image loading be done in tripleo-common similarly to the load-images script in tripleo-incubator. The image building is already implemented [1], but not yet merged. We want the yaml to drive the build/load, rather than hard-code how we handle the images. [1] https://review.openstack.org/#/c/235569/ -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Command structure for OSC plugin
On 24/08/15 19:31 +0200, Dmitry Tantsur wrote: On 08/24/2015 07:25 PM, Brad P. Crochet wrote: On 24/08/15 17:56 +0200, Dmitry Tantsur wrote: On 08/24/2015 05:41 PM, Jay Pipes wrote: On 08/24/2015 08:03 AM, Brad P. Crochet wrote: I am working on extending the current set of patches that implement the OSC plugin for Ironic. I would like some discussion/guidance about a couple of command structures. Currently provisioning state is set via 'openstack baremetal set --provision-state [active|deleted|rebuild|inspect|provide|manage] $NODE' dtantsur suggests it be top-level a command (which I concur) 'openstack baremetal [active|delete|rebuild|inspect|provide|manage] $NODE' Question there is does that make sense? I prefer the current CLI command structure. `openstack baremetal active $NODE` does not make grammatical sense. `openstack baremetal activate $NODE` would make more sense, but I actually think the original is easier. As it is now it's a bit hard to understand what "openstack baremetal set" command actually does, as it corresponds to 2 API's (and I hope it won't also do node updating, will it?) I'm not sure what you mean about node updating... Do you mean setting properties? Because it does that. Can you be more specific about what you mean? So is it a replacement for 3 APIs/commands: ironic node-set-maintenance ironic node-set-provision-state ironic node-update ? If so, that's too much IMO. I can see your point there. Perhaps the maintenance and provision state should be treated more like the power state currently is? maintenance [--on|--off] provision state [--active|--deleted|etc.] Best, -jay __ 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 -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Command structure for OSC plugin
On 24/08/15 18:19 +, Tim Bell wrote: From a user perspective, where bare metal and VMs are just different flavors (with varying capabilities), can we not use the same commands (server create/rebuild/...) ? Containers will create the same conceptual problems. OSC can provide a converged interface but if we just replace '$ ironic ' by '$ openstack baremetal ', this seems to be a missed opportunity to hide the complexity from the end user. Can we re-use the existing server structures ? Tim To my knowledge, overriding or enhancing existing commands like that is not possible. -Original Message- From: Dmitry Tantsur [mailto:dtant...@redhat.com] Sent: 24 August 2015 19:31 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin On 08/24/2015 07:25 PM, Brad P. Crochet wrote: > On 24/08/15 17:56 +0200, Dmitry Tantsur wrote: >> On 08/24/2015 05:41 PM, Jay Pipes wrote: >>> On 08/24/2015 08:03 AM, Brad P. Crochet wrote: >>>> I am working on extending the current set of patches that implement >>>> the OSC plugin for Ironic. I would like some discussion/guidance >>>> about a couple of command structures. >>>> >>>> Currently provisioning state is set via 'openstack baremetal set >>>> --provision-state [active|deleted|rebuild|inspect|provide|manage] >>>> $NODE' >>>> >>>> dtantsur suggests it be top-level a command (which I concur) >>>> 'openstack baremetal [active|delete|rebuild|inspect|provide|manage] >>>> $NODE' >>>> >>>> Question there is does that make sense? >>> >>> I prefer the current CLI command structure. >>> >>> `openstack baremetal active $NODE` does not make grammatical sense. >>> >>> `openstack baremetal activate $NODE` would make more sense, but I >>> actually think the original is easier. >> >> As it is now it's a bit hard to understand what "openstack baremetal >> set" command actually does, as it corresponds to 2 API's (and I hope >> it won't also do node updating, will it?) > > I'm not sure what you mean about node updating... Do you mean setting > properties? Because it does that. Can you be more specific about what > you mean? So is it a replacement for 3 APIs/commands: ironic node-set-maintenance ironic node-set-provision-state ironic node-update ? If so, that's too much IMO. > >> >>> >>> Best, >>> -jay >>> >>> __ __ >>> __ >>> >>> 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 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 -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Command structure for OSC plugin
On 24/08/15 19:31 +0200, Dmitry Tantsur wrote: On 08/24/2015 07:25 PM, Brad P. Crochet wrote: On 24/08/15 17:56 +0200, Dmitry Tantsur wrote: On 08/24/2015 05:41 PM, Jay Pipes wrote: On 08/24/2015 08:03 AM, Brad P. Crochet wrote: I am working on extending the current set of patches that implement the OSC plugin for Ironic. I would like some discussion/guidance about a couple of command structures. Currently provisioning state is set via 'openstack baremetal set --provision-state [active|deleted|rebuild|inspect|provide|manage] $NODE' dtantsur suggests it be top-level a command (which I concur) 'openstack baremetal [active|delete|rebuild|inspect|provide|manage] $NODE' Question there is does that make sense? I prefer the current CLI command structure. `openstack baremetal active $NODE` does not make grammatical sense. `openstack baremetal activate $NODE` would make more sense, but I actually think the original is easier. As it is now it's a bit hard to understand what "openstack baremetal set" command actually does, as it corresponds to 2 API's (and I hope it won't also do node updating, will it?) I'm not sure what you mean about node updating... Do you mean setting properties? Because it does that. Can you be more specific about what you mean? So is it a replacement for 3 APIs/commands: ironic node-set-maintenance ironic node-set-provision-state ironic node-update ? If so, that's too much IMO. Yes, it is. But it does fit with OSC conventions. Best, -jay __ 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 -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Command structure for OSC plugin
On 24/08/15 17:56 +0200, Dmitry Tantsur wrote: On 08/24/2015 05:41 PM, Jay Pipes wrote: On 08/24/2015 08:03 AM, Brad P. Crochet wrote: I am working on extending the current set of patches that implement the OSC plugin for Ironic. I would like some discussion/guidance about a couple of command structures. Currently provisioning state is set via 'openstack baremetal set --provision-state [active|deleted|rebuild|inspect|provide|manage] $NODE' dtantsur suggests it be top-level a command (which I concur) 'openstack baremetal [active|delete|rebuild|inspect|provide|manage] $NODE' Question there is does that make sense? I prefer the current CLI command structure. `openstack baremetal active $NODE` does not make grammatical sense. `openstack baremetal activate $NODE` would make more sense, but I actually think the original is easier. As it is now it's a bit hard to understand what "openstack baremetal set" command actually does, as it corresponds to 2 API's (and I hope it won't also do node updating, will it?) I'm not sure what you mean about node updating... Do you mean setting properties? Because it does that. Can you be more specific about what you mean? Best, -jay __ 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 -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Command structure for OSC plugin
On 24/08/15 11:03 -0400, Brad P. Crochet wrote: I am working on extending the current set of patches that implement the OSC plugin for Ironic. I would like some discussion/guidance about a couple of command structures. [...snip...] Secondly, maintenance mode makes sense to be part of 'openstack baremetal set' command, but implementation would be easier and less error-prone if an antonym for maintenance were used as a flag. * openstack baremetal set --maintenance --reason $REASON $NODE * openstack baremetal set --maintenance-antonym $NODE argparse can be used to set them as mutually exclusive and negate the need to check explicitly for maintenance off and !$REASON Question is what should the antonym of maintenance be? Since 'active' is a node state, it was suggest that it be avoided to minimize confusion. One thought is to use --disable/--enable, with help text in the command stating what it does, but it was suggested that display of the maintenance field would need to change. Comments? Suggestions? Credit to lucasagomes... It makes more sense to use 'openstack baremetal unset --maintenance' to turn it off. So I think that one can be put to rest. -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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] [Ironic] Command structure for OSC plugin
I am working on extending the current set of patches that implement the OSC plugin for Ironic. I would like some discussion/guidance about a couple of command structures. Currently provisioning state is set via 'openstack baremetal set --provision-state [active|deleted|rebuild|inspect|provide|manage] $NODE' dtantsur suggests it be top-level a command (which I concur) 'openstack baremetal [active|delete|rebuild|inspect|provide|manage] $NODE' Question there is does that make sense? Secondly, maintenance mode makes sense to be part of 'openstack baremetal set' command, but implementation would be easier and less error-prone if an antonym for maintenance were used as a flag. * openstack baremetal set --maintenance --reason $REASON $NODE * openstack baremetal set --maintenance-antonym $NODE argparse can be used to set them as mutually exclusive and negate the need to check explicitly for maintenance off and !$REASON Question is what should the antonym of maintenance be? Since 'active' is a node state, it was suggest that it be avoided to minimize confusion. One thought is to use --disable/--enable, with help text in the command stating what it does, but it was suggested that display of the maintenance field would need to change. Comments? Suggestions? -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 (w) 919.301.3231 __ 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