Re: [openstack-dev] [ironic][bifrost][sushy][ironic-inspector][ironic-ui][virtualbmc] sub-project/repository core reviewer changes

[Vladyslav Drok]

+1 to all the changes.

On Fri, Aug 24, 2018 at 12:12 PM Sam Betts (sambetts) 
wrote:

> +1
>
>
>
> Sam
>
>
>
> On 23/08/2018, 21:38, "Mark Goddard"  wrote:
>
>
>
> +1
>
>
>
> On Thu, 23 Aug 2018, 20:43 Jim Rollenhagen, 
> wrote:
>
> ++
>
>
>
> // jim
>
>
>
> On Thu, Aug 23, 2018 at 2:24 PM, Julia Kreger 
> wrote:
>
> Greetings everyone!
>
> In our team meeting this week we stumbled across the subject of
> promoting contributors to be sub-project's core reviewers.
> Traditionally it is something we've only addressed as needed or
> desired by consensus with-in those sub-projects, but we were past due
> time to take a look at the entire picture since not everything should
> fall to ironic-core.
>
> And so, I've taken a look at our various repositories and I'm
> proposing the following additions:
>
> For sushy-core, sushy-tools-core, and virtualbmc-core: Ilya
> Etingof[1]. Ilya has been actively involved with sushy, sushy-tools,
> and virtualbmc this past cycle. I've found many of his reviews and
> non-voting review comments insightful and willing to understand. He
> has taken on some of the effort that is needed to maintain and keep
> these tools usable for the community, and as such adding him to the
> core group for these repositories makes lots of sense.
>
> For ironic-inspector-core and ironic-specs-core: Kaifeng Wang[2].
> Kaifeng has taken on some hard problems in ironic and
> ironic-inspector, as well as brought up insightful feedback in
> ironic-specs. They are demonstrating a solid understanding that I only
> see growing as time goes on.
>
> For sushy-core: Debayan Ray[3]. Debayan has been involved with the
> community for some time and has worked on sushy from early on in its
> life. He has indicated it is near and dear to him, and he has been
> actively reviewing and engaging in discussion on patchsets as his time
> has permitted.
>
> With any addition it is good to look at inactivity as well. It saddens
> me to say that we've had some contributors move on as priorities have
> shifted to where they are no longer involved with the ironic
> community. Each person listed below has been inactive for a year or
> more and is no longer active in the ironic community. As such I've
> removed their group membership from the sub-project core reviewer
> groups. Should they return, we will welcome them back to the community
> with open arms.
>
> bifrost-core: Stephanie Miller[4]
> ironic-inspector-core: Anton Arefivev[5]
> ironic-ui-core: Peter Peila[6], Beth Elwell[7]
>
> Thanks,
>
> -Julia
>
> [1]: http://stackalytics.com/?user_id=etingof=marks
> [2]: http://stackalytics.com/?user_id=kaifeng=marks
> [3]: http://stackalytics.com/?user_id=deray=marks=all
> [4]: http://stackalytics.com/?metric=marks=all_id=stephan
> [5]: http://stackalytics.com/?user_id=aarefiev=marks
> [6]: http://stackalytics.com/?metric=marks=all_id=ppiela
> [7]:
> http://stackalytics.com/?metric=marks=all_id=bethelwell=ironic-ui
>
> __
> 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

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Vladyslav Drok]

On Tue, Jun 26, 2018 at 5:14 PM Vladyslav Drok  wrote:

>
> On Tue, Jun 26, 2018 at 4:58 PM Takashi Yamamoto 
> wrote:
>
>> On Tue, Jun 26, 2018 at 10:13 PM, Doug Hellmann 
>> wrote:
>> > Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
>> >> Thanks a bunch for digging into this, Tony. I'll follow up with the
>> >> oauthlib maintainers and see if they'd be interested in these changes
>> >> upstream. If so, I can chip away at it. For now we'll have to settle
>> for
>> >> not treating warnings as errors to unblock our documentation gate [0].
>> >>
>> >> [0] https://review.openstack.org/#/c/577974/
>> >
>> > How are docstrings from a third-party library making their way into the
>> > keystone docs and breaking the build?
>>
>> in the same way that docstrings from os-vif affect networking-midonet
>> docs.
>> i.e. via class inheritance
>>
>> >
>> > Doug
>> >
>> >>
>> >> On 06/25/2018 07:27 PM, Tony Breeds wrote:
>> >> > On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
>> >> >> Keystone is hitting this, too [0]. I attempted the same solution
>> that
>> >> >> Tony posted, but no luck. I've even gone so far as removing every
>> >> >> comment from the module to see if that helps narrow down the problem
>> >> >> area, but sphinx still trips. The output from the error message
>> isn't
>> >> >> very descriptive either. Has anyone else had issues fixing this for
>> >> >> python comments, not just docstrings?
>> >> >>
>> >> >> [0] https://bugs.launchpad.net/keystone/+bug/1778603
>> >> > I did a little digging for the keystone problem and it's due to a
>> >> > missing ':' in
>> >> >
>> https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
>> >> >
>> >> > So the correct way to fix this is to correct that in oauthlib, get it
>> >> > released and use that.
>> >> >
>> >> > I hit additional problems in that enabling -W in oauthlib, to pevent
>> >> > this happening in the future, lead me down a rabbit hole I don't
>> really
>> >> > have cycles to dig out of.
>> >> >
>> >> > Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
>> >> > debugging but it isn't too hard to reproduce and someone that knows
>> more
>> >> > Sphinx will be able to understand the errors better than I can.
>> >> >
>> >> >
>> >> > [1] http://paste.openstack.org/show/724271/
>> >> >
>> >> > Yours Tony.
>>
>
> This also might be related to this thread, in ironic I can see the
> following while building the docs, apart from 'Bullet list ends without a
> blank line' issue:
>
> Warning, treated as error:
> /home/vlad/work/ironic/ironic/api/app.py:docstring of
> ironic.api.app.IronicCORS:1:Error in "wsme:service" directive:
> unknown option: "module".
>
> .. wsme:service:: None
>:module: ironic.api.app
>
>Bases: :class:`oslo_middleware.cors.CORS`
>
>Ironic-specific CORS class
>
>We're adding the Ironic-specific version headers to the list of simple
>headers in order that a request bearing those headers might be accepted
> by
>the Ironic REST API.
>
> I see that there is some code in wsmeext that should be dealing with that
> if I understand correctly --
> https://github.com/openstack/wsme/blob/0.8.0/wsmeext/sphinxext.py#L356-L357
>
> Sphinx version I have is 1.7.5.
>
> Several other folks indicated that they hit it with on fresh fedora.
>

It also appears that index of :module: entry has changed:

