Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Cédric Jeanneret]

On 05/29/2018 09:43 PM, Davanum Srinivas wrote:
> Agree with Ian here.
> 
> Also another problem that comes up is: "Why are you touching *MY*
> review?" (probably coming from the view where stats - and stackalytics
> leaderboard position is important). So i guess we ask permission
> before editing (or) file a follow up later (or) just tell folks that
> this is ok to do!!

We call that "communication". It's an important thing, especially in an
open source project with many, many contributors from many, many
different cultures and languages. Good communication avoids wars ;).

So yep - if someone has anything to correct and feels the urge to push a
patch on someone else', please do, but communicate the reasons (at
least, that's my point of view).

Cheers,

C.

> 
> Hoping engaging with them will solve yet another issue is someone
> going around filing the same change in a dozen projects (repeatedly!),
> but that may be wishful thinking.
> 
> -- Dims
> 
> On Tue, May 29, 2018 at 12:17 PM, Ian Wells  wrote:
>> If your nitpick is a spelling mistake or the need for a comment where you've
>> pretty much typed the text of the comment in the review comment itself, then
>> I have personally found it easiest to use the Gerrit online editor to
>> actually update the patch yourself.  There's nothing magical about the
>> original submitter, and no point in wasting your time and theirs to get them
>> to make the change.  That said, please be a grown up; if you're changing
>> code or messing up formatting enough for PEP8 to be a concern, it's your
>> responsibility, not the original submitter's, to fix it.  Also, do all your
>> fixes in one commit if you don't want to make Zuul cry.
>> --
>> Ian.
>>
>>
>> On 29 May 2018 at 09:00, Neil Jerram  wrote:
>>>
>>> From my point of view as someone who is still just an occasional
>>> contributor (in all OpenStack projects other than my own team's networking
>>> driver), and so I think still sensitive to the concerns being raised here:
>>>
>>> - Nits are not actually a problem, at all, if they are uncontroversial and
>>> quick to deal with.  For example, if it's a point of English, and most
>>> English speakers would agree that a correction is better, it's quick and no
>>> problem for me to make that correction.
>>>
>>> - What is much more of a problem is:
>>>
>>>   - Anything that is more a matter of opinion.  If a markup is just the
>>> reviewer's personal opinion, and they can't say anything to explain more
>>> objectively why their suggestion is better, it would be wiser to defer to
>>> the contributor's initial choice.
>>>
>>>   - Questioning something unconstructively or out of proportion to the
>>> change being made.  This is a tricky one to pin down, but sometimes I've had
>>> comments that raise some random left-field question that isn't really
>>> related to the change being made, or where the reviewer could have done a
>>> couple minutes research themselves and then either made a more precise
>>> comment, or not made their comment at all.
>>>
>>>   - Asking - implicitly or explicitly - the contributor to add more
>>> cleanups to their change.  If someone usefully fixes a problem, and their
>>> fix does not of itself impair the quality or maintainability of the
>>> surrounding code, they should not be asked to extend their fix so as to fix
>>> further problems that a more regular developer may be aware of in that area,
>>> or to advance a refactoring / cleanup that another developer has in mind.
>>> (At least, not as part of that initial change.)
>>>
>>> (Obviously the common thread of those problem points is taking up more
>>> time; psychologically I think one of the things that can turn a contributor
>>> away is the feeling that they've contributed a clearly useful thing, yet the
>>> community is stalling over accepting it for reasons that do not appear
>>> clearcut.)
>>>
>>> Hoping this is vaguely helpful...
>>>  Neil
>>>
>>>
>>> On Tue, May 29, 2018 at 4:35 PM Amy Marrich  wrote:

 If I have a nit that doesn't affect things, I'll make a note of it and
 say if you do another patch I'd really like it fixed but also give the 
 patch
 a vote. What I'll also do sometimes if I know the user or they are online
 I'll offer to fix things for them, that way they can see what I've done,
 I've sped things along and I haven't caused a simple change to take a long
 amount of time and reviews.

 I think this is a great addition!

 Thanks,

 Amy (spotz)

 On Tue, May 29, 2018 at 6:55 AM, Julia Kreger
  wrote:
>
> During the Forum, the topic of review culture came up in session after
> session. During these discussions, the subject of our use of nitpicks
> were often raised as a point of contention and frustration, especially
> by community members that have left the community and that were
> attempting to re-engage the community. Contributors raised the point
> of review feedback 

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Cédric Jeanneret]

On 05/30/2018 01:42 AM, Zane Bitter wrote:
> On 29/05/18 16:49, Slawomir Kaplonski wrote:
>> Hi,
>>
>>> Wiadomość napisana przez Jay S Bryant  w dniu
>>> 29.05.2018, o godz. 22:25:
>>> Maybe it would be different now that I am a Core/PTL but in the past
>>> I had been warned to be careful as it could be misinterpreted if I
>>> was changing other people's patches or that it could look like I was
>>> trying to pad my numbers. (I am a nit-picker though I do my best not
>>> to be.
>>
>> Exactly. I remember when I was doing my first patch (or one of first
>> patches) and someone pushed new PS with some very small nits fixed. I
>> was a bit confused because of that and I was thinking why he did it
>> instead of me?
>> Now it’s of course much more clear for me but for someone who is new
>> contributor I think that this might be confusing. Maybe such person
>> should at least remember to explain in comment why he pushed new PS
>> and that’s not „stealing” work of original author :)
> 
> Another issue is that if the original author needs to rev the patch
> again for any reason, they then need to figure out how to check out the
> modified patch. This requires a fairly sophisticated knowledge of both
> git and gerrit, which isn't a problem for those of us who have been
> using them for years but is potentially a nightmarish introduction for a
> relatively new contributor. Sometimes it's the right choice though
> (especially if the patch owner hasn't been seen for a while).

hm, "Download" -> copy/paste, and Voilà. Gerrit interface is pretty nice
with the user (I an "old new contributor", never really struggled with
Gerrit itself.. On the other hand, heat, ansible, that's another story :) ).

> 
> A follow-up patch is a good alternative, unless of course it conflicts
> with another patch in the series.
> 
> +1 with a comment can also get you a long way - it indicates that you've
> reviewed the whole patch and have found only nits to quibble with. If
> you're a core reviewer, another core could potentially +2/+A on a
> subsequent patch set with the nits addressed if they felt it
> appropriate, and even if they don't you'll have an easy re-review when
> you follow up.
> 
> We have lots of tools in our toolbox that are less blunt than -1. Let's
> save -1 for when major work is required and/or the patch as written
> would actually break something.

+1 (not core, can't +2, sorry :D)

"-1" is "aggressive".

Cheers,

C.

> 
> 
> Since I am replying to this thread, Julia also mentioned the situation
> where two core reviewers are asking for opposite changes to a patch. It
> is never ever ever the contributor's responsibility to resolve a dispute
> between two core reviewers! If you see a core reviewer's advice on a
> patch and you want to give the opposite advice, by all means take it up
> immediately - with *the other core reviewer*. NOT the submitter.
> Preferably on IRC and not in the review. You work together every day,
> you can figure it out! A random contributor has no chance of parachuting
> into the middle of that dynamic and walking out unscathed, and they
> should never be asked to.
> 
> cheers,
> Zane.
> 
> __
> 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

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
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] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting this week is canceled, since many Vitrage developers are on 
vacation.

We will meet next Wednesday, June 6th, at 8:00 UTC.

See you next week,
Ifat

__
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] [tc][all] A culture change (nitpicking)

[Masayuki Igawa]

I think this is not only for code but also for doc and reno. We should
fix it basically, especially about doc/reno. But I don't think it
should be in the same patch if the mistake isn't critical which means
*nitpicks*. I think we can fix them with following patches if we need
to fix it.

Otherwise, writing reno/doc might be a really difficult and hard work
for ESL people like me.

-- Masayuki


On 05/30, Ghanshyam Mann wrote:
> Thanks for making it formal process which really helps. I think most
> of the people usually does that but yes it is always helpful to be
> added as principles.
> 
> I have gotten mix feedback on fixing other patches in past and when i
> got anger by author i try to leave comment for a day or two then fix
> if it is really needed otherwise just go with follow-up.
> 
> One question - This only applies to code nitpick only right? not
> documentation or releasenotes. For doc and reno, we should fix spell
> or grammar mistake etc in same patch.
> 
> -gmann
> 
> 
> On Tue, May 29, 2018 at 10:55 PM, Julia Kreger
>  wrote:
> > During the Forum, the topic of review culture came up in session after
> > session. During these discussions, the subject of our use of nitpicks
> > were often raised as a point of contention and frustration, especially
> > by community members that have left the community and that were
> > attempting to re-engage the community. Contributors raised the point
> > of review feedback requiring for extremely precise English, or
> > compliance to a particular core reviewer's style preferences, which
> > may not be the same as another core reviewer.
> >
> > These things are not just frustrating, but also very inhibiting for
> > part time contributors such as students who may also be time limited.
> > Or an operator who noticed something that was clearly a bug and that
> > put forth a very minor fix and doesn't have the time to revise it over
> > and over.
> >
> > While nitpicks do help guide and teach, the consensus seemed to be
> > that we do need to shift the culture a little bit. As such, I've
> > proposed a change to our principles[1] in governance that attempts to
> > capture the essence and spirit of the nitpicking topic as a first
> > step.
> >
> > -Julia
> > -
> > [1]: https://review.openstack.org/570940
> >
> > __
> > 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

-- 
Happy Hacking!!
  Masayuki Igawa
  GPG fingerprint = C27C 2F00 3A2A 999A 903A  753D 290F 53ED C899 BF90


signature.asc
Description: PGP signature
__
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] [tc][all] A culture change (nitpicking)

[Ghanshyam Mann]

Thanks for making it formal process which really helps. I think most
of the people usually does that but yes it is always helpful to be
added as principles.

I have gotten mix feedback on fixing other patches in past and when i
got anger by author i try to leave comment for a day or two then fix
if it is really needed otherwise just go with follow-up.

One question - This only applies to code nitpick only right? not
documentation or releasenotes. For doc and reno, we should fix spell
or grammar mistake etc in same patch.

-gmann


On Tue, May 29, 2018 at 10:55 PM, Julia Kreger
 wrote:
> During the Forum, the topic of review culture came up in session after
> session. During these discussions, the subject of our use of nitpicks
> were often raised as a point of contention and frustration, especially
> by community members that have left the community and that were
> attempting to re-engage the community. Contributors raised the point
> of review feedback requiring for extremely precise English, or
> compliance to a particular core reviewer's style preferences, which
> may not be the same as another core reviewer.
>
> These things are not just frustrating, but also very inhibiting for
> part time contributors such as students who may also be time limited.
> Or an operator who noticed something that was clearly a bug and that
> put forth a very minor fix and doesn't have the time to revise it over
> and over.
>
> While nitpicks do help guide and teach, the consensus seemed to be
> that we do need to shift the culture a little bit. As such, I've
> proposed a change to our principles[1] in governance that attempts to
> capture the essence and spirit of the nitpicking topic as a first
> step.
>
> -Julia
> -
> [1]: https://review.openstack.org/570940
>
> __
> 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] [tc][all] A culture change (nitpicking)

[Samuel Cassiba]

On Tue, May 29, 2018 at 4:26 PM, Ian Wells  wrote:

> On 29 May 2018 at 14:53, Jeremy Stanley  wrote:
>
>> On 2018-05-29 15:25:01 -0500 (-0500), Jay S Bryant wrote:
>> [...]
>> > Maybe it would be different now that I am a Core/PTL but in the past I
>> had
>> > been warned to be careful as it could be misinterpreted if I was
>> changing
>> > other people's patches or that it could look like I was trying to pad my
>> > numbers. (I am a nit-picker though I do my best not to be.
>> [...]
>>
>> Most stats tracking goes by the Gerrit "Owner" metadata or the Git
>> "Author" field, neither of which are modified in a typical new
>> patchset workflow and so carry over from the original patchset #1
>> (resetting Author requires creating a new commit from scratch or
>> passing extra options to git to reset it, while changing the Owner
>> needs a completely new Change-Id footer).
>>
>
> We know this, but other people don't, so the comment is wise.  Also,
> arguably, if I badly fix someone else's patch, I'm making them look bad by
> leaving them with the 'credit' for my bad work, so it's important to be
> careful and tactful.  But the history is public record, at least.
>
>
If the patch is bad enough where I have to step in to rewrite, I'm making
the submitter look bad no matter what. That makes everyone worse off.

Best,
Samuel


> --
> Ian.
>
> __
> 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] [tc][all] A culture change (nitpicking)

[Ben Swartzlander]

On 05/29/2018 03:43 PM, Davanum Srinivas wrote:

Agree with Ian here.

Also another problem that comes up is: "Why are you touching *MY*
review?" (probably coming from the view where stats - and stackalytics
leaderboard position is important). So i guess we ask permission
before editing (or) file a follow up later (or) just tell folks that
this is ok to do!!


I think Stackalytics is evil and should be killed with fire. It 
encourages all kinds of pathological behavior, this being one prime 
example. Having worked as a core reviewer, I find zero value from the 
project. We know who is contributing code and who is doing reviews 
without some robot to tell us.


-Ben



Hoping engaging with them will solve yet another issue is someone
going around filing the same change in a dozen projects (repeatedly!),
but that may be wishful thinking.

-- Dims

On Tue, May 29, 2018 at 12:17 PM, Ian Wells  wrote:

If your nitpick is a spelling mistake or the need for a comment where you've
pretty much typed the text of the comment in the review comment itself, then
I have personally found it easiest to use the Gerrit online editor to
actually update the patch yourself.  There's nothing magical about the
original submitter, and no point in wasting your time and theirs to get them
to make the change.  That said, please be a grown up; if you're changing
code or messing up formatting enough for PEP8 to be a concern, it's your
responsibility, not the original submitter's, to fix it.  Also, do all your
fixes in one commit if you don't want to make Zuul cry.
--
Ian.


On 29 May 2018 at 09:00, Neil Jerram  wrote:


 From my point of view as someone who is still just an occasional
contributor (in all OpenStack projects other than my own team's networking
driver), and so I think still sensitive to the concerns being raised here:

- Nits are not actually a problem, at all, if they are uncontroversial and
quick to deal with.  For example, if it's a point of English, and most
English speakers would agree that a correction is better, it's quick and no
problem for me to make that correction.

- What is much more of a problem is:

   - Anything that is more a matter of opinion.  If a markup is just the
reviewer's personal opinion, and they can't say anything to explain more
objectively why their suggestion is better, it would be wiser to defer to
the contributor's initial choice.

   - Questioning something unconstructively or out of proportion to the
change being made.  This is a tricky one to pin down, but sometimes I've had
comments that raise some random left-field question that isn't really
related to the change being made, or where the reviewer could have done a
couple minutes research themselves and then either made a more precise
comment, or not made their comment at all.

   - Asking - implicitly or explicitly - the contributor to add more
cleanups to their change.  If someone usefully fixes a problem, and their
fix does not of itself impair the quality or maintainability of the
surrounding code, they should not be asked to extend their fix so as to fix
further problems that a more regular developer may be aware of in that area,
or to advance a refactoring / cleanup that another developer has in mind.
(At least, not as part of that initial change.)

(Obviously the common thread of those problem points is taking up more
time; psychologically I think one of the things that can turn a contributor
away is the feeling that they've contributed a clearly useful thing, yet the
community is stalling over accepting it for reasons that do not appear
clearcut.)

Hoping this is vaguely helpful...
  Neil


On Tue, May 29, 2018 at 4:35 PM Amy Marrich  wrote:


If I have a nit that doesn't affect things, I'll make a note of it and
say if you do another patch I'd really like it fixed but also give the patch
a vote. What I'll also do sometimes if I know the user or they are online
I'll offer to fix things for them, that way they can see what I've done,
I've sped things along and I haven't caused a simple change to take a long
amount of time and reviews.

I think this is a great addition!

Thanks,

Amy (spotz)

On Tue, May 29, 2018 at 6:55 AM, Julia Kreger
 wrote:


