Re: [openstack-dev] [mistral] Help with test run

[Brad P. Crochet]

On Fri, Apr 27, 2018 at 5:23 AM András Kövi <allp...@gmail.com> 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

[Brad P. Crochet]

+1 from me!

On Fri, Apr 20, 2018 at 8:04 AM Yolanda Robla Mota <yrobl...@redhat.com>
wrote:

> +1, Marius has been a great help
>
> On Thu, Apr 19, 2018 at 7:01 PM, Emilien Macchi <emil...@redhat.com>
> 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

[Brad P. Crochet]

On Tue, Feb 6, 2018 at 1:59 PM Wesley Hayutin <whayu...@redhat.com> 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

[Brad P. Crochet]

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

[Brad P. Crochet]

On Mon, Dec 11, 2017 at 5:20 PM Alex Schultz <aschu...@redhat.com> wrote:

> On Mon, Dec 11, 2017 at 1:20 PM, Brad P. Crochet <b...@redhat.com> wrote:
> >
> >
> > On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz <aschu...@redhat.com> 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

[Brad P. Crochet]

On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz <aschu...@redhat.com> 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

[Brad P. Crochet]

definite +1

On Wed, Nov 29, 2017 at 2:35 PM John Trowbridge <tr...@redhat.com> 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

[Brad P. Crochet]

+1

On Wed, Dec 6, 2017 at 10:46 AM Emilien Macchi <emil...@redhat.com> 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

[Brad P. Crochet]

On Thu, Oct 19, 2017 at 4:56 PM James Slagle <james.sla...@gmail.com> 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

[Brad P. Crochet]

On Wed, Oct 18, 2017 at 12:34 AM Renat Akhmerov <renat.akhme...@gmail.com>
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 <dou...@redhat.com>, wrote:
>
>
>
> On 17 October 2017 at 09:19, Renat Akhmerov <renat.akhme...@gmail.com>
> 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?

[Brad P. Crochet]

On Tue, Sep 26, 2017 at 2:58 PM Ben Nemec <openst...@nemebean.com> 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=02%7C01%7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329=6oEmh0LJacV3WPGGp3wW%2BhL3nPDxRh%2BzNPY67X09Blc%3D=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=02%7C01%7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329=EsydZ9EsUjkYcF92Gys569SJEvQ%2B%2Fu6uV8WAQJ0YMfc%3D=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

[Brad P. Crochet]

On Thu, Aug 24, 2017 at 5:35 PM, Ben Nemec <openst...@nemebean.com> 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

[Brad P. Crochet]

On Tue, Apr 18, 2017 at 2:10 AM Ренат Ахмеров <renat.akhme...@gmail.com>
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 <b...@redhat.com>, 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

[Brad P. Crochet]

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

[Brad P. Crochet]

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 

Re: [openstack-dev] [tripleo] State of upgrade CLI commands

[Brad P. Crochet]

On Thu, Aug 18, 2016 at 4:25 AM, mathieu bultel <mbul...@redhat.com> 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

[Brad P. Crochet]

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

[Brad P. Crochet]

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)
<sambe...@cisco.com> 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

[Brad P. Crochet]

On Tue, Nov 3, 2015 at 10:25 AM, Gregory Haynes <g...@greghaynes.net> 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] [OSC] Quick poll: OpenStackClient command for provision action

[Brad P. Crochet]

On Tue, Nov 10, 2015 at 9:32 AM, Steve Martinelli <steve...@ca.ibm.com> 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

[Brad P. Crochet]

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] [Ironic] Quick poll: OpenStackClient command for provision action

[Brad P. Crochet]

On Tue, Nov 10, 2015 at 4:09 AM, Dmitry Tantsur <dtant...@redhat.com> 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

[Brad P. Crochet]

On Tue, Nov 10, 2015 at 11:14 AM, Dean Troyer <dtro...@gmail.com> wrote:
> On Tue, Nov 10, 2015 at 9:46 AM, Dmitry Tantsur <dtant...@redhat.com> 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

[Brad P. Crochet]

On Tue, Nov 10, 2015 at 4:09 AM, Dmitry Tantsur <dtant...@redhat.com> 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] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Brad P. Crochet]

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] [Ironic] Quick poll: OpenStackClient command for provision action

[Brad P. Crochet]

On Tue, Nov 10, 2015 at 10:53 AM, Dean Troyer <dtro...@gmail.com> wrote:
> On Tue, Nov 10, 2015 at 9:32 AM, Brad P. Crochet <b...@redhat.com> 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] [tripleO] appropriate location for docker image uploading

[Brad P. Crochet]

On Tue, Nov 3, 2015 at 2:54 PM, Jeff Peeler <jpee...@redhat.com> 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

[Brad P. Crochet]

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

[Brad P. Crochet]

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

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[Brad P. Crochet]

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

[Brad P. Crochet]

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

[Brad P. Crochet]

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

[Brad P. Crochet]

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