-> if ':module:' in self.directive.result[-1]:
(Pdb) self.directive.result
ViewList(['', '.. py:module:: ironic.api.app', '', '', '.. wsme:service::
None', '   :module: ironic.api.app', '', '   Bases:
:class:`oslo_middleware.cors.CORS`'],
items=[('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app', 0), ('/home/vlad/work/ironic/ironic/api/app.py:docstring
of ironic.api.app', 0),
('/home/vlad/work/ironic/ironic/api/app.py:docstring of ironic.api.app',
0), ('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS', 0),
('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS', 0),
('/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS', 0),
('/ho

Re: [openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Vladyslav Drok]

On Tue, Jun 26, 2018 at 4:58 PM Takashi Yamamoto 
wrote:

> On Tue, Jun 26, 2018 at 10:13 PM, Doug Hellmann 
> wrote:
> > Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
> >> Thanks a bunch for digging into this, Tony. I'll follow up with the
> >> oauthlib maintainers and see if they'd be interested in these changes
> >> upstream. If so, I can chip away at it. For now we'll have to settle for
> >> not treating warnings as errors to unblock our documentation gate [0].
> >>
> >> [0] https://review.openstack.org/#/c/577974/
> >
> > How are docstrings from a third-party library making their way into the
> > keystone docs and breaking the build?
>
> in the same way that docstrings from os-vif affect networking-midonet docs.
> i.e. via class inheritance
>
> >
> > Doug
> >
> >>
> >> On 06/25/2018 07:27 PM, Tony Breeds wrote:
> >> > On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
> >> >> Keystone is hitting this, too [0]. I attempted the same solution that
> >> >> Tony posted, but no luck. I've even gone so far as removing every
> >> >> comment from the module to see if that helps narrow down the problem
> >> >> area, but sphinx still trips. The output from the error message isn't
> >> >> very descriptive either. Has anyone else had issues fixing this for
> >> >> python comments, not just docstrings?
> >> >>
> >> >> [0] https://bugs.launchpad.net/keystone/+bug/1778603
> >> > I did a little digging for the keystone problem and it's due to a
> >> > missing ':' in
> >> >
> https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
> >> >
> >> > So the correct way to fix this is to correct that in oauthlib, get it
> >> > released and use that.
> >> >
> >> > I hit additional problems in that enabling -W in oauthlib, to pevent
> >> > this happening in the future, lead me down a rabbit hole I don't
> really
> >> > have cycles to dig out of.
> >> >
> >> > Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
> >> > debugging but it isn't too hard to reproduce and someone that knows
> more
> >> > Sphinx will be able to understand the errors better than I can.
> >> >
> >> >
> >> > [1] http://paste.openstack.org/show/724271/
> >> >
> >> > Yours Tony.
>

This also might be related to this thread, in ironic I can see the
following while building the docs, apart from 'Bullet list ends without a
blank line' issue:

Warning, treated as error:
/home/vlad/work/ironic/ironic/api/app.py:docstring of
ironic.api.app.IronicCORS:1:Error in "wsme:service" directive:
unknown option: "module".

.. wsme:service:: None
   :module: ironic.api.app

   Bases: :class:`oslo_middleware.cors.CORS`

   Ironic-specific CORS class

   We're adding the Ironic-specific version headers to the list of simple
   headers in order that a request bearing those headers might be accepted
by
   the Ironic REST API.

I see that there is some code in wsmeext that should be dealing with that
if I understand correctly --
https://github.com/openstack/wsme/blob/0.8.0/wsmeext/sphinxext.py#L356-L357

Sphinx version I have is 1.7.5.

Several other folks indicated that they hit it with on fresh fedora.


> >> >
> >> >
> >> >
> __
> >> > 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

Re: [openstack-dev] Proposing Mark Goddard to ironic-core

[Vladyslav Drok]

On Mon, May 21, 2018 at 4:49 PM Jim Rollenhagen 
wrote:

> On Sun, May 20, 2018 at 10:45 AM, Julia Kreger <
> juliaashleykre...@gmail.com> wrote:
>
>> Greetings everyone!
>>
>> I would like to propose Mark Goddard to ironic-core. I am aware he
>> recently joined kolla-core, but his contributions in ironic have been
>> insightful and valuable. The kind of value that comes from operative use.
>>
>> I also make this nomination knowing that our community landscape is
>> changing and that we must not silo our team responsibilities or ability to
>> move things forward to small highly focused team. I trust Mark to use his
>> judgement as he has time or need to do so. He might not always have time,
>> but I think at the end of the day, we’re all in that same boat.
>>
>
> +2!
>
> // jim
>

+1


>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Nominating Hironori Shiina for ironic-core

[Vladyslav Drok]

+1

On Mon, Feb 5, 2018 at 10:12 AM, Julia Kreger 
wrote:

> I would like to nominate Hironori Shiina to ironic-core. He has been
> working in the ironic community for some time, and has been helping
> over the past several cycles with more complex features. He has
> demonstrated an understanding of Ironic's code base, mechanics, and
> overall community style. His review statistics are also extremely
> solid. I personally have a great deal of trust in his reviews.
>
> I believe he would make a great addition to our team.
>
> Thanks,
>
> -Julia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystoneauth] [osc] [ironic] Usage of none loader in the CLI

[Vladyslav Drok]

On Wed, Oct 25, 2017 at 3:07 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> Hi!
>
> Thanks for raising this.
>
> On 10/19/2017 01:11 PM, Vladyslav Drok wrote:
>
>> Hi!
>>
>> I'd like to discuss the usage of the new noauth plugin to keystoneauth,
>> which was introduced in [1]. The docstring of the loader says it is
>> intended to be used during adapter initialization along with
>> endpoint_override. But what about the CLI usage in the OpenStack client? I
>> was trying to make the none loader work with baremetal plugin, as part of
>> testing [2], and encountered some problems, which are hacked around in [3].
>>
>> So, here are some questions:
>>
>> 1. Was it intended to be used in CLI at all, or should we still use the
>> token_endpoint?
>> 2. If it was intended, should we:
>>  2.1. do the hacks as in [3]?
>>
>
> I don't particularly like hardcoding an entrypoint name in the code here,
> to be honest.
>
>  2.2. introduce endpoint as an option for the none loader, making it a
>> bit similar to token_endpoint, with token hardcoded (and also get_endpoint
>> method to the auth plugin I think)?
>>
>
> I think that's the way to go, we should fix the none loader in
> keystoneauth.
>

I'll go with this option, Dean also suggested this in his review of [3]


>
>  2.3. leave it as-is, allowing the usage of none loader only by
>> specifying the parameters in the clouds.yaml, as in [4] for example?
>>
>
> That's not great. We're getting rid of the "ironic" command in favour of
> "openstack baremetal", but inability to properly use a no-auth mode hurts
> quite a few of our use cases (like Bifrost).
>
>
>> [1] https://review.openstack.org/469863 <https://review.openstack.org/
>> 469863>
>> [2] https://review.openstack.org/359061
>> [3] https://review.openstack.org/512699
>> [4] https://github.com/openstack/bifrost/blob/21ca45937a9cb36c6f
>> 04073182bf2edea8acbd5d/playbooks/roles/bifrost-keystone-client-config/
>> templates/clouds.yaml.j2#L17-L19
>>
>> Thanks,
>> Vlad
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [Openstack-operators] replace node "tags" with node "traits"

[Vladyslav Drok]

On Fri, Oct 27, 2017 at 12:19 AM, Jay Pipes  wrote:

> On 10/25/2017 12:55 PM, Mathieu Gagné wrote:
>
>> Hi,
>>
>> On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby  wrote:
>>
>>> Hello ironic'ers,
>>>
>>> A while ago, we approved a spec to add node tag support to ironic [1].
>>> The
>>> feature itself did not land yet (although some of the code has). Now that
>>> the (nova) community has come up with traits, ironic wants to support
>>> node
>>> traits, and there is a spec proposing that [2]. At the ironic node level,
>>> this is VERY similar to the node tag support, so the thought is to drop
>>> (not
>>> implement) the node tagging feature, since the node traits feature could
>>> be
>>> used instead. There are a few differences between the tags and traits.
>>> "Traits" means something in OpenStack, and there are some restrictions
>>> about
>>> it:
>>>
>>> - max 50 per node
>>>
>>> - names must be one of those in os-traits library OR prefixed with
>>> 'CUSTOM_'
>>>
>>> For folks that wanted the node tagging feature, will this new node traits
>>> feature work for your use case? Should we support both tags and traits? I
>>> was wondering about e.g. using ironic standalone.
>>>
>>> Please feel free to comment in [2].
>>>
>>> Thanks in advance,
>>>
>>> --ruby
>>>
>>> [1]
>>> http://specs.openstack.org/openstack/ironic-specs/specs/appr
>>> oved/nodes-tagging.html
>>>
>>> [2] https://review.openstack.org/#/c/504531/
>>>
>>>
>> Are tags/traits serving a different purpose? One serves the purpose of
>> helping the scheduling/placement while the other is more or less aims
>> at grouping for the "end users"?
>> I understand that the code will be *very* similar but who/what will be
>> the consumers/users?
>> I fell they won't be the same and could artificially limit its use due
>> to technical/design "limitations". (must be in os-traits or be
>> prefixed by CUSTOM)
>>
>> For example which I personally foresee:
>> * I might want to populate Ironic inventory from an external system
>> which would also injects the appropriate traits.
>> * I might also want some technical people to use/query Ironic and
>> allow them to tag nodes based on their own needs while not messing
>> with the traits part (as it's managed by an external system and will
>> influence the scheduling later)
>>
>> Lets not assume traits/tags have the same purpose and same user.
>>
>
> I agree with Matthieu 100% here.
>
> Traits are structured, formalized, and set by the system or the operator
> against resource providers.
>
> Tags are for end-users to, well, tag their instances with whatever strings
> they want.
>
> Best,
> -jay


I'd also vote for having them separate. We can refactor the common bits of
code instead.

-Vlad


>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystoneauth] [osc] [ironic] Usage of none loader in the CLI

[Vladyslav Drok]

Hi!

I'd like to discuss the usage of the new noauth plugin to keystoneauth,
which was introduced in [1]. The docstring of the loader says it is
intended to be used during adapter initialization along with
endpoint_override. But what about the CLI usage in the OpenStack client? I
was trying to make the none loader work with baremetal plugin, as part of
testing [2], and encountered some problems, which are hacked around in [3].

So, here are some questions:

1. Was it intended to be used in CLI at all, or should we still use the
token_endpoint?
2. If it was intended, should we:
2.1. do the hacks as in [3]?
2.2. introduce endpoint as an option for the none loader, making it a
bit similar to token_endpoint, with token hardcoded (and also get_endpoint
method to the auth plugin I think)?
2.3. leave it as-is, allowing the usage of none loader only by
specifying the parameters in the clouds.yaml, as in [4] for example?

[1] https://review.openstack.org/469863
[2] https://review.openstack.org/359061
[3] https://review.openstack.org/512699
[4]
https://github.com/openstack/bifrost/blob/21ca45937a9cb36c6f04073182bf2edea8acbd5d/playbooks/roles/bifrost-keystone-client-config/templates/clouds.yaml.j2#L17-L19

Thanks,
Vlad
__
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] Proposing Shivanand Tendulker for ironic-core

[Vladyslav Drok]

+1 for Shiv

On 3 Oct 2017 11:20 a.m., "Sam Betts (sambetts)"  wrote:

+1,



Sam



On 03/10/2017, 08:21, "tua...@vn.fujitsu.com"  wrote:



+1 , Yes, I definitely agree with you.



Regards

Tuan



*From:* Nisha Agarwal [mailto:agarwalnisha1...@gmail.com]
*Sent:* Tuesday, October 03, 2017 12:28 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [ironic] Proposing Shivanand Tendulker for
ironic-core



+1



Regards

Nisha



On Mon, Oct 2, 2017 at 11:13 PM, Loo, Ruby  wrote:

+1, Thx Dmitry for the proposal and Shiv for doing all the work :D



--ruby



*From: *Dmitry Tantsur 
*Reply-To: *"OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
*Date: *Monday, October 2, 2017 at 10:17 AM
*To: *"OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
*Subject: *[openstack-dev] [ironic] Proposing Shivanand Tendulker for
ironic-core



Hi all!

I would like to propose Shivanand (stendulker) to the core team.

His stats have been consistently high [1]. He has given a lot of insightful
reviews recently, and his expertise in the iLO driver is also very valuable
for the team.

As usual, please respond with your comments and objections.

Thanks,

Dmitry


[1] http://stackalytics.com/report/contribution/ironic-group/90


__
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





-- 

The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] ironic-staging-drivers core cleanup and additions

[Vladyslav Drok]

Hey Dmitry,

On Tue, Aug 22, 2017 at 12:24 PM, Dmitry Tantsur 
wrote:

> Hi all!
>
> This email concerns the ironic-staging-drivers project which is outside of
> the official Ironic governance. Please ignore it if you don't care about
> this project.
>
> I've checked the core [1] and the release [2] teams for the project, and I
> think they need an update based (see [3]).
>
> I suggest removing the following people:
> * Dan Prince (due to inactivity)
> * Lucas Alvares Gomes (due to priorities change)
> * Imre Farkas (no longer works on OpenStack)
>
> I suggest adding Pavlo Shchelokovskyy, who actively contributes to and
> reviews the project, to the core team.
>

++ to all of the changes.


> I've cc'ed affected people as I was a bit too lazy to reach to them on IRC
> :) Please let me know your opinion.
>
> [1] https://review.openstack.org/#/admin/groups/1258,members
> [2] https://review.openstack.org/#/admin/groups/1259,members
> [3] http://stackalytics.com/?module=ironic-staging-drivers=pike
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][python-ironicclient][keystoneauth] Getting rid of a custom HTTPClient implementation