During the Forum, the topic of review culture came up in session after
session. During these discussions, the subject of our use of nitpicks
were often raised as a point of contention and frustration, especially
by community members that have left the community and that were
attempting to re-engage the community. Contributors raised the point
of review feedback requiring for extremely precise English, or
compliance to a particular core reviewer's style preferences, which
may not be the same as another core reviewer.

These things are not just frustrating, but also very inhibiting for
part time contributors such as students who may also be time limited.
Or an operator who noticed something that was clearly a bug and that
put forth a very minor fix and doesn't have the time to 

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Zane Bitter]

On 29/05/18 16:49, Slawomir Kaplonski wrote:

Hi,


Wiadomość napisana przez Jay S Bryant  w dniu 29.05.2018, 
o godz. 22:25:
Maybe it would be different now that I am a Core/PTL but in the past I had been 
warned to be careful as it could be misinterpreted if I was changing other 
people's patches or that it could look like I was trying to pad my numbers. (I 
am a nit-picker though I do my best not to be.


Exactly. I remember when I was doing my first patch (or one of first patches) 
and someone pushed new PS with some very small nits fixed. I was a bit confused 
because of that and I was thinking why he did it instead of me?
Now it’s of course much more clear for me but for someone who is new 
contributor I think that this might be confusing. Maybe such person should at 
least remember to explain in comment why he pushed new PS and that’s not 
„stealing” work of original author :)


Another issue is that if the original author needs to rev the patch 
again for any reason, they then need to figure out how to check out the 
modified patch. This requires a fairly sophisticated knowledge of both 
git and gerrit, which isn't a problem for those of us who have been 
using them for years but is potentially a nightmarish introduction for a 
relatively new contributor. Sometimes it's the right choice though 
(especially if the patch owner hasn't been seen for a while).


A follow-up patch is a good alternative, unless of course it conflicts 
with another patch in the series.


+1 with a comment can also get you a long way - it indicates that you've 
reviewed the whole patch and have found only nits to quibble with. If 
you're a core reviewer, another core could potentially +2/+A on a 
subsequent patch set with the nits addressed if they felt it 
appropriate, and even if they don't you'll have an easy re-review when 
you follow up.


We have lots of tools in our toolbox that are less blunt than -1. Let's 
save -1 for when major work is required and/or the patch as written 
would actually break something.



Since I am replying to this thread, Julia also mentioned the situation 
where two core reviewers are asking for opposite changes to a patch. It 
is never ever ever the contributor's responsibility to resolve a dispute 
between two core reviewers! If you see a core reviewer's advice on a 
patch and you want to give the opposite advice, by all means take it up 
immediately - with *the other core reviewer*. NOT the submitter. 
Preferably on IRC and not in the review. You work together every day, 
you can figure it out! A random contributor has no chance of parachuting 
into the middle of that dynamic and walking out unscathed, and they 
should never be asked to.


cheers,
Zane.

__
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] [Cyborg] [Nova] Cyborg traits

[Nadathur, Sundar]

Hi all,
   The Cyborg/Nova scheduling spec [1] details what traits will be 
applied to the resource providers that represent devices like GPUs. Some 
of the traits referred to vendor names. I got feedback that traits must 
not refer to products or specific models of devices. I agree. However, 
we need some reference to device types to enable matching the VM driver 
with the device.


TL;DR We need some reference to device types, but we don't need product 
names. I will update the spec [1] to clarify that. Rest of this email 
clarifies why we need device types in traits, and what traits we propose 
to include.


In general, an accelerator device is operated by two pieces of software: 
a driver in the kernel (which may discover and handle the PF for SR-IOV  
devices), and a driver/library in the guest (which may handle the 
assigned VF).


The device assigned to the VM must match the driver/library packaged in 
the VM. For this, the request must explicitly state what category of 
devices it needs. For example, if the VM needs a GPU, it needs to say 
whether it needs an AMD GPU or an Nvidia GPU, since it may have the 
driver/libraries for that vendor alone. It may also need to state what 
version of Cuda is needed, if it is a Nvidia GPU. These aspects are 
necessarily vendor-specific.


Further, one driver/library version may handle multiple devices. Since a 
new driver version may be backwards compatible, multiple driver versions 
may manage the same device. The development/release of the 
driver/library inside the VM should be independent of the kernel driver 
for that device.


For FPGAs, there is an additional twist as the VM may need specific 
bitstream(s), and they match only specific device/region types. The 
bitstream for a device from a vendor will not fit any other device from 
the same vendor, let alone other vendors. IOW, the region type is 
specific not just to a vendor but to a device type within the vendor. 
So, it is essential to identify the device type.


So, the proposed set of RCs and traits are as below. As we learn more 
about actual usages by operators, we may need to evolve this set.


 * There is a resource class per device category e.g.
   CUSTOM_ACCELERATOR_GPU, CUSTOM_ACCELERATOR_FPGA.
 * The resource provider that represents a device has the following traits:
 o Vendor/Category trait: e.g. CUSTOM_GPU_AMD, CUSTOM_FPGA_XILINX.
 o Device type trait which is a refinement of vendor/category trait
   e.g. CUSTOM_FPGA_XILINX_VU9P.

   NOTE: This is not a product or model, at least for FPGAs.
   Multiple products may use the same FPGA chip.
   NOTE: The reason for having both the vendor/category and this
   one is that a flavor may ask for either, depending on the
   granularity desired. IOW, if one driver can handle all devices
   from a vendor (*eye roll*), the flavor can ask for the
   vendor/category trait alone. If there are separate drivers for
   different device families from the same vendor, the flavor must
   specify the trait for the device family.
   NOTE: The equivalent trait for GPUs may be like
   CUSTOM_GPU_NVIDIA_P90, but I'll let others decide if that is a
   product or not.

 o For FPGAs, we have additional traits:
 + Functionality trait: e.g. CUSTOM_FPGA_COMPUTE,
   CUSTOM_FPGA_NETWORK, CUSTOM_FPGA_STORAGE
 + Region type ID.  e.g. CUSTOM_FPGA_INTEL_REGION_.
 + Optionally, a function ID, indicating what function is
   currently programmed in the region RP. e.g.
   CUSTOM_FPGA_INTEL_FUNCTION_. Not all implementations
   may provide it. The function trait may change on
   reprogramming, but it is not expected to be frequent.
 + Possibly, CUSTOM_PROGRAMMABLE as a separate trait.

[1] https://review.openstack.org/#/c/554717/

Thanks.

Regards,
Sundar
__
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] [tc][all] A culture change (nitpicking)

[Ian Wells]

On 29 May 2018 at 14:53, Jeremy Stanley  wrote:

> On 2018-05-29 15:25:01 -0500 (-0500), Jay S Bryant wrote:
> [...]
> > Maybe it would be different now that I am a Core/PTL but in the past I
> had
> > been warned to be careful as it could be misinterpreted if I was changing
> > other people's patches or that it could look like I was trying to pad my
> > numbers. (I am a nit-picker though I do my best not to be.
> [...]
>
> Most stats tracking goes by the Gerrit "Owner" metadata or the Git
> "Author" field, neither of which are modified in a typical new
> patchset workflow and so carry over from the original patchset #1
> (resetting Author requires creating a new commit from scratch or
> passing extra options to git to reset it, while changing the Owner
> needs a completely new Change-Id footer).
>

We know this, but other people don't, so the comment is wise.  Also,
arguably, if I badly fix someone else's patch, I'm making them look bad by
leaving them with the 'credit' for my bad work, so it's important to be
careful and tactful.  But the history is public record, at least.

-- 
Ian.
__
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] [tc][forum] TC Retrospective for Queens/Rocky

[Jeremy Stanley]

On 2018-05-29 17:26:16 -0400 (-0400), Doug Hellmann wrote:
[...]
> There was some discussion of whether the office hours themselves
> are useful, based on the apparent lack of participation. We had
> theories that this was a combination of bad times (meaning that TC
> members haven't always attended) and bad platforms (meaning that
> some parts of the community we are trying to reach may emphasize
> other tools over IRC for real time chat). We need to look into that.
[...]

We also had some consensus in the room on starting to use meetbot
during office hours to highlight whatever we discussed in the
resulting meeting minutes. I'm planning to do that at our 01:00z
office hour (a couple hours from now) and see how it goes, though
that timeslot in particular tends to have little or no discussion.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [tc][all] A culture change (nitpicking)

[Jeremy Stanley]

On 2018-05-29 15:25:01 -0500 (-0500), Jay S Bryant wrote:
[...]
> Maybe it would be different now that I am a Core/PTL but in the past I had
> been warned to be careful as it could be misinterpreted if I was changing
> other people's patches or that it could look like I was trying to pad my
> numbers. (I am a nit-picker though I do my best not to be.
[...]

Most stats tracking goes by the Gerrit "Owner" metadata or the Git
"Author" field, neither of which are modified in a typical new
patchset workflow and so carry over from the original patchset #1
(resetting Author requires creating a new commit from scratch or
passing extra options to git to reset it, while changing the Owner
needs a completely new Change-Id footer).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [tc][all] A culture change (nitpicking)

[Doug Hellmann]

Excerpts from Slawomir Kaplonski's message of 2018-05-29 22:49:07 +0200:
> Hi,
> 
> > Wiadomość napisana przez Jay S Bryant  w dniu 
> > 29.05.2018, o godz. 22:25:
> > 
> > 
> > On 5/29/2018 3:19 PM, Doug Hellmann wrote:
> >> Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400:
> >>> On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
> >>> :> >> maybe we're all saying the same thing here?
> >>> :> > Yeah, I feel like we're all essentially in agreement that nits (of 
> >>> the
> >>> :> > English mistake of typo type) do need to get fixed, but sometimes
> >>> :> > (often?) putting the burden of fixing them on the original patch
> >>> :> > contributor is neither fair nor constructive.
> >>> :> I am ok with this statement if we are all in agreement that doing
> >>> :> follow-up patches is an acceptable practice.
> >>> :
> >>> :Has it ever not been?
> >>> :
> >>> :It seems like it has always come down to a bit of negotiation with
> >>> :the original author, hasn't it? And that won't change, except that
> >>> :we will be emphasizing to reviewers that we encourage them to be
> >>> :more active in seeking out that negotiation and then proposing
> >>> :patches?
> >>> 
> >>> Exactly, it's more codifying a default.
> >>> 
> >>> It's not been unacceptable but I think there's some understandable
> >>> reluctance to make changes to someone else's work, you don't want to
> >>> seem like your taking over or getting in the way.  At least that's
> >>> what's in my head when deciding should this be a comment or a patch.
> >>> 
> >>> I think this discussion suggests for certain class of "nits" patch is
> >>> preferred to comment.  If that is true making this explicit is a good
> >>> thing becuase let's face it my social skills are only marginally
> >>> better than my speeling :)
> >>> 
> >>> -Jon
> >>> 
> >> OK, that's all good. I'm just surprised to learn that throwing a
> >> follow-up patch on top of someone else's patch was ever seen as
> >> discouraged.
> >> 
> >> The spice must flow,
> >> Doug
> > 
> > Maybe it would be different now that I am a Core/PTL but in the past I had 
> > been warned to be careful as it could be misinterpreted if I was changing 
> > other people's patches or that it could look like I was trying to pad my 
> > numbers. (I am a nit-picker though I do my best not to be.
> 
> Exactly. I remember when I was doing my first patch (or one of first patches) 
> and someone pushed new PS with some very small nits fixed. I was a bit 
> confused because of that and I was thinking why he did it instead of me?
> Now it’s of course much more clear for me but for someone who is new 
> contributor I think that this might be confusing. Maybe such person should at 
> least remember to explain in comment why he pushed new PS and that’s not 
> „stealing” work of original author :)

I guess it never occurred to me that someone would do that without
also leaving a comment explaining the situation.

Doug

> 
> > 
> > I am happy if people understand I am just trying to keep the process moving 
> > and keep the read/flow of Cinder consistent.  :-)
> > 
> > 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
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 

__
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] [tc] Organizational diversity tag

[Jeremy Stanley]

On 2018-05-29 13:17:50 -0400 (-0400), Doug Hellmann wrote:
[...]
> We have the status:maintenance-mode tag[3] today. How would a new
> "low-activity" tag be differentiated from the existing one?
[...]

status:maintenance-mode is (as it says on the tin) a subjective
indicator that a team has entered a transient period of reduced
activity. By contrast, a low-activity tag (maybe it should be
something more innocuous like low-churn?) would be an objective
indicator that attempts to make contributor diversity assertions are
doomed to fail the statistical significance test. We could consider
overloading status:maintenance-mode for this purpose, but some teams
perhaps simply don't have large amounts of code change ever and
that's just a normal effect of how they operate.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] review runway status

[melanie witt]

Hi everybody,

This is just a brief status about the blueprints currently occupying
review runways [0] and an ask for the nova-core team to give these
reviews priority for their code review focus.

Note that these 3 blueprints were in runways during summit week with end 
dates of 2018-05-28 and 2018-05-30. Because of significantly reduced 
review attention during the summit as core team members were in 
attendance and busy, we have extended the end date for these blueprints 
by one week to EOD next Tuesday 2018-06-05.


* PowerVM Driver 
https://blueprints.launchpad.net/nova/+spec/powervm-vscsi (esberglu) 
[END DATE: 2018-06-05] vSCSI Cinder Volume Driver: 
https://review.openstack.org/526094


* Granular Placement Policy 
https://blueprints.launchpad.net/nova/+spec/granular-placement-policy 
(mriedem) [END DATE: 2018-06-05] 
https://review.openstack.org/#/q/topic:bp/granular-placement-policy+status:open


* vGPU work in rocky 
https://blueprints.launchpad.net/nova/+spec/vgpu-rocky (naichuans) [END 
DATE: 2018-06-05] series starting at https://review.openstack.org/520313


Best,
-melanie

[0] https://etherpad.openstack.org/p/nova-runways-rocky

__
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] [tc] Organizational diversity tag

[Jeremy Stanley]

On 2018-05-29 13:59:27 +0200 (+0200), Thierry Carrez wrote:
[...]
> Alternatively (if that's too much work), we could add a new team
> tag (low-activity ?) that would appear for all projects where the
> activity is so low that the team diversity tags no longer really
> apply.

As others have also said, this seems like a potentially useful
metric on its own anyway. We could simply avoid including
low-activity tagged teams in diversity reporting and not associate
any diversity tags with them.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [tc][forum] TC Retrospective for Queens/Rocky

[Doug Hellmann]

At the forum last week the TC held a retrospective to discuss how
we felt things have gone for the TC over the last 6-ish months,
since the previous election. I will try to summarize the feedback
here based on the notes in the etherpad [1], but please reply if I
misremember something, leave out details, or otherwise give an
incomplete view of what we talked about.

We approached the retro using the 3 questions (what went well, what
didn't go well, what can we change) but in this summary I'm going
to focus on each topic, because some ended up in multiple sections.

We all agreed that having some new members on the TC is healthy.
Graham, Mohammed, and Zane have all already started taking a very
active role.

The work Thierry has done to engage with the kubernetes community
leadership through in-person meetings at some of their conferences
has been received well by participants from both groups. The recent
event in Copenhagen was more lightly attended than the one in Austin
in December, in part because of the increased demands on the time
from the participants as their events grow larger. We, of course,
also have other outreach activities from Dims, hogepoge, and others
who are working directly on integration projects, but since this
was a TC retrospective we were talking specifically about TC-led
engagement between the communities.

Our efforts at communicating outside of office hours through
discussion digests and the #openstack-tc channel seem to be going
well. There was some discussion of whether the office hours themselves
are useful, based on the apparent lack of participation. We had
theories that this was a combination of bad times (meaning that TC
members haven't always attended) and bad platforms (meaning that
some parts of the community we are trying to reach may emphasize
other tools over IRC for real time chat). We need to look into that.

Thierry brought up the point that the diversity tags may be less
relevant as they are currently defined, especially because some
projects with very low activity may end up bouncing back and forth
between "diverse" and not with a very small change in participation.
Mohammed and Thierry are going to work on addressing that. See the
thread starting with
http://lists.openstack.org/pipermail/openstack-dev/2018-May/130776.html for
details.

There was some discussion of how well the interaction with the
Foundation staff and Board is working. Opinions were mixed, but
generally still positive. I will be working with Alan to increase
engagement with the Board and with Thierry and other Foundation
staff on that relationship. I encourage all of you to join the Board
meetings when it is possible. It looks like we will have another
in-person joint leadership meeting before the PTG in Denver, so
start thinking of things we might want to place on the agenda for
discussion. Keep in mind that given the large size of the group,
pre-seeding discussions with a mailing list thread can help frame
things for everyone, just like with design summit sessions.

Chris also brought up a concern about a decline in the electorate
voting for TC members. I don't remember having enough details in
the room to confirm this as an overall trend, but there was some
discussion of the most recent numbers seeming low in an unhealthy
way. We need to talk about this further.

Jeremy also brought up a lack of geographic diversity among the
candidates who won the elections. That continues to be a challenge,
and the cause isn't obvious to me. I hope that past (and future)
candidates will get involved with the TC regardless of the outcome
of the election, since we do want their input and being active is
one of the best ways to raise your profile for an election.

Colleen mentioned that our goal selection was "contentious" and
based on the discussion of Stein goals and the goal process in
general I think we have some good feedback about how to improve
that. I'm sure Sean will be posting about that session separately.

Chris brought up a concern about whether we have much traction on
"doing stuff" and especially "getting things done that not everyone
wants," Graham noted a lack of "visible impact," and Zane mentioned
the TC vision in particular. Based on conversations last week, I
am currently tracking a list of 20+ things the TC is working on. I
will add the public ones to the wiki page this week as I catch up
with my notes (remember, sometimes these things involve disputes
that can be more smoothly handled one-on-one, so not everything
that is going on is necessarily going to have its own email thread
announcing it).

As far as the vision, although we aren't "done" with those items,
I do think we’re doing better than may be obvious, in part because
we haven’t reviewed it recently. Thierry, Emilien, and Jeremy
volunteered to review our progress. It would be good to do that
before the PTG, and to especially consider how we can talk more
about the impact of the changes we have made as part of that work.

Re: [openstack-dev] [all][tc] final stages of python 3 transition

[Jeremy Stanley]

On 2018-05-29 15:51:31 -0400 (-0400), Doug Hellmann wrote:
[...]
> Could we, for example, look at the set of packages installed under
> python2 and report errors if any OpenStack packages end up there?
[...]

This sounds like a marvellous solution.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [tc][all] A culture change (nitpicking)

[Slawomir Kaplonski]

Hi,

> Wiadomość napisana przez Jay S Bryant  w dniu 
> 29.05.2018, o godz. 22:25:
> 
> 
> On 5/29/2018 3:19 PM, Doug Hellmann wrote:
>> Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400:
>>> On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
>>> :> >> maybe we're all saying the same thing here?
>>> :> > Yeah, I feel like we're all essentially in agreement that nits (of the
>>> :> > English mistake of typo type) do need to get fixed, but sometimes
>>> :> > (often?) putting the burden of fixing them on the original patch
>>> :> > contributor is neither fair nor constructive.
>>> :> I am ok with this statement if we are all in agreement that doing
>>> :> follow-up patches is an acceptable practice.
>>> :
>>> :Has it ever not been?
>>> :
>>> :It seems like it has always come down to a bit of negotiation with
>>> :the original author, hasn't it? And that won't change, except that
>>> :we will be emphasizing to reviewers that we encourage them to be
>>> :more active in seeking out that negotiation and then proposing
>>> :patches?
>>> 
>>> Exactly, it's more codifying a default.
>>> 
>>> It's not been unacceptable but I think there's some understandable
>>> reluctance to make changes to someone else's work, you don't want to
>>> seem like your taking over or getting in the way.  At least that's
>>> what's in my head when deciding should this be a comment or a patch.
>>> 
>>> I think this discussion suggests for certain class of "nits" patch is
>>> preferred to comment.  If that is true making this explicit is a good
>>> thing becuase let's face it my social skills are only marginally
>>> better than my speeling :)
>>> 
>>> -Jon
>>> 
>> OK, that's all good. I'm just surprised to learn that throwing a
>> follow-up patch on top of someone else's patch was ever seen as
>> discouraged.
>> 
>> The spice must flow,
>> Doug
> 
> Maybe it would be different now that I am a Core/PTL but in the past I had 
> been warned to be careful as it could be misinterpreted if I was changing 
> other people's patches or that it could look like I was trying to pad my 
> numbers. (I am a nit-picker though I do my best not to be.

Exactly. I remember when I was doing my first patch (or one of first patches) 
and someone pushed new PS with some very small nits fixed. I was a bit confused 
because of that and I was thinking why he did it instead of me?
Now it’s of course much more clear for me but for someone who is new 
contributor I think that this might be confusing. Maybe such person should at 
least remember to explain in comment why he pushed new PS and that’s not 
„stealing” work of original author :)

> 
> I am happy if people understand I am just trying to keep the process moving 
> and keep the read/flow of Cinder consistent.  :-)
> 
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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][tc] final stages of python 3 transition

[Doug Hellmann]

Excerpts from Matthew Treinish's message of 2018-05-29 16:16:50 -0400:
> On Tue, May 29, 2018 at 03:51:31PM -0400, Doug Hellmann wrote:
> > Following up on this topic, at the Forum discussion last week (see
> > https://etherpad.openstack.org/p/YVR-python-2-deprecation-timeline) the
> > general plan outlined below was acceptable to most of the folks in the
> > room with a few small changes (included below).
> > 
> > Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
> > > It's time to talk about the next steps in our migration from python
> > > 2 to python 3.
> > > 
> > > Up to this point we have mostly focused on reaching a state where
> > > we support both versions of the language. We are not quite there
> > > with all projects, as you can see by reviewing the test coverage
> > > status information at
> > > https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects
> > > 
> > > Still, we need to press on to the next phase of the migration, which
> > > I have been calling "Python 3 first". This is where we use python
> > > 3 as the default, for everything, and set up the exceptions we need
> > > for anything that still requires python 2.
> > > 
> > > To reach that stage, we need to:
> > > 
> > > 1. Change the documentation and release notes jobs to use python 3.
> > >(The Oslo team recently completed this, and found that we did
> > >need to make a few small code changes to get them to work.)
> > > 2. Change (or duplicate) all functional test jobs to run under
> > >python 3.
> > > 3. Change the packaging jobs to use python 3.
> > > 4. Update devstack to use 3 by default and require setting a flag to
> > >use 2. (This may trigger other job changes.)
> > 
> > Also:
> > 
> > - Ensure that devstack configures mod_wsgi (or whatever WSGI service) to
> >   use Python 3 when deploying API components.
> 
> The python 3 dsvm jobs already do this for the most part. All API services 
> that
> support running as a wsgi application run under uwsgi with a single apache
> redirecting traffic to those. This is the supported model for running wsgi
> services on devstack. Currently keystone, glance, nova, placement, and cinder
> run their API servers this way. Neutron doesn't run under as wsgi app (I
> don't recall why this was never implemented for neutron) and swift doesn't run
> in the py3 jobs at all. You can see an example of this here:

OK, good, thank you for clarifying that. I think the folks in the room
weren't 100% sure, so the point was to double check. And it sounds like
we still need to do that for projects using devstack plugins, based on
your next comment.

> 
> http://logs.openstack.org/08/550108/3/gate/tempest-full-py3/df744ef/controller/logs/
> 
> For other services it depends on how they implemented their devstack plugin. I
> haven't done an inventory on how all the plugins are running things, so I 
> don't
> know what the status of each project is there.
> 
> > - Test "python version skew" within a service during a rolling upgrade
> >   across multiple hosts.
> > - Add an integration test job that does not include python2 on the host
> >   at all.
> > 
> > That last item may block us from using other tools, such as ansible,
> > that rely on python2. If the point of such a test is to ensure that
> > we are properly installing (and running) our tools under python3,
> > maybe *that's* what we want to check, instead of forbidding a python2
> > package at all? Could we, for example, look at the set of packages
> > installed under python2 and report errors if any OpenStack packages end
> > up there?
> > 
> > > 
> > > At that point, all of our deliverables will be produced using python
> > > 3, and we can be relatively confident that if we no longer had
> > > access to python 2 we could still continue operating. We could also
> > > start updating deployment tools to use either python 3 or 2, so
> > > that users could actually deploy using the python 3 versions of
> > > services.
> > > 
> > > Somewhere in that time frame our third-party CI systems will need
> > > to ensure they have python 3 support as well.
> > > 
> > > After the "Python 3 first" phase is completed we should release
> > > one series using the packages built with python 3. Perhaps Stein?
> > > Or is that too ambitious?
> > > 
> > > Next, we will be ready to address the prerequisites for "Python 3
> > > only," which will allow us to drop Python 2 support.
> > > 
> > > We need to wait to drop python 2 support as a community, rather
> > > than going one project at a time, to avoid doubling the work of
> > > downstream consumers such as distros and independent deployers. We
> > > don't want them to have to package all (or even a large number) of
> > > the dependencies of OpenStack twice because they have to install
> > > some services running under python 2 and others under 3. Ideally
> > > they would be able to upgrade all of the services on a node together
> > > as part of their transition to the 

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Jay S Bryant]

On 5/29/2018 3:19 PM, Doug Hellmann wrote:

Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400:

On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
:> >> maybe we're all saying the same thing here?
:> > Yeah, I feel like we're all essentially in agreement that nits (of the
:> > English mistake of typo type) do need to get fixed, but sometimes
:> > (often?) putting the burden of fixing them on the original patch
:> > contributor is neither fair nor constructive.
:> I am ok with this statement if we are all in agreement that doing
:> follow-up patches is an acceptable practice.
:
:Has it ever not been?
:
:It seems like it has always come down to a bit of negotiation with
:the original author, hasn't it? And that won't change, except that
:we will be emphasizing to reviewers that we encourage them to be
:more active in seeking out that negotiation and then proposing
:patches?

Exactly, it's more codifying a default.

It's not been unacceptable but I think there's some understandable
reluctance to make changes to someone else's work, you don't want to
seem like your taking over or getting in the way.  At least that's
what's in my head when deciding should this be a comment or a patch.

I think this discussion suggests for certain class of "nits" patch is
preferred to comment.  If that is true making this explicit is a good
thing becuase let's face it my social skills are only marginally
better than my speeling :)

-Jon


OK, that's all good. I'm just surprised to learn that throwing a
follow-up patch on top of someone else's patch was ever seen as
discouraged.

The spice must flow,
Doug


Maybe it would be different now that I am a Core/PTL but in the past I 
had been warned to be careful as it could be misinterpreted if I was 
changing other people's patches or that it could look like I was trying 
to pad my numbers. (I am a nit-picker though I do my best not to be.


I am happy if people understand I am just trying to keep the process 
moving and keep the read/flow of Cinder consistent.  :-)


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

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Doug Hellmann]

Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400:
> On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
> :> >> maybe we're all saying the same thing here?
> :> > Yeah, I feel like we're all essentially in agreement that nits (of the
> :> > English mistake of typo type) do need to get fixed, but sometimes
> :> > (often?) putting the burden of fixing them on the original patch
> :> > contributor is neither fair nor constructive.
> :> I am ok with this statement if we are all in agreement that doing 
> :> follow-up patches is an acceptable practice.
> :
> :Has it ever not been?
> :
> :It seems like it has always come down to a bit of negotiation with
> :the original author, hasn't it? And that won't change, except that
> :we will be emphasizing to reviewers that we encourage them to be
> :more active in seeking out that negotiation and then proposing
> :patches?
> 
> Exactly, it's more codifying a default.
> 
> It's not been unacceptable but I think there's some understandable
> reluctance to make changes to someone else's work, you don't want to
> seem like your taking over or getting in the way.  At least that's
> what's in my head when deciding should this be a comment or a patch.
> 
> I think this discussion suggests for certain class of "nits" patch is
> preferred to comment.  If that is true making this explicit is a good
> thing becuase let's face it my social skills are only marginally
> better than my speeling :)
> 
> -Jon
> 

OK, that's all good. I'm just surprised to learn that throwing a
follow-up patch on top of someone else's patch was ever seen as
discouraged.

The spice must flow,
Doug

__
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][tc] final stages of python 3 transition

[Matthew Treinish]

On Tue, May 29, 2018 at 03:51:31PM -0400, Doug Hellmann wrote:
> Following up on this topic, at the Forum discussion last week (see
> https://etherpad.openstack.org/p/YVR-python-2-deprecation-timeline) the
> general plan outlined below was acceptable to most of the folks in the
> room with a few small changes (included below).
> 
> Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
> > It's time to talk about the next steps in our migration from python
> > 2 to python 3.
> > 
> > Up to this point we have mostly focused on reaching a state where
> > we support both versions of the language. We are not quite there
> > with all projects, as you can see by reviewing the test coverage
> > status information at
> > https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects
> > 
> > Still, we need to press on to the next phase of the migration, which
> > I have been calling "Python 3 first". This is where we use python
> > 3 as the default, for everything, and set up the exceptions we need
> > for anything that still requires python 2.
> > 
> > To reach that stage, we need to:
> > 
> > 1. Change the documentation and release notes jobs to use python 3.
> >(The Oslo team recently completed this, and found that we did
> >need to make a few small code changes to get them to work.)
> > 2. Change (or duplicate) all functional test jobs to run under
> >python 3.
> > 3. Change the packaging jobs to use python 3.
> > 4. Update devstack to use 3 by default and require setting a flag to
> >use 2. (This may trigger other job changes.)
> 
> Also:
> 
> - Ensure that devstack configures mod_wsgi (or whatever WSGI service) to
>   use Python 3 when deploying API components.

The python 3 dsvm jobs already do this for the most part. All API services that
support running as a wsgi application run under uwsgi with a single apache
redirecting traffic to those. This is the supported model for running wsgi
services on devstack. Currently keystone, glance, nova, placement, and cinder
run their API servers this way. Neutron doesn't run under as wsgi app (I
don't recall why this was never implemented for neutron) and swift doesn't run
in the py3 jobs at all. You can see an example of this here:

http://logs.openstack.org/08/550108/3/gate/tempest-full-py3/df744ef/controller/logs/

For other services it depends on how they implemented their devstack plugin. I
haven't done an inventory on how all the plugins are running things, so I don't
know what the status of each project is there.

> - Test "python version skew" within a service during a rolling upgrade
>   across multiple hosts.
> - Add an integration test job that does not include python2 on the host
>   at all.
> 
> That last item may block us from using other tools, such as ansible,
> that rely on python2. If the point of such a test is to ensure that
> we are properly installing (and running) our tools under python3,
> maybe *that's* what we want to check, instead of forbidding a python2
> package at all? Could we, for example, look at the set of packages
> installed under python2 and report errors if any OpenStack packages end
> up there?
> 
> > 
> > At that point, all of our deliverables will be produced using python
> > 3, and we can be relatively confident that if we no longer had
> > access to python 2 we could still continue operating. We could also
> > start updating deployment tools to use either python 3 or 2, so
> > that users could actually deploy using the python 3 versions of
> > services.
> > 
> > Somewhere in that time frame our third-party CI systems will need
> > to ensure they have python 3 support as well.
> > 
> > After the "Python 3 first" phase is completed we should release
> > one series using the packages built with python 3. Perhaps Stein?
> > Or is that too ambitious?
> > 
> > Next, we will be ready to address the prerequisites for "Python 3
> > only," which will allow us to drop Python 2 support.
> > 
> > We need to wait to drop python 2 support as a community, rather
> > than going one project at a time, to avoid doubling the work of
> > downstream consumers such as distros and independent deployers. We
> > don't want them to have to package all (or even a large number) of
> > the dependencies of OpenStack twice because they have to install
> > some services running under python 2 and others under 3. Ideally
> > they would be able to upgrade all of the services on a node together
> > as part of their transition to the new version, without ending up
> > with a python 2 version of a dependency along side a python 3 version
> > of the same package.
> > 
> > The remaining items could be fixed earlier, but this is the point
> > at which they would block us:
> > 
> > 1. Fix oslo.service functional tests -- the Oslo team needs help
> >maintaining this library. Alternatively, we could move all
> >services to use cotyledon (https://pypi.org/project/cotyledon/).
> > 
> > 2. Finish the unit test and 

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Jonathan Proulx]

On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
:> >> maybe we're all saying the same thing here?
:> > Yeah, I feel like we're all essentially in agreement that nits (of the
:> > English mistake of typo type) do need to get fixed, but sometimes
:> > (often?) putting the burden of fixing them on the original patch
:> > contributor is neither fair nor constructive.
:> I am ok with this statement if we are all in agreement that doing 
:> follow-up patches is an acceptable practice.
:
:Has it ever not been?
:
:It seems like it has always come down to a bit of negotiation with
:the original author, hasn't it? And that won't change, except that
:we will be emphasizing to reviewers that we encourage them to be
:more active in seeking out that negotiation and then proposing
:patches?