[Vladyslav Drok]

Greetings!

I have a patch [0] to deprecate the custom HTTPClient implementation that
we have in python-ironicclient. Currently it is used when the 'ironic'
command is issued in a standalone mode, that is, with '--ironic-url' and
'--os-auth-token' parameters, or when a client is instantiated through the
following module [1] directly without passing the session object, or even
directly calling HTTPClient constructor at [2]. In other cases,
keystoneauth's SessionClient derivative object is used. [0] will basically
substitute the HTTPClient with the SessionClient (by using the
'admin_token' auth plugin). It seems like a breaking change, as most likely
some HTTP error codes and exceptions thrown may be different, so I think
we'll need the major client library version bump. We'll also make it clear
in the docs that the only "true" way for instantiating the client is
through 'get_client' method in [3].

After that, we'll need to remove the HTTPClient class completely, and here
a question is, whether we should have another major version bump? Or can we
remove it right away, and single major version bump should be enough? (as
the HTTPClient defined in [2] was not something we advertised as a part of
our public python API)

Any suggestions welcome :)

-Vlad

[0] https://review.openstack.org/359061
[1]
https://github.com/openstack/python-ironicclient/blob/master/ironicclient/v1/client.py
[2]
https://github.com/openstack/python-ironicclient/blob/master/ironicclient/common/http.py
[3]
https://github.com/openstack/python-ironicclient/blob/master/ironicclient/client.py
__
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] ipmitool

[Vladyslav Drok]

Hi Yuriy,

On Fri, Apr 21, 2017 at 12:59 PM, Yuriy Zveryanskyy <
yzveryans...@mirantis.com> wrote:

> Hi.
>
> After "ipminative" driver has been removed (I think it was right
> decision), we support IPMI in ironic only via drivers which use
> "ipmitool" utility.
> This utility is mostly good, but main problem is that running by
> ironic subprocess can be stalled on buggy/broken BMCs.
>

Here is one example of such issue -
https://bugs.launchpad.net/ironic/+bug/1683902, and a bit of comments about
the root cause in the eavesdrop

.


> This causes situations like stop executing of sync power state
> periodic task without any logging, reduce free green threads
> number in the conductor service pool etc.
> Administrators often have only one version of ipmitool in
> repository and should build new version from source for
> bug fixing.
> We can implement custom executor for ipmitool with timeout
> for process, but this adds more complexity to IPMI drivers,
> or maybe use another solution? Maybe we should have pure
> Python well tested IPMI library optimized for ironic (like sushy
> for RedFish)?
>

Or maybe work on improving pyghmi, and reintroduce the ipminative driver.


>
> Yuriy Zveryanskyy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [third-party-ci] pkvmci ironic job breakage details

[Vladyslav Drok]

Hey Michael,

On Fri, Apr 14, 2017 at 6:51 PM, Michael Turek 
wrote:

> Hey ironic-ers,
>
> So our third party CI job for ironic has been, and remains, broken. I was
> able to do some investigation today and here's a summary of what we're
> seeing. I'm hoping someone might know the root of the problem.
>
> For reference, please see this paste and the logs of the job that I was
> working in:
> http://paste.openstack.org/show/606564/
> https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-
> f597-448c-8ec2-164e9f710dd6/pkvmci/ironic/25/454625/10/
> check-ironic/tempest-dsvm-ironic-agent_ipmitool/0520958/
>
> I've redacted the credentials in the ironic node-show for obvious reasons
> but rest assured they are properly set. These commands are run while
> '/opt/stack/new/ironic/devstack/lib/ironic:wait_for_nova_resources' is
> looping.
>
> Basically, the ironic hypervisor for the node doesn't appear. As well,
> none of the node's properties make it to the hypervisor stats.
>
> Some more strangeness is that the 'count' value from the 'openstack
> hypervisor stats show'. Though no hypervisors appear, the count is still 1.
> Since the run was broken, I decided to delete node-0 (about 3-5 minutes
> before the run failed) and see if it updated the count. It did.
>
> Does anyone have any clue what might be happening here? Any advice would
> be appreciated!
>

So the failure seems to be here --
https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/ironic/25/454625/10/check-ironic/tempest-dsvm-ironic-agent_ipmitool/0520958/screen-ir-api.txt.gz,
API and conductor are not able to communicate via RPC for some reason. Need
to investigate this more. Do you mind filing a bug about this?


>
> Thanks,
> mjturek
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Translations removal

[Vladyslav Drok]

On Wed, Mar 22, 2017 at 12:10 AM, Taryma, Joanna 
wrote:

> Hi team,
>
>
>
> As discussed on Monday, logged messages shouldn’t be translated anymore.
> Exception messages still should be still translated.
>
> While removing usages of _LE, _LW, _LI should be fairly easy, some usages
> of _ may cause issues.
>
>
>
> Some messages in the code are declared with ‘_’ method and used both for
> logger and exception. This has to be changed, so we don’t have some log
> entries translated because of that.
>
> The best option in terms of code redundancy would be something like:
>
> msg = “”
>
> LOG.error(msg, {: })
>
> raise Exception(_(msg) % {: })
>
>
>
> However, pep8 does not accept passing variable to translation functions,
> so this results in ‘H701 Empty localization string’ error.
>
> Possible options to handle that:
>
> 1)   Duplicate messages:
>
> LOG.error(“”, {: })
>
> raise Exception(_(“”) % {: })
>
> 2)   Ignore this error
>
> 3)   Talk to hacking people about possible upgrade of this check
>
> 4)   Pass translated text to LOG in such cases
>
>
>
> I’d personally vote for 2. What are your thoughts?
>

I don't think we can simply ignore it --
https://docs.openstack.org/developer/oslo.i18n/guidelines.html#using-a-marker-function,
it is just a marker for i18n IIUC, and if we'll change to just doing
_(var), it will not be translated.

-Vlad


>
>
> Kind regards,
>
> Joanna
>
>
>
> [0] http://eavesdrop.openstack.org/irclogs/%23openstack-
> ironic/%23openstack-ironic.2017-03-21.log.html#t2017-03-21T14:00:49
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] End-of-Ocata core team updates

[Vladyslav Drok]

On Fri, Feb 17, 2017 at 11:40 AM, Dmitry Tantsur 
wrote:

> Hi all!
>
> I'd like to propose a few changes based on the recent contributor activity.
>
> I have two candidates that look very good and pass the formal barrier of 3
> reviews a day on average [1].
>
> First, Vasyl Saienko (vsaienk0). I'm pretty confident in him, his stats
> [2] are high, he's doing a lot of extremely useful work around networking
> and CI.
>

+1


>
> Second, Mario Villaplana (mariojv). His stats [3] are quite high too, he
> has been doing some quality reviews for critical patches in the Ocata cycle.
>

+1


>
> Active cores and interested contributors, please respond with your +-1 to
> these suggestions.
>
> Unfortunately, there is one removal as well. Devananda, our team leader
> for several cycles since the very beginning of the project, has not been
> active on the project for some time [4]. I propose to (hopefully temporary)
> remove him from the core team. Of course, when (look, I'm not even saying
> "if"!) he comes back to active reviewing, I suggest we fast-forward him
> back. Thanks for everything Deva, good luck with your current challenges!
>