Exactly, it's more codifying a default.

It's not been unacceptable but I think there's some understandable
reluctance to make changes to someone else's work, you don't want to
seem like your taking over or getting in the way.  At least that's
what's in my head when deciding should this be a comment or a patch.

I think this discussion suggests for certain class of "nits" patch is
preferred to comment.  If that is true making this explicit is a good
thing becuase let's face it my social skills are only marginally
better than my speeling :)

-Jon

__
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] [tc] Organizational diversity tag

[Samuel Cassiba]

On Tue, May 29, 2018 at 5:51 AM, Mohammed Naser  wrote:

> On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez 
> wrote:
> > Mohammed Naser wrote:
> >>
> >> During the TC retrospective at the OpenStack summit last week, the
> >> topic of the organizational diversity tag is becoming irrelevant was
> >> brought up by Thierry (ttx)[1].  It seems that for projects that are
> >> not very active, they can easily lose this tag with a few changes by
> >> perhaps the infrastructure team for CI related fixes.
> >>
> >> As an action item, Thierry and I have paired up in order to look into
> >> a way to resolve this issue.  There have been ideas to switch this to
> >> a report that is published at the end of the cycle rather than
> >> continuously.  Julia (TheJulia) suggested that we change or track
> >> different types of diversity.
> >>
> >> Before we start diving into solutions, I wanted to bring this topic up
> >> to the mailing list and ask for any suggestions.  In digging the
> >> codebase behind this[2], I've found that there are some knobs that we
> >> can also tweak if need-be, or perhaps we can adjust those numbers
> >> depending on the number of commits.
> >
> >
> > Right, the issue is that under a given level of team activity, there is a
> > lot of state flapping between single-vendor, no tag, and
> > diverse-affiliation. Some isolated events (someone changing affiliation,
> a
> > dozen of infra-related changes) end up having a significant impact.
> >
> > My current thinking was that rather than apply a mathematical rule to
> > produce quantitative results every month, we could take the time for a
> > deeper analysis and produce a qualitative report every quarter.
>
> I like this idea, however...
>
> > Alternatively (if that's too much work), we could add a new team tag
> > (low-activity ?) that would appear for all projects where the activity
> is so
> > low that the team diversity tags no longer really apply.
>
> I think as a first step, it would be better to look into adding a
> low-activity team that so that anything under X number of commits
> would fall under that tag.  I personally lean towards this because
> it'll be a useful indication for consumers of deliverables of these
> projects, because I think low activity is just as important as
> diversity/single-vendor driven projects.
>
> The only thing I have in mind is the possible 'feeling' for projects
> which are very stable, quiet and functioning to end up with
> low-activity tag, giving an impression that they are unmaintained.  I
> think in general most associate low activity = unmaintained.. but I
> can't come up with any better options either.
>

This seems like my cue. It's unfortunate that I could not be in Vancouver
last week to discuss this, and I don't want to give the wrong impression,
but here goes. Putting my own interests up front: if openstack-chef, a
relatively quiet subproject, with a reasonably stable codebase and
measurable user base, were to be suddenly be labeled with 'low-activity',
then openstack-chef, and I imagine others in a similar situation, surely
would be considered as dead as some perceptions have suggested in the past.
The wrong perceptions can make open source contributions increasingly more
difficult to obtain and maintain over time, making 'low-activity' a
self-fulfilling prophecy and not a particularly helpful metric. For the
record, openstack-chef has no tags at all, even though we may have at some
point qualified for organizational diversity on paper.

The problem with any label close to the idea of things declining is that
the perception would be more overt than it is if we were to put our
collective heads in the sand, unable to come to an accord. Hearken to
Glance (a core project!) being barely able to make a release due to rapid
developer decline over a cycle. Consider the more recently talked about
people-formerly-known-as-docs-team, or the lesser known projects with
contributors from a couple of companies struggling to get and maintain
exposure, and the ones that lag behind core by a release (hi!) just because
it takes that long to get to the next one. Brand any or all of them
'low-activity' with the best of intentions of identifying the ones that
need love, and that's more or less signaling their end of life, since
'nobody' wants to touch that janky, unmaintained abandonware with 'no
activity'.

The moniker of 'low-activity' does give the very real, negative perception
that things are just barely hanging on. It conveys the subconscious,
officiated statement (!!!whether or not this was intended!!!) that nobody
in their right mind should consider using the subproject, let alone develop
on or against it, for fear that it wind up some poor end-user's support
nightmare. Having quietly served as PTL for four cycles -- sometimes not as
quietly as others -- I've struggled with the notions of contributorship
versus maintainership. After this long at it, experience says a bunch of
well-intended contributors does not 

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Doug Hellmann]

Excerpts from Julia Kreger's message of 2018-05-29 15:41:55 -0400:
> On Tue, May 29, 2018 at 3:16 PM, Jay S Bryant  wrote:
> >
> >
> > On 5/29/2018 2:06 PM, Artom Lifshitz wrote:
> >> Yeah, I feel like we're all essentially in agreement that nits (of the
> >> English mistake of typo type) do need to get fixed, but sometimes
> >> (often?) putting the burden of fixing them on the original patch
> >> contributor is neither fair nor constructive.
> >
> > I am ok with this statement if we are all in agreement that doing follow-up
> > patches is an acceptable practice.
> >
> It does feel like there is some general agreement. \o/
> 
> Putting my Ironic hat on, we've been trying to stress that follow-up
> patches are totally acceptable and encouraged. Follow-up patches seem
> to land faster in the grand scheme of things and allow series of
> patches to move forward in the mean time which is important when a
> feature may be spread across 10+ patches
> 
> As for editing just prior to approving, we have learned there can be
> absolutely no delay between that edit being made and the patch
> approved to land. In essence patches would begin to look like only a
> single core reviewer had approved the change they just edited even if
> the prior revision had a second core approving the prior revision.. In
> my experience, the async nature of waiting for a second core to
> sign-off on your edits incurs additional time for nitpicks to occur
> and a patch to be blocked.
> 
> Sadly putting the burden on the person approving changes to land is a
> bit much as well. I think anyone should be free to propose a follow-up
> to any patch, at least that is my opinion and why I wrote the
> principles change as I did.
> 

+1 to that last bit, for sure.

In several conversations about this last week we discussed the
impression that we don't often see +1 votes with useful comments.
A +1 with a follow-up to fix minor issues seems like something we
ought to encourage.

Doug

__
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] [tc][all] A culture change (nitpicking)

[Doug Hellmann]

Excerpts from Jay S Bryant's message of 2018-05-29 14:16:33 -0500:
> 
> On 5/29/2018 2:06 PM, Artom Lifshitz wrote:
> >> On Tue, May 29, 2018 at 10:52:04AM -0400, Mohammed Naser wrote:
> >>
> >> :On Tue, May 29, 2018 at 10:43 AM, Artom Lifshitz  
> >> wrote:
> >> :>  One idea would be that, once the meat of the patch
> >> :> has passed multiple rounds of reviews and looks good, and what remains
> >> :> is only nits, the reviewer themselves take on the responsibility of
> >> :> pushing a new patch that fixes the nits that they found.
> >>
> >> Doesn't the above suggestion sufficiently address the concern below?
> >>
> >> :I'd just like to point out that what you perceive as a 'finished
> >> :product that looks unprofessional' might be already hard enough for a
> >> :contributor to achieve.  We have a lot of new contributors coming from
> >> :all over the world and it is very discouraging for them to have their
> >> :technical knowledge and work be categorized as 'unprofessional'
> >> :because of the language barrier.
> >> :
> >> :git-nit and a few minutes of your time will go a long way, IMHO.
> >>
> >> As very intermittent contributor and native english speaker with
> >> relatively poor spelling and typing I'd be much happier with a
> >> reviewer pushing a patch that fixes nits rather than having a ton of
> >> inline comments that point them out.
> >>
> >> maybe we're all saying the same thing here?
> > Yeah, I feel like we're all essentially in agreement that nits (of the
> > English mistake of typo type) do need to get fixed, but sometimes
> > (often?) putting the burden of fixing them on the original patch
> > contributor is neither fair nor constructive.
> I am ok with this statement if we are all in agreement that doing 
> follow-up patches is an acceptable practice.

Has it ever not been?

It seems like it has always come down to a bit of negotiation with
the original author, hasn't it? And that won't change, except that
we will be emphasizing to reviewers that we encourage them to be
more active in seeking out that negotiation and then proposing
patches?

Doug

__
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][tc] final stages of python 3 transition

[Doug Hellmann]

Following up on this topic, at the Forum discussion last week (see
https://etherpad.openstack.org/p/YVR-python-2-deprecation-timeline) the
general plan outlined below was acceptable to most of the folks in the
room with a few small changes (included below).

Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
> It's time to talk about the next steps in our migration from python
> 2 to python 3.
> 
> Up to this point we have mostly focused on reaching a state where
> we support both versions of the language. We are not quite there
> with all projects, as you can see by reviewing the test coverage
> status information at
> https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects
> 
> Still, we need to press on to the next phase of the migration, which
> I have been calling "Python 3 first". This is where we use python
> 3 as the default, for everything, and set up the exceptions we need
> for anything that still requires python 2.
> 
> To reach that stage, we need to:
> 
> 1. Change the documentation and release notes jobs to use python 3.
>(The Oslo team recently completed this, and found that we did
>need to make a few small code changes to get them to work.)
> 2. Change (or duplicate) all functional test jobs to run under
>python 3.
> 3. Change the packaging jobs to use python 3.
> 4. Update devstack to use 3 by default and require setting a flag to
>use 2. (This may trigger other job changes.)

Also:

- Ensure that devstack configures mod_wsgi (or whatever WSGI service) to
  use Python 3 when deploying API components.
- Test "python version skew" within a service during a rolling upgrade
  across multiple hosts.
- Add an integration test job that does not include python2 on the host
  at all.

That last item may block us from using other tools, such as ansible,
that rely on python2. If the point of such a test is to ensure that
we are properly installing (and running) our tools under python3,
maybe *that's* what we want to check, instead of forbidding a python2
package at all? Could we, for example, look at the set of packages
installed under python2 and report errors if any OpenStack packages end
up there?

> 
> At that point, all of our deliverables will be produced using python
> 3, and we can be relatively confident that if we no longer had
> access to python 2 we could still continue operating. We could also
> start updating deployment tools to use either python 3 or 2, so
> that users could actually deploy using the python 3 versions of
> services.
> 
> Somewhere in that time frame our third-party CI systems will need
> to ensure they have python 3 support as well.
> 
> After the "Python 3 first" phase is completed we should release
> one series using the packages built with python 3. Perhaps Stein?
> Or is that too ambitious?
> 
> Next, we will be ready to address the prerequisites for "Python 3
> only," which will allow us to drop Python 2 support.
> 
> We need to wait to drop python 2 support as a community, rather
> than going one project at a time, to avoid doubling the work of
> downstream consumers such as distros and independent deployers. We
> don't want them to have to package all (or even a large number) of
> the dependencies of OpenStack twice because they have to install
> some services running under python 2 and others under 3. Ideally
> they would be able to upgrade all of the services on a node together
> as part of their transition to the new version, without ending up
> with a python 2 version of a dependency along side a python 3 version
> of the same package.
> 
> The remaining items could be fixed earlier, but this is the point
> at which they would block us:
> 
> 1. Fix oslo.service functional tests -- the Oslo team needs help
>maintaining this library. Alternatively, we could move all
>services to use cotyledon (https://pypi.org/project/cotyledon/).
> 
> 2. Finish the unit test and functional test ports so that all of
>our tests can run under python 3 (this implies that the services
>all run under python 3, so there is no more porting to do).
> 
> Finally, after we have *all* tests running on python 3, we can
> safely drop python 2.

We clarified that we would only drop python 2 support on master.
That clarification also raised the point that eventually backports
may become more difficult if master is using python 3 features, but
Matt and Tony agreed that we could potentially have rebasing issues
with fixes today so while this is a new source of such issues it
isn't a completely new problem and our stable backport policies
already address it.

> 
> We have previously discussed the end of the T cycle as the point
> at which we would have all of those tests running, and if that holds
> true we could reasonably drop python 2 during the beginning of the
> U cycle, in late 2019 and before the 2020 cut-off point when upstream
> python 2 support will be dropped.

This date as the earliest point at which existing 

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Davanum Srinivas]

Agree with Ian here.

Also another problem that comes up is: "Why are you touching *MY*
review?" (probably coming from the view where stats - and stackalytics
leaderboard position is important). So i guess we ask permission
before editing (or) file a follow up later (or) just tell folks that
this is ok to do!!

Hoping engaging with them will solve yet another issue is someone
going around filing the same change in a dozen projects (repeatedly!),
but that may be wishful thinking.

-- Dims

On Tue, May 29, 2018 at 12:17 PM, Ian Wells  wrote:
> If your nitpick is a spelling mistake or the need for a comment where you've
> pretty much typed the text of the comment in the review comment itself, then
> I have personally found it easiest to use the Gerrit online editor to
> actually update the patch yourself.  There's nothing magical about the
> original submitter, and no point in wasting your time and theirs to get them
> to make the change.  That said, please be a grown up; if you're changing
> code or messing up formatting enough for PEP8 to be a concern, it's your
> responsibility, not the original submitter's, to fix it.  Also, do all your
> fixes in one commit if you don't want to make Zuul cry.
> --
> Ian.
>
>
> On 29 May 2018 at 09:00, Neil Jerram  wrote:
>>
>> From my point of view as someone who is still just an occasional
>> contributor (in all OpenStack projects other than my own team's networking
>> driver), and so I think still sensitive to the concerns being raised here:
>>
>> - Nits are not actually a problem, at all, if they are uncontroversial and
>> quick to deal with.  For example, if it's a point of English, and most
>> English speakers would agree that a correction is better, it's quick and no
>> problem for me to make that correction.
>>
>> - What is much more of a problem is:
>>
>>   - Anything that is more a matter of opinion.  If a markup is just the
>> reviewer's personal opinion, and they can't say anything to explain more
>> objectively why their suggestion is better, it would be wiser to defer to
>> the contributor's initial choice.
>>
>>   - Questioning something unconstructively or out of proportion to the
>> change being made.  This is a tricky one to pin down, but sometimes I've had
>> comments that raise some random left-field question that isn't really
>> related to the change being made, or where the reviewer could have done a
>> couple minutes research themselves and then either made a more precise
>> comment, or not made their comment at all.
>>
>>   - Asking - implicitly or explicitly - the contributor to add more
>> cleanups to their change.  If someone usefully fixes a problem, and their
>> fix does not of itself impair the quality or maintainability of the
>> surrounding code, they should not be asked to extend their fix so as to fix
>> further problems that a more regular developer may be aware of in that area,
>> or to advance a refactoring / cleanup that another developer has in mind.
>> (At least, not as part of that initial change.)
>>
>> (Obviously the common thread of those problem points is taking up more
>> time; psychologically I think one of the things that can turn a contributor
>> away is the feeling that they've contributed a clearly useful thing, yet the
>> community is stalling over accepting it for reasons that do not appear
>> clearcut.)
>>
>> Hoping this is vaguely helpful...
>>  Neil
>>
>>
>> On Tue, May 29, 2018 at 4:35 PM Amy Marrich  wrote:
>>>
>>> If I have a nit that doesn't affect things, I'll make a note of it and
>>> say if you do another patch I'd really like it fixed but also give the patch
>>> a vote. What I'll also do sometimes if I know the user or they are online
>>> I'll offer to fix things for them, that way they can see what I've done,
>>> I've sped things along and I haven't caused a simple change to take a long
>>> amount of time and reviews.
>>>
>>> I think this is a great addition!
>>>
>>> Thanks,
>>>
>>> Amy (spotz)
>>>
>>> On Tue, May 29, 2018 at 6:55 AM, Julia Kreger
>>>  wrote:

 During the Forum, the topic of review culture came up in session after
 session. During these discussions, the subject of our use of nitpicks
 were often raised as a point of contention and frustration, especially
 by community members that have left the community and that were
 attempting to re-engage the community. Contributors raised the point
 of review feedback requiring for extremely precise English, or
 compliance to a particular core reviewer's style preferences, which
 may not be the same as another core reviewer.

 These things are not just frustrating, but also very inhibiting for
 part time contributors such as students who may also be time limited.
 Or an operator who noticed something that was clearly a bug and that
 put forth a very minor fix and doesn't have the time to revise it over
 and over.

 While nitpicks do help guide and teach, the consensus seemed to be

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Julia Kreger]

On Tue, May 29, 2018 at 3:16 PM, Jay S Bryant  wrote:
>
>
> On 5/29/2018 2:06 PM, Artom Lifshitz wrote:
>> Yeah, I feel like we're all essentially in agreement that nits (of the
>> English mistake of typo type) do need to get fixed, but sometimes
>> (often?) putting the burden of fixing them on the original patch
>> contributor is neither fair nor constructive.
>
> I am ok with this statement if we are all in agreement that doing follow-up
> patches is an acceptable practice.
>
It does feel like there is some general agreement. \o/

Putting my Ironic hat on, we've been trying to stress that follow-up
patches are totally acceptable and encouraged. Follow-up patches seem
to land faster in the grand scheme of things and allow series of
patches to move forward in the mean time which is important when a
feature may be spread across 10+ patches

As for editing just prior to approving, we have learned there can be
absolutely no delay between that edit being made and the patch
approved to land. In essence patches would begin to look like only a
single core reviewer had approved the change they just edited even if
the prior revision had a second core approving the prior revision.. In
my experience, the async nature of waiting for a second core to
sign-off on your edits incurs additional time for nitpicks to occur
and a patch to be blocked.

Sadly putting the burden on the person approving changes to land is a
bit much as well. I think anyone should be free to propose a follow-up
to any patch, at least that is my opinion and why I wrote the
principles change as I did.

__
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] [tc][all] A culture change (nitpicking)

[Ian Wells]

If your nitpick is a spelling mistake or the need for a comment where
you've pretty much typed the text of the comment in the review comment
itself, then I have personally found it easiest to use the Gerrit online
editor to actually update the patch yourself.  There's nothing magical
about the original submitter, and no point in wasting your time and theirs
to get them to make the change.  That said, please be a grown up; if you're
changing code or messing up formatting enough for PEP8 to be a concern,
it's your responsibility, not the original submitter's, to fix it.  Also,
do all your fixes in one commit if you don't want to make Zuul cry.
-- 
Ian.


On 29 May 2018 at 09:00, Neil Jerram  wrote:

> From my point of view as someone who is still just an occasional
> contributor (in all OpenStack projects other than my own team's networking
> driver), and so I think still sensitive to the concerns being raised here:
>
> - Nits are not actually a problem, at all, if they are uncontroversial and
> quick to deal with.  For example, if it's a point of English, and most
> English speakers would agree that a correction is better, it's quick and no
> problem for me to make that correction.
>
> - What is much more of a problem is:
>
>   - Anything that is more a matter of opinion.  If a markup is just the
> reviewer's personal opinion, and they can't say anything to explain more
> objectively why their suggestion is better, it would be wiser to defer to
> the contributor's initial choice.
>
>   - Questioning something unconstructively or out of proportion to the
> change being made.  This is a tricky one to pin down, but sometimes I've
> had comments that raise some random left-field question that isn't really
> related to the change being made, or where the reviewer could have done a
> couple minutes research themselves and then either made a more precise
> comment, or not made their comment at all.
>
>   - Asking - implicitly or explicitly - the contributor to add more
> cleanups to their change.  If someone usefully fixes a problem, and their
> fix does not of itself impair the quality or maintainability of the
> surrounding code, they should not be asked to extend their fix so as to fix
> further problems that a more regular developer may be aware of in that
> area, or to advance a refactoring / cleanup that another developer has in
> mind.  (At least, not as part of that initial change.)
>
> (Obviously the common thread of those problem points is taking up more
> time; psychologically I think one of the things that can turn a contributor
> away is the feeling that they've contributed a clearly useful thing, yet
> the community is stalling over accepting it for reasons that do not appear
> clearcut.)
>
> Hoping this is vaguely helpful...
>  Neil
>
>
> On Tue, May 29, 2018 at 4:35 PM Amy Marrich  wrote:
>
>> If I have a nit that doesn't affect things, I'll make a note of it and
>> say if you do another patch I'd really like it fixed but also give the
>> patch a vote. What I'll also do sometimes if I know the user or they are
>> online I'll offer to fix things for them, that way they can see what I've
>> done, I've sped things along and I haven't caused a simple change to take a
>> long amount of time and reviews.
>>
>> I think this is a great addition!
>>
>> Thanks,
>>
>> Amy (spotz)
>>
>> On Tue, May 29, 2018 at 6:55 AM, Julia Kreger <
>> juliaashleykre...@gmail.com> wrote:
>>
>>> During the Forum, the topic of review culture came up in session after
>>> session. During these discussions, the subject of our use of nitpicks
>>> were often raised as a point of contention and frustration, especially
>>> by community members that have left the community and that were
>>> attempting to re-engage the community. Contributors raised the point
>>> of review feedback requiring for extremely precise English, or
>>> compliance to a particular core reviewer's style preferences, which
>>> may not be the same as another core reviewer.
>>>
>>> These things are not just frustrating, but also very inhibiting for
>>> part time contributors such as students who may also be time limited.
>>> Or an operator who noticed something that was clearly a bug and that
>>> put forth a very minor fix and doesn't have the time to revise it over
>>> and over.
>>>
>>> While nitpicks do help guide and teach, the consensus seemed to be
>>> that we do need to shift the culture a little bit. As such, I've
>>> proposed a change to our principles[1] in governance that attempts to
>>> capture the essence and spirit of the nitpicking topic as a first
>>> step.
>>>
>>> -Julia
>>> -
>>> [1]: https://review.openstack.org/570940
>>>
>>> 
>>> __
>>> 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] [tc][all] A culture change (nitpicking)

[Jay S Bryant]

On 5/29/2018 2:06 PM, Artom Lifshitz wrote:

On Tue, May 29, 2018 at 10:52:04AM -0400, Mohammed Naser wrote:

:On Tue, May 29, 2018 at 10:43 AM, Artom Lifshitz  wrote:
:>  One idea would be that, once the meat of the patch
:> has passed multiple rounds of reviews and looks good, and what remains
:> is only nits, the reviewer themselves take on the responsibility of
:> pushing a new patch that fixes the nits that they found.

Doesn't the above suggestion sufficiently address the concern below?

:I'd just like to point out that what you perceive as a 'finished
:product that looks unprofessional' might be already hard enough for a
:contributor to achieve.  We have a lot of new contributors coming from
:all over the world and it is very discouraging for them to have their
:technical knowledge and work be categorized as 'unprofessional'
:because of the language barrier.
:
:git-nit and a few minutes of your time will go a long way, IMHO.

As very intermittent contributor and native english speaker with
relatively poor spelling and typing I'd be much happier with a
reviewer pushing a patch that fixes nits rather than having a ton of
inline comments that point them out.

maybe we're all saying the same thing here?

Yeah, I feel like we're all essentially in agreement that nits (of the
English mistake of typo type) do need to get fixed, but sometimes
(often?) putting the burden of fixing them on the original patch
contributor is neither fair nor constructive.
I am ok with this statement if we are all in agreement that doing 
follow-up patches is an acceptable practice.



__
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] [tc][all] A culture change (nitpicking)

[Artom Lifshitz]

> On Tue, May 29, 2018 at 10:52:04AM -0400, Mohammed Naser wrote:
>
> :On Tue, May 29, 2018 at 10:43 AM, Artom Lifshitz  wrote:
> :>  One idea would be that, once the meat of the patch
> :> has passed multiple rounds of reviews and looks good, and what remains
> :> is only nits, the reviewer themselves take on the responsibility of
> :> pushing a new patch that fixes the nits that they found.
>
> Doesn't the above suggestion sufficiently address the concern below?
>
> :I'd just like to point out that what you perceive as a 'finished
> :product that looks unprofessional' might be already hard enough for a
> :contributor to achieve.  We have a lot of new contributors coming from
> :all over the world and it is very discouraging for them to have their
> :technical knowledge and work be categorized as 'unprofessional'
> :because of the language barrier.
> :
> :git-nit and a few minutes of your time will go a long way, IMHO.
>
> As very intermittent contributor and native english speaker with
> relatively poor spelling and typing I'd be much happier with a
> reviewer pushing a patch that fixes nits rather than having a ton of
> inline comments that point them out.
>
> maybe we're all saying the same thing here?

Yeah, I feel like we're all essentially in agreement that nits (of the
English mistake of typo type) do need to get fixed, but sometimes
(often?) putting the burden of fixing them on the original patch
contributor is neither fair nor constructive.

__
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] [tc][all] A culture change (nitpicking)

[Jay S Bryant]

Julia,

Thank you for starting this discussion.


On 5/29/2018 9:43 AM, Artom Lifshitz wrote:

I dunno, there's a fine line to be drawn between getting a finished
product that looks unprofessional (because of typos, English mistakes,
etc), and nitpicking to the point of smothering and being
counter-productive. One idea would be that, once the meat of the patch
has passed multiple rounds of reviews and looks good, and what remains
is only nits, the reviewer themselves take on the responsibility of
pushing a new patch that fixes the nits that they found.
In the past this is something that I have wanted to do but have received 
mixed feedback on its level of appropriateness.  I am happy to push 
follow-up patches to address nit-picks rather than hold up a patch.  We, 
however, will need to communicate to the community that this is now an 
acceptable practice.



On Tue, May 29, 2018 at 9:55 AM, Julia Kreger
 wrote:

During the Forum, the topic of review culture came up in session after
session. During these discussions, the subject of our use of nitpicks
were often raised as a point of contention and frustration, especially
by community members that have left the community and that were
attempting to re-engage the community. Contributors raised the point
of review feedback requiring for extremely precise English, or
compliance to a particular core reviewer's style preferences, which
may not be the same as another core reviewer.

These things are not just frustrating, but also very inhibiting for
part time contributors such as students who may also be time limited.
Or an operator who noticed something that was clearly a bug and that
put forth a very minor fix and doesn't have the time to revise it over
and over.

While nitpicks do help guide and teach, the consensus seemed to be
that we do need to shift the culture a little bit. As such, I've
proposed a change to our principles[1] in governance that attempts to
capture the essence and spirit of the nitpicking topic as a first
step.

-Julia
-
[1]: https://review.openstack.org/570940

__
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] [TC] [Infra] Terms of service for hosted projects

[Jeremy Stanley]

On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote:
> We allow various open source projects that are not an official
> part of OpenStack or necessarily used by OpenStack to be hosted on
> OpenStack infrastructure - previously under the 'StackForge'
> branding, but now without separate branding. Do we document
> anywhere the terms of service under which we offer such hosting?

We do so minimally here:

https://docs.openstack.org/infra/system-config/unofficial_project_hosting.html

It's linked from this section of the Project Creator’s Guide in the
Infra Manual:

https://docs.openstack.org/infra/manual/creators.html#decide-status-of-your-project

But yes, we should probably add some clarity to that document and
see about making sure it's linked more prominently. We also maintain
some guidelines for reviewers of changes to the
openstack-infra/project-config repository, which has a bit to say
about new repository creation changes:

https://git.openstack.org/cgit/openstack-infra/project-config/tree/REVIEWING.rst

> It is my understanding that the infra team will enforce the
> following conditions when a repo import request is received:
> 
> * The repo must be licensed under an OSI-approved open source
> license.

That has been our custom, but we should add a statement to this
effect in the aforementioned document.

> * If the repo is a fork of another project, there must be (public)
> evidence of an attempt to co-ordinate with the upstream first.

I don't recall this ever being mandated, though the project-config
reviewers do often provide suggestions to project creators such as
places in the existing community with which they might consider
cooperating/collaborating.

> Neither of those appears to be documented (specifically,
> https://governance.openstack.org/tc/reference/licensing.html only
> specifies licensing requirements for official projects, libraries
> imported by official projects, and software used by the Infra
> team).

The Infrastructure team has been granted a fair amount of autonomy
to determine its operating guidelines, and future plans to separate
project hosting further from the OpenStack name (in an attempt to
make it more clear that hosting your project in the infrastructure
is not an endorsement by OpenStack and doesn't make it "part of
OpenStack") make the OpenStack TC governance site a particularly
poor choice of venue to document such things.

> In addition, I think we should require projects hosted on our
> infrastructure to agree to other policies:
> 
> * Adhere to the OpenStack Foundation Code of Conduct.

This seems like a reasonable addition to our hosting requirements.

> * Not misrepresent their relationship to the official OpenStack
> project or the Foundation. Ideally we'd come up with language that
> they *can* use to describe their status, such as "hosted on the
> OpenStack infrastructure".

Also a great suggestion. We sort of say that in the "what being an
unoffocial project is not" bullet list, but it could use some
fleshing out.

> If we don't have place where this kind of thing is documented
> already, I'll submit a review adding one. Does anybody have any
> ideas about a process for ensuring that projects have read and
> agreed to the terms when we add them?

Adding process forcing active confirmation of such rules seems like
a lot of unnecessary overhead/red tape/bureaucracy. As it stands,
we're working to get rid of active agreement to the ICLA in favor of
simply asserting the DCO in commit messages, so I'm not a fan of
adding some new agreement people have to directly acknowledge along
with associated automation and policing.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [tc] Organizational diversity tag

[Doug Hellmann]

Excerpts from Mohammed Naser's message of 2018-05-29 08:51:16 -0400:
> On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez  wrote:
> > Mohammed Naser wrote:
> >>
> >> During the TC retrospective at the OpenStack summit last week, the
> >> topic of the organizational diversity tag is becoming irrelevant was
> >> brought up by Thierry (ttx)[1].  It seems that for projects that are
> >> not very active, they can easily lose this tag with a few changes by
> >> perhaps the infrastructure team for CI related fixes.
> >>
> >> As an action item, Thierry and I have paired up in order to look into
> >> a way to resolve this issue.  There have been ideas to switch this to
> >> a report that is published at the end of the cycle rather than
> >> continuously.  Julia (TheJulia) suggested that we change or track
> >> different types of diversity.
> >>
> >> Before we start diving into solutions, I wanted to bring this topic up
> >> to the mailing list and ask for any suggestions.  In digging the
> >> codebase behind this[2], I've found that there are some knobs that we
> >> can also tweak if need-be, or perhaps we can adjust those numbers
> >> depending on the number of commits.
> >
> >
> > Right, the issue is that under a given level of team activity, there is a
> > lot of state flapping between single-vendor, no tag, and
> > diverse-affiliation. Some isolated events (someone changing affiliation, a
> > dozen of infra-related changes) end up having a significant impact.
> >
> > My current thinking was that rather than apply a mathematical rule to
> > produce quantitative results every month, we could take the time for a
> > deeper analysis and produce a qualitative report every quarter.
> 
> I like this idea, however...
> 
> > Alternatively (if that's too much work), we could add a new team tag
> > (low-activity ?) that would appear for all projects where the activity is so
> > low that the team diversity tags no longer really apply.
> 
> I think as a first step, it would be better to look into adding a
> low-activity team that so that anything under X number of commits
> would fall under that tag.  I personally lean towards this because
> it'll be a useful indication for consumers of deliverables of these
> projects, because I think low activity is just as important as
> diversity/single-vendor driven projects.
> 
> The only thing I have in mind is the possible 'feeling' for projects
> which are very stable, quiet and functioning to end up with
> low-activity tag, giving an impression that they are unmaintained.  I
> think in general most associate low activity = unmaintained.. but I
> can't come up with any better options either.

We have the status:maintenance-mode tag[3] today. How would a new
"low-activity" tag be differentiated from the existing one?

[3] 
https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html

> 
> > --
> > Thierry Carrez (ttx)
> >
> > __
> > 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] [tc][all] A culture change (nitpicking)

[Davanum Srinivas]

Thanks for driving this Julia. +1. It's time to do this.

-- Dims

On Tue, May 29, 2018 at 6:55 AM, Julia Kreger
 wrote:
> During the Forum, the topic of review culture came up in session after
> session. During these discussions, the subject of our use of nitpicks
> were often raised as a point of contention and frustration, especially
> by community members that have left the community and that were
> attempting to re-engage the community. Contributors raised the point
> of review feedback requiring for extremely precise English, or
> compliance to a particular core reviewer's style preferences, which
> may not be the same as another core reviewer.
>
> These things are not just frustrating, but also very inhibiting for
> part time contributors such as students who may also be time limited.
> Or an operator who noticed something that was clearly a bug and that
> put forth a very minor fix and doesn't have the time to revise it over
> and over.
>
> While nitpicks do help guide and teach, the consensus seemed to be
> that we do need to shift the culture a little bit. As such, I've
> proposed a change to our principles[1] in governance that attempts to
> capture the essence and spirit of the nitpicking topic as a first
> step.
>
> -Julia
> -
> [1]: https://review.openstack.org/570940
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [tc][all] A culture change (nitpicking)

[Joshua Harlow]

Jonathan D. Proulx wrote:

On Tue, May 29, 2018 at 10:52:04AM -0400, Mohammed Naser wrote:

:On Tue, May 29, 2018 at 10:43 AM, Artom Lifshitz  wrote:
:>   One idea would be that, once the meat of the patch
:>  has passed multiple rounds of reviews and looks good, and what remains
:>  is only nits, the reviewer themselves take on the responsibility of
:>  pushing a new patch that fixes the nits that they found.

Doesn't the above suggestion sufficiently address the concern below?

:I'd just like to point out that what you perceive as a 'finished
:product that looks unprofessional' might be already hard enough for a
:contributor to achieve.  We have a lot of new contributors coming from
:all over the world and it is very discouraging for them to have their
:technical knowledge and work be categorized as 'unprofessional'
:because of the language barrier.
:
:git-nit and a few minutes of your time will go a long way, IMHO.

As very intermittent contributor and native english speaker with
relatively poor spelling and typing I'd be much happier with a
reviewer pushing a patch that fixes nits rather than having a ton of
inline comments that point them out.

maybe we're all saying the same thing here?


https://sep.yimg.com/ay/computergear/i-write-code-computer-t-shirt-13.gif

I am the same ;)