+1 :( Many thanks to Devananda for all his work since the very start of the
project!

Vlad


>
> Thanks,
> Dmitry
>
> [1] http://stackalytics.com/report/contribution/ironic-group/90
> [2] http://stackalytics.com/?user_id=vsaienko=marks
> [3] http://stackalytics.com/?user_id=mario-villaplana-j=marks
> [4] http://stackalytics.com/?user_id=devananda=marks
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

[Vladyslav Drok]

On Wed, Jan 4, 2017 at 5:45 PM, Vladyslav Drok <vd...@mirantis.com> wrote:

> Thanks all for replies!
>
> On Tue, Jan 3, 2017 at 5:16 PM, Jay Faulkner <j...@jvf.cc> wrote:
>
>> Hey Vdrok, some comments inline.
>>
>> > On Dec 30, 2016, at 8:40 AM, Vladyslav Drok <vd...@mirantis.com> wrote:
>> >
>> > Hi all!
>> >
>> > There is a long standing problem of resources reporting in ironic virt
>> driver. It's described in a couple of bugs I've found - [0], [1]. Switching
>> to placement API will make things better, but still there are some problems
>> there. For example, there are cases when ironic needs to say "this node is
>> not available", and it reports the vcpus=memory_mb=local_gb as 0 in this
>> case. Placement API does not allow 0s, so in [2] it is proposed to remove
>> inventory records in this case.
>> >
>> > But the whole logic here [3] seems not that obvious to me, so I'd like
>> to discuss when do we need to report 0s to placement API. I'm thinking
>> about the following (copy-pasted from my comment on [2]):
>> >
>> >   • If there is an instance_uuid on the node, no matter what
>> provision/power state it's in, consider the resources as used. In case it's
>> an orphan, an admin will need to take some manual action anyway.
>>
>> This won’t work, because of https://bugs.launchpad.net/nova/+bug/1503453
>> — basically the Nova resource tracker checks, decides we’re lying about it
>> being used for an instance because Nova’s records don’t show we do, and it
>> reads the capacity to the pool.
>>
>
> Aha, I see, after looking at code a bit more and discussing with JayF,
> that happens during update_available_resource here
> https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636
> 829759b80f/nova/compute/resource_tracker.py#L921-L934, where "instances"
> are all instances assigned to current host and node. Though, I don't really
> like the fact that _used amount is greater than the 
> amount that is possible here - https://github.com/openstack/nova/blob/
> 372452a1f703115310ea3400f9f636829759b80f/nova/virt/ironic/
> driver.py#L301-L326, as it makes the free values reported to be negative
> (I can't find the place where they are set to 0 if negative). Maybe we
> could at least report 0 for both available and used amounts?
>

OK, I must be blind, it is set to 0 if negative here
https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/compute/resource_tracker.py#L938-L939,
so it should be fine, apart from the fact that used value will be greater
than available.


>
>
>>
>> Generally I agree with Jay Pipes’ comments — we should have available
>> resources for nodes that can be scheduled to, used resources for nodes with
>> with a nova instance, and report no resources whatsoever for nodes in an
>> unschedulable state, such as cleaning, enroll, etc.
>>
>> -
>> Jay Faulkner
>> OSIC
>>
>> >   • If there is no instance_uuid and a node is in cleaning/clean
>> wait after tear down, it is a part of normal node lifecycle, report all
>> resources as used. This means we need a way to determine if it's a manual
>> or automated clean.
>> >   • If there is no instance_uuid, and a node:
>> >   • has a bad power state or
>> >   • is in maintenance
>> >   • or actually in any other case, consider it unavailable,
>> report available resources = used resources = 0. Provision state does not
>> matter in this logic, all cases that we wanted to take into account are
>> described in the first two bullets.
>> >
>> > Any thoughts?
>> >
>> > [0]. https://bugs.launchpad.net/nova/+bug/1402658
>> > [1]. https://bugs.launchpad.net/nova/+bug/1637449
>> > [2]. https://review.openstack.org/414214
>> > [3]. https://github.com/openstack/nova/blob/1506c36b4446f6ba1487a
>> 2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262
>> >
>> > Happy holidays to everyone!
>> > -Vlad
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

[Vladyslav Drok]

Thanks all for replies!

On Tue, Jan 3, 2017 at 5:16 PM, Jay Faulkner <j...@jvf.cc> wrote:

> Hey Vdrok, some comments inline.
>
> > On Dec 30, 2016, at 8:40 AM, Vladyslav Drok <vd...@mirantis.com> wrote:
> >
> > Hi all!
> >
> > There is a long standing problem of resources reporting in ironic virt
> driver. It's described in a couple of bugs I've found - [0], [1]. Switching
> to placement API will make things better, but still there are some problems
> there. For example, there are cases when ironic needs to say "this node is
> not available", and it reports the vcpus=memory_mb=local_gb as 0 in this
> case. Placement API does not allow 0s, so in [2] it is proposed to remove
> inventory records in this case.
> >
> > But the whole logic here [3] seems not that obvious to me, so I'd like
> to discuss when do we need to report 0s to placement API. I'm thinking
> about the following (copy-pasted from my comment on [2]):
> >
> >   • If there is an instance_uuid on the node, no matter what
> provision/power state it's in, consider the resources as used. In case it's
> an orphan, an admin will need to take some manual action anyway.
>
> This won’t work, because of https://bugs.launchpad.net/nova/+bug/1503453
> — basically the Nova resource tracker checks, decides we’re lying about it
> being used for an instance because Nova’s records don’t show we do, and it
> reads the capacity to the pool.
>

Aha, I see, after looking at code a bit more and discussing with JayF, that
happens during update_available_resource here
https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/compute/resource_tracker.py#L921-L934,
where "instances" are all instances assigned to current host and node.
Though, I don't really like the fact that _used amount is greater
than the  amount that is possible here -
https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/virt/ironic/driver.py#L301-L326,
as it makes the free values reported to be negative (I can't find the place
where they are set to 0 if negative). Maybe we could at least report 0 for
both available and used amounts?


>
> Generally I agree with Jay Pipes’ comments — we should have available
> resources for nodes that can be scheduled to, used resources for nodes with
> with a nova instance, and report no resources whatsoever for nodes in an
> unschedulable state, such as cleaning, enroll, etc.
>
> -
> Jay Faulkner
> OSIC
>
> >   • If there is no instance_uuid and a node is in cleaning/clean
> wait after tear down, it is a part of normal node lifecycle, report all
> resources as used. This means we need a way to determine if it's a manual
> or automated clean.
> >   • If there is no instance_uuid, and a node:
> >   • has a bad power state or
> >   • is in maintenance
> >   • or actually in any other case, consider it unavailable,
> report available resources = used resources = 0. Provision state does not
> matter in this logic, all cases that we wanted to take into account are
> described in the first two bullets.
> >
> > Any thoughts?
> >
> > [0]. https://bugs.launchpad.net/nova/+bug/1402658
> > [1]. https://bugs.launchpad.net/nova/+bug/1637449
> > [2]. https://review.openstack.org/414214
> > [3]. https://github.com/openstack/nova/blob/
> 1506c36b4446f6ba1487a2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262
> >
> > Happy holidays to everyone!
> > -Vlad
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

[Vladyslav Drok]

Hi all!

There is a long standing problem of resources reporting in ironic virt
driver. It's described in a couple of bugs I've found - [0], [1]. Switching
to placement API will make things better, but still there are some problems
there. For example, there are cases when ironic needs to say "this node is
not available", and it reports the vcpus=memory_mb=local_gb as 0 in this
case. Placement API does not allow 0s, so in [2] it is proposed to remove
inventory records in this case.

But the whole logic here [3] seems not that obvious to me, so I'd like to
discuss when do we need to report 0s to placement API. I'm thinking about
the following (copy-pasted from my comment on [2]):


   - If there is an instance_uuid on the node, no matter what
   provision/power state it's in, consider the resources as used. In case it's
   an orphan, an admin will need to take some manual action anyway.
   - If there is no instance_uuid and a node is in cleaning/clean wait
   after tear down, it is a part of normal node lifecycle, report all
   resources as used. This means we need a way to determine if it's a manual
   or automated clean.
   - If there is no instance_uuid, and a node:
  - has a bad power state or
  - is in maintenance
  - or actually in any other case, consider it unavailable, report
  available resources = used resources = 0. Provision state does not matter
  in this logic, all cases that we wanted to take into account are
described
  in the first two bullets.


Any thoughts?

[0]. https://bugs.launchpad.net/nova/+bug/1402658
[1]. https://bugs.launchpad.net/nova/+bug/1637449
[2]. https://review.openstack.org/414214
[3].
https://github.com/openstack/nova/blob/1506c36b4446f6ba1487a2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262

Happy holidays to everyone!
-Vlad
__
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] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Vladyslav Drok]

On Wed, Dec 14, 2016 at 3:48 PM, Ian Cordasco 
wrote:

> -Original Message-
> From: Joshua Hesketh 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: December 14, 2016 at 06:56:22
> To: OpenStack Development Mailing List ,
> openstack-infra 
> Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls]
> Tagging liberty as EOL
>
> > The repos listed[0] have had stable/liberty branch removed and replaced
> > with a liberty-eol tag. Any open reviews have been abandoned.
> >
> > Please let me know if there are any mistakes or latecomers to the list.
> >
> > Cheers,
> > Josh
> >
> > [0]
> > https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> Glance was late to the party, but it should have had its liberty branches
> EOL'd as well.
>
> --
> Ian Cordasco
>

Also, after liberty was EOL'd and stable/liberty branches were removed,
liberty release note pages need to be updated to reference liberty-eol tag
instead of origin/stable/liberty, like done here
https://review.openstack.org/410798 as a temporary solution, until this is
fixed on the reno side (https://review.openstack.org/410792), if I get the
situation correctly.

-Vlad


>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Testing config drive creation in our CI

[Vladyslav Drok]

This makes sense to me. Another approach is here -
https://review.openstack.org/375467

Thanks,
Vlad

On Fri, Sep 23, 2016 at 2:37 PM, Dmitry Tantsur  wrote:

> Hi folks!
>
> We've found out that we're not testing creating of config drives in our
> CI. It ended up in one combination being actually broken (pxe_* + wholedisk
> + configdrive). I would like to cover this testing gap. Is there any
> benefit in NOT using config drives in all jobs? I assume we should not
> bother too much testing the metadata service, as it's not within our code
> base (unlike config drive).
>
> I've proposed https://review.openstack.org/375362 to switch our tempest
> plugin to testing config drives, please vote. As you see one job fails on
> it - this is the breakage I was talking about. It will (hopefully) get
> fixed with the next release of ironic-lib.
>
> Finally, we need to run all jobs on ironic-lib, not only one, as
> ironic-lib is not the basis for all deployment variants. This will probably
> happen after we switch our DSVM jobs to Xenial though.
>
> -- Dmitry
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Future of cleaning when in maintenance mode

[Vladyslav Drok]

On 8 Sep 2016 10:12 a.m., "Dmitry Tantsur"  wrote:
>
> On 09/07/2016 05:25 PM, Dmitry Tantsur wrote:
>>
>> Hi all!
>>
>> Today while playing with my installation I noticed that we do try to run
>> cleaning for nodes in maintenance mode. This leads to a somewhat
>> confusing result, because we no-op heartbeats for such nodes. So
>> cleaning gets stuck in "clean wait" forever [1].
>>
>> However, it seems like some folks find it a convenient feature. This way
>> they can ask Ironic to boot the ramdisk and make it wait for operator's
>> commands. It's a fair use case, but I still find the current situation
>> confusing.
>>
>> We've ended up with these few options:
>>
>> 1. Ensure we don't run cleaning for nodes in maintenance mode. I've
>> proposed a patch [2] banning most of provision verbs from working in
>> maintenance. However, we still want to allow deleting an instance, which
>> still results in cleaning.
>>
>> 2. On receiving a heartbeat in {CLEAN,DEPLOY}WAIT and maintenance on
>> [3], move the node to {CLEAN,DEPLOY}FAIL (optionally without powering it
>> off, so that IPA stays running).
>
>
> It looks like this approach does not cause contention, so I'll look into
it first. I will keep patch for option #1 around as well, in case we want
to explore it.
>

Yes, this is what makes the most sense to me with leaving the possibility
to launch ramdisk, so my vote is for #2. Thanks Dmitry!

>
>>
>> 3. Document this as a desired feature and don't change anything.
>>
>> What do you think?
>>
>> [1] https://bugs.launchpad.net/ironic/+bug/1621006
>> [2] https://review.openstack.org/#/c/366793/
>> [3]
>>
https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/agent_base_vendor.py#L474-L478
.
>>
>>
>>
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] should we provide 'ironic node-list --chassis' and 'ironic port-list --node' commands?