-JOn

__
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] [tc][all] A culture change (nitpicking)

[Mathieu Gagné]

Hi Julia,

Thanks for the follow up on this topic.

On Tue, May 29, 2018 at 6:55 AM, Julia Kreger
 wrote:
>
> These things are not just frustrating, but also very inhibiting for
> part time contributors such as students who may also be time limited.
> Or an operator who noticed something that was clearly a bug and that
> put forth a very minor fix and doesn't have the time to revise it over
> and over.
>

What I found frustrating is receiving *only* nitpicks, addressing them
to only receive more nitpicks (sometimes from the same reviewer) with
no substantial review on the change itself afterward.
I wouldn't mind addressing nitpicks if more substantial reviews were
made in a timely fashion.

--
Mathieu

__
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] [tc][all] A culture change (nitpicking)

[Jonathan D. Proulx]

On Tue, May 29, 2018 at 10:52:04AM -0400, Mohammed Naser wrote:

:On Tue, May 29, 2018 at 10:43 AM, Artom Lifshitz  wrote:
:>  One idea would be that, once the meat of the patch
:> has passed multiple rounds of reviews and looks good, and what remains
:> is only nits, the reviewer themselves take on the responsibility of
:> pushing a new patch that fixes the nits that they found.

Doesn't the above suggestion sufficiently address the concern below?

:I'd just like to point out that what you perceive as a 'finished
:product that looks unprofessional' might be already hard enough for a
:contributor to achieve.  We have a lot of new contributors coming from
:all over the world and it is very discouraging for them to have their
:technical knowledge and work be categorized as 'unprofessional'
:because of the language barrier.
:
:git-nit and a few minutes of your time will go a long way, IMHO.

As very intermittent contributor and native english speaker with
relatively poor spelling and typing I'd be much happier with a
reviewer pushing a patch that fixes nits rather than having a ton of
inline comments that point them out.

maybe we're all saying the same thing here?

-JOn

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

Re: [openstack-dev] [Release-job-failures][tripleo] Release of openstack/tripleo-validations failed

[Alex Schultz]

On Tue, May 29, 2018 at 9:31 AM, Doug Hellmann  wrote:
> Excerpts from zuul's message of 2018-05-29 14:28:57 +:
>> Build failed.
>>
>> - release-openstack-python 
>> http://logs.openstack.org/26/26956a27b95550e2162243da79d62bb1b19d50d7/release/release-openstack-python/2bd7f7d/
>>  : POST_FAILURE in 6m 34s
>> - announce-release announce-release : SKIPPED
>> - propose-update-constraints propose-update-constraints : SKIPPED
>>
>
> There appears to be an issue with the tripleo-validations README.rst
> file. It's likely this is new validation being done by PyPI, so rather
> than worrying about which change broke things, I suggest just working out
> how to fix it and move on.
>
> http://logs.openstack.org/26/26956a27b95550e2162243da79d62bb1b19d50d7/release/release-openstack-python/2bd7f7d/job-output.txt.gz#_2018-05-29_14_28_35_963702
>

https://bugs.launchpad.net/tripleo/+bug/1774001

I've proposed a fix to shuffle around the readme to clean this up.
https://review.openstack.org/570954

Thanks,
-Alex

> Doug
>
> __
> 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] [tc][all] A culture change (nitpicking)

[Neil Jerram]

>From my point of view as someone who is still just an occasional
contributor (in all OpenStack projects other than my own team's networking
driver), and so I think still sensitive to the concerns being raised here:

- Nits are not actually a problem, at all, if they are uncontroversial and
quick to deal with.  For example, if it's a point of English, and most
English speakers would agree that a correction is better, it's quick and no
problem for me to make that correction.

- What is much more of a problem is:

  - Anything that is more a matter of opinion.  If a markup is just the
reviewer's personal opinion, and they can't say anything to explain more
objectively why their suggestion is better, it would be wiser to defer to
the contributor's initial choice.

  - Questioning something unconstructively or out of proportion to the
change being made.  This is a tricky one to pin down, but sometimes I've
had comments that raise some random left-field question that isn't really
related to the change being made, or where the reviewer could have done a
couple minutes research themselves and then either made a more precise
comment, or not made their comment at all.

  - Asking - implicitly or explicitly - the contributor to add more
cleanups to their change.  If someone usefully fixes a problem, and their
fix does not of itself impair the quality or maintainability of the
surrounding code, they should not be asked to extend their fix so as to fix
further problems that a more regular developer may be aware of in that
area, or to advance a refactoring / cleanup that another developer has in
mind.  (At least, not as part of that initial change.)

(Obviously the common thread of those problem points is taking up more
time; psychologically I think one of the things that can turn a contributor
away is the feeling that they've contributed a clearly useful thing, yet
the community is stalling over accepting it for reasons that do not appear
clearcut.)

Hoping this is vaguely helpful...
 Neil


On Tue, May 29, 2018 at 4:35 PM Amy Marrich  wrote:

> If I have a nit that doesn't affect things, I'll make a note of it and say
> if you do another patch I'd really like it fixed but also give the patch a
> vote. What I'll also do sometimes if I know the user or they are online
> I'll offer to fix things for them, that way they can see what I've done,
> I've sped things along and I haven't caused a simple change to take a long
> amount of time and reviews.
>
> I think this is a great addition!
>
> Thanks,
>
> Amy (spotz)
>
> On Tue, May 29, 2018 at 6:55 AM, Julia Kreger  > wrote:
>
>> During the Forum, the topic of review culture came up in session after
>> session. During these discussions, the subject of our use of nitpicks
>> were often raised as a point of contention and frustration, especially
>> by community members that have left the community and that were
>> attempting to re-engage the community. Contributors raised the point
>> of review feedback requiring for extremely precise English, or
>> compliance to a particular core reviewer's style preferences, which
>> may not be the same as another core reviewer.
>>
>> These things are not just frustrating, but also very inhibiting for
>> part time contributors such as students who may also be time limited.
>> Or an operator who noticed something that was clearly a bug and that
>> put forth a very minor fix and doesn't have the time to revise it over
>> and over.
>>
>> While nitpicks do help guide and teach, the consensus seemed to be
>> that we do need to shift the culture a little bit. As such, I've
>> proposed a change to our principles[1] in governance that attempts to
>> capture the essence and spirit of the nitpicking topic as a first
>> step.
>>
>> -Julia
>> -
>> [1]: https://review.openstack.org/570940
>>
>> __
>> 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] [tc][all] A culture change (nitpicking)

[Amy Marrich]

If I have a nit that doesn't affect things, I'll make a note of it and say
if you do another patch I'd really like it fixed but also give the patch a
vote. What I'll also do sometimes if I know the user or they are online
I'll offer to fix things for them, that way they can see what I've done,
I've sped things along and I haven't caused a simple change to take a long
amount of time and reviews.

I think this is a great addition!

Thanks,

Amy (spotz)

On Tue, May 29, 2018 at 6:55 AM, Julia Kreger 
wrote:

> During the Forum, the topic of review culture came up in session after
> session. During these discussions, the subject of our use of nitpicks
> were often raised as a point of contention and frustration, especially
> by community members that have left the community and that were
> attempting to re-engage the community. Contributors raised the point
> of review feedback requiring for extremely precise English, or
> compliance to a particular core reviewer's style preferences, which
> may not be the same as another core reviewer.
>
> These things are not just frustrating, but also very inhibiting for
> part time contributors such as students who may also be time limited.
> Or an operator who noticed something that was clearly a bug and that
> put forth a very minor fix and doesn't have the time to revise it over
> and over.
>
> While nitpicks do help guide and teach, the consensus seemed to be
> that we do need to shift the culture a little bit. As such, I've
> proposed a change to our principles[1] in governance that attempts to
> capture the essence and spirit of the nitpicking topic as a first
> step.
>
> -Julia
> -
> [1]: https://review.openstack.org/570940
>
> __
> 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] [Release-job-failures][tripleo] Release of openstack/tripleo-validations failed

[Doug Hellmann]

Excerpts from zuul's message of 2018-05-29 14:28:57 +:
> Build failed.
> 
> - release-openstack-python 
> http://logs.openstack.org/26/26956a27b95550e2162243da79d62bb1b19d50d7/release/release-openstack-python/2bd7f7d/
>  : POST_FAILURE in 6m 34s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 

There appears to be an issue with the tripleo-validations README.rst
file. It's likely this is new validation being done by PyPI, so rather
than worrying about which change broke things, I suggest just working out
how to fix it and move on.

http://logs.openstack.org/26/26956a27b95550e2162243da79d62bb1b19d50d7/release/release-openstack-python/2bd7f7d/job-output.txt.gz#_2018-05-29_14_28_35_963702

Doug

__
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] [TC] Terms of service for hosted projects

[Zane Bitter]

We allow various open source projects that are not an official part of 
OpenStack or necessarily used by OpenStack to be hosted on OpenStack 
infrastructure - previously under the 'StackForge' branding, but now 
without separate branding. Do we document anywhere the terms of service 
under which we offer such hosting?


It is my understanding that the infra team will enforce the following 
conditions when a repo import request is received:


* The repo must be licensed under an OSI-approved open source license.

* If the repo is a fork of another project, there must be (public) 
evidence of an attempt to co-ordinate with the upstream first.


Neither of those appears to be documented (specifically, 
https://governance.openstack.org/tc/reference/licensing.html only 
specifies licensing requirements for official projects, libraries 
imported by official projects, and software used by the Infra team).


In addition, I think we should require projects hosted on our 
infrastructure to agree to other policies:


* Adhere to the OpenStack Foundation Code of Conduct.

* Not misrepresent their relationship to the official OpenStack project 
or the Foundation. Ideally we'd come up with language that they *can* 
use to describe their status, such as "hosted on the OpenStack 
infrastructure".


If we don't have place where this kind of thing is documented already, 
I'll submit a review adding one. Does anybody have any ideas about a 
process for ensuring that projects have read and agreed to the terms 
when we add them?


cheers,
Zane.

__
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] [tc][all] A culture change (nitpicking)

[Mohammed Naser]

On Tue, May 29, 2018 at 10:43 AM, Artom Lifshitz  wrote:
> I dunno, there's a fine line to be drawn between getting a finished
> product that looks unprofessional (because of typos, English mistakes,
> etc), and nitpicking to the point of smothering and being
> counter-productive. One idea would be that, once the meat of the patch
> has passed multiple rounds of reviews and looks good, and what remains
> is only nits, the reviewer themselves take on the responsibility of
> pushing a new patch that fixes the nits that they found.

I'd just like to point out that what you perceive as a 'finished
product that looks unprofessional' might be already hard enough for a
contributor to achieve.  We have a lot of new contributors coming from
all over the world and it is very discouraging for them to have their
technical knowledge and work be categorized as 'unprofessional'
because of the language barrier.

git-nit and a few minutes of your time will go a long way, IMHO.

> On Tue, May 29, 2018 at 9:55 AM, Julia Kreger
>  wrote:
>> During the Forum, the topic of review culture came up in session after
>> session. During these discussions, the subject of our use of nitpicks
>> were often raised as a point of contention and frustration, especially
>> by community members that have left the community and that were
>> attempting to re-engage the community. Contributors raised the point
>> of review feedback requiring for extremely precise English, or
>> compliance to a particular core reviewer's style preferences, which
>> may not be the same as another core reviewer.
>>
>> These things are not just frustrating, but also very inhibiting for
>> part time contributors such as students who may also be time limited.
>> Or an operator who noticed something that was clearly a bug and that
>> put forth a very minor fix and doesn't have the time to revise it over
>> and over.
>>
>> While nitpicks do help guide and teach, the consensus seemed to be
>> that we do need to shift the culture a little bit. As such, I've
>> proposed a change to our principles[1] in governance that attempts to
>> capture the essence and spirit of the nitpicking topic as a first
>> step.
>>
>> -Julia
>> -
>> [1]: https://review.openstack.org/570940
>>
>> __
>> 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
>
>
>
> --
> --
> Artom Lifshitz
> Software Engineer, OpenStack Compute DFG
>
> __
> 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] [tc][all] A culture change (nitpicking)

[Artom Lifshitz]

I dunno, there's a fine line to be drawn between getting a finished
product that looks unprofessional (because of typos, English mistakes,
etc), and nitpicking to the point of smothering and being
counter-productive. One idea would be that, once the meat of the patch
has passed multiple rounds of reviews and looks good, and what remains
is only nits, the reviewer themselves take on the responsibility of
pushing a new patch that fixes the nits that they found.

On Tue, May 29, 2018 at 9:55 AM, Julia Kreger
 wrote:
> During the Forum, the topic of review culture came up in session after
> session. During these discussions, the subject of our use of nitpicks
> were often raised as a point of contention and frustration, especially
> by community members that have left the community and that were
> attempting to re-engage the community. Contributors raised the point
> of review feedback requiring for extremely precise English, or
> compliance to a particular core reviewer's style preferences, which
> may not be the same as another core reviewer.
>
> These things are not just frustrating, but also very inhibiting for
> part time contributors such as students who may also be time limited.
> Or an operator who noticed something that was clearly a bug and that
> put forth a very minor fix and doesn't have the time to revise it over
> and over.
>
> While nitpicks do help guide and teach, the consensus seemed to be
> that we do need to shift the culture a little bit. As such, I've
> proposed a change to our principles[1] in governance that attempts to
> capture the essence and spirit of the nitpicking topic as a first
> step.
>
> -Julia
> -
> [1]: https://review.openstack.org/570940
>
> __
> 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



-- 
--
Artom Lifshitz
Software Engineer, OpenStack Compute DFG

__
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-operators] [nova] Need some feedback on the proposed heal_allocations CLI

[Matt Riedemann]

On 5/28/2018 7:31 AM, Sylvain Bauza wrote:
That said, given I'm now working on using Nested Resource Providers for 
VGPU inventories, I wonder about a possible upgrade problem with VGPU 
allocations. Given that :
  - in Queens, VGPU inventories are for the root RP (ie. the compute 
node RP), but,
  - in Rocky, VGPU inventories will be for children RPs (ie. against a 
specific VGPU type), then


if we have VGPU allocations in Queens, when upgrading to Rocky, we 
should maybe recreate the allocations to a specific other inventory ?


For how the heal_allocations CLI works today, if the instance has any 
allocations in placement, it skips that instance. So this scenario 
wouldn't be a problem.




Hope you see the problem with upgrading by creating nested RPs ?


Yes, the CLI doesn't attempt to have any knowledge about nested resource 
providers, it just takes the flavor embedded in the instance and creates 
allocations against the compute node provider using the flavor. It has 
no explicit knowledge about granular request groups or more advanced 
features like that.


--

Thanks,

Matt

__
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] [nova] nova aggregate and nova placement api aggregate

[Matt Riedemann]

On 5/25/2018 12:56 AM, Matt Riedemann wrote:

On 5/24/2018 8:33 PM, Jeffrey Zhang wrote:
Recently, i am trying to implement a function which aggregate nova 
hypervisors
rather than nova compute host. But seems nova only aggregate 
nova-compute host.


On the other hand, since Ocata, nova depends on placement api which 
supports
aggregating resource providers. But nova-scheduler doesn't use this 
feature

now.

So  is there any better way to solve such issue? and is there any plan 
which
make nova legacy aggregate and placement api aggregate cloud work 
together?


There are some new features in Rocky [1] that involve resource provider 
aggregates for compute nodes which can be used for scheduling and will 
actually allow you to remove some older filters 
(AggregateMultiTenancyIsolation and AvailabilityZoneFilter). CERN is 
using these to improve performance with their cells v2 deployment.




Oops, I forgot to include the link to the reference [1].

[1] 
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregates-in-placement


--

Thanks,

Matt

__
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] [tc][all] A culture change (nitpicking)

[Julia Kreger]

During the Forum, the topic of review culture came up in session after
session. During these discussions, the subject of our use of nitpicks
were often raised as a point of contention and frustration, especially
by community members that have left the community and that were
attempting to re-engage the community. Contributors raised the point
of review feedback requiring for extremely precise English, or
compliance to a particular core reviewer's style preferences, which
may not be the same as another core reviewer.

These things are not just frustrating, but also very inhibiting for
part time contributors such as students who may also be time limited.
Or an operator who noticed something that was clearly a bug and that
put forth a very minor fix and doesn't have the time to revise it over
and over.

While nitpicks do help guide and teach, the consensus seemed to be
that we do need to shift the culture a little bit. As such, I've
proposed a change to our principles[1] in governance that attempts to
capture the essence and spirit of the nitpicking topic as a first
step.

-Julia
-
[1]: https://review.openstack.org/570940

__
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] [nova] [placement] Upgrade concerns with nested Resource Providers

[Sylvain Bauza]

On Tue, May 29, 2018 at 2:21 PM, Balázs Gibizer  wrote:

>
>
> On Tue, May 29, 2018 at 1:47 PM, Sylvain Bauza  wrote:
>
>>
>>
>> Le mar. 29 mai 2018 à 11:02, Balázs Gibizer 
>> a écrit :
>>
>>>
>>>
>>> On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza 
>>> wrote:
>>> >
>>> >
>>> > On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA
>>> >  wrote
>>> >
>>> >> > In that situation, say for example with VGPU inventories, that
>>> >> would mean
>>> >> > that the compute node would stop reporting inventories for its
>>> >> root RP, but
>>> >> > would rather report inventories for at least one single child RP.
>>> >> > In that model, do we reconcile the allocations that were already
>>> >> made
>>> >> > against the "root RP" inventory ?
>>> >>
>>> >> It would be nice to see Eric and Jay comment on this,
>>> >> but if I'm not mistaken, when the virt driver stops reporting
>>> >> inventories for its root RP, placement would try to delete that
>>> >> inventory inside and raise InventoryInUse exception if any
>>> >> allocations still exist on that resource.
>>> >>
>>> >> ```
>>> >> update_from_provider_tree() (nova/compute/resource_tracker.py)
>>> >>   + _set_inventory_for_provider() (nova/scheduler/client/report.py)
>>> >>   + put() - PUT /resource_providers//inventories with
>>> >> new inventories (scheduler/client/report.py)
>>> >>   + set_inventories() (placement/handler/inventory.py)
>>> >>   + _set_inventory()
>>> >> (placement/objects/resource_proveider.py)
>>> >>   + _delete_inventory_from_provider()
>>> >> (placement/objects/resource_proveider.py)
>>> >>   -> raise exception.InventoryInUse
>>> >> ```
>>> >>
>>> >> So we need some trick something like deleting VGPU allocations
>>> >> before upgrading and set the allocation again for the created new
>>> >> child after upgrading?
>>> >>
>>> >
>>> > I wonder if we should keep the existing inventory in the root RP, and
>>> > somehow just reserve the left resources (so Placement wouldn't pass
>>> > that root RP for queries, but would still have allocations). But
>>> > then, where and how to do this ? By the resource tracker ?
>>> >
>>>
>>> AFAIK it is the virt driver that decides to model the VGU resource at a
>>> different place in the RP tree so I think it is the responsibility of
>>> the same virt driver to move any existing allocation from the old place
>>> to the new place during this change.
>>>
>>> Cheers,
>>> gibi
>>>
>>
>> Why not instead not move the allocation but rather have the virt driver
>> updating the root RP by modifying the reserved value to the total size?
>>
>> That way, the virt driver wouldn't need to ask for an allocation but
>> rather continue to provide inventories...
>>
>> Thoughts?
>>
>
> Keeping the old allocaton at the old RP and adding a similar sized
> reservation in the new RP feels hackis as those are not really reserved
> GPUs but used GPUs just from the old RP. If somebody sums up the total
> reported GPUs in this setup via the placement API then she will get more
> GPUs in total that what is physically visible for the hypervisor as the
> GPUs part of the old allocation reported twice in two different total
> value. Could we just report less GPU inventories to the new RP until the
> old RP has GPU allocations?
>
>

We could keep the old inventory in the root RP for the previous vGPU type
already supported in Queens and just add other inventories for other vGPU
types now supported. That looks possibly the simpliest option as the virt
driver knows that.



> Some alternatives from my jetlagged brain:
>
> a) Implement a move inventory/allocation API in placement. Given a
> resource class and a source RP uuid and a destination RP uuid placement
> moves the inventory and allocations of that resource class from the source
> RP to the destination RP. Then the virt drive can call this API to move the
> allocation. This has an impact on the fast forward upgrade as it needs
> running virt driver to do the allocation move.
>
>
Instead of having the virt driver doing that (TBH, I don't like that given
both Xen and libvirt drivers have the same problem), we could write a
nova-manage upgrade call for that that would call the Placement API, sure.


> b) For this I assume that live migrating an instance having a GPU
> allocation on the old RP will allocate GPU for that instance from the new
> RP. In the virt driver do not report GPUs to the new RP while there is
> allocation for such GPUs in the old RP. Let the deployer live migrate away
> the instances. When the virt driver detects that there is no more GPU
> allocations on the old RP it can delete the inventory from the old RP and
> report it to the new RP.
>
>
For the moment, vGPUs don't support live migration, even within QEMU. I
haven't checked that, but IIUC when you live-migrate an instance that have
vGPUs, it will just migrate it without recreating the vGPUs.
Now, the problem is with the VGPU allocation, we should delete it then.

Re: [openstack-dev] [tc] Organizational diversity tag

[Mohammed Naser]

On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez  wrote:
> Mohammed Naser wrote:
>>
>> During the TC retrospective at the OpenStack summit last week, the
>> topic of the organizational diversity tag is becoming irrelevant was
>> brought up by Thierry (ttx)[1].  It seems that for projects that are
>> not very active, they can easily lose this tag with a few changes by
>> perhaps the infrastructure team for CI related fixes.
>>
>> As an action item, Thierry and I have paired up in order to look into
>> a way to resolve this issue.  There have been ideas to switch this to
>> a report that is published at the end of the cycle rather than
>> continuously.  Julia (TheJulia) suggested that we change or track
>> different types of diversity.
>>
>> Before we start diving into solutions, I wanted to bring this topic up
>> to the mailing list and ask for any suggestions.  In digging the
>> codebase behind this[2], I've found that there are some knobs that we
>> can also tweak if need-be, or perhaps we can adjust those numbers
>> depending on the number of commits.
>
>
> Right, the issue is that under a given level of team activity, there is a
> lot of state flapping between single-vendor, no tag, and
> diverse-affiliation. Some isolated events (someone changing affiliation, a
> dozen of infra-related changes) end up having a significant impact.
>
> My current thinking was that rather than apply a mathematical rule to
> produce quantitative results every month, we could take the time for a
> deeper analysis and produce a qualitative report every quarter.

I like this idea, however...

> Alternatively (if that's too much work), we could add a new team tag
> (low-activity ?) that would appear for all projects where the activity is so
> low that the team diversity tags no longer really apply.

I think as a first step, it would be better to look into adding a
low-activity team that so that anything under X number of commits
would fall under that tag.  I personally lean towards this because
it'll be a useful indication for consumers of deliverables of these
projects, because I think low activity is just as important as
diversity/single-vendor driven projects.

The only thing I have in mind is the possible 'feeling' for projects
which are very stable, quiet and functioning to end up with
low-activity tag, giving an impression that they are unmaintained.  I
think in general most associate low activity = unmaintained.. but I
can't come up with any better options either.

> --
> Thierry Carrez (ttx)
>
> __
> 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] [nova] [placement] Upgrade concerns with nested Resource Providers

[Balázs Gibizer]

On Tue, May 29, 2018 at 1:47 PM, Sylvain Bauza  
wrote:



Le mar. 29 mai 2018 à 11:02, Balázs Gibizer 
 a écrit :



On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza 
wrote:
>
>
> On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA
>  wrote
>
>> > In that situation, say for example with VGPU inventories, that
>> would mean
>> > that the compute node would stop reporting inventories for its
>> root RP, but
>> > would rather report inventories for at least one single child 
RP.

>> > In that model, do we reconcile the allocations that were already
>> made
>> > against the "root RP" inventory ?
>>
>> It would be nice to see Eric and Jay comment on this,
>> but if I'm not mistaken, when the virt driver stops reporting
>> inventories for its root RP, placement would try to delete that
>> inventory inside and raise InventoryInUse exception if any
>> allocations still exist on that resource.
>>
>> ```
>> update_from_provider_tree() (nova/compute/resource_tracker.py)
>>   + _set_inventory_for_provider() 
(nova/scheduler/client/report.py)

>>   + put() - PUT /resource_providers//inventories with
>> new inventories (scheduler/client/report.py)
>>   + set_inventories() (placement/handler/inventory.py)
>>   + _set_inventory()
>> (placement/objects/resource_proveider.py)
>>   + _delete_inventory_from_provider()
>> (placement/objects/resource_proveider.py)
>>   -> raise exception.InventoryInUse
>> ```
>>
>> So we need some trick something like deleting VGPU allocations
>> before upgrading and set the allocation again for the created new
>> child after upgrading?
>>
>
> I wonder if we should keep the existing inventory in the root RP, 
and

> somehow just reserve the left resources (so Placement wouldn't pass
> that root RP for queries, but would still have allocations). But
> then, where and how to do this ? By the resource tracker ?
>

AFAIK it is the virt driver that decides to model the VGU resource 
at a

different place in the RP tree so I think it is the responsibility of
the same virt driver to move any existing allocation from the old 
place

to the new place during this change.

Cheers,
gibi


Why not instead not move the allocation but rather have the virt 
driver updating the root RP by modifying the reserved value to the 
total size?


That way, the virt driver wouldn't need to ask for an allocation but 
rather continue to provide inventories...


Thoughts?


Keeping the old allocaton at the old RP and adding a similar sized 
reservation in the new RP feels hackis as those are not really reserved 
GPUs but used GPUs just from the old RP. If somebody sums up the total 
reported GPUs in this setup via the placement API then she will get 
more GPUs in total that what is physically visible for the hypervisor 
as the GPUs part of the old allocation reported twice in two different 
total value. Could we just report less GPU inventories to the new RP 
until the old RP has GPU allocations?


Some alternatives from my jetlagged brain:

a) Implement a move inventory/allocation API in placement. Given a 
resource class and a source RP uuid and a destination RP uuid placement 
moves the inventory and allocations of that resource class from the 
source RP to the destination RP. Then the virt drive can call this API 
to move the allocation. This has an impact on the fast forward upgrade 
as it needs running virt driver to do the allocation move.


b) For this I assume that live migrating an instance having a GPU 
allocation on the old RP will allocate GPU for that instance from the 
new RP. In the virt driver do not report GPUs to the new RP while there 
is allocation for such GPUs in the old RP. Let the deployer live 
migrate away the instances. When the virt driver detects that there is 
no more GPU allocations on the old RP it can delete the inventory from 
the old RP and report it to the new RP.


c) For this I assume that there is no support for live migration of an 
instance having a GPU. If there is GPU allocation in the old RP then 
virt driver does not report GPU inventory to the new RP just creates 
the new nested RPs. Provide a placement-manage command to do the 
inventory + allocation copy from the old RP to the new RP.


Cheers,
gibi





> -Sylvain
>


__
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] [tc] Organizational diversity tag

[Thierry Carrez]

Mohammed Naser wrote:

During the TC retrospective at the OpenStack summit last week, the
topic of the organizational diversity tag is becoming irrelevant was
brought up by Thierry (ttx)[1].  It seems that for projects that are
not very active, they can easily lose this tag with a few changes by
perhaps the infrastructure team for CI related fixes.

As an action item, Thierry and I have paired up in order to look into
a way to resolve this issue.  There have been ideas to switch this to
a report that is published at the end of the cycle rather than
continuously.  Julia (TheJulia) suggested that we change or track
different types of diversity.

Before we start diving into solutions, I wanted to bring this topic up
to the mailing list and ask for any suggestions.  In digging the
codebase behind this[2], I've found that there are some knobs that we
can also tweak if need-be, or perhaps we can adjust those numbers
depending on the number of commits.


Right, the issue is that under a given level of team activity, there is 
a lot of state flapping between single-vendor, no tag, and 
diverse-affiliation. Some isolated events (someone changing affiliation, 
a dozen of infra-related changes) end up having a significant impact.


My current thinking was that rather than apply a mathematical rule to 
produce quantitative results every month, we could take the time for a 
deeper analysis and produce a qualitative report every quarter.


Alternatively (if that's too much work), we could add a new team tag 
(low-activity ?) that would appear for all projects where the activity 
is so low that the team diversity tags no longer really apply.


--
Thierry Carrez (ttx)

__
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] [nova] [placement] Upgrade concerns with nested Resource Providers

[Sylvain Bauza]

Le mar. 29 mai 2018 à 11:02, Balázs Gibizer  a
écrit :

>
>
> On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza 
> wrote:
> >
> >
> > On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA
> >  wrote
> >
> >> > In that situation, say for example with VGPU inventories, that
> >> would mean
> >> > that the compute node would stop reporting inventories for its
> >> root RP, but
> >> > would rather report inventories for at least one single child RP.
> >> > In that model, do we reconcile the allocations that were already
> >> made
> >> > against the "root RP" inventory ?
> >>
> >> It would be nice to see Eric and Jay comment on this,
> >> but if I'm not mistaken, when the virt driver stops reporting
> >> inventories for its root RP, placement would try to delete that
> >> inventory inside and raise InventoryInUse exception if any
> >> allocations still exist on that resource.
> >>
> >> ```
> >> update_from_provider_tree() (nova/compute/resource_tracker.py)
> >>   + _set_inventory_for_provider() (nova/scheduler/client/report.py)
> >>   + put() - PUT /resource_providers//inventories with
> >> new inventories (scheduler/client/report.py)
> >>   + set_inventories() (placement/handler/inventory.py)
> >>   + _set_inventory()
> >> (placement/objects/resource_proveider.py)
> >>   + _delete_inventory_from_provider()
> >> (placement/objects/resource_proveider.py)
> >>   -> raise exception.InventoryInUse
> >> ```
> >>
> >> So we need some trick something like deleting VGPU allocations
> >> before upgrading and set the allocation again for the created new
> >> child after upgrading?
> >>
> >
> > I wonder if we should keep the existing inventory in the root RP, and
> > somehow just reserve the left resources (so Placement wouldn't pass
> > that root RP for queries, but would still have allocations). But
> > then, where and how to do this ? By the resource tracker ?
> >
>
> AFAIK it is the virt driver that decides to model the VGU resource at a
> different place in the RP tree so I think it is the responsibility of
> the same virt driver to move any existing allocation from the old place
> to the new place during this change.
>
> Cheers,
> gibi
>