[Vladyslav Drok]

The ironic node-list --chassis seems to be easier to understand for me.
I've commented on one of the patches that maybe we should deprecate the
chassis-node-list if we add this, but then, the deprecation is slow, we
have some functional tests already... Having two commands kind of reflects
the duplication in our API, where we can do /chassis//nodes and
/nodes?chassis_uuid=, so maybe having both of them is fine.

Vlad

On Mon, Aug 29, 2016 at 7:22 PM, Loo, Ruby  wrote:

> Hi,
>
>
>
> While working on the openstackclient plugin commands for ironic, I was
> thinking about the equivalents for 'ironic chassis-node-list' (nodes that
> are part of specified chassis) and 'ironic-node-port-list' (ports that are
> part of specified node). It didn't make sense to me to have an 'openstack
> baremetal chassis node list', since a 'chassis' and a 'node' are two
> different objects in osc lingo and we already have 'openstack baremetal
> chassis xx' and 'openstack baremetal node yy' commands. Furthermore, our
> REST API supports 'GET /v1/nodes?chassis=c1' and 'GET /v1/ports?node=n1'.
>
>
>
> So I proposed 'openstack baremetal node list --chassis' and 'openstack
> baremetal port list --node' [1]. To implement this, I need to enhance our
> corresponding python APIs. The question I have is whether we want to only
> enhance the python API, or also provide 'ironic node-list --chassis' and
> 'ironic port-list --node' commands. The latter is being proposed [2] and
> coded at [3]. Doing this would mean two different ironic CLIs to do the
> same thing, but also provide a more obvious 1:1 correspondence between
> ironic & osc commands, and between ironic CLI and python API.
>
>
>
> Thoughts?
>
>
>
> It'd be great if we could decide in the next day or so, in order to get
> the osc-related commands into the client this week for the Newton release.
>
>
>
> --ruby
>
>
>
> [1] http://specs.openstack.org/openstack/ironic-specs/specs/
> approved/ironicclient-osc-plugin.html#openstack-baremetal-node
>
> [2] https://launchpad.net/bugs/1616242
>
> [3] https://review.openstack.org/#/c/359520/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

[Vladyslav Drok]

On Mon, Aug 22, 2016 at 9:48 PM, Loo, Ruby  wrote:

> Hi,
>
>
>
> I admit, I didn't read the entire thread [0], but did read the summary
> [1]. I like this, except that I'm not sure about #3. What's the rationale
> of adding a new config option 'enable_unsupported_drivers' that defaults to
> False. Versus not having it, and "just" logging a warning if they are
> loading an unsupported (in-tree) driver?
>
>
>
> If I understand this...
>
>
>
> If we have 'enable_unsupported_drivers': since it defaults to False, the
> conductor will fail on startup, if an unsupported driver is in the
> enabled_drivers config. (The conductor will emit a warning in the logs, or
> maybe it won't?) The operator (if they haven't changed it), will now change
> it to True if they want to use any unsupported drivers. The conductor will
> start up and emit a warning in the logs.
>
>
>
> If we don't have an enable_unsupported_drivers config, will the conductor
> start up and emit a warning in the logs?
>

We have not added any deprecation warnings to drivers. I think that just
gives a bit more time to switch to other drivers and it will make the
removal more visible, as the current spec states: "Third party driver teams
that do not implement a reliable reporting CI test system by the N release
feature freeze (see Deliverable milestones above) will be removed from the
ironic source tree.", IIUC meaning that conductor will fail startup not
being able to find the removed code.


>
>
> I was also wondering, where is the value for the 'supported' flag for each
> driver going to be kept? Hard-coded in the driver code?
>

Yep, seems like it.


>
>
> --ruby
>
>
>
>
>
> On 2016-08-19, 10:15 AM, "Jim Rollenhagen"  wrote:
>
>
>
> Hi Ironickers,
>
>
>
> There was a big thread here[0] about Cinder, driver removal, and standard
>
> deprecation policy. If you haven't read through it yet, please do before
>
> continuing here. :)
>
>
>
> The outcome of that thread is summarized well here.[1]
>
>
>
> I know that I previously had a different opinion on this, but I think we
>
> should go roughly the same route, for the sake of the users.
>
>
>
> 1) A ``supported`` flag for each driver that is True if and only if the
> driver
>
>is tested in infra or third-party CI (and meets our third party CI
>
>requirements).
>
> 2) If the supported flag is False for a driver, deprecation is implied (and
>
>a warning is emitted at load time). A driver may be removed per standard
>
>deprecation policies, with turning the supported flag False to start the
>
>clock.
>
> 3) Add a ``enable_unsupported_drivers`` config option that allows enabling
>
>drivers marked supported=False. If a driver is in enabled_drivers, has
>
>supported=False, and enable_unsupported_drivers=False, ironic-conductor
>
>will fail to start. Setting enable_unsupported_drivers=True will allow
>
>ironic-conductor to start with warnings emitted.
>
>
>
> It is important to note that (3) does still technically break the standard
>
> deprecation policy (old config may not work with new version of ironic).
>
> However, this is a much softer landing than the original plan. FWIW, I do
>
> expect (but not hope!) this part will be somewhat contentious.
>
>
>
> I'd like to hear thoughts and get consensus on this from the rest of the
>
> ironic community, so please do reply whether you agree or disagree.
>
>
>
> I'm happy to do the work required (update spec, code patches, doc updates)
>
> when we do come to agreement.
>
>
>
> // jim
>
>
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101428.html
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101898.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
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

[Vladyslav Drok]

+1 from me then :)

On Mon, Aug 22, 2016 at 4:52 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> On Mon, Aug 22, 2016 at 8:01 AM, Vladyslav Drok <vd...@mirantis.com>
> wrote:
> > On Fri, Aug 19, 2016 at 5:15 PM, Jim Rollenhagen <j...@jimrollenhagen.com
> >
> > wrote:
> >>
> >> Hi Ironickers,
> >>
> >> There was a big thread here[0] about Cinder, driver removal, and
> standard
> >> deprecation policy. If you haven't read through it yet, please do before
> >> continuing here. :)
> >>
> >> The outcome of that thread is summarized well here.[1]
> >>
> >> I know that I previously had a different opinion on this, but I think we
> >> should go roughly the same route, for the sake of the users.
> >>
> >> 1) A ``supported`` flag for each driver that is True if and only if the
> >> driver
> >>is tested in infra or third-party CI (and meets our third party CI
> >>requirements).
> >> 2) If the supported flag is False for a driver, deprecation is implied
> >> (and
> >>a warning is emitted at load time). A driver may be removed per
> >> standard
> >>deprecation policies, with turning the supported flag False to start
> >> the
> >>clock.
> >> 3) Add a ``enable_unsupported_drivers`` config option that allows
> enabling
> >>drivers marked supported=False. If a driver is in enabled_drivers,
> has
> >>supported=False, and enable_unsupported_drivers=False,
> ironic-conductor
> >>will fail to start. Setting enable_unsupported_drivers=True will
> allow
> >>ironic-conductor to start with warnings emitted.
> >
> >
> > Just for clarity, its default value is False?
>
> Sorry, I meant to add that. Yes, default for
> enable_unsupported_drivers is False.
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

[Vladyslav Drok]

On Fri, Aug 19, 2016 at 5:15 PM, Jim Rollenhagen 
wrote:

> Hi Ironickers,
>
> There was a big thread here[0] about Cinder, driver removal, and standard
> deprecation policy. If you haven't read through it yet, please do before
> continuing here. :)
>
> The outcome of that thread is summarized well here.[1]
>
> I know that I previously had a different opinion on this, but I think we
> should go roughly the same route, for the sake of the users.
>
> 1) A ``supported`` flag for each driver that is True if and only if the
> driver
>is tested in infra or third-party CI (and meets our third party CI
>requirements).
> 2) If the supported flag is False for a driver, deprecation is implied (and
>a warning is emitted at load time). A driver may be removed per standard
>deprecation policies, with turning the supported flag False to start the
>clock.
> 3) Add a ``enable_unsupported_drivers`` config option that allows enabling
>drivers marked supported=False. If a driver is in enabled_drivers, has
>supported=False, and enable_unsupported_drivers=False, ironic-conductor
>will fail to start. Setting enable_unsupported_drivers=True will allow
>ironic-conductor to start with warnings emitted.
>

Just for clarity, its default value is False?


>
> It is important to note that (3) does still technically break the standard
> deprecation policy (old config may not work with new version of ironic).
> However, this is a much softer landing than the original plan. FWIW, I do
> expect (but not hope!) this part will be somewhat contentious.
>
> I'd like to hear thoughts and get consensus on this from the rest of the
> ironic community, so please do reply whether you agree or disagree.
>
> I'm happy to do the work required (update spec, code patches, doc updates)
> when we do come to agreement.
>
> // jim
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101428.html
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/101898.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
>
__
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] why do we need setting network driver per node?

[Vladyslav Drok]

Thanks for bringing this up Dmitry, here are my thoughts on this.

Another case is an out-of-tree network driver, that can basically do
whatever an operator needs to, and may have some parameters defined in
driver_info as is the case for most of other interfaces ironic drivers have.

I think neutron and flat drivers coexistence in the same deployment is
unlikely, but neutron and none or flat and none seems to be valid case. As
for nova, this might be as easy as adding an availability zone with nodes
that have network isolation enabled.

Also, with all the driver composition work, I think we don't want to have
some weird things like dhcp providers anymore and go further with
interfaces. And if it is an interface, it should be considered as such (the
basic spec containing most of the requirements is merged, and we can use it
to make network interface as close to the spec as possible, while not going
too far, as multitenancy slipping another release would be very bad). There
might be some caveats with backwards compatibility in this particular case,
but they're all solvable.

Thanks,
Vlad

On Tue, Jun 28, 2016 at 7:08 PM, Mathieu Mitchell 
wrote:

> Following discussion on IRC, here are my thoughts:
>
> The proposed network_interface allows choosing a "driver" for the network
> part of a node. The values could be something like "nobody", "neutron-flat
> networking" and "neutron-tenant separation".
>
> I think this choice should be left per-node. My reasoning is that you
> could have a bunch of nodes for which you have complete Neutron support,
> through for example an ML2 plugin. These nodes would be configured using
> one of the "neutron-*" modes.
>
> On the other hand, that same Ironic installation could also manage nodes
> for which the switches are unmanaged, or manually configured. In such case,
> you would probably want to use the "nobody" mode.
>
> An important point is to expose this "capability" to Nova as you might
> want to offer nodes with neutron integration differently from "any node". I
> am unsure if the capability should be the value of the network_interface or
> a boolean "neutron integration?". Thoughts?
>
> Mathieu
>
>
> On 2016-06-28 11:32 AM, Dmitry Tantsur wrote:
>
>> Hi folks!
>>
>> I was reviewing https://review.openstack.org/317391 and realized I don't
>> quite understand why we want to have node.network_interface. What's the
>> real life use case for it?
>>
>> Do we expect some nodes to use Neutron, some - not?
>>
>> Do we expect some nodes to benefit from network separation, some - not?
>> There may be a use case here, but then we have to expose this field to
>> Nova for scheduling, so that users can request a "secure" node or a
>> "less secure" one. If we don't do that, Nova will pick at random, which
>> makes the use case unclear again.
>> If we do that, the whole work goes substantially beyond what we were
>> trying to do initially: isolate tenants from the provisioning network
>> and from each other.
>>
>> Flexibility it good, but the patches raise upgrade concerns, because
>> it's unclear how to provide a good default for the new field. And anyway
>> it makes the whole thing much more complex than it could be.
>>
>> Any hints are welcome.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Proposing two new cores

[Vladyslav Drok]

+1 from me, both Jay and Sam are doing very good job :)

On Thu, Jun 16, 2016 at 6:20 PM, Lucas Alvares Gomes 
wrote:

> Hi,
>
> > Both Sam and Jay are to the point where I consider their +1 or -1 as
> > highly as any other core, so I think it's past time to allow them to +2
> > as well.
> >
> > Current cores, please reply with your vote.
> >
>
> Great work Sam and Jay!
>
> +1 for both
>
> Cheers,
> Lucas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] looking for documentation liaison

[Vladyslav Drok]

Hi,

I "like" documentation, so if you won't find anyone that "loves" it,
consider me a candidate :)

- Vlad

On Tue, May 31, 2016 at 8:23 PM, Loo, Ruby  wrote:

> Hi,
>
> We¹re looking for a documentation liaison [1]. If you love (Œlike¹ is also
> acceptable) documentation, care that ironic has great documentation, and
> would love to volunteer, please let us know.
>
> The position would require you to:
>
> - attend the weekly doc team meetings [2] (or biweekly, depending on which
> times work for you), and represent ironic
> - attend the weekly ironic meetings[3] and report (via the subteam
> reports) on anything that may impact ironic
> - open bugs/whatever to track getting any documentation-related work done.
> You aren¹t expected to do the work yourself although please do if you¹d
> like!
> - know the general status of ironic documentation
> - see the expectations mentioned at [1]
>
> Please let me know if you have any questions. Thanks and may the best
> candidate win ?
>
> --ruby
>
> [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation
> [2] https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting
> [3] https://wiki.openstack.org/wiki/Meetings/Ironic
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][qa][ironic][nova] When Nova should mark instance as successfully deleted?

[Vladyslav Drok]

On Fri, May 27, 2016 at 5:52 PM, Vasyl Saienko 
wrote:

> Lucas, Andrew
>
> Thanks for fast response.
>
> On Fri, May 27, 2016 at 4:53 PM, Andrew Laski  wrote:
>
>>
>>
>> On Fri, May 27, 2016, at 09:25 AM, Lucas Alvares Gomes wrote:
>> > Hi,
>> >
>> > Thanks for bringing this up Vasyl!
>> >
>> > > At the moment Nova with ironic virt_driver consider instance as
>> deleted,
>> > > while on Ironic side server goes to cleaning which can take a while.
>> As
>> > > result current implementation of Nova tempest tests doesn't work for
>> case
>> > > when Ironic is enabled.
>>
>> What is the actual failure? Is it a capacity issue because nodes do not
>> become available again quickly enough?
>>
>>
> The actual failure is that temepest community doesn't want to accept 1
> option.
> https://review.openstack.org/315422/
> And I'm not sure that it is the right way.
>

The reason this was added was to make tempest smoke tests (as part of
grenade) to pass on a limited amount of nodes (which was 3 initially). Now
we have 7 nodes created in the gate, so we might be OK running grenade, but
we can't increase concurrency to something more than 1 in this case. Maybe
we should run our own tests, not smoke, as part of grenade?


>
> > >
>> > > There are two possible options how to fix it:
>> > >
>> > >  Update Nova tempest test scenarios for Ironic case to wait when
>> cleaning is
>> > > finished and Ironic node goes to 'available' state.
>> > >
>> > > Mark instance as deleted in Nova only after cleaning is finished on
>> Ironic
>> > > side.
>> > >
>> > > I'm personally incline to 2 option. From user side successful instance
>> > > termination means that no instance data is available any more, and
>> nobody
>> > > can access/restore that data. Current implementation breaks this rule.
>> > > Instance is marked as successfully deleted while in fact it may be not
>> > > cleaned, it may fail to clean and user will not know anything about
>> it.
>> > >
>
> >
>> > I don't really like option #2, cleaning can take several hours
>> > depending on the configuration of the node. I think that it would be a
>> > really bad experience if the user of the cloud had to wait a really
>> > long time before his resources are available again once he deletes an
>> > instance. The idea of marking the instance as deleted in Nova quickly
>> > is aligned with our idea of making bare metal deployments
>> > look-and-feel like VMs for the end user. And also (one of) the
>> > reason(s) why we do have a separated state in Ironic for DELETING and
>> > CLEANING.
>>
>
> The resources will be available only if there are other available
> baremetal nodes in the cloud.
> User doesn't have ability to track for status of available resources
> without admin access.
>
>
>> I agree. From a user perspective once they've issued a delete their
>> instance should be gone. Any delay in that actually happening is purely
>> an internal implementation detail that they should not care about.
>>
>> >
>> > I think we should go with #1, but instead of erasing the whole disk
>> > for real maybe we should have a "fake" clean step that runs quickly
>> > for tests purposes only?
>> >
>>
>
> At the gates we just waiting for bootstrap and callback from node when
> cleaning starts. All heavy operations are postponed. We can disable
> automated_clean, which means it is not tested.
>
>
>> > Cheers,
>> > Lucas
>> >
>> >
>> __
>> > 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

Re: [openstack-dev] [ironic] usage of ironic-lib

[Vladyslav Drok]

On Thu, May 19, 2016 at 6:16 PM, Lucas Alvares Gomes 
wrote:

> Hi,
>
> > So… how does any library get ready to be used by others? Clearly it is
> being
> > used now by the fuel-agent. Do we say ‘sorry fuel-agent, we don’t
> guarantee
> > yet that we won’t break you’? Or ‘fuel-agent, just so you know.
> Ironic-lib
> > isn’t quite ready to be used so we cannot guarantee that we won’t break
> you
> > but we will try our best not to do so’? Or… ?
> >
>
> Yes, I think we should say sorry for not communicating this well and
> then fix our stuff, i.e Add a note to the ironic-lib README, indicate
> that it's ironic use only in the governance description, send an email
> to the ML, etc... Fortunately, fuel-agent only uses a tiny function
> [0] of the library which can easily be copied into fuel's repository
> and have the ironic-lib dependency dropped, here's a patch [1].
>

Agree with this, as it was not designed for general use and we proposed
a fix before breaking people, I think it's fine, maybe we need to update
the ironic-lib README to mention all the things discussed in this thread.