Why not instead not move the allocation but rather have the virt driver
updating the root RP by modifying the reserved value to the total size?

That way, the virt driver wouldn't need to ask for an allocation but rather
continue to provide inventories...

Thoughts?


> > -Sylvain
> >
>
>
> __
> 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] New OpenStack project for rolling maintenance and upgrade in interaction with application on top of it

[Juvonen, Tomi (Nokia - FI/Espoo)]

Hi,

I am the PTL of the OPNFV Doctor project.

I have been working for a couple of years figuring out the infrastructure 
maintenance in interaction with application on top of it. Looked into Nova, 
Craton and had several Ops sessions. Past half a year there has been couple of 
different POCs, the last in March in the ONS [1] [2]

In OpenStack Vancouver summit last week it was time to present [3]. In Forum 
discussion following the presentation it was whether to make this just by 
utilizing different existing projects, but to make this generic, pluggable, 
easily adapted and future proof, it now goes down to start what I almost 
started a couple of years ago; the OpenStack Fenix project [4].

On behalf of OPNFV Doctor I would welcome any last thoughts before starting the 
project and would also love to see somebody joining to make the Fenix fly.

Main use cases to list most of them:
*   As a cloud admin I want to maintain and upgrade my infrastructure in a 
rolling fashion.
*   As a cloud admin I want to have a pluggable workflow to maintain and 
upgrade my infrastructure, to ensure it can be done with complicated 
infrastructure components and in interaction with different application 
payloads on top of it.
*   As a infrastructure service, I need to know whether infrastructure 
unavailability is because of planned maintenance.
*   As a critical application owner, I want to be aware of any planned 
downtime effecting to my service.
*   As a critical application owner, I want to have interaction with 
infrastructure rolling maintenance workflow to have a time window to ensure 
zero down time for my service and to be able to decide to make admin actions 
like migration of my instance.
*   As an application owner, I need to know when admin action like 
migration is complete.
*   As an application owner, I want to know about new capabilities coming 
because of infrastructure maintenance or upgrade, so I can take it also into 
use by my application. This could be hardware capability or for example 
OpenStack upgrade.
*   As a critical application that needs to scale by varying load, I need 
to interactively know about infrastructure resources scaling up and down, so I 
can scale my application at the same and keeping zero downtime for my service
*   As a critical application, I want to have retirement of my service done 
in controlled fashion.

[1] Infrastructure Maintenance & Upgrade: Zero VNF Downtime with OPNFV Doctor 
on OCP Hardware video
[2] Infrastructure Maintenance & Upgrade: Zero VNF Downtime with OPNFV Doctor 
on OCP Hardware 
slides
[3] How to gain VNF zero down-time during Infrastructure Maintenance and 
Upgrade
[4] Fenix project wiki
[5] Doctor design guideline 
draft


Best Regards,
Tomi Juvonen



__
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] [nova] [placement] Upgrade concerns with nested Resource Providers

[Balázs Gibizer]

On Tue, May 29, 2018 at 11:52 AM, Sylvain Bauza 
 wrote:



2018-05-29 11:01 GMT+02:00 Balázs Gibizer 
:



On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza  
wrote:



On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA 
 wrote


> In that situation, say for example with VGPU inventories, that 
would mean
> that the compute node would stop reporting inventories for its 
root RP, but

> would rather report inventories for at least one single child RP.
> In that model, do we reconcile the allocations that were already 
made

> against the "root RP" inventory ?

It would be nice to see Eric and Jay comment on this,
but if I'm not mistaken, when the virt driver stops reporting 
inventories for its root RP, placement would try to delete that 
inventory inside and raise InventoryInUse exception if any 
allocations still exist on that resource.


```
update_from_provider_tree() (nova/compute/resource_tracker.py)
  + _set_inventory_for_provider() (nova/scheduler/client/report.py)
  + put() - PUT /resource_providers//inventories with 
new inventories (scheduler/client/report.py)

  + set_inventories() (placement/handler/inventory.py)
  + _set_inventory() 
(placement/objects/resource_proveider.py)
  + _delete_inventory_from_provider() 
(placement/objects/resource_proveider.py)

  -> raise exception.InventoryInUse
```

So we need some trick something like deleting VGPU allocations 
before upgrading and set the allocation again for the created new 
child after upgrading?




I wonder if we should keep the existing inventory in the root RP, 
and somehow just reserve the left resources (so Placement wouldn't 
pass that root RP for queries, but would still have allocations). 
But then, where and how to do this ? By the resource tracker ?




AFAIK it is the virt driver that decides to model the VGU resource 
at a different place in the RP tree so I think it is the 
responsibility of the same virt driver to move any existing 
allocation from the old place to the new place during this change.




No. Allocations are done by the scheduler or by the conductor. Virt 
drivers only provide inventories.


I understand that the allocation is made by the scheduler and the 
conductor but today the scheduler and the conductor do not have to know 
the structure for the RP tree to make such allocations. Therefore for 
me the scheduler and the conductor is a bad place to try to move 
allocation around due to a change in the modelling of the resources in 
the RP tree. In the other hand the virt driver knows the structure of 
the RP tree so it has the necessary information to move the existing 
allocaiton from the old place to the new place.


gibi





Cheers,
gibi



-Sylvain




__
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] Notification update week 22

[Balázs Gibizer]

Hi,

Here is the latest notification subteam update.

Bugs

No new bugs, no progress on open bugs.


Features


Sending full traceback in versioned notifications
~
https://blueprints.launchpad.net/nova/+spec/add-full-traceback-to-error-notifications
I left some comment in the implementation patch 
https://review.openstack.org/#/c/564092/


Add notification support for trusted_certs
~~
This is part of the bp nova-validate-certificates implementation series
to extend some of the instance notifications.
I'm +2 on the notification impact in 
https://review.openstack.org/#/c/563269 waiting for the rest of the 
series to merge.


Introduce Pending VM state
~~
The spec https://review.openstack.org/#/c/554212 proposes some
notification change to signal when a VM goes to PENDING state. We 
discussed the notification impact on the summit and agreed to transform 
the legacy scheduler.select_destinations notification and extend it if 
necessary. Detailed discussion still ongoing in the spec review.



No progress:

* Versioned notification transformation 
https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-rocky+status:open
* Introduce instance.lock and instance.unlock notifications 
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances
* Add the user id and project id of the user initiated the instance 
action to the notification 
https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications



Blocked:

* Add versioned notifications for removing a member from a server group 
https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications



Weekly meeting
--
The next meeting will be held on 29th of May (Today!) on 
#openstack-meeting-4

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180529T17

Cheers,
gibi




__
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] [nova] [placement] Upgrade concerns with nested Resource Providers

[Sylvain Bauza]

2018-05-29 11:01 GMT+02:00 Balázs Gibizer :

>
>
> On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza  wrote:
>
>>
>>
>> On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA <
>> nakamura.tets...@lab.ntt.co.jp> wrote
>>
>> > In that situation, say for example with VGPU inventories, that would
>>> mean
>>> > that the compute node would stop reporting inventories for its root
>>> RP, but
>>> > would rather report inventories for at least one single child RP.
>>> > In that model, do we reconcile the allocations that were already made
>>> > against the "root RP" inventory ?
>>>
>>> It would be nice to see Eric and Jay comment on this,
>>> but if I'm not mistaken, when the virt driver stops reporting
>>> inventories for its root RP, placement would try to delete that inventory
>>> inside and raise InventoryInUse exception if any allocations still exist on
>>> that resource.
>>>
>>> ```
>>> update_from_provider_tree() (nova/compute/resource_tracker.py)
>>>   + _set_inventory_for_provider() (nova/scheduler/client/report.py)
>>>   + put() - PUT /resource_providers//inventories with new
>>> inventories (scheduler/client/report.py)
>>>   + set_inventories() (placement/handler/inventory.py)
>>>   + _set_inventory() (placement/objects/resource_pr
>>> oveider.py)
>>>   + _delete_inventory_from_provider()
>>> (placement/objects/resource_proveider.py)
>>>   -> raise exception.InventoryInUse
>>> ```
>>>
>>> So we need some trick something like deleting VGPU allocations before
>>> upgrading and set the allocation again for the created new child after
>>> upgrading?
>>>
>>>
>> I wonder if we should keep the existing inventory in the root RP, and
>> somehow just reserve the left resources (so Placement wouldn't pass that
>> root RP for queries, but would still have allocations). But then, where and
>> how to do this ? By the resource tracker ?
>>
>>
> AFAIK it is the virt driver that decides to model the VGU resource at a
> different place in the RP tree so I think it is the responsibility of the
> same virt driver to move any existing allocation from the old place to the
> new place during this change.
>
>
No. Allocations are done by the scheduler or by the conductor. Virt drivers
only provide inventories.



> Cheers,
> gibi
>
>
> -Sylvain
>>
>>
>
> __
> 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] [nova] [placement] Upgrade concerns with nested Resource Providers

[Balázs Gibizer]

On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza  
wrote:



On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA 
 wrote


> In that situation, say for example with VGPU inventories, that 
would mean
> that the compute node would stop reporting inventories for its 
root RP, but

> would rather report inventories for at least one single child RP.
> In that model, do we reconcile the allocations that were already 
made

> against the "root RP" inventory ?

It would be nice to see Eric and Jay comment on this,
but if I'm not mistaken, when the virt driver stops reporting 
inventories for its root RP, placement would try to delete that 
inventory inside and raise InventoryInUse exception if any 
allocations still exist on that resource.


```
update_from_provider_tree() (nova/compute/resource_tracker.py)
  + _set_inventory_for_provider() (nova/scheduler/client/report.py)
  + put() - PUT /resource_providers//inventories with 
new inventories (scheduler/client/report.py)

  + set_inventories() (placement/handler/inventory.py)
  + _set_inventory() 
(placement/objects/resource_proveider.py)
  + _delete_inventory_from_provider() 
(placement/objects/resource_proveider.py)

  -> raise exception.InventoryInUse
```

So we need some trick something like deleting VGPU allocations 
before upgrading and set the allocation again for the created new 
child after upgrading?




I wonder if we should keep the existing inventory in the root RP, and 
somehow just reserve the left resources (so Placement wouldn't pass 
that root RP for queries, but would still have allocations). But 
then, where and how to do this ? By the resource tracker ?




AFAIK it is the virt driver that decides to model the VGU resource at a 
different place in the RP tree so I think it is the responsibility of 
the same virt driver to move any existing allocation from the old place 
to the new place during this change.


Cheers,
gibi


-Sylvain




__
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] [kolla-ansible] dns_interface, inv

[vladislav . belogrudov]

Hi,

in multinode inventory I see that both haproxy and l3 agents run on 
network nodes. Does it mean that network nodes need two public 
interfaces - one for external VIP and another (unassigned) for external 
bridge? Will it work without conflicts?


Another question, designate-mdns runs on network nodes while others 
including designate-backend-bind - on controllers. Would it be better to 
run *bind on network node to facilitate easier external connectivity? I 
mean requirement for dns_interface, in other words, why not to make 
dns_interface == external one?


Thanks,
Vladislav




__
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] [nova] [placement] Upgrade concerns with nested Resource Providers

[Sylvain Bauza]

On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA <
nakamura.tets...@lab.ntt.co.jp> wrote:

> Hi,
>
> > Do I still understand correctly ? If yes, perfect, let's jump to my
> upgrade
> > concern.
>
> Yes, I think. The old microversions look into only root providers and give
> up providing resources if a root provider itself doesn't have enough
> inventories for requested resources. But the new microversion looks into
> the root's descendents also and see if it can provide requested resources
> *collectively* in that tree.
>
> The tests from [1] would help you understand this, where VCPUs come from
> the root(compute host) and SRIOV_NET_VFs from its grandchild.
>
> [1] https://review.openstack.org/#/c/565487/15/nova/tests/functi
> onal/api/openstack/placement/gabbits/allocation-candidates.yaml@362
>
>
Yeah I already saw those tests, but I wanted to make sure I was correctly
understanding.


> > In that situation, say for example with VGPU inventories, that would mean
> > that the compute node would stop reporting inventories for its root RP,
> but
> > would rather report inventories for at least one single child RP.
> > In that model, do we reconcile the allocations that were already made
> > against the "root RP" inventory ?
>
> It would be nice to see Eric and Jay comment on this,
> but if I'm not mistaken, when the virt driver stops reporting inventories
> for its root RP, placement would try to delete that inventory inside and
> raise InventoryInUse exception if any allocations still exist on that
> resource.
>
> ```
> update_from_provider_tree() (nova/compute/resource_tracker.py)
>   + _set_inventory_for_provider() (nova/scheduler/client/report.py)
>   + put() - PUT /resource_providers//inventories with new
> inventories (scheduler/client/report.py)
>   + set_inventories() (placement/handler/inventory.py)
>   + _set_inventory() (placement/objects/resource_proveider.py)
>   + _delete_inventory_from_provider()
> (placement/objects/resource_proveider.py)
>   -> raise exception.InventoryInUse
> ```
>
> So we need some trick something like deleting VGPU allocations before
> upgrading and set the allocation again for the created new child after
> upgrading?
>
>
I wonder if we should keep the existing inventory in the root RP, and
somehow just reserve the left resources (so Placement wouldn't pass that
root RP for queries, but would still have allocations). But then, where and
how to do this ? By the resource tracker ?

-Sylvain


> On 2018/05/28 23:18, Sylvain Bauza wrote:
>
>> Hi,
>>
>> I already told about that in a separate thread, but let's put it here too
>> for more visibility.
>>
>> tl;dr: I suspect existing allocations are being lost when we upgrade a
>> compute service from Queens to Rocky, if those allocations are made
>> against
>> inventories that are now provided by a child Resource Provider.
>>
>>
>> I started reviewing https://review.openstack.org/#/c/565487/ and bottom
>> patches to understand the logic with querying nested resource providers.
>>
>>> From what I understand, the scheduler will query Placement using the same
>>>
>> query but will get (thanks to a new microversion) not only allocation
>> candidates that are root resource providers but also any possible child.
>>
>> If so, that's great as in a rolling upgrade scenario with mixed computes
>> (both Queens and Rocky), we will still continue to return both old RPs and
>> new child RPs if they both support the same resource classes ask.
>> Accordingly, allocations done by the scheduler will be made against the
>> corresponding Resource Provider, whether it's a root RP (old way) or a
>> child RP (new way).
>>
>> Do I still understand correctly ? If yes, perfect, let's jump to my
>> upgrade
>> concern.
>> Now, consider the Queens->Rocky compute upgrade. If I'm an operator and I
>> start deploying Rocky on one compute node, it will provide to Placement
>> API
>> new inventories that are possibly nested.
>> In that situation, say for example with VGPU inventories, that would mean
>> that the compute node would stop reporting inventories for its root RP,
>> but
>> would rather report inventories for at least one single child RP.
>> In that model, do we reconcile the allocations that were already made
>> against the "root RP" inventory ? I don't think so, hence my question
>> here.
>>
>> Thanks,
>> -Sylvain
>>
>>
>>
>> 
>> __
>> 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
>>
>>
> --
> Tetsuro Nakamura 
> NTT Network Service Systems Laboratories
> TEL:0422 59 6914(National)/+81 422 59 6914(International)
> 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan
>
>
>
__