>
>
> > What needs to be done for ironic-lib to be officially used by anyone?
> Lucas
> > mentioned some things. Is that all? Do we open bugs for them? At what
> point
> > would we feel comfortable saying ‘yes, here’s a library that can be used
> by
> > anyone?’
> >
>
> I think the library should then be architect with that in mind, the
> methods should be flexible so they can be extended, methods should be
> less opinionated (i.e see work_on_disk()[2], it does partition the
> disk for the ironic use case), we should have a proper documentation,
> should be independent of the Ironic project (e.g ironic-lib _right
> now_ depends on the ironic-rootwrap command, which is create by
> installing ironic), etc... IMO That would be a good starting point.
>
> If it is agreed that we want this library to be generic, then yes we
> should open bugs against it.


> [0]
> https://github.com/openstack/fuel-agent/blob/master/contrib/ironic/ironic-fa-deploy/ironic_fa_deploy/modules/fuel_agent.py#L288
> [1] https://review.openstack.org/#/c/318724/
> [2]
> https://github.com/openstack/ironic-lib/blob/adedae3915b5f4e9104b2a3f1f5d0413457fa8db/ironic_lib/disk_utils.py#L387
>
> As a note and not OpenStack specific, here's a great talk by Michael
> Kerrisk about the (ideal) process of designing a Linux kernel
> interfaces. It's not a tech talk, it's just about the process and
> common errors and how they can be avoided:
>
> http://bofh.nikhef.nl/events/FOSDEM/2016/janson/how-to-design-a-linux-kernel-api.mp4
>
> Hope that helps,
> Lucas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic-staging-drivers] Tests at the gates

[Vladyslav Drok]

It seems that all the drivers' dependencies currently present in ironic
tree can be installed
from binary packages, so maybe we could make use of bindep. But what if
some driver
will require addition of some custom repository, it will have to go
directly to plugin.sh?
Also, after e.g. gate switch to ubuntu 16.04, some of packages may break
(e.g. pywsman
states that it has been tested only on ubuntu 14.04), we should disable
those broken
drivers and require maintainers to fix things, is there any time frame set
for this?

On Thu, Apr 21, 2016 at 11:26 AM, Andreas Jaeger  wrote:

> On 2016-04-21 10:20, Vasyl Saienko wrote:
> > Hello Andreas,
> >
> > Thanks for comment, I didn't know about other-requirements.
> >
> > There is a tool 'bindep' [0] that allows to parse other-requirements.txt
> > It is possible to mix python/system dependencies in single
> > other-requirements.txt. But mixing packages from different distros are
> > not supported.
>
> other-requirements.txt only handles binary distro packages, you can mix
> different distros.
>
> > Also it doesn't allow to install dependencies from sources. I'm not sure
> > that it is what we need.
>
> Then, please name what you do differently to avoid confusion.
>
> > I would prefer to have shell script that is maintained by driver's owner
> > and provides complete freedom in configuration.
>
> Do you really need that?
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [api] Fixing bugs in old microversions

[Vladyslav Drok]

Thank you Jay, Dmitry and Sean for your input! On the yesterday's ironic
meeting the consensus
was to leave the removal possibility in older api versions and not to
bikeshed with new microversions.

Vlad

On Mon, Apr 11, 2016 at 5:36 PM, Jay Pipes <jaypi...@gmail.com> wrote:

> On 04/11/2016 10:11 AM, Sean Dague wrote:
>
>> On 04/11/2016 09:54 AM, Jay Pipes wrote:
>>
>>> On 04/11/2016 09:48 AM, Dmitry Tantsur wrote:
>>>
>>>> On 04/11/2016 02:00 PM, Jay Pipes wrote:
>>>>
>>>>> On 04/11/2016 04:48 AM, Vladyslav Drok wrote:
>>>>>
>>>>>> Hi all!
>>>>>>
>>>>>> There is a bug <https://bugs.launchpad.net/ironic/+bug/1565663> in
>>>>>> ironic API that allows to remove node name using any API version,
>>>>>> while node names were added in version 1.5. There are concerns that
>>>>>> fixing this might
>>>>>> be a breaking change, and I'm not sure how to proceed with that.
>>>>>> Here is
>>>>>> a change <https://review.openstack.org/300983> that
>>>>>> fixes the bug by just forbidding to do PATCH remove request on /name
>>>>>> path if requested
>>>>>> API version is less than 1.5. Is it enough to just mention this in a
>>>>>> release note, maybe
>>>>>> both in fixes and upgrade sections? As bumping API microversion to fix
>>>>>> some previous
>>>>>> microversion seems weird to me.
>>>>>>
>>>>>> Any suggestions?
>>>>>>
>>>>>
>>>>> I think the approach you've taken -- just fix it and not add a new
>>>>> microversion -- is the correct approach.
>>>>>
>>>>
>>>> Do we really allow breaking API changes, covering old microversions?
>>>>
>>>
>>> Generally we have said that if a patch is fixing only an error response
>>> code (as would be the case here -- changing from a 202 to a 400 when
>>> name is attempted to be changed) then it doesn't need a microversion.
>>>
>>> Sean, am I remembering that correctly?
>>>
>>
>> No, in Nova land a 2xx -> 4xx would use a microversion. These sorts of
>> things actually break people (we've seen it happen in Tempest / Shade).
>>
>> Fixing a 5xx does not, as the server is never supposed to 5xx. 5xx is
>> always a bug.
>>
>
> OK, my apologies Vlad and Dmitry. This is why I defer to Sean :)
>
> 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-dev] [ironic] [api] Fixing bugs in old microversions

[Vladyslav Drok]

Hi all!

There is a bug  in ironic
API that allows to remove node name using any API version,
while node names were added in version 1.5. There are concerns that fixing
this might
be a breaking change, and I'm not sure how to proceed with that. Here is a
change  that
fixes the bug by just forbidding to do PATCH remove request on /name path
if requested
API version is less than 1.5. Is it enough to just mention this in a
release note, maybe
both in fixes and upgrade sections? As bumping API microversion to fix some
previous
microversion seems weird to me.

Any suggestions?

Thanks,
Vlad
__
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] [inspector] Proposing Anton Arefiev (aarefiev) for ironic-inspector-core

[Vladyslav Drok]

Not sure if I'm eligible to vote, but his reviews are insightful, so +1
from me. Congrats! :)

On Tue, Apr 5, 2016 at 3:22 PM, Imre Farkas  wrote:

> +1 from me. Thanks for your work Anton and congrats! ;-)
>
> Imre
>
>
>
> On 04/05/2016 12:24 PM, Dmitry Tantsur wrote:
>
>> Hi!
>>
>> I'd like to propose Anton to the ironic-inspector core reviewers team.
>> His stats are pretty nice [1], he's making meaningful reviews and he's
>> pushing important things (discovery, now tempest).
>>
>> Members of the current ironic-inspector-team and everyone interested,
>> please respond with your +1/-1. A lazy consensus will be applied: if
>> nobody objects by the next Tuesday, the change will be in effect.
>>
>> Thanks
>>
>> [1] http://stackalytics.com/report/contribution/ironic-inspector/60
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Nominating Julia Kreger for core reviewer

[Vladyslav Drok]

+1!

On Fri, Mar 25, 2016 at 4:03 AM, Zhenguo Niu  wrote:

> +1, thanks for all the hard work Julia!
>
> On Fri, Mar 25, 2016 at 8:39 AM, 守屋哲 / MORIYA，SATORU <
> satoru.moriya...@hitachi.com> wrote:
>
>> +1 for me. She has given lots of valuable reviews to boot from volume
>> effort.
>> Thanks Julia!
>>
>> Satoru
>>
>> > -Original Message-
>> > From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
>> > Sent: Friday, March 25, 2016 4:09 AM
>> > To: openstack-dev@lists.openstack.org
>> > Subject: [!][openstack-dev] [ironic] Nominating Julia Kreger for core
>> reviewer
>> >
>> > Hey all,
>> >
>> > I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
>> > the Bifrost project, gives super valuable reviews, is beginning to lead
>> > the boot from volume efforts, and is clearly an expert in this space.
>> >
>> > All in favor say +1 :)
>> >
>> > // jim
>> >
>> >
>> __
>> > 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
>>
>
>
>
> --
> Best Regards,
> Zhenguo Niu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] A strange transition in Ironic FSM

[Vladyslav Drok]

Hi all,

Looking at the state machine spec
,
this might be a leftover from the older state machine.
When the node is in deleting state, we only clean up the kernel/ramdisk and
clear DHCP
options, so rebuild may be completed successfully afterwards. I agree that
this transition
does not make much sense, and removing it will help fixing the bug you've
referenced,
but I'm not sure how to handle backwards compatibility in this case (and
whether we need
to do this).

Vlad

On Fri, Feb 5, 2016 at 4:00 PM, Yuriy Zveryanskyy  wrote:

> Hi.
>
> We have a followed transition in common/states.py:
>
> # An errored instance can be rebuilt
> # ironic/conductor/manager.py:do_node_deploy()
> machine.add_transition(ERROR, DEPLOYING, 'rebuild')
>
> At first glance it looks correct. But ERROR state is
> used only for error after deleting, see
> http://docs.openstack.org/developer/ironic/_images/states.svg
> So ERROR is delete error, at least now, and transition
> error (delete error) -> deploying (on_rebuild)
> is possible.
> Looks strange if operator wants to remove an instance completely and then
> does rebuild after error (non-error targets for deleting is cleaning ->
> available).
> I think this transition should be removed. Without this strange transition
> bug https://bugs.launchpad.net/ironic/+bug/1522008 can be fixed by simple
> way,
> port's vif id can be removed via Ironic virt driver request before waiting
> of CLEANING
> (it's no more needed).
>
> Yuriy Zveryanskyy
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [ironic] Hardware composition

[Vladyslav Drok]

Hi list!

There is an idea of making use of hardware composition (e.g.
http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-architecture-resources.html)
to create nodes for ironic.

The current proposal is:

1. To create hardware-compositor service under ironic umbrella to manage
this composition process. Its initial implementation will support Intel
RSA, other technologies may be added in future. At the beginning, it will
contain the most basic CRUD logic for composed system.

2. Add logic to nova to compose a node using this new project and register
it in ironic if the scheduler is not able to find any ironic node matching
the flavor. An alternative (as pointed out by Devananda during yesterday's
meeting) could be using it in ironic by claims API when it's implemented (
https://review.openstack.org/204641).

3. If implemented in nova, there will be no changes to ironic right now
(apart from needing the driver to manage these composed nodes, which is
redfish I beleive), but there are cases when it may be useful to call this
service from ironic directly, e.g. to free the resources when a node is
deleted.

Thoughts?

Thanks,
Vlad
__
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] Redfish drivers in ironic

[Vladyslav Drok]

On Fri, Nov 20, 2015 at 1:50 AM, Bruno Cornec <bruno.cor...@hpe.com> wrote:

> Hello,
>
> Vladyslav Drok said on Thu, Nov 19, 2015 at 03:59:41PM +0200:
>
>> Hi list and Bruno,
>>
>> I’m interested in adding virtual media boot interface for redfish (
>> https://blueprints.launchpad.net/ironic/+spec/redfish-virtual-media-boot
>> ).
>> It depends on
>> https://blueprints.launchpad.net/ironic/+spec/ironic-redfish
>> and a corresponding spec https://review.openstack.org/184653, that
>> proposes
>> adding support for redfish (adding new power and management interfaces) to
>> ironic. It also seems to depend on python-redfish client -
>> https://github.com/devananda/python-redfish.
>>
>
> Very good idea ;-)
>
> I’d like to know what is the current status of it?
>>
>
> We have made recently some successful tests with both a real HP ProLiant
> server with a redfish compliant iLO FW (2.30+) and the DMTF simulator.
>

Great news! :)


>
> The version working for these tests is at
> https://github.com/bcornec/python-redfish (prototype branch)
> I think we should now move that work into master and make again a pull
> request to Devananda.
>
> Is there some roadmap of what should be added to
>> python-redfish (or is the one mentioned in spec is still relevant)?
>>
>
> I think this is still relevant.
>
> Is there a way for others to contribute in it?
>>
>
> Feel free to git clone the repo and propose patches to it ! We would be
> happy to have contributors :-) I've also copied our mailing list to the
> other contributors are aware of this.


I'll dig into current code and will try to contribute something meaningful
then.


>
>
> Bruno, do you plan to move it
>> under ironic umbrella, or into pyghmi as people suggested in spec?
>>
>
> That's a difficult question. One one hand, I don't think python-redfish
> should be under the OpenStack umbrella per se. This is a useful python
> module to dialog with servers providing a Redfish interface and this has
> no relationship with OpenStack ... except that it's very useful for
> Ironic ! But could also be used by other projects in the future such as
> Hadoop for node deployment, or my MondoRescue Disaster Recovery project
> e.g. That's also why we have not used OpenStack modules in order to
> avoid to create an artificial dependency that could prevent that module
> tobe used py these other projects.
>
> I'm new to the python galaxy myself, but thought that pypy would be the
> right place for it, but I really welcome suggestions here.
> I also need to come back to the Redfish spec itself and upate with the
> atest feedback we got, in order to have more up to date content for the
> Mitaka cycle.
>
> Best regards,
> Bruno.
> --
> Open Source Profession, Linux Community Lead WW  http://hpintelco.net
> HPE EMEA EG Open Source Technology Strategist http://hp.com/go/opensource
> FLOSS projects: http://mondorescue.org http://project-builder.org
> Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
>

Thanks for the answers :)
Vlad
__
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] Do we need to have a mid-cycle?

[Vladyslav Drok]

Seems good to me too.

On Thu, Nov 19, 2015 at 5:07 PM, John Villalovos  wrote:

> Me too :)
>
> +1 for trying a virtual midcycle
>
> On Thu, Nov 19, 2015 at 8:55 AM, Lucas Alvares Gomes <
> lucasago...@gmail.com> wrote:
>
>> Hi,
>>
>> > I sent a new idea to openstack-dev, and nobody has opinions? :P
>> >
>> > I'd like to get consensus on this soon, please do reply if you have
>> > thoughts on this.
>> >
>>
>> Sorry for the delay...
>>
>> Yeah, I've no problem giving this virtual midcycle idea a go, so +1
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Redfish drivers in ironic

[Vladyslav Drok]

Hi list and Bruno,

I’m interested in adding virtual media boot interface for redfish (
https://blueprints.launchpad.net/ironic/+spec/redfish-virtual-media-boot).
It depends on https://blueprints.launchpad.net/ironic/+spec/ironic-redfish
and a corresponding spec https://review.openstack.org/184653, that proposes
adding support for redfish (adding new power and management interfaces) to
ironic. It also seems to depend on python-redfish client -
https://github.com/devananda/python-redfish. I’d like to know what is the
current status of it? Is there some roadmap of what should be added to
python-redfish (or is the one mentioned in spec is still relevant)? Is
there a way for others to contribute in it? Bruno, do you plan to move it
under ironic umbrella, or into pyghmi as people suggested in spec?

Thanks,
Vlad
__
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] Nominating two new core reviewers

[Vladyslav Drok]

Thank you all for the nomination and support! It is a big responsibility to
be a member of the core team, and I'll do my best to justify your trust.

Vlad
On Oct 11, 2015 20:33, "Jim Rollenhagen" <j...@jimrollenhagen.com> wrote:

> On Thu, Oct 08, 2015 at 02:47:01PM -0700, Jim Rollenhagen wrote:
> > Hi all,
> >
> > I've been thinking a lot about Ironic's core reviewer team and how we
> might
> > make it better.
> >
> > I'd like to grow the team more through trust and mentoring. We should be
> > able to promote someone to core based on a good knowledge of *some* of
> > the code base, and trust them not to +2 things they don't know about. I'd
> > also like to build a culture of mentoring non-cores on how to review, in
> > preparation for adding them to the team. Through these pieces, I'm hoping
> > we can have a few rounds of core additions this cycle.
> >
> > With that said...
> >
> > I'd like to nominate Vladyslav Drok (vdrok) for the core team. His
> reviews
> > have been super high quality, and the quantity is ever-increasing. He's
> > also started helping out with some smaller efforts (full tempest, for
> > example), and I'd love to see that continue with larger efforts.
> >
> > I'd also like to nominate John Villalovos (jlvillal). John has been
> > reviewing a ton of code and making a real effort to learn everything,
> > and keep track of everything going on in the project.
> >
> > Ironic cores, please reply with your vote; provided feedback is positive,
> > I'd like to make this official next week sometime. Thanks!
>
> It appears all cores have responded positively; I've added both
> Vladyslav and John to the ironic-core group in Gerrit.
>
> Note that your browser cache may prevent you from seeing the +2 option.
> If this happens, just do a hard refresh (ctrl-shift-r) and it should
> work itself out.
>
> Congrats to both of you, and welcome to the team! :)
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Nominating two new core reviewers

[Vladyslav Drok]

Oh, right, and now I can vote for John, +2 :)
On Oct 11, 2015 21:59, "John Villalovos" <openstack@sodarock.com> wrote:

> I also would like to say thank you for the nomination and support. I am
> honored and humbled to be chosen. Thank you to all of you for this vote of
> confidence and I will do my best to maintain it.
>
> And congrats to Vlad, it is well deserved :)
>
> John
>
> On Sun, Oct 11, 2015 at 11:27 AM, Vladyslav Drok <vd...@mirantis.com>
> wrote:
>
>> Thank you all for the nomination and support! It is a big responsibility
>> to be a member of the core team, and I'll do my best to justify your trust.
>>
>> Vlad
>> On Oct 11, 2015 20:33, "Jim Rollenhagen" <j...@jimrollenhagen.com> wrote:
>>
>>> On Thu, Oct 08, 2015 at 02:47:01PM -0700, Jim Rollenhagen wrote:
>>> > Hi all,
>>> >
>>> > I've been thinking a lot about Ironic's core reviewer team and how we
>>> might
>>> > make it better.
>>> >
>>> > I'd like to grow the team more through trust and mentoring. We should
>>> be
>>> > able to promote someone to core based on a good knowledge of *some* of
>>> > the code base, and trust them not to +2 things they don't know about.
>>> I'd
>>> > also like to build a culture of mentoring non-cores on how to review,
>>> in
>>> > preparation for adding them to the team. Through these pieces, I'm
>>> hoping
>>> > we can have a few rounds of core additions this cycle.
>>> >
>>> > With that said...
>>> >
>>> > I'd like to nominate Vladyslav Drok (vdrok) for the core team. His
>>> reviews
>>> > have been super high quality, and the quantity is ever-increasing. He's
>>> > also started helping out with some smaller efforts (full tempest, for
>>> > example), and I'd love to see that continue with larger efforts.
>>> >
>>> > I'd also like to nominate John Villalovos (jlvillal). John has been
>>> > reviewing a ton of code and making a real effort to learn everything,
>>> > and keep track of everything going on in the project.
>>> >
>>> > Ironic cores, please reply with your vote; provided feedback is
>>> positive,
>>> > I'd like to make this official next week sometime. Thanks!
>>>
>>> It appears all cores have responded positively; I've added both
>>> Vladyslav and John to the ironic-core group in Gerrit.
>>>
>>> Note that your browser cache may prevent you from seeing the +2 option.
>>> If this happens, just do a hard refresh (ctrl-shift-r) and it should
>>> work itself out.
>>>
>>> Congrats to both of you, and welcome to the team! :)
>>>
>>> // jim
>>>
>>>
>>> __
>>> 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