Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2018-09-17 16:12:30 -0400:
> On 17/09/18 3:06 PM, Jay Pipes wrote:
> > On 09/17/2018 01:31 PM, Doug Hellmann wrote:
> >> New Project Application Process
> >> ===
> >>
> >> We wrapped up Sunday with a discussion of of our process for reviewing
> >> new project applications. Zane and Chris in particular felt the
> >> process for Adjutant was too painful for the project team because
> >> there was no way to know how long discussions might go on and now
> >> way for them to anticipate some of the issues they encountered.
> >>
> >> We talked about formalizing a "coach" position to have someone from
> >> the TC (or broader community) work with the team to prepare their
> >> application with sufficient detail, seek feedback before voting
> >> starts, etc.
> >>
> >> We also talked about adding a time limit to the process, so that
> >> teams at least have a rejection with feedback in a reasonable amount
> >> of time.  Some of the less contentious discussions have averaged
> >> from 1-4 months with a few more contentious cases taking as long
> >> as 10 months. We did not settle on a time frame during the meeting,
> >> so I expect this to be a topic for us to work out during the next
> >> term.
> > 
> > So, to summarize... the TC is back to almost exactly the same point it 
> > was at right before the Project Structure Reform happened in 2014-2015 
> > (that whole Big Tent thing).
> 
> I wouldn't go that far. There are more easy decisions than there were 
> before the reform, but there still exist hard decisions. This is perhaps 
> inevitable.
> 
> > The Project Structure Reform occurred because the TC could not make 
> > decisions on whether projects should join OpenStack using objective 
> > criteria, and due to this, new project applicants were forced to endure 
> > long waits and subjective "graduation" reviews that could change from 
> > one TC election cycle to the next.
> > 
> > The solution to this was to make an objective set of application 
> > criteria and remove the TC from the "Supreme Court of OpenStack" role 
> > that new applicants needed to come before and submit to the court's 
> > judgment.
> > 
> > Many people complained that the Project Structure Reform was the TC 
> > simply abrogating responsibility for being a judgmental body.
> > 
> > It seems that although we've now gotten rid of those objective criteria 
> > for project inclusion and gone back to the TC being a subjective 
> > judgmental body, that the TC is still not actually willing to pass 
> > judgment one way or the other on new project applicants.
> 
> No criteria have been gotten rid of, but even after the Project 
> Structure Reform there existed criteria that were subjective. Here is a 
> thread discussing them during the last TC election:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html
> 
> (I actually think that the perception that the criteria should be 
> entirely objective might be a contributor to the problem: when faced 
> with a subjective decision and no documentation or precedent to guide 
> them, TC members can be reluctant to choose.)

I think turning the decision about which projects fit the mission
into an entirely mechanical one would be a mistake. I would prefer
us to use, and trust, our judgement in cases where the answer needs
some thought.

I don't remember the history quite the way Jay does, either. I
remember us trying to base the decision more about what the team
was doing than how the code looked or whether the implementation
met anyone's idea of "good". That's why we retained the requirement
that the project "aligns with the OpenStack Mission".

> 
> > Is this because it is still remarkably unclear what OpenStack actually 
> > *is* (the whole mission/scope thing)?
> > 
> > Or is this because TC members simply don't want to be the ones to say 
> > "No" to good-meaning people
> 
> I suspect both of those reasons are probably in the mix, along with a 
> few others as well.

There was a good deal of confusion early on about what "workflow" meant
in the context of Adjutant and whether the use of workflows was
overlapping unnecessarily with Mistral. After that was clarified we
talked about the interoperability concerns with an API that may be
different based on deployer choices.

> 
> > that may have an idea that is only 
> > tangentially related to cloud computing?
> 
> It should be noted that in this case Adjutant pretty clearly fills an 
> essential use case for public clouds. The debate was around whether 
> accepting it was likely to lead to the desired standardisation across 
> public OpenStack clouds or effectively act as an official endorsement 
> for API fragmentation.
> 
> It's not clear that any change to the criteria could have made this 
> particular decision any easier.

Only adding a specific rule about the API interoperability would
have addressed my concern directly. I'm not sure applying such a
rule 

Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

[Jay Pipes]

On 09/17/2018 04:50 PM, Doug Hellmann wrote:

Excerpts from Zane Bitter's message of 2018-09-17 16:12:30 -0400:

On 17/09/18 3:06 PM, Jay Pipes wrote:

On 09/17/2018 01:31 PM, Doug Hellmann wrote:

New Project Application Process
===

We wrapped up Sunday with a discussion of of our process for reviewing
new project applications. Zane and Chris in particular felt the
process for Adjutant was too painful for the project team because
there was no way to know how long discussions might go on and now
way for them to anticipate some of the issues they encountered.

We talked about formalizing a "coach" position to have someone from
the TC (or broader community) work with the team to prepare their
application with sufficient detail, seek feedback before voting
starts, etc.

We also talked about adding a time limit to the process, so that
teams at least have a rejection with feedback in a reasonable amount
of time.  Some of the less contentious discussions have averaged
from 1-4 months with a few more contentious cases taking as long
as 10 months. We did not settle on a time frame during the meeting,
so I expect this to be a topic for us to work out during the next
term.


So, to summarize... the TC is back to almost exactly the same point it
was at right before the Project Structure Reform happened in 2014-2015
(that whole Big Tent thing).


I wouldn't go that far. There are more easy decisions than there were
before the reform, but there still exist hard decisions. This is perhaps
inevitable.


The Project Structure Reform occurred because the TC could not make
decisions on whether projects should join OpenStack using objective
criteria, and due to this, new project applicants were forced to endure
long waits and subjective "graduation" reviews that could change from
one TC election cycle to the next.

The solution to this was to make an objective set of application
criteria and remove the TC from the "Supreme Court of OpenStack" role
that new applicants needed to come before and submit to the court's
judgment.

Many people complained that the Project Structure Reform was the TC
simply abrogating responsibility for being a judgmental body.

It seems that although we've now gotten rid of those objective criteria
for project inclusion and gone back to the TC being a subjective
judgmental body, that the TC is still not actually willing to pass
judgment one way or the other on new project applicants.


No criteria have been gotten rid of, but even after the Project
Structure Reform there existed criteria that were subjective. Here is a
thread discussing them during the last TC election:

http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html

(I actually think that the perception that the criteria should be
entirely objective might be a contributor to the problem: when faced
with a subjective decision and no documentation or precedent to guide
them, TC members can be reluctant to choose.)


I think turning the decision about which projects fit the mission
into an entirely mechanical one would be a mistake. I would prefer
us to use, and trust, our judgement in cases where the answer needs
some thought.

I don't remember the history quite the way Jay does, either. I
remember us trying to base the decision more about what the team
was doing than how the code looked or whether the implementation
met anyone's idea of "good". That's why we retained the requirement
that the project "aligns with the OpenStack Mission".


Hmm. I very specifically remember the incubation and graduation review 
of Zaqar and the fact that over a couple cycles of TC elections, the 
"advice" given by the TC about specific technical implementation details 
changed, often arbitrarily, depending on who was on the TC and what day 
of the week it was. In fact, I pretty vividly remember this arbitrary 
nature of the architectural review being one of the primary reasons we 
switched to a purely objective set of criteria.


Also, for the record, I actually wasn't referring to Adjutant 
specifically when I referred in my original post to "only tangentially 
related to cloud computing". I was referring to my recollection of 
fairly recent history. I remember the seemingly endless debates about 
whether some applicants "fit" the OpenStack ecosystem or whether the 
applicant was merely trying to jump on a hype bandwagon for marketing 
purposes. Again, I wasn't specifically referring to Adjutant here, so I 
apologize if my words came across that way.


Best,
-jay

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

Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

[Jay Pipes]

On 09/17/2018 01:31 PM, Doug Hellmann wrote:

New Project Application Process
===

We wrapped up Sunday with a discussion of of our process for reviewing
new project applications. Zane and Chris in particular felt the
process for Adjutant was too painful for the project team because
there was no way to know how long discussions might go on and now
way for them to anticipate some of the issues they encountered.

We talked about formalizing a "coach" position to have someone from
the TC (or broader community) work with the team to prepare their
application with sufficient detail, seek feedback before voting
starts, etc.

We also talked about adding a time limit to the process, so that
teams at least have a rejection with feedback in a reasonable amount
of time.  Some of the less contentious discussions have averaged
from 1-4 months with a few more contentious cases taking as long
as 10 months. We did not settle on a time frame during the meeting,
so I expect this to be a topic for us to work out during the next
term.


So, to summarize... the TC is back to almost exactly the same point it 
was at right before the Project Structure Reform happened in 2014-2015 
(that whole Big Tent thing).


The Project Structure Reform occurred because the TC could not make 
decisions on whether projects should join OpenStack using objective 
criteria, and due to this, new project applicants were forced to endure 
long waits and subjective "graduation" reviews that could change from 
one TC election cycle to the next.


The solution to this was to make an objective set of application 
criteria and remove the TC from the "Supreme Court of OpenStack" role 
that new applicants needed to come before and submit to the court's 
judgment.


Many people complained that the Project Structure Reform was the TC 
simply abrogating responsibility for being a judgmental body.


It seems that although we've now gotten rid of those objective criteria 
for project inclusion and gone back to the TC being a subjective 
judgmental body, that the TC is still not actually willing to pass 
judgment one way or the other on new project applicants.


Is this because it is still remarkably unclear what OpenStack actually 
*is* (the whole mission/scope thing)?


Or is this because TC members simply don't want to be the ones to say 
"No" to good-meaning people that may have an idea that is only 
tangentially related to cloud computing?


Everything old is new again.

Best,
-jay

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

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Samuel Cassiba]

On Mon, Sep 17, 2018 at 6:58 AM Sylvain Bauza  wrote:
>
>
>
> Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  a écrit :
>>
>> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
>> [...]
>> > - What is the problem joining Wechat will solve (keeping in mind the
>> > language barrier)?
>>
>> As I understand it, the suggestion is that mere presence of project
>> leadership in venues where this emerging subset of our community
>> gathers would provide a strong signal that we support them and care
>> about their experience with the software.
>>
>> > - Isn't this problem already solved for other languages with
>> > existing initiatives like local ambassadors and i18n team? Why
>> > aren't these relevant?
>> [...]
>>
>> It seems like there are at least couple of factors at play here:
>> first the significant number of users and contributors within
>> mainland China compared to other regions (analysis suggests there
>> were nearly as many contributors to the Rocky release from China as
>> the USA), but second there may be facets of Chinese culture which
>> make this sort of demonstrative presence a much stronger signal than
>> it would be in other cultures.
>>
>> > - Pardon my ignorance here, what is the problem with email? (I
>> > understand some chat systems might be blocked, I thought emails
>> > would be fine, and the lowest common denominator).
>>
>> Someone in the TC room (forgive me, I don't recall who now, maybe
>> Rico?) asserted that Chinese contributors generally only read the
>> first message in any given thread (perhaps just looking for possible
>> announcements?) and that if they _do_ attempt to read through some
>> of the longer threads they don't participate in them because the
>> discussion is presumed to be over and decisions final by the time
>> they "reach the end" (I guess not realizing that it's perfectly fine
>> to reply to a month-old discussion and try to help alter course on
>> things if you have an actual concern?).
>>
>
> While I understand the technical issues that could be due using IRC in China, 
> I still don't get why opening the gates and saying WeChat being yet another 
> official channel would prevent our community from fragmenting.
>
> Truly the usage of IRC is certainly questionable, but if we have multiple 
> ways to discuss, I just doubt we could prevent us to silo ourselves between 
> our personal usages.
> Either we consider the new channels as being only for southbound 
> communication, or we envisage the possibility, as a community, to migrate 
> from IRC to elsewhere (I'm particulary not fan of the latter so I would 
> challenge this but I can understand the reasons)
>
> -Sylvain
>

Objectively, I don't see a way to endorse something other than IRC
without some form of collective presence on more than just Wechat to
keep the message intact. IRC is the official messaging platform, for
whatever that's worth these days. However, at present, it makes less
and less sense to explicitly eschew other outlets in favor. From a
Chef OpenStack perspective, the common medium is, perhaps not
unsurprising, code review. Everything else evolved over time to be
southbound paths to the code, including most of the conversation
taking place there as opposed to IRC.

The continuation of this thread only confirms that there is already
fragmentation in the community, and that people on each side of the
void genuinely want to close that gap. At this point, the thing to do
is prevent further fragmentation of the intent. It is, however, far
easier to bikeshed over which platform of choice.

At present, it seems a collective presence is forming ad hoc,
regardless of any such resolution. With some additional coordination
and planning, I think that there could be something that could scale
beyond one or two outlets.

Best,
Samuel

__
OpenStack Development Mailing 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] When can/should we change additionalProperties=False in GET /servers(/detail)?

[Matt Riedemann]

This is a question from a change [1] which adds a new changes-before 
filter to the servers, os-instance-actions and os-migrations APIs.


For context, the os-instance-actions API stopped accepting undefined 
query parameters in 2.58 when we added paging support.


The os-migrations API stopped allowing undefined query parameters in 
2.59 when we added paging support.


The open question on the review is if we should change GET /servers and 
GET /servers/detail to stop allowing undefined query parameters starting 
with microversion 2.66 [2]. Apparently when we added support for 2.5 and 
2.26 for listing servers we didn't think about this. It means that a 
user can specify a query parameter, documented in the API reference, but 
with an older microversion and it will be silently ignored. That is 
backward compatible but confusing from an end user perspective since it 
would appear to them that the filter is not being applied, when it fact 
it would be if they used the correct microversion.


So do we want to start enforcing query parameters when listing servers 
to our defined list with microversion 2.66 or just continue to silently 
ignore them if used incorrectly?


Note that starting in Rocky, the Neutron API will start rejecting 
unknown query parameteres [3] if the filter-validation extension is 
enabled (since Neutron doesn't use microversions). So there is some 
precedent in OpenStack for starting to enforce query parameters.


[1] https://review.openstack.org/#/c/599276/
[2] 
https://review.openstack.org/#/c/599276/23/nova/api/openstack/compute/schemas/servers.py

[3] https://docs.openstack.org/releasenotes/neutron/rocky.html#upgrade-notes

--

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] [election][tc]Question for candidates about global reachout

[Mohammed Naser]

Hi,

On that note, is there any way to get an 'invite' onto those channels?

Any information about the foundation side of things about the
'official' channels?

Thanks,
Mohammed
On Mon, Sep 17, 2018 at 3:28 PM Samuel Cassiba  wrote:
>
> On Mon, Sep 17, 2018 at 6:58 AM Sylvain Bauza  wrote:
> >
> >
> >
> > Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  a écrit :
> >>
> >> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
> >> [...]
> >> > - What is the problem joining Wechat will solve (keeping in mind the
> >> > language barrier)?
> >>
> >> As I understand it, the suggestion is that mere presence of project
> >> leadership in venues where this emerging subset of our community
> >> gathers would provide a strong signal that we support them and care
> >> about their experience with the software.
> >>
> >> > - Isn't this problem already solved for other languages with
> >> > existing initiatives like local ambassadors and i18n team? Why
> >> > aren't these relevant?
> >> [...]
> >>
> >> It seems like there are at least couple of factors at play here:
> >> first the significant number of users and contributors within
> >> mainland China compared to other regions (analysis suggests there
> >> were nearly as many contributors to the Rocky release from China as
> >> the USA), but second there may be facets of Chinese culture which
> >> make this sort of demonstrative presence a much stronger signal than
> >> it would be in other cultures.
> >>
> >> > - Pardon my ignorance here, what is the problem with email? (I
> >> > understand some chat systems might be blocked, I thought emails
> >> > would be fine, and the lowest common denominator).
> >>
> >> Someone in the TC room (forgive me, I don't recall who now, maybe
> >> Rico?) asserted that Chinese contributors generally only read the
> >> first message in any given thread (perhaps just looking for possible
> >> announcements?) and that if they _do_ attempt to read through some
> >> of the longer threads they don't participate in them because the
> >> discussion is presumed to be over and decisions final by the time
> >> they "reach the end" (I guess not realizing that it's perfectly fine
> >> to reply to a month-old discussion and try to help alter course on
> >> things if you have an actual concern?).
> >>
> >
> > While I understand the technical issues that could be due using IRC in 
> > China, I still don't get why opening the gates and saying WeChat being yet 
> > another official channel would prevent our community from fragmenting.
> >
> > Truly the usage of IRC is certainly questionable, but if we have multiple 
> > ways to discuss, I just doubt we could prevent us to silo ourselves between 
> > our personal usages.
> > Either we consider the new channels as being only for southbound 
> > communication, or we envisage the possibility, as a community, to migrate 
> > from IRC to elsewhere (I'm particulary not fan of the latter so I would 
> > challenge this but I can understand the reasons)
> >
> > -Sylvain
> >
>
> Objectively, I don't see a way to endorse something other than IRC
> without some form of collective presence on more than just Wechat to
> keep the message intact. IRC is the official messaging platform, for
> whatever that's worth these days. However, at present, it makes less
> and less sense to explicitly eschew other outlets in favor. From a
> Chef OpenStack perspective, the common medium is, perhaps not
> unsurprising, code review. Everything else evolved over time to be
> southbound paths to the code, including most of the conversation
> taking place there as opposed to IRC.
>
> The continuation of this thread only confirms that there is already
> fragmentation in the community, and that people on each side of the
> void genuinely want to close that gap. At this point, the thing to do
> is prevent further fragmentation of the intent. It is, however, far
> easier to bikeshed over which platform of choice.
>
> At present, it seems a collective presence is forming ad hoc,
> regardless of any such resolution. With some additional coordination
> and planning, I think that there could be something that could scale
> beyond one or two outlets.
>
> Best,
> Samuel
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [nova] When can/should we change additionalProperties=False in GET /servers(/detail)?

[Jay Pipes]

On 09/17/2018 03:28 PM, Matt Riedemann wrote:
This is a question from a change [1] which adds a new changes-before 
filter to the servers, os-instance-actions and os-migrations APIs.


For context, the os-instance-actions API stopped accepting undefined 
query parameters in 2.58 when we added paging support.


The os-migrations API stopped allowing undefined query parameters in 
2.59 when we added paging support.


The open question on the review is if we should change GET /servers and 
GET /servers/detail to stop allowing undefined query parameters starting 
with microversion 2.66 [2]. Apparently when we added support for 2.5 and 
2.26 for listing servers we didn't think about this. It means that a 
user can specify a query parameter, documented in the API reference, but 
with an older microversion and it will be silently ignored. That is 
backward compatible but confusing from an end user perspective since it 
would appear to them that the filter is not being applied, when it fact 
it would be if they used the correct microversion.


So do we want to start enforcing query parameters when listing servers 
to our defined list with microversion 2.66 or just continue to silently 
ignore them if used incorrectly?


Note that starting in Rocky, the Neutron API will start rejecting 
unknown query parameteres [3] if the filter-validation extension is 
enabled (since Neutron doesn't use microversions). So there is some 
precedent in OpenStack for starting to enforce query parameters.


[1] https://review.openstack.org/#/c/599276/
[2] 
https://review.openstack.org/#/c/599276/23/nova/api/openstack/compute/schemas/servers.py 

[3] 
https://docs.openstack.org/releasenotes/neutron/rocky.html#upgrade-notes


My vote would be just change additionalProperties to False in the 599276 
patch and be done with it.


Add a release note about the change, of course.

-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

Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

[Zane Bitter]

On 17/09/18 3:06 PM, Jay Pipes wrote:

On 09/17/2018 01:31 PM, Doug Hellmann wrote:

New Project Application Process
===

We wrapped up Sunday with a discussion of of our process for reviewing
new project applications. Zane and Chris in particular felt the
process for Adjutant was too painful for the project team because
there was no way to know how long discussions might go on and now
way for them to anticipate some of the issues they encountered.

We talked about formalizing a "coach" position to have someone from
the TC (or broader community) work with the team to prepare their
application with sufficient detail, seek feedback before voting
starts, etc.

We also talked about adding a time limit to the process, so that
teams at least have a rejection with feedback in a reasonable amount
of time.  Some of the less contentious discussions have averaged
from 1-4 months with a few more contentious cases taking as long
as 10 months. We did not settle on a time frame during the meeting,
so I expect this to be a topic for us to work out during the next
term.


So, to summarize... the TC is back to almost exactly the same point it 
was at right before the Project Structure Reform happened in 2014-2015 
(that whole Big Tent thing).


I wouldn't go that far. There are more easy decisions than there were 
before the reform, but there still exist hard decisions. This is perhaps 
inevitable.


The Project Structure Reform occurred because the TC could not make 
decisions on whether projects should join OpenStack using objective 
criteria, and due to this, new project applicants were forced to endure 
long waits and subjective "graduation" reviews that could change from 
one TC election cycle to the next.


The solution to this was to make an objective set of application 
criteria and remove the TC from the "Supreme Court of OpenStack" role 
that new applicants needed to come before and submit to the court's 
judgment.


Many people complained that the Project Structure Reform was the TC 
simply abrogating responsibility for being a judgmental body.


It seems that although we've now gotten rid of those objective criteria 
for project inclusion and gone back to the TC being a subjective 
judgmental body, that the TC is still not actually willing to pass 
judgment one way or the other on new project applicants.


No criteria have been gotten rid of, but even after the Project 
Structure Reform there existed criteria that were subjective. Here is a 
thread discussing them during the last TC election:


http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html

(I actually think that the perception that the criteria should be 
entirely objective might be a contributor to the problem: when faced 
with a subjective decision and no documentation or precedent to guide 
them, TC members can be reluctant to choose.)


Is this because it is still remarkably unclear what OpenStack actually 
*is* (the whole mission/scope thing)?


Or is this because TC members simply don't want to be the ones to say 
"No" to good-meaning people


I suspect both of those reasons are probably in the mix, along with a 
few others as well.


that may have an idea that is only 
tangentially related to cloud computing?


It should be noted that in this case Adjutant pretty clearly fills an 
essential use case for public clouds. The debate was around whether 
accepting it was likely to lead to the desired standardisation across 
public OpenStack clouds or effectively act as an official endorsement 
for API fragmentation.


It's not clear that any change to the criteria could have made this 
particular decision any easier.


Things did seem to go more smoothly after we nominated a couple of 
people to work directly with the project to polish their application, 
and in retrospect we probably should have treated it with more urgency 
rather than e.g. waiting for a face-to-face discussion at the Forum 
before attempting to make progress. Those are the lessons behind the 
process improvements that we discussed last week that Doug summarised above.


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] [election][tc]Question for candidates about global reachout

[Lance Bragstad]

On Mon, Sep 17, 2018 at 1:42 PM Mohammed Naser  wrote:

> Hi,
>
> On that note, is there any way to get an 'invite' onto those channels?
>
> Any information about the foundation side of things about the
> 'official' channels?
>

I actually have a question about this as well. During the TC discussion
last Friday there was representation from the Foundation in the room. I
though I remember someone (annabelleB?) saying there were known issues
(technical or otherwise) regarding the official channels spun up by the
Foundation.

Does anyone know what issues were being referred to here?


>
> Thanks,
> Mohammed
> On Mon, Sep 17, 2018 at 3:28 PM Samuel Cassiba  wrote:
> >
> > On Mon, Sep 17, 2018 at 6:58 AM Sylvain Bauza 
> wrote:
> > >
> > >
> > >
> > > Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  a
> écrit :
> > >>
> > >> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
> > >> [...]
> > >> > - What is the problem joining Wechat will solve (keeping in mind the
> > >> > language barrier)?
> > >>
> > >> As I understand it, the suggestion is that mere presence of project
> > >> leadership in venues where this emerging subset of our community
> > >> gathers would provide a strong signal that we support them and care
> > >> about their experience with the software.
> > >>
> > >> > - Isn't this problem already solved for other languages with
> > >> > existing initiatives like local ambassadors and i18n team? Why
> > >> > aren't these relevant?
> > >> [...]
> > >>
> > >> It seems like there are at least couple of factors at play here:
> > >> first the significant number of users and contributors within
> > >> mainland China compared to other regions (analysis suggests there
> > >> were nearly as many contributors to the Rocky release from China as
> > >> the USA), but second there may be facets of Chinese culture which
> > >> make this sort of demonstrative presence a much stronger signal than
> > >> it would be in other cultures.
> > >>
> > >> > - Pardon my ignorance here, what is the problem with email? (I
> > >> > understand some chat systems might be blocked, I thought emails
> > >> > would be fine, and the lowest common denominator).
> > >>
> > >> Someone in the TC room (forgive me, I don't recall who now, maybe
> > >> Rico?) asserted that Chinese contributors generally only read the
> > >> first message in any given thread (perhaps just looking for possible
> > >> announcements?) and that if they _do_ attempt to read through some
> > >> of the longer threads they don't participate in them because the
> > >> discussion is presumed to be over and decisions final by the time
> > >> they "reach the end" (I guess not realizing that it's perfectly fine
> > >> to reply to a month-old discussion and try to help alter course on
> > >> things if you have an actual concern?).
> > >>
> > >
> > > While I understand the technical issues that could be due using IRC in
> China, I still don't get why opening the gates and saying WeChat being yet
> another official channel would prevent our community from fragmenting.
> > >
> > > Truly the usage of IRC is certainly questionable, but if we have
> multiple ways to discuss, I just doubt we could prevent us to silo
> ourselves between our personal usages.
> > > Either we consider the new channels as being only for southbound
> communication, or we envisage the possibility, as a community, to migrate
> from IRC to elsewhere (I'm particulary not fan of the latter so I would
> challenge this but I can understand the reasons)
> > >
> > > -Sylvain
> > >
> >
> > Objectively, I don't see a way to endorse something other than IRC
> > without some form of collective presence on more than just Wechat to
> > keep the message intact. IRC is the official messaging platform, for
> > whatever that's worth these days. However, at present, it makes less
> > and less sense to explicitly eschew other outlets in favor. From a
> > Chef OpenStack perspective, the common medium is, perhaps not
> > unsurprising, code review. Everything else evolved over time to be
> > southbound paths to the code, including most of the conversation
> > taking place there as opposed to IRC.
> >
> > The continuation of this thread only confirms that there is already
> > fragmentation in the community, and that people on each side of the
> > void genuinely want to close that gap. At this point, the thing to do
> > is prevent further fragmentation of the intent. It is, however, far
> > easier to bikeshed over which platform of choice.
> >
> > At present, it seems a collective presence is forming ad hoc,
> > regardless of any such resolution. With some additional coordination
> > and planning, I think that there could be something that could scale
> > beyond one or two outlets.
> >
> > Best,
> > Samuel
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> 

Re: [openstack-dev] [cinder][infra] Remove driverfixes/ocata branch

[Jay S Bryant]

On 9/17/2018 10:46 AM, Sean McGinnis wrote:

Plan

We would now like to have the driverfixes/ocata branch deleted so there is no
confusion about where backports should go and we don't accidentally get these
out of sync again.

Infra team, please delete this branch or let me know if there is a process
somewhere I should follow to have this removed.

The first step is to make sure that all changes on the branch are in a non open 
state (merged or abandoned). 
https://review.openstack.org/#/q/project:openstack/cinder+branch:driverfixes/ocata+status:open
 shows that there are no open changes.

Next you will want to make sure that the commits on this branch are preserved 
somehow. Git garbage collection will delete and cleanup commits if they are not 
discoverable when working backward from some ref. This is why our old stable 
branch deletion process required we tag the stable branch as $release-eol 
first. Looking at `git log origin/driverfixes/ocata ^origin/stable/ocata 
--no-merges --oneline` there are quite a few commits on the driverfixes branch 
that are not on the stable branch, but that appears to be due to cherry pick 
writing new commits. You have indicated above that you believe the two branches 
are in sync at this point. A quick sampling of commits seems to confirm this as 
well.

If you can go ahead and confirm that you are ready to delete the 
driverfixes/ocata branch I will go ahead and remove it.

Clark


I did another spot check too to make sure I hadn't missed anything, but it does
appear to be as you stated that the cherry pick resulted in new commits and
they actually are in sync for our purposes.

I believe we are ready to proceed.

Sean,

Thank you for following up on this.  I agee it is a good idea to remove 
the old driverfixes/ocata branch to avoid possible confusion in the future.


Clark,

Sean, myself and the team worked to carefully cherry-pick everything 
that was needed in stable/ocata so I am confident that we are ready to 
remove driverfixes/ocata.


Thanks!
Jay



Thanks for your help.

Sean

__
OpenStack Development Mailing 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] [cinder][infra] Remove driverfixes/ocata branch

[Clark Boylan]

On Mon, Sep 17, 2018, at 8:53 AM, Jay S Bryant wrote:
> 
> 
> On 9/17/2018 10:46 AM, Sean McGinnis wrote:
> >>> Plan
> >>> 
> >>> We would now like to have the driverfixes/ocata branch deleted so there 
> >>> is no
> >>> confusion about where backports should go and we don't accidentally get 
> >>> these
> >>> out of sync again.
> >>>
> >>> Infra team, please delete this branch or let me know if there is a process
> >>> somewhere I should follow to have this removed.
> >> The first step is to make sure that all changes on the branch are in a non 
> >> open state (merged or abandoned). 
> >> https://review.openstack.org/#/q/project:openstack/cinder+branch:driverfixes/ocata+status:open
> >>  shows that there are no open changes.
> >>
> >> Next you will want to make sure that the commits on this branch are 
> >> preserved somehow. Git garbage collection will delete and cleanup commits 
> >> if they are not discoverable when working backward from some ref. This is 
> >> why our old stable branch deletion process required we tag the stable 
> >> branch as $release-eol first. Looking at `git log origin/driverfixes/ocata 
> >> ^origin/stable/ocata --no-merges --oneline` there are quite a few commits 
> >> on the driverfixes branch that are not on the stable branch, but that 
> >> appears to be due to cherry pick writing new commits. You have indicated 
> >> above that you believe the two branches are in sync at this point. A quick 
> >> sampling of commits seems to confirm this as well.
> >>
> >> If you can go ahead and confirm that you are ready to delete the 
> >> driverfixes/ocata branch I will go ahead and remove it.
> >>
> >> Clark
> >>
> > I did another spot check too to make sure I hadn't missed anything, but it 
> > does
> > appear to be as you stated that the cherry pick resulted in new commits and
> > they actually are in sync for our purposes.
> >
> > I believe we are ready to proceed.
> Sean,
> 
> Thank you for following up on this.  I agee it is a good idea to remove 
> the old driverfixes/ocata branch to avoid possible confusion in the future.
> 
> Clark,
> 
> Sean, myself and the team worked to carefully cherry-pick everything 
> that was needed in stable/ocata so I am confident that we are ready to 
> remove driverfixes/ocata.
> 

I have removed openstack/cinder driverfixes/ocata branch with HEAD 
a37cc259f197e1a515cf82deb342739a125b65c6.

Clark

__
OpenStack Development Mailing 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] [senlin][stable] Nominating chenyb4 to Senlin Stable Maintainers Team

[Duc Truong]

Voting has concluded.  Welcome chenyb4 to the Senlin stable review team.

On Thu, Sep 13, 2018 at 10:50 PM Qiming Teng  wrote:
>
> +2 from me.
>
> Thanks.
>  - Qiming
>
> On Mon, Sep 10, 2018 at 09:56:10AM -0700, Duc Truong wrote:
> > Hi Senlin Stable Team,
> >
> > I would like to nominate Yuanbin Chen (chenyb4) to the Senlin stable
> > review team. Yuanbin has been doing stable reviews and shown that he
> > understands the policy for merging stable patches [1].
> >
> > Voting is open for 7 days. Please reply with your +1 vote in favor or
> > -1 as a veto vote.
> >
> > [1] 
> > https://review.openstack.org/#/q/branch:%255Estable/.*+reviewedby:cybing4%2540gmail.com
> >
> > Regards,
> >
> > Duc (dtruong)
> >
> > __
> > OpenStack Development Mailing 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] [cinder][infra] Remove driverfixes/ocata branch

[Clark Boylan]

On Mon, Sep 17, 2018, at 8:00 AM, Sean McGinnis wrote:
> Hello Cinder and Infra teams. Cinder needs some help from infra or some
> pointers on how to proceed.
> 
> tl;dr - The openstack/cinder repo had a driverfixes/ocata branch created for
> fixes that no longer met the more restrictive phase II stable policy criteria.
> Extended maintenance has changed that and we want to delete driverfixes/ocata
> to make sure patches are going to the right place.
> 
> Background
> --
> Before the extended maintenance changes, the Cinder team found a lot of 
> vendors
> were maintaining their own forks to keep backported driver fixes that we were
> not allowing upstream due to the stable policy being more restrictive for 
> older
> (or deleted) branches. We created the driverfixes/* branches as a central 
> place
> for these to go so distros would have one place to grab these fixes, if they
> chose to do so.
> 
> This has worked great IMO, and we do occasionally still have things that need
> to go to driverfixes/mitaka and driverfixes/newton. We had also pushed a lot 
> of
> fixes to driverfixes/ocata, but with the changes to stable policy with 
> extended
> maintenance, that is no longer needed.
> 
> Extended Maintenance Changes
> 
> With things being somewhat relaxed with the extended maintenance changes, we
> are now able to backport bug fixes to stable/ocata that we couldn't before and
> we don't have to worry as much about that branch being deleted.
> 
> I had gone through and identified all patches backported to driverfixes/ocata
> but not stable/ocata and cherry-picked them over to get the two branches in
> sync. The stable/ocata should now be identical or ahead of driverfixes/ocata
> and we want to make sure nothing more gets accidentally merged to
> driverfixes/ocata instead of the official stable branch.
> 
> Plan
> 
> We would now like to have the driverfixes/ocata branch deleted so there is no
> confusion about where backports should go and we don't accidentally get these
> out of sync again.
> 
> Infra team, please delete this branch or let me know if there is a process
> somewhere I should follow to have this removed.

The first step is to make sure that all changes on the branch are in a non open 
state (merged or abandoned). 
https://review.openstack.org/#/q/project:openstack/cinder+branch:driverfixes/ocata+status:open
 shows that there are no open changes.

Next you will want to make sure that the commits on this branch are preserved 
somehow. Git garbage collection will delete and cleanup commits if they are not 
discoverable when working backward from some ref. This is why our old stable 
branch deletion process required we tag the stable branch as $release-eol 
first. Looking at `git log origin/driverfixes/ocata ^origin/stable/ocata 
--no-merges --oneline` there are quite a few commits on the driverfixes branch 
that are not on the stable branch, but that appears to be due to cherry pick 
writing new commits. You have indicated above that you believe the two branches 
are in sync at this point. A quick sampling of commits seems to confirm this as 
well.

If you can go ahead and confirm that you are ready to delete the 
driverfixes/ocata branch I will go ahead and remove it.

Clark

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

Re: [openstack-dev] [TripleO] Regarding dropping Ocata related jobs from TripleO

[Jose Luis Franco Arza]

Hi,

>From the upgrades/updates point of view it should be ok dropping the Ocata
jobs.
The only one covering Ocata to Pike upgrade in upstream CI is running in
RDO cloud as a non voting one,
and it is failing at the moment.

Thanks,

Jose Luis

On Fri, Sep 14, 2018 at 6:33 PM Alex Schultz  wrote:

> On Fri, Sep 14, 2018 at 10:20 AM, Elõd Illés 
> wrote:
> > Hi,
> >
> > just a comment: Ocata release is not EOL [1][2] rather in Extended
> > Maintenance. Do you really want to EOL TripleO stable/ocata?
> >
>
> Yes unless there are any objections.  We've already been keeping this
> branch alive on life support but CI has started to fail and we've just
> been turning it off jobs as they fail.  We had not planned on extended
> maintenance for Ocata (or Pike).  We'll likely consider that starting
> with Queens.  We could switch it to extended maintenance but without
> the promotion jobs we won't have packages to run CI so it would be
> better to just EOL it.
>
> Thanks,
> -Alex
>
> > [1] https://releases.openstack.org/
> > [2]
> >
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
> >
> > Cheers,
> >
> > Előd
> >
> >
> >
> > On 2018-09-14 09:20, Juan Antonio Osorio Robles wrote:
> >>
> >>
> >> On 09/14/2018 09:01 AM, Alex Schultz wrote:
> >>>
> >>> On Fri, Sep 14, 2018 at 6:37 AM, Chandan kumar 
> >>> wrote:
> 
>  Hello,
> 
>  As Ocata release is already EOL on 27-08-2018 [1].
>  In TripleO, we are running Ocata jobs in TripleO CI and in promotion
>  pipelines.
>  Can we drop it all the jobs related to Ocata or do we need to keep
> some
>  jobs
>  to support upgrades in CI?
> 
> >>> I think unless there are any objections around upgrades, we can drop
> >>> the promotion pipelines. It's likely that we'll also want to
> >>> officially EOL the tripleo ocata branches.
> >>
> >> sounds good to me.
> >>>
> >>> Thanks,
> >>> -Alex
> >>>
>  Links:
>  [1.] https://releases.openstack.org/
> 
>  Thanks,
> 
>  Chandan Kumar
> 
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] Forum Topic Submission Period

[Jimmy McArthur]

Hello Everyone!

The Forum Topic Submission session started September 12 and will run 
through September 26th.  Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum topics 
through. Don't rely only on a PTL to make the agenda... step on up and 
place the items you consider important front and center.


As you may have noticed on the Forum Wiki 
(https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP 
tool this year. We did our best to remove Summit specific language, but 
if you notice something, just know that you are submitting to the 
Forum.  URL is here:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Looking forward to seeing everyone's submissions!

If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
Jimmy

__
OpenStack Development Mailing 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] [cinder][infra] Remove driverfixes/ocata branch

[Sean McGinnis]

Hello Cinder and Infra teams. Cinder needs some help from infra or some
pointers on how to proceed.

tl;dr - The openstack/cinder repo had a driverfixes/ocata branch created for
fixes that no longer met the more restrictive phase II stable policy criteria.
Extended maintenance has changed that and we want to delete driverfixes/ocata
to make sure patches are going to the right place.

Background
--
Before the extended maintenance changes, the Cinder team found a lot of vendors
were maintaining their own forks to keep backported driver fixes that we were
not allowing upstream due to the stable policy being more restrictive for older
(or deleted) branches. We created the driverfixes/* branches as a central place
for these to go so distros would have one place to grab these fixes, if they
chose to do so.

This has worked great IMO, and we do occasionally still have things that need
to go to driverfixes/mitaka and driverfixes/newton. We had also pushed a lot of
fixes to driverfixes/ocata, but with the changes to stable policy with extended
maintenance, that is no longer needed.

Extended Maintenance Changes

With things being somewhat relaxed with the extended maintenance changes, we
are now able to backport bug fixes to stable/ocata that we couldn't before and
we don't have to worry as much about that branch being deleted.

I had gone through and identified all patches backported to driverfixes/ocata
but not stable/ocata and cherry-picked them over to get the two branches in
sync. The stable/ocata should now be identical or ahead of driverfixes/ocata
and we want to make sure nothing more gets accidentally merged to
driverfixes/ocata instead of the official stable branch.

Plan

We would now like to have the driverfixes/ocata branch deleted so there is no
confusion about where backports should go and we don't accidentally get these
out of sync again.

Infra team, please delete this branch or let me know if there is a process
somewhere I should follow to have this removed.

Thanks!
Sean (smcginnis)

__
OpenStack Development Mailing 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] [cinder][infra] Remove driverfixes/ocata branch

[Sean McGinnis]

> > 
> > Plan
> > 
> > We would now like to have the driverfixes/ocata branch deleted so there is 
> > no
> > confusion about where backports should go and we don't accidentally get 
> > these
> > out of sync again.
> > 
> > Infra team, please delete this branch or let me know if there is a process
> > somewhere I should follow to have this removed.
> 
> The first step is to make sure that all changes on the branch are in a non 
> open state (merged or abandoned). 
> https://review.openstack.org/#/q/project:openstack/cinder+branch:driverfixes/ocata+status:open
>  shows that there are no open changes.
> 
> Next you will want to make sure that the commits on this branch are preserved 
> somehow. Git garbage collection will delete and cleanup commits if they are 
> not discoverable when working backward from some ref. This is why our old 
> stable branch deletion process required we tag the stable branch as 
> $release-eol first. Looking at `git log origin/driverfixes/ocata 
> ^origin/stable/ocata --no-merges --oneline` there are quite a few commits on 
> the driverfixes branch that are not on the stable branch, but that appears to 
> be due to cherry pick writing new commits. You have indicated above that you 
> believe the two branches are in sync at this point. A quick sampling of 
> commits seems to confirm this as well.
> 
> If you can go ahead and confirm that you are ready to delete the 
> driverfixes/ocata branch I will go ahead and remove it.
> 
> Clark
> 

I did another spot check too to make sure I hadn't missed anything, but it does
appear to be as you stated that the cherry pick resulted in new commits and
they actually are in sync for our purposes.

I believe we are ready to proceed.

Thanks for your help.

Sean

__
OpenStack Development Mailing 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] [keystone] Rocky Retrospective

[Lance Bragstad]

This is typically something we do in-person during the PTG, but due to
weather and travel approval we didn't have great representation last week.

That said, let's try to do an asynchronous retrospective to gather feedback
regarding the last cycle. Afterwords we can try and meet to go through
specific things, if needed. I've created a doodle to see if we can get a
time lined up [0]. The retrospective board [1] is available and waiting for
your feedback! The board should be public, but if you need access to add
cards, just ping me.

I'll collect results from the doodle on Friday and see what times work.

Thanks,

Lance

[0] https://doodle.com/poll/5vkztz9sumkbzp4h
[1] https://trello.com/b/af8vmDPs/keystone-rocky-retrospective
__
OpenStack Development Mailing 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] [senlin] Nominations to Senlin Core Team

[Duc Truong]

Voting has concluded. Welcome Jude and Erik to the Senlin Core team.

On Thu, Sep 13, 2018 at 12:14 AM x Lyn  wrote:
>
> +1 to both, looking forward to their future contribution.
>
> > On Sep 11, 2018, at 12:59 AM, Duc Truong  wrote:
> >
> > Hi Senlin Core Team,
> >
> > I would like to nominate 2 new core reviewers for Senlin:
> >
> > [1] Jude Cross (jucr...@blizzard.com)
> > [2] Erik Olof Gunnar Andersson (eanders...@blizzard.com)
> >
> > Jude has been doing a number of reviews and contributed some important
> > patches to Senlin during the Rocky cycle that resolved locking
> > problems.
> >
> > Erik has the most number of reviews in Rocky and has contributed high
> > quality code reviews for some time.
> >
> > [1] 
> > http://stackalytics.com/?module=senlin-group=marks=rocky_id=jucr...@blizzard.com
> > [2] 
> > http://stackalytics.com/?module=senlin-group=marks_id=eandersson=rocky
> >
> > Voting is open for 7 days.  Please reply with your +1 vote in favor or
> > -1 as a veto vote.
> >
> > Regards,
> >
> > Duc (dtruong)
> >
> > __
> > OpenStack Development Mailing 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] notes from stein ptg meetings of the technical committee

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2018-09-17 17:07:43 -0400:
> On 09/17/2018 04:50 PM, Doug Hellmann wrote:
> > Excerpts from Zane Bitter's message of 2018-09-17 16:12:30 -0400:
> >> On 17/09/18 3:06 PM, Jay Pipes wrote:
> >>> On 09/17/2018 01:31 PM, Doug Hellmann wrote:
>  New Project Application Process
>  ===
> 
>  We wrapped up Sunday with a discussion of of our process for reviewing
>  new project applications. Zane and Chris in particular felt the
>  process for Adjutant was too painful for the project team because
>  there was no way to know how long discussions might go on and now
>  way for them to anticipate some of the issues they encountered.
> 
>  We talked about formalizing a "coach" position to have someone from
>  the TC (or broader community) work with the team to prepare their
>  application with sufficient detail, seek feedback before voting
>  starts, etc.
> 
>  We also talked about adding a time limit to the process, so that
>  teams at least have a rejection with feedback in a reasonable amount
>  of time.  Some of the less contentious discussions have averaged
>  from 1-4 months with a few more contentious cases taking as long
>  as 10 months. We did not settle on a time frame during the meeting,
>  so I expect this to be a topic for us to work out during the next
>  term.
> >>>
> >>> So, to summarize... the TC is back to almost exactly the same point it
> >>> was at right before the Project Structure Reform happened in 2014-2015
> >>> (that whole Big Tent thing).
> >>
> >> I wouldn't go that far. There are more easy decisions than there were
> >> before the reform, but there still exist hard decisions. This is perhaps
> >> inevitable.
> >>
> >>> The Project Structure Reform occurred because the TC could not make
> >>> decisions on whether projects should join OpenStack using objective
> >>> criteria, and due to this, new project applicants were forced to endure
> >>> long waits and subjective "graduation" reviews that could change from
> >>> one TC election cycle to the next.
> >>>
> >>> The solution to this was to make an objective set of application
> >>> criteria and remove the TC from the "Supreme Court of OpenStack" role
> >>> that new applicants needed to come before and submit to the court's
> >>> judgment.
> >>>
> >>> Many people complained that the Project Structure Reform was the TC
> >>> simply abrogating responsibility for being a judgmental body.
> >>>
> >>> It seems that although we've now gotten rid of those objective criteria
> >>> for project inclusion and gone back to the TC being a subjective
> >>> judgmental body, that the TC is still not actually willing to pass
> >>> judgment one way or the other on new project applicants.
> >>
> >> No criteria have been gotten rid of, but even after the Project
> >> Structure Reform there existed criteria that were subjective. Here is a
> >> thread discussing them during the last TC election:
> >>
> >> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html
> >>
> >> (I actually think that the perception that the criteria should be
> >> entirely objective might be a contributor to the problem: when faced
> >> with a subjective decision and no documentation or precedent to guide
> >> them, TC members can be reluctant to choose.)
> > 
> > I think turning the decision about which projects fit the mission
> > into an entirely mechanical one would be a mistake. I would prefer
> > us to use, and trust, our judgement in cases where the answer needs
> > some thought.
> > 
> > I don't remember the history quite the way Jay does, either. I
> > remember us trying to base the decision more about what the team
> > was doing than how the code looked or whether the implementation
> > met anyone's idea of "good". That's why we retained the requirement
> > that the project "aligns with the OpenStack Mission".
> 
> Hmm. I very specifically remember the incubation and graduation review 
> of Zaqar and the fact that over a couple cycles of TC elections, the 
> "advice" given by the TC about specific technical implementation details 
> changed, often arbitrarily, depending on who was on the TC and what day 
> of the week it was. In fact, I pretty vividly remember this arbitrary 
> nature of the architectural review being one of the primary reasons we 
> switched to a purely objective set of criteria.

I remember talking about objectivity, but I also remember that we
stopped reviewing aspects of a project like it's architecture or
implementation details to avoid having the case you describe recur.
I remember that because I had a hard time coming around to that
point of view, at first.

You're correct, however, that the resolution we adopted as the first
step toward the big tent change

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Zhipeng Huang]

Would like to see some updates on the foundation's official wechat group up
:)

On the other note, I would like to point out that this email is merely
asking who would be interested. The question about "dividing teams" and
such is addressed in https://review.openstack.org/602697 .


On Tue, Sep 18, 2018 at 5:57 AM Lance Bragstad  wrote:

>
>
> On Mon, Sep 17, 2018 at 1:42 PM Mohammed Naser 
> wrote:
>
>> Hi,
>>
>> On that note, is there any way to get an 'invite' onto those channels?
>>
>> Any information about the foundation side of things about the
>> 'official' channels?
>>
>
> I actually have a question about this as well. During the TC discussion
> last Friday there was representation from the Foundation in the room. I
> though I remember someone (annabelleB?) saying there were known issues
> (technical or otherwise) regarding the official channels spun up by the
> Foundation.
>
> Does anyone know what issues were being referred to here?
>
>
>>
>> Thanks,
>> Mohammed
>> On Mon, Sep 17, 2018 at 3:28 PM Samuel Cassiba  wrote:
>> >
>> > On Mon, Sep 17, 2018 at 6:58 AM Sylvain Bauza 
>> wrote:
>> > >
>> > >
>> > >
>> > > Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  a
>> écrit :
>> > >>
>> > >> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
>> > >> [...]
>> > >> > - What is the problem joining Wechat will solve (keeping in mind
>> the
>> > >> > language barrier)?
>> > >>
>> > >> As I understand it, the suggestion is that mere presence of project
>> > >> leadership in venues where this emerging subset of our community
>> > >> gathers would provide a strong signal that we support them and care
>> > >> about their experience with the software.
>> > >>
>> > >> > - Isn't this problem already solved for other languages with
>> > >> > existing initiatives like local ambassadors and i18n team? Why
>> > >> > aren't these relevant?
>> > >> [...]
>> > >>
>> > >> It seems like there are at least couple of factors at play here:
>> > >> first the significant number of users and contributors within
>> > >> mainland China compared to other regions (analysis suggests there
>> > >> were nearly as many contributors to the Rocky release from China as
>> > >> the USA), but second there may be facets of Chinese culture which
>> > >> make this sort of demonstrative presence a much stronger signal than
>> > >> it would be in other cultures.
>> > >>
>> > >> > - Pardon my ignorance here, what is the problem with email? (I
>> > >> > understand some chat systems might be blocked, I thought emails
>> > >> > would be fine, and the lowest common denominator).
>> > >>
>> > >> Someone in the TC room (forgive me, I don't recall who now, maybe
>> > >> Rico?) asserted that Chinese contributors generally only read the
>> > >> first message in any given thread (perhaps just looking for possible
>> > >> announcements?) and that if they _do_ attempt to read through some
>> > >> of the longer threads they don't participate in them because the
>> > >> discussion is presumed to be over and decisions final by the time
>> > >> they "reach the end" (I guess not realizing that it's perfectly fine
>> > >> to reply to a month-old discussion and try to help alter course on
>> > >> things if you have an actual concern?).
>> > >>
>> > >
>> > > While I understand the technical issues that could be due using IRC
>> in China, I still don't get why opening the gates and saying WeChat being
>> yet another official channel would prevent our community from fragmenting.
>> > >
>> > > Truly the usage of IRC is certainly questionable, but if we have
>> multiple ways to discuss, I just doubt we could prevent us to silo
>> ourselves between our personal usages.
>> > > Either we consider the new channels as being only for southbound
>> communication, or we envisage the possibility, as a community, to migrate
>> from IRC to elsewhere (I'm particulary not fan of the latter so I would
>> challenge this but I can understand the reasons)
>> > >
>> > > -Sylvain
>> > >
>> >
>> > Objectively, I don't see a way to endorse something other than IRC
>> > without some form of collective presence on more than just Wechat to
>> > keep the message intact. IRC is the official messaging platform, for
>> > whatever that's worth these days. However, at present, it makes less
>> > and less sense to explicitly eschew other outlets in favor. From a
>> > Chef OpenStack perspective, the common medium is, perhaps not
>> > unsurprising, code review. Everything else evolved over time to be
>> > southbound paths to the code, including most of the conversation
>> > taking place there as opposed to IRC.
>> >
>> > The continuation of this thread only confirms that there is already
>> > fragmentation in the community, and that people on each side of the
>> > void genuinely want to close that gap. At this point, the thing to do
>> > is prevent further fragmentation of the intent. It is, however, far
>> > easier to bikeshed over which platform of choice.
>> >
>> > At present, it 

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Anne Bertucio]

> I though I remember someone (annabelleB?) saying there were known issues 
> (technical or otherwise) regarding the official channels spun up by the 
> Foundation.

Two separate issues that perhaps got mashed together :) 

Unofficial WeChat channels are limited to ~500 participants and are 
invite-only. That makes a few challenges for a community of our size (much more 
than 500!). Official subscription channels don’t have these limitations, but 
there’s a lengthy process to get one. It’s currently in progress (unfortunately 
I don’t think we have an ETA beyond “in progress” at this point—more than one 
month; less than six months?).

  
Anne Bertucio
OpenStack Foundation
a...@openstack.org | irc: annabelleB





> On Sep 17, 2018, at 2:56 PM, Lance Bragstad  wrote:
> 
> 
> 
> On Mon, Sep 17, 2018 at 1:42 PM Mohammed Naser  > wrote:
> Hi,
> 
> On that note, is there any way to get an 'invite' onto those channels?
> 
> Any information about the foundation side of things about the
> 'official' channels?
> 
> I actually have a question about this as well. During the TC discussion last 
> Friday there was representation from the Foundation in the room. I though I 
> remember someone (annabelleB?) saying there were known issues (technical or 
> otherwise) regarding the official channels spun up by the Foundation.
> 
> Does anyone know what issues were being referred to here?
>  
> 
> Thanks,
> Mohammed
> On Mon, Sep 17, 2018 at 3:28 PM Samuel Cassiba  > wrote:
> >
> > On Mon, Sep 17, 2018 at 6:58 AM Sylvain Bauza  > > wrote:
> > >
> > >
> > >
> > > Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  > > > a écrit :
> > >>
> > >> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
> > >> [...]
> > >> > - What is the problem joining Wechat will solve (keeping in mind the
> > >> > language barrier)?
> > >>
> > >> As I understand it, the suggestion is that mere presence of project
> > >> leadership in venues where this emerging subset of our community
> > >> gathers would provide a strong signal that we support them and care
> > >> about their experience with the software.
> > >>
> > >> > - Isn't this problem already solved for other languages with
> > >> > existing initiatives like local ambassadors and i18n team? Why
> > >> > aren't these relevant?
> > >> [...]
> > >>
> > >> It seems like there are at least couple of factors at play here:
> > >> first the significant number of users and contributors within
> > >> mainland China compared to other regions (analysis suggests there
> > >> were nearly as many contributors to the Rocky release from China as
> > >> the USA), but second there may be facets of Chinese culture which
> > >> make this sort of demonstrative presence a much stronger signal than
> > >> it would be in other cultures.
> > >>
> > >> > - Pardon my ignorance here, what is the problem with email? (I
> > >> > understand some chat systems might be blocked, I thought emails
> > >> > would be fine, and the lowest common denominator).
> > >>
> > >> Someone in the TC room (forgive me, I don't recall who now, maybe
> > >> Rico?) asserted that Chinese contributors generally only read the
> > >> first message in any given thread (perhaps just looking for possible
> > >> announcements?) and that if they _do_ attempt to read through some
> > >> of the longer threads they don't participate in them because the
> > >> discussion is presumed to be over and decisions final by the time
> > >> they "reach the end" (I guess not realizing that it's perfectly fine
> > >> to reply to a month-old discussion and try to help alter course on
> > >> things if you have an actual concern?).
> > >>
> > >
> > > While I understand the technical issues that could be due using IRC in 
> > > China, I still don't get why opening the gates and saying WeChat being 
> > > yet another official channel would prevent our community from fragmenting.
> > >
> > > Truly the usage of IRC is certainly questionable, but if we have multiple 
> > > ways to discuss, I just doubt we could prevent us to silo ourselves 
> > > between our personal usages.
> > > Either we consider the new channels as being only for southbound 
> > > communication, or we envisage the possibility, as a community, to migrate 
> > > from IRC to elsewhere (I'm particulary not fan of the latter so I would 
> > > challenge this but I can understand the reasons)
> > >
> > > -Sylvain
> > >
> >
> > Objectively, I don't see a way to endorse something other than IRC
> > without some form of collective presence on more than just Wechat to
> > keep the message intact. IRC is the official messaging platform, for
> > whatever that's worth these days. However, at present, it makes less
> > and less sense to explicitly eschew other outlets in favor. From a
> > Chef OpenStack perspective, the common medium is, perhaps not
> > unsurprising, code review. Everything else 

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Davanum Srinivas]

On Mon, Sep 17, 2018 at 7:06 PM Anne Bertucio  wrote:

> I though I remember someone (annabelleB?) saying there were known issues
> (technical or otherwise) regarding the official channels spun up by the
> Foundation.
>
>
> Two separate issues that perhaps got mashed together :)
>
> Unofficial WeChat channels are limited to ~500 participants and are
> invite-only. That makes a few challenges for a community of our size (much
> more than 500!). Official subscription channels don’t have these
> limitations, but there’s a lengthy process to get one. It’s currently in
> progress (unfortunately I don’t think we have an ETA beyond “in progress”
> at this point—more than one month; less than six months?).
>

Weird! Isn't Tencent a platinum sponsor?  Can we please ask them for help
move this forward?

(cc'ing Ruan He)

-- Dims


>
> Anne Bertucio
> OpenStack Foundation
> a...@openstack.org | irc: annabelleB
>
>
>
>
>
> On Sep 17, 2018, at 2:56 PM, Lance Bragstad  wrote:
>
>
>
> On Mon, Sep 17, 2018 at 1:42 PM Mohammed Naser 
> wrote:
>
>> Hi,
>>
>> On that note, is there any way to get an 'invite' onto those channels?
>>
>> Any information about the foundation side of things about the
>> 'official' channels?
>>
>
> I actually have a question about this as well. During the TC discussion
> last Friday there was representation from the Foundation in the room. I
> though I remember someone (annabelleB?) saying there were known issues
> (technical or otherwise) regarding the official channels spun up by the
> Foundation.
>
> Does anyone know what issues were being referred to here?
>
>
>>
>> Thanks,
>> Mohammed
>> On Mon, Sep 17, 2018 at 3:28 PM Samuel Cassiba  wrote:
>> >
>> > On Mon, Sep 17, 2018 at 6:58 AM Sylvain Bauza 
>> wrote:
>> > >
>> > >
>> > >
>> > > Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  a
>> écrit :
>> > >>
>> > >> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
>> > >> [...]
>> > >> > - What is the problem joining Wechat will solve (keeping in mind
>> the
>> > >> > language barrier)?
>> > >>
>> > >> As I understand it, the suggestion is that mere presence of project
>> > >> leadership in venues where this emerging subset of our community
>> > >> gathers would provide a strong signal that we support them and care
>> > >> about their experience with the software.
>> > >>
>> > >> > - Isn't this problem already solved for other languages with
>> > >> > existing initiatives like local ambassadors and i18n team? Why
>> > >> > aren't these relevant?
>> > >> [...]
>> > >>
>> > >> It seems like there are at least couple of factors at play here:
>> > >> first the significant number of users and contributors within
>> > >> mainland China compared to other regions (analysis suggests there
>> > >> were nearly as many contributors to the Rocky release from China as
>> > >> the USA), but second there may be facets of Chinese culture which
>> > >> make this sort of demonstrative presence a much stronger signal than
>> > >> it would be in other cultures.
>> > >>
>> > >> > - Pardon my ignorance here, what is the problem with email? (I
>> > >> > understand some chat systems might be blocked, I thought emails
>> > >> > would be fine, and the lowest common denominator).
>> > >>
>> > >> Someone in the TC room (forgive me, I don't recall who now, maybe
>> > >> Rico?) asserted that Chinese contributors generally only read the
>> > >> first message in any given thread (perhaps just looking for possible
>> > >> announcements?) and that if they _do_ attempt to read through some
>> > >> of the longer threads they don't participate in them because the
>> > >> discussion is presumed to be over and decisions final by the time
>> > >> they "reach the end" (I guess not realizing that it's perfectly fine
>> > >> to reply to a month-old discussion and try to help alter course on
>> > >> things if you have an actual concern?).
>> > >>
>> > >
>> > > While I understand the technical issues that could be due using IRC
>> in China, I still don't get why opening the gates and saying WeChat being
>> yet another official channel would prevent our community from fragmenting.
>> > >
>> > > Truly the usage of IRC is certainly questionable, but if we have
>> multiple ways to discuss, I just doubt we could prevent us to silo
>> ourselves between our personal usages.
>> > > Either we consider the new channels as being only for southbound
>> communication, or we envisage the possibility, as a community, to migrate
>> from IRC to elsewhere (I'm particulary not fan of the latter so I would
>> challenge this but I can understand the reasons)
>> > >
>> > > -Sylvain
>> > >
>> >
>> > Objectively, I don't see a way to endorse something other than IRC
>> > without some form of collective presence on more than just Wechat to
>> > keep the message intact. IRC is the official messaging platform, for
>> > whatever that's worth these days. However, at present, it makes less
>> > and less sense to explicitly eschew other outlets in favor. 

Re: [openstack-dev] [nova] When can/should we change additionalProperties=False in GET /servers(/detail)?

[Matt Riedemann]

On 9/17/2018 3:06 PM, Jay Pipes wrote:
My vote would be just change additionalProperties to False in the 599276 
patch and be done with it.


Well, it would be on a microversion boundary so the user would be opting 
into this stricter validation, but that's the point of microversions. So 
my custom API extension that handles GET /servers?bestpet=cats will 
continue to work as long as I'm using microversion < 2.66.


--

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] [election][tc]Question for candidates about global reachout

[Zhipeng Huang]

Thanks Anne :)

On another side note, there has not been a (maybe I missed) good "no" vote
message I was looking for.

A good quality "no" message could something like this in my opinion (and
this is just one of many possibilities):

"Thanks for invitation but no I would not like to use social media apps
other than IRC. General social media apps are open to a more variety of
people than in IRC channels and there are personalities or social
characters that I found myself just cannot cope with. Moreover social media
apps demands instant response, or at least has the expectation for one, in
its nature and it would make me feel pressured all the time. So no thank
you I would not use social media in any form, however if you do have good
technical questions from the social apps, please feel free to relay to me
and I'm glad to help when I have the bandwidth"




On Tue, Sep 18, 2018 at 7:06 AM Anne Bertucio  wrote:

> I though I remember someone (annabelleB?) saying there were known issues
> (technical or otherwise) regarding the official channels spun up by the
> Foundation.
>
>
> Two separate issues that perhaps got mashed together :)
>
> Unofficial WeChat channels are limited to ~500 participants and are
> invite-only. That makes a few challenges for a community of our size (much
> more than 500!). Official subscription channels don’t have these
> limitations, but there’s a lengthy process to get one. It’s currently in
> progress (unfortunately I don’t think we have an ETA beyond “in progress”
> at this point—more than one month; less than six months?).
>
>
> Anne Bertucio
> OpenStack Foundation
> a...@openstack.org | irc: annabelleB
>
>
>
>
>
> On Sep 17, 2018, at 2:56 PM, Lance Bragstad  wrote:
>
>
>
> On Mon, Sep 17, 2018 at 1:42 PM Mohammed Naser 
> wrote:
>
>> Hi,
>>
>> On that note, is there any way to get an 'invite' onto those channels?
>>
>> Any information about the foundation side of things about the
>> 'official' channels?
>>
>
> I actually have a question about this as well. During the TC discussion
> last Friday there was representation from the Foundation in the room. I
> though I remember someone (annabelleB?) saying there were known issues
> (technical or otherwise) regarding the official channels spun up by the
> Foundation.
>
> Does anyone know what issues were being referred to here?
>
>
>>
>> Thanks,
>> Mohammed
>> On Mon, Sep 17, 2018 at 3:28 PM Samuel Cassiba  wrote:
>> >
>> > On Mon, Sep 17, 2018 at 6:58 AM Sylvain Bauza 
>> wrote:
>> > >
>> > >
>> > >
>> > > Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  a
>> écrit :
>> > >>
>> > >> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
>> > >> [...]
>> > >> > - What is the problem joining Wechat will solve (keeping in mind
>> the
>> > >> > language barrier)?
>> > >>
>> > >> As I understand it, the suggestion is that mere presence of project
>> > >> leadership in venues where this emerging subset of our community
>> > >> gathers would provide a strong signal that we support them and care
>> > >> about their experience with the software.
>> > >>
>> > >> > - Isn't this problem already solved for other languages with
>> > >> > existing initiatives like local ambassadors and i18n team? Why
>> > >> > aren't these relevant?
>> > >> [...]
>> > >>
>> > >> It seems like there are at least couple of factors at play here:
>> > >> first the significant number of users and contributors within
>> > >> mainland China compared to other regions (analysis suggests there
>> > >> were nearly as many contributors to the Rocky release from China as
>> > >> the USA), but second there may be facets of Chinese culture which
>> > >> make this sort of demonstrative presence a much stronger signal than
>> > >> it would be in other cultures.
>> > >>
>> > >> > - Pardon my ignorance here, what is the problem with email? (I
>> > >> > understand some chat systems might be blocked, I thought emails
>> > >> > would be fine, and the lowest common denominator).
>> > >>
>> > >> Someone in the TC room (forgive me, I don't recall who now, maybe
>> > >> Rico?) asserted that Chinese contributors generally only read the
>> > >> first message in any given thread (perhaps just looking for possible
>> > >> announcements?) and that if they _do_ attempt to read through some
>> > >> of the longer threads they don't participate in them because the
>> > >> discussion is presumed to be over and decisions final by the time
>> > >> they "reach the end" (I guess not realizing that it's perfectly fine
>> > >> to reply to a month-old discussion and try to help alter course on
>> > >> things if you have an actual concern?).
>> > >>
>> > >
>> > > While I understand the technical issues that could be due using IRC
>> in China, I still don't get why opening the gates and saying WeChat being
>> yet another official channel would prevent our community from fragmenting.
>> > >
>> > > Truly the usage of IRC is certainly questionable, but if we have
>> multiple ways to discuss, I just 

[openstack-dev] GUI for Swift object storage

[M Ranga Swami Reddy]

Hi - is there any GUI (open source) available for Swift objects storage?

Thanks
Swa
__
OpenStack Development Mailing 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] [election][tc]Question for candidates about global reachout

[Jeremy Stanley]

On 2018-09-18 07:27:26 +0800 (+0800), Zhipeng Huang wrote:
[...]
> On another side note, there has not been a (maybe I missed) good
> "no" vote message I was looking for.
> 
> A good quality "no" message could something like this in my
> opinion (and this is just one of many possibilities):
> 
> "Thanks for invitation but no I would not like to use social media
> apps other than IRC. General social media apps are open to a more
> variety of people than in IRC channels and there are personalities
> or social characters that I found myself just cannot cope with.
> Moreover social media apps demands instant response, or at least
> has the expectation for one, in its nature and it would make me
> feel pressured all the time. So no thank you I would not use
> social media in any form, however if you do have good technical
> questions from the social apps, please feel free to relay to me
> and I'm glad to help when I have the bandwidth"

This seems to completely miss the reasons I personally reject such
platforms. I don't use proprietary tools or services for interacting
with our community, I avoid relying on products from companies which
attempt to track or share my location and activities for their own
profit or to report them to various government agencies, and I have
no interest in owning a "smart phone" (which some services such as
wechat outright require). At least for me, the example rejection you
proposed above is a miss on all counts...

I am plenty capable of coping with any of the "personalities or
social characters" I'm likely to encounter on those services (I'm
quite certain IRC is where you're going to find some of the worst
and *most* intolerable characters of any discussion medium). I also
am accustomed to providing a near instant response to urgent
requests in IRC, and at the same time don't feel particularly
"pressured" to do so. And I _do_ use some social media: both IRC and
mailing lists are in fact legitimate examples of social media. I'm
really not even opposed to using other forms as long as they rely on
open protocols and both the client _and_ server software are
available under a free/libre open source license.
-- 
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] [nova] When can/should we change additionalProperties=False in GET /servers(/detail)?

[Alex Xu]

That only means after 599276 we only have servers API and
os-instance-action API stopped accepting the undefined query parameter.

What I'm thinking about is checking all the APIs, add json-query-param
checking with additionalProperties=True if the API don't have yet. And
using another microversion set additionalProperties to False, then the
whole Nova API become consistent.

Jay Pipes  于2018年9月18日周二 上午4:07写道：

> On 09/17/2018 03:28 PM, Matt Riedemann wrote:
> > This is a question from a change [1] which adds a new changes-before
> > filter to the servers, os-instance-actions and os-migrations APIs.
> >
> > For context, the os-instance-actions API stopped accepting undefined
> > query parameters in 2.58 when we added paging support.
> >
> > The os-migrations API stopped allowing undefined query parameters in
> > 2.59 when we added paging support.
> >
> > The open question on the review is if we should change GET /servers and
> > GET /servers/detail to stop allowing undefined query parameters starting
> > with microversion 2.66 [2]. Apparently when we added support for 2.5 and
> > 2.26 for listing servers we didn't think about this. It means that a
> > user can specify a query parameter, documented in the API reference, but
> > with an older microversion and it will be silently ignored. That is
> > backward compatible but confusing from an end user perspective since it
> > would appear to them that the filter is not being applied, when it fact
> > it would be if they used the correct microversion.
> >
> > So do we want to start enforcing query parameters when listing servers
> > to our defined list with microversion 2.66 or just continue to silently
> > ignore them if used incorrectly?
> >
> > Note that starting in Rocky, the Neutron API will start rejecting
> > unknown query parameteres [3] if the filter-validation extension is
> > enabled (since Neutron doesn't use microversions). So there is some
> > precedent in OpenStack for starting to enforce query parameters.
> >
> > [1] https://review.openstack.org/#/c/599276/
> > [2]
> >
> https://review.openstack.org/#/c/599276/23/nova/api/openstack/compute/schemas/servers.py
> >
> > [3]
> > https://docs.openstack.org/releasenotes/neutron/rocky.html#upgrade-notes
>
> My vote would be just change additionalProperties to False in the 599276
> patch and be done with it.
>
> Add a release note about the change, of course.
>
> -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] GUI for Swift object storage

[John Dickinson]

That's a great question.

A quick google search shows a few like Swift Explorer, Cyberduck, and 
Gladinet. But since Swift supports the S3 API (check with your cluster 
operator to see if this is enabled, or examine the results of a `GET 
/info` request), you can use any available S3 GUI client as well (as 
long as you can configure the endpoints you connect to).



--John





On 17 Sep 2018, at 16:48, M Ranga Swami Reddy wrote:

Hi - is there any GUI (open source) available for Swift objects 
storage?


Thanks
Swa
__
OpenStack Development Mailing 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] [goals][python3] mixed versions?

[Ken Giusti]

On Thu, Sep 13, 2018 at 7:39 PM Doug Hellmann  wrote:

> Excerpts from Jim Rollenhagen's message of 2018-09-13 12:08:08 -0600:
> > On Wed, Sep 12, 2018 at 2:28 PM, Doug Hellmann 
> > wrote:
> >
> > > Excerpts from Doug Hellmann's message of 2018-09-12 12:04:02 -0600:
> > > > Excerpts from Clark Boylan's message of 2018-09-12 10:44:55 -0700:
> > > > > On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:
> > > > > > The process of operators upgrading Python versions across their
> > > fleet came
> > > > > > up this morning. It's fairly obvious that operators will want to
> do
> > > this in
> > > > > > a rolling fashion.
> > > > > >
> > > > > > Has anyone considered doing this in CI? For example, running
> > > multinode
> > > > > > grenade with python 2 on one node and python 3 on the other node.
> > > > > >
> > > > > > Should we (openstack) test this situation, or even care?
> > > > > >
> > > > >
> > > > > This came up in a Vancouver summit session (the python3 one I
> think).
> > > General consensus there seemed to be that we should have grenade jobs
> that
> > > run python2 on the old side and python3 on the new side and test the
> update
> > > from one to another through a release that way. Additionally there was
> > > thought that the nova partial job (and similar grenade jobs) could
> hold the
> > > non upgraded node on python2 and that would talk to a python3 control
> plane.
> > > > >
> > > > > I haven't seen or heard of anyone working on this yet though.
> > > > >
> > > > > Clark
> > > > >
> > > >
> > > > IIRC, we also talked about not supporting multiple versions of
> > > > python on a given node, so all of the services on a node would need
> > > > to be upgraded together.
> > > >
> > > > Doug
> > >
> > > I spent a little time talking with the QA team about setting up
> > > this job, and Attila pointed out that we should think about what
> > > exactly we think would break during a 2-to-3 in-place upgrade like
> > > this.
> > >
> > > Keeping in mind that we are still testing initial installation under
> > > both versions and upgrades under python 2, do we have any specific
> > > concerns about the python *version* causing upgrade issues?
> > >
> >
> > A specific example brought up in the ironic room was the way we encode
> > exceptions in oslo.messaging for transmitting over RPC. I know that we've
> > found encoding bugs in that in the past, and one can imagine that RPC
> > between a service running on py2 and a service running on py3 could have
> > similar issues.
>
> Mixing python 2 and 3 components of the same service across nodes
> does seem like an interesting case. I wonder if it's something we
> could build a functional test job in oslo.messaging for, though,
> without having to test every service separately. I'd be happy if
> someone did that.
>
>
Currently that's a hole in the oslo.messaging tests.  I've opened a work
item to address this in launchpad:
https://bugs.launchpad.net/oslo.messaging/+bug/1792977


> > It's definitely edge cases that we'd be catching here (if any), so I'm
> > personally fine with assuming it will just work. But I wanted to pose the
> > question to the list, as we agreed this isn't only an ironic problem.
>
> Yes, definitely. I think it's likely to be a bit of work to set up the
> jobs and run them for all services, which is why I'm trying to
> understand if it's really needed. Thinking through the cases on the list
> is a good way to get folks to poke holes in any assertions, so I
> appreciate that you started the thread and that everyone is
> participating.
>
> 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
>


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

[openstack-dev] [tc] notes from stein ptg meetings of the technical committee

[Doug Hellmann]

The TC held meetings on 2 days at the Stein PTG in Denver. On Sunday 9
September, we met for a few hours in the afternoon to discuss
introspective topics. On Friday 14 September, we met for a full day to
discuss community topics. Below is a summary of my notes. Please let me
know if I omitted or misremembered anything.

Agenda and notes: https://etherpad.openstack.org/p/tc-stein-ptg


Backlog Review
==

We started the Sunday meeting with a review of all of the work that
TC members are doing outside of the TC. This gave us a clearer view
of what we could expect to be able to do as a group, given time
constraints.  With that grounding, we reviewed our backlog
(https://wiki.openstack.org/wiki/Technical_Committee_Tracker) and
removed many items that we either felt were completed, would not
be completed, or were ongoing monitoring and did not need to be
tracked as specific tasks. We also agreed to try to work together
as a group on a smaller number of initiatives, rather than maintaining
a long list of open items in the tracker.

The python 2.7 deprecation timeline has been documented
(https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html)
and we saw no need to be more formal about documenting expectations
for new projects joining the community, so we removed that item
from the tracker.

We have discussed building a set of documentation around project
constellations, but decided the information we hoped to convey in
constellations would better be conveyed through the software section
of the foundation web site. Now that the data for that section is
being moved to a repository that anyone in the community can update,
we no longer felt it was necessary for the TC to commit to writing
constellation documentation (although we would support someone else
picking up that work). We dropped this item from the tracker.

We had completed the item to add a key manager to the base services
list when we added "a castellan-compatible" service, but not removed
it from the backlog because there was also some discussion about
adding Barbican specifically. Work on that is on hold, so we removed
the item from the tracker for now and will add it back in the future
if we decide to move ahead with adding Barbican.

We removed the item for improving the visibility of status updates
because we considered it an ongoing task. We will still be working
on the problem, but since it may never be done we didn't feel like
tracking it as a "task" made sense. Doug, Thierry, and Jeremy talked
with the Infra team about upgrading and adding tools later in the
week.

We removed StarlingX from the tracker because the work on that
project are happening out in the open more so we felt the initial
status check was sufficiently completed.

We removed the item for clarifying the terms of service for hosted
projects on openstack.org infrastructure because that work is now
being done by the team soon-to-be-called OpenDev.

We removed the item that called for a review of the status of the
electorate. The election officials produce some statistics after
each election and they offered to add any details we thought were
useful.  Since this is a recurring item managed by the election
team, we do not need to track it ourselves.

We removed the item for improving the help-wanted list because it
wasn't clear that the TC was the best group to manage a list of
"roles" or other more detailed information. We discussed placing
that information into team documentation or hosting it somewhere
outside of the governance repository where more people could
contribute. The kubernetes community has set up a forum, for example.

We removed the task of updating the PTI for translation and PDF
support in documentation builds because we worked out a way to do
that without a governance change.
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134609.html


Joint Leadership Meeting in Berlin
==

Alan Clark, chair of the Foundation board of directors, was present
for the meeting, and asked that we include an agenda item to start
planning for the joint leadership meeting with the board, UC,
Foundation staff, and representatives from other projects being
piloted by the Foundation.

We spent a little bit of time discussing the previous meeting,
including some feedback from TC members that the project announcements
made that morning caused some distraction during the day. Jonathan
Bryce indicated that they will time those announcements better to
avoid that problem, and that with the new process being developed
there should be fewer surprises in the future.

Alan also gave us the feedback that with the ongoing evolution of
the OpenStack project, the board is going to expect the TC to start
providing more strategic planning information. He recommended that
we be ready to discuss major themes of ongoing work and give the
board members the information they need to project a positive image
to the 

Re: [openstack-dev] [goals][python3] mixed versions?

[Doug Hellmann]

Excerpts from Ken Giusti's message of 2018-09-17 13:18:28 -0400:
> On Thu, Sep 13, 2018 at 7:39 PM Doug Hellmann  wrote:
> > Excerpts from Jim Rollenhagen's message of 2018-09-13 12:08:08 -0600:

[snip]

> > > A specific example brought up in the ironic room was the way we encode
> > > exceptions in oslo.messaging for transmitting over RPC. I know that we've
> > > found encoding bugs in that in the past, and one can imagine that RPC
> > > between a service running on py2 and a service running on py3 could have
> > > similar issues.
> >
> > Mixing python 2 and 3 components of the same service across nodes
> > does seem like an interesting case. I wonder if it's something we
> > could build a functional test job in oslo.messaging for, though,
> > without having to test every service separately. I'd be happy if
> > someone did that.
> >
> >
> Currently that's a hole in the oslo.messaging tests.  I've opened a work
> item to address this in launchpad:
> https://bugs.launchpad.net/oslo.messaging/+bug/1792977

Thanks, Ken!

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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

[Rico Lin]

Hope you all safely travel back to home now.

Here is the summarize from some discussions (as much as I can trigger or
attend) in PTG for SIGs/WGs expose and some idea for action,
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134689.html

I also like the idea to at least expose the information of SIGs/WGs right
away. Feel free to give your feedback.

And not like the following message matters to anyone, but just in case. I
believe this is a goal for all group in the community so just don't let who
your duty, position, or full hand of good tasks to limit what you think
about the relative of this goal with you. Give your positive or negative
opinions to help us get a better shape.


On Wed, Sep 12, 2018 at 11:47 PM Matt Riedemann  wrote:

> Rather than take a tangent on Kristi's candidacy thread [1], I'll bring
> this up separately.
>
> Kristi said:
>
> "Ultimately, this list isn’t exclusive and I’d love to hear your and
> other people's opinions about what you think the I should focus on."
>
> Well since you asked...
>
> Some feedback I gave to the public cloud work group yesterday was to get
> their RFE/bug list ranked from the operator community (because some of
> the requests are not exclusive to public cloud), and then put pressure
> on the TC to help project manage the delivery of the top issue. I would
> like all of the SIGs to do this. The upgrades SIG should rank and
> socialize their #1 issue that needs attention from the developer
> community - maybe that's better upgrade CI testing for deployment
> projects, maybe it's getting the pre-upgrade checks goal done for Stein.
> The UC should also be doing this; maybe that's the UC saying, "we need
> help on closing feature gaps in openstack client and/or the SDK". I
> don't want SIGs to bombard the developers with *all* of their
> requirements, but I want to get past *talking* about the *same* issues
> *every* time we get together. I want each group to say, "this is our top
> issue and we want developers to focus on it." For example, the extended
> maintenance resolution [2] was purely birthed from frustration about
> talking about LTS and stable branch EOL every time we get together. It's
> also the responsibility of the operator and user communities to weigh in
> on proposed release goals, but the TC should be actively trying to get
> feedback from those communities about proposed goals, because I bet
> operators and users don't care about mox removal [3].
>
> I want to see the TC be more of a cross-project project management
> group, like a group of Ildikos and what she did between nova and cinder
> to get volume multi-attach done, which took persistent supervision to
> herd the cats and get it delivered. Lance is already trying to do this
> with unified limits. Doug is doing this with the python3 goal. I want my
> elected TC members to be pushing tangible technical deliverables forward.
>
> I don't find any value in the TC debating ad nauseam about visions and
> constellations and "what is openstack?". Scope will change over time
> depending on who is contributing to openstack, we should just accept
> this. And we need to realize that if we are failing to deliver value to
> operators and users, they aren't going to use openstack and then "what
> is openstack?" won't matter because no one will care.
>
> So I encourage all elected TC members to work directly with the various
> SIGs to figure out their top issue and then work on managing those
> deliverables across the community because the TC is particularly well
> suited to do so given the elected position. I realize political and
> bureaucratic "how should openstack deal with x?" things will come up,
> but those should not be the priority of the TC. So instead of
> philosophizing about things like, "should all compute agents be in a
> single service with a REST API" for hours and hours, every few months -
> immediately ask, "would doing that get us any closer to achieving top
> technical priority x?" Because if not, or it's so fuzzy in scope that no
> one sees the way forward, document a decision and then drop it.
>
> [1]
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html
> [2]
>
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
> [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html
>
> --
>
> Thanks,
>
> Matt
>
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] [election][tc]Question for candidates about global reachout

[Zhipeng Huang]

On Tue, Sep 18, 2018 at 8:06 AM Jeremy Stanley  wrote:

> This seems to completely miss the reasons I personally reject such
> platforms. I don't use proprietary tools or services for interacting
> with our community, I avoid relying on products from companies which
> attempt to track or share my location and activities for their own
> profit or to report them to various government agencies, and I have
> no interest in owning a "smart phone" (which some services such as
> wechat outright require). At least for me, the example rejection you
> proposed above is a miss on all counts...
>
> I am plenty capable of coping with any of the "personalities or
> social characters" I'm likely to encounter on those services (I'm
> quite certain IRC is where you're going to find some of the worst
> and *most* intolerable characters of any discussion medium). I also
> am accustomed to providing a near instant response to urgent
> requests in IRC, and at the same time don't feel particularly
> "pressured" to do so. And I _do_ use some social media: both IRC and
> mailing lists are in fact legitimate examples of social media. I'm
> really not even opposed to using other forms as long as they rely on
> open protocols and both the client _and_ server software are
> available under a free/libre open source license.
> --
> Jeremy Stanley
>

Jeremy, what I'm saying here, and also addressed in comments with the
related resolution patch, is that personality reasons are the ones that we
have to respect and no form of governance change could help solve the
problem. However other than that, we could always find a way to address the
issue for remedies, if we don't have a good answer now maybe we will have
sometime later.

Preference on  social tooling is something that the technical committee is
able to address, with isolation of usage of proprietary tools for certain
scenario and also strict policy on enforcing the open source communication
solutions we have today as the central ones the community will continue to
use. This is not an unsolvable problem given that we have a technical
committee, but personality issues are, no matter what governance instrument
we have.


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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] [tc]Global Reachout Proposal

[Ghanshyam Mann]

  On Sat, 15 Sep 2018 02:49:40 +0900 Zhipeng Huang  
wrote  
 > Hi all,
 > Follow up the diversity discussion we had in the tc session this morning 
 > [0], I've proposed a resolution on facilitating technical community in large 
 > to engage in global reachout for OpenStack more efficiently. 
 > Your feedbacks are welcomed. Whether this should be a new resolution or not 
 > at the end of the day, this is a conversation worthy to have.
 > [0] https://review.openstack.org/602697

I like that we are discussing the Global Reachout things which i personally 
feel is very important. There are many obstacle to have a standard global 
communication way. Honestly saying, there cannot be any standard communication 
channel which can accommodate different language, cultures , company/govt 
restriction. So the better we can do is best solution. 

I can understand that IRC cannot be used in China which is very painful and 
mostly it is used weChat. But there are few key points we need to consider for 
any social app to use?
- Technical discussions which needs more people to participate and need ref of 
links etc cannot be done on mobile app. You need desktop version of that app.
- Many of the social app have # of participation, invitation, logging 
restriction. 
- Those apps are not restricted to other place.
- It does not split the community members among more than one app or exiting 
channel.

With all those point, we need to think what all communication channel we really 
want to promote as community. 

IMO, we should educate and motivate people to participate over existing channel 
like IRC,  ML as much as possible. At least ML does not have any issue about 
usage. Ambassador and local user groups people can play a critical role here or 
local developers (i saw Alex volunteer for nova discussion in china) and they 
can ask them to start communication in ML or if they cannot then they can start 
the thread and proxy for them. 

I know slack is being used for Japan community and most of the communication 
there is in Japanese so i cannot help there even I join it. When talking to 
Akira (Japan Ambassador ) and as per him most of the developers do communicate 
in IRC, ML but users hesitate to do so because of culture and language. 

So if proposal is to participate community (Developers, TC, UC, Ambassador, 
User Group members etc) in local chat app and encourage people to move to ML 
etc then it is great idea. But if we want to promote all different chat app as 
community practice then, it can lead to lot of other problems than solving the 
current one.  For example:  It will divide the technical discussion etc

-gmann

 > -- 
 > Zhipeng (Howard) Huang
 > Standard EngineerIT Standard & Patent/IT Product LineHuawei Technologies 
 > Co,. LtdEmail: huangzhipeng@huawei.comOffice: Huawei Industrial Base, 
 > Longgang, Shenzhen
 > (Previous)
 > Research AssistantMobile Ad-Hoc Network Lab, Calit2University of California, 
 > IrvineEmail: zhipengh@uci.eduOffice: Calit2 Building Room 2402
 > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado 
 > ___
 > OpenStack-operators mailing list
 > openstack-operat...@lists.openstack.org
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 > 



__
OpenStack Development Mailing 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] GUI for Swift object storage

[M Ranga Swami Reddy]

All GUI tools are non open source...need to pay like cyberduck etc.
Looking for open source GUI for Swift API access.

On Tue, 18 Sep 2018, 06:41 John Dickinson,  wrote:

> That's a great question.
>
> A quick google search shows a few like Swift Explorer, Cyberduck, and
> Gladinet. But since Swift supports the S3 API (check with your cluster
> operator to see if this is enabled, or examine the results of a GET /info
> request), you can use any available S3 GUI client as well (as long as you
> can configure the endpoints you connect to).
>
> --John
>
> On 17 Sep 2018, at 16:48, M Ranga Swami Reddy wrote:
>
> Hi - is there any GUI (open source) available for Swift objects storage?
>
> Thanks
> Swa
> __
> OpenStack Development Mailing 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] [nova] When can/should we change additionalProperties=False in GET /servers(/detail)?

[Ghanshyam Mann]

  On Tue, 18 Sep 2018 09:33:30 +0900 Alex Xu  wrote  
 > That only means after 599276 we only have servers API and os-instance-action 
 > API stopped accepting the undefined query parameter.
 > What I'm thinking about is checking all the APIs, add json-query-param 
 > checking with additionalProperties=True if the API don't have yet. And using 
 > another microversion set additionalProperties to False, then the whole Nova 
 > API become consistent.

I too vote for doing it for all other API together. Restricting the unknown 
query or request param are very useful for API consistency. Item#1 in this 
etherpad https://etherpad.openstack.org/p/nova-api-cleanup

If you would like, i can propose a quick spec for that and positive response to 
do all together then we skip to do that in 599276 otherwise do it for GET 
servers in 599276. 

-gmann

 > Jay Pipes  于2018年9月18日周二 上午4:07写道：
 >  __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 > On 09/17/2018 03:28 PM, Matt Riedemann wrote:
 >  > This is a question from a change [1] which adds a new changes-before 
 >  > filter to the servers, os-instance-actions and os-migrations APIs.
 >  > 
 >  > For context, the os-instance-actions API stopped accepting undefined 
 >  > query parameters in 2.58 when we added paging support.
 >  > 
 >  > The os-migrations API stopped allowing undefined query parameters in 
 >  > 2.59 when we added paging support.
 >  > 
 >  > The open question on the review is if we should change GET /servers and 
 >  > GET /servers/detail to stop allowing undefined query parameters starting 
 >  > with microversion 2.66 [2]. Apparently when we added support for 2.5 and 
 >  > 2.26 for listing servers we didn't think about this. It means that a 
 >  > user can specify a query parameter, documented in the API reference, but 
 >  > with an older microversion and it will be silently ignored. That is 
 >  > backward compatible but confusing from an end user perspective since it 
 >  > would appear to them that the filter is not being applied, when it fact 
 >  > it would be if they used the correct microversion.
 >  > 
 >  > So do we want to start enforcing query parameters when listing servers 
 >  > to our defined list with microversion 2.66 or just continue to silently 
 >  > ignore them if used incorrectly?
 >  > 
 >  > Note that starting in Rocky, the Neutron API will start rejecting 
 >  > unknown query parameteres [3] if the filter-validation extension is 
 >  > enabled (since Neutron doesn't use microversions). So there is some 
 >  > precedent in OpenStack for starting to enforce query parameters.
 >  > 
 >  > [1] https://review.openstack.org/#/c/599276/
 >  > [2] 
 >  > 
 > https://review.openstack.org/#/c/599276/23/nova/api/openstack/compute/schemas/servers.py
 >  
 >  > 
 >  > [3] 
 >  > https://docs.openstack.org/releasenotes/neutron/rocky.html#upgrade-notes
 >  
 >  My vote would be just change additionalProperties to False in the 599276 
 >  patch and be done with it.
 >  
 >  Add a release note about the change, of course.
 >  
 >  -jay
 >  
 >  __
 >  OpenStack Development Mailing List (not for usage questions)
 >  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 >  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >  



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

[openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

[Rico Lin]

*TL;DR*
*How about a forum in Berlin for discussing autoscaling integration (as a
long-term goal) in OpenStack?*


Hi all, as we start to discuss how can we join develop from Heat and Senlin
as we originally planned when we decided to fork Senlin from Heat long time
ago.

IMO the biggest issues we got now are we got users using autoscaling in
both services, appears there is a lot of duplicated effort, and some great
enhancement didn't exist in another service.
As a long-term goal (from the beginning), we should try to join development
to sync functionality, and move users to use Senlin for autoscaling. So we
should start to review this goal, or at least we should try to discuss how
can we help users without break or enforce anything.

What will be great if we can build common library cross projects, and use
that common library in both projects, make sure we have all improvement
implemented in that library, finally to use Senlin from that from that
library call in Heat autoscaling group. And in long-term, we gonna let all
user use more general way instead of multiple ways but generate huge
confusing for users.

*As an action, I propose we have a forum in Berlin and sync up all effort
from both teams to plan for idea scenario design. The forum submission [1]
ended at 9/26.*
Also would benefit from both teams to start to think about how they can
modulize those functionalities for easier integration in the future.

>From some Heat PTG sessions, we keep bring out ideas on how can we improve
current solutions for Autoscaling. We should start to talk about will it
make sense if we combine all group resources into one, and inherit from it
for other resources (ideally gonna deprecate rest resource types). Like we
can do Batch create/delete in Resource Group, but not in ASG. We definitely
got some unsynchronized works inner Heat, and cross Heat and Senlin.

Please let me know who is interesting in this idea, so we can work together
and reach our goal step by step.
Also please provide though if you got any concerns about this proposal.

[1] https://www.openstack.org/summit/berlin-2018/call-for-presentations
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] [Freezer] Freezer support relational db and osbrick

[geng.changcai2]

Hi,Saad Zaher:

   1) Implementing Sqlalchemy driver for freezer-api:

At present, there is part 1 function in implementing Sqlalchemy driver for 
freezer-api in https://review.openstack.org/#/c/539077/.

Is there part 2 function? If you have an uncommitted patches, can you share it? 
I'd like to make it more complete so that it can be used.

If not, I plan to make a BP, which has been completed.




  2) osbrick:

There are many problems, such as multi partitions and LVM partition is not 
supported, etc. If there is no development to complete, if so, I would like to 
mention a BP to complete it.




Best regards,

gengchc2__
OpenStack Development Mailing 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] [puppet] [placement]

[Lee Yarwood]

On 15-09-18 11:42:37, Emilien Macchi wrote:
> I'm currently taking care of creating puppet-placement:
> https://review.openstack.org/#/c/602870/
> https://review.openstack.org/#/c/602871/
> https://review.openstack.org/#/c/602869/
> 
> Once these merge, we'll use cookiecutter, and move things from puppet-nova.
> We'll also find a way to call puppet-placement from nova::placement class,
> eventually.
> Hopefully we can make the switch to new placement during Stein!

Thanks Emilien,

FWIW I've also started work on the RDO packaging front [1] and would be
happy to help with this puppet extraction.

Cheers,

Lee

[1] https://gitlab.com/lyarwood/placement-distgit
-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


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] [puppet] [placement]

[Tobias Urdin]

Sounds great, thanks for pushing this Emilien!

Best regards
Tobias

On 09/15/2018 07:48 PM, Emilien Macchi wrote:

I'm currently taking care of creating puppet-placement:
https://review.openstack.org/#/c/602870/
https://review.openstack.org/#/c/602871/
https://review.openstack.org/#/c/602869/

Once these merge, we'll use cookiecutter, and move things from 
puppet-nova. We'll also find a way to call puppet-placement from 
nova::placement class, eventually.

Hopefully we can make the switch to new placement during Stein!

Thanks,
--
Emilien Macchi


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

Re: [openstack-dev] [nova][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possibledeprecation of Nova's legacy notification interface

[Balázs Gibizer]

Hi,

On the Stein PTG the nova team agreed to deprecate the legacy, 
unversioned notification interface of nova. We also agreed that we will 
not try to remove the legacy notification sending from the code any 
time soon. So this deprecation means the following:
* by default configuration nova will only emit versioned notifications, 
but the unversioned notifications still can be turned on in the 
configuration.
* nova will not maintain the legacy notification code path further, so 
it can break


I pushed the deprecation patch [2] but it will only be merged after the 
remaining versioned notification transformation patches [3] are merged.


Cheers,
gibi

[2] https://review.openstack.org/#/c/603079
[3] 
https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-stein


On Tue, Aug 28, 2018 at 4:31 PM, Balázs Gibizer 
 wrote:
Thanks for all the responses. I collected them on the nova ptg 
discussion etherpad [1] (L186 at the moment). The nova team will talk 
about deprecation of the legacy interface on Friday on the PTG. If 
you want participate in the discussion but you are not planning to 
sit in the nova room whole day then let me know and I will try to 
ping you over IRC when we about to start the item.


Cheers,
gibi

[1] https://etherpad.openstack.org/p/nova-ptg-stein

On Thu, Aug 9, 2018 at 11:41 AM, Balázs Gibizer 
 wrote:

Dear Nova notification consumers!


The Nova team made progress with the new versioned notification 
interface [1] and it is almost reached feature parity [2] with the 
legacy, unversioned one. So Nova team will discuss on the upcoming 
PTG the deprecation of the legacy interface. There is a list of 
projects (we know of) consuming the legacy interface and we would 
like to know if any of these projects plan to switch over to the 
new interface in the foreseeable future so we can make a well 
informed decision about the deprecation.



* Searchlight [3] - it is in maintenance mode so I guess the answer 
is no

* Designate [4]
* Telemetry [5]
* Mistral [6]
* Blazar [7]
* Watcher [8] - it seems Watcher uses both legacy and versioned nova 
notifications
* Masakari - I'm not sure Masakari depends on nova notifications or 
not


Cheers,
gibi

[1] 
https://docs.openstack.org/nova/latest/reference/notifications.html

[2] http://burndown.peermore.com/nova-notification/

[3] 
https://github.com/openstack/searchlight/blob/master/searchlight/elasticsearch/plugins/nova/notification_handler.py
[4] 
https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py
[5] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml#L2
[6] 
https://github.com/openstack/mistral/blob/master/etc/event_definitions.yml.sample#L2
[7] 
https://github.com/openstack/blazar/blob/5526ed1f9b74d23b5881a5f73b70776ba9732da4/doc/source/user/compute-host-monitor.rst
[8] 
https://github.com/openstack/watcher/blob/master/watcher/decision_engine/model/notification/nova.py#L335






__
OpenStack Development Mailing 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][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possibledeprecation of Nova's legacy notification interface

[Trinh Nguyen]

Hi gibi,

Thank for the info. Searchlight team is working on a patch to support the
versioned Nova. Hopefully, it will be released in Stein-1.

Bests,

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Mon, Sep 17, 2018 at 8:23 PM Balázs Gibizer 
wrote:

> Hi,
>
> On the Stein PTG the nova team agreed to deprecate the legacy,
> unversioned notification interface of nova. We also agreed that we will
> not try to remove the legacy notification sending from the code any
> time soon. So this deprecation means the following:
> * by default configuration nova will only emit versioned notifications,
> but the unversioned notifications still can be turned on in the
> configuration.
> * nova will not maintain the legacy notification code path further, so
> it can break
>
> I pushed the deprecation patch [2] but it will only be merged after the
> remaining versioned notification transformation patches [3] are merged.
>
> Cheers,
> gibi
>
> [2] https://review.openstack.org/#/c/603079
> [3]
>
> https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-stein
>
> On Tue, Aug 28, 2018 at 4:31 PM, Balázs Gibizer
>  wrote:
> > Thanks for all the responses. I collected them on the nova ptg
> > discussion etherpad [1] (L186 at the moment). The nova team will talk
> > about deprecation of the legacy interface on Friday on the PTG. If
> > you want participate in the discussion but you are not planning to
> > sit in the nova room whole day then let me know and I will try to
> > ping you over IRC when we about to start the item.
> >
> > Cheers,
> > gibi
> >
> > [1] https://etherpad.openstack.org/p/nova-ptg-stein
> >
> > On Thu, Aug 9, 2018 at 11:41 AM, Balázs Gibizer
> >  wrote:
> >> Dear Nova notification consumers!
> >>
> >>
> >> The Nova team made progress with the new versioned notification
> >>  interface [1] and it is almost reached feature parity [2] with the
> >>  legacy, unversioned one. So Nova team will discuss on the upcoming
> >>  PTG the deprecation of the legacy interface. There is a list of
> >>  projects (we know of) consuming the legacy interface and we would
> >>  like to know if any of these projects plan to switch over to the
> >> new  interface in the foreseeable future so we can make a well
> >> informed  decision about the deprecation.
> >>
> >>
> >> * Searchlight [3] - it is in maintenance mode so I guess the answer
> >>  is no
> >> * Designate [4]
> >> * Telemetry [5]
> >> * Mistral [6]
> >> * Blazar [7]
> >> * Watcher [8] - it seems Watcher uses both legacy and versioned nova
> >>  notifications
> >> * Masakari - I'm not sure Masakari depends on nova notifications or
> >>  not
> >>
> >> Cheers,
> >> gibi
> >>
> >> [1]
> >>  https://docs.openstack.org/nova/latest/reference/notifications.html
> >> [2] http://burndown.peermore.com/nova-notification/
> >>
> >> [3]
> >>
> https://github.com/openstack/searchlight/blob/master/searchlight/elasticsearch/plugins/nova/notification_handler.py
> >> [4]
> >>
> https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py
> >> [5]
> >>
> https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml#L2
> >> [6]
> >>
> https://github.com/openstack/mistral/blob/master/etc/event_definitions.yml.sample#L2
> >> [7]
> >>
> https://github.com/openstack/blazar/blob/5526ed1f9b74d23b5881a5f73b70776ba9732da4/doc/source/user/compute-host-monitor.rst
> >> [8]
> >>
> https://github.com/openstack/watcher/blob/master/watcher/decision_engine/model/notification/nova.py#L335
> >>
> >>
> >
> >
> >
> __
> > OpenStack Development Mailing 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] [kolla] Committing proprietary plugins to OpenStack

[Eduardo Gonzalez]

Hi Shyam,

We offer methods [0] to allow users add their plugins during build time
through template overrides.
This allows extends dockerfiles with custom content as may be your use case.

Also we offer a method to add an external directory into the buildable list
of Dockerfiles with ``--config-dir /mydockerfiles/``

With this two methods you can provide your users the images or the
mechanism to customize their docker images.

In kolla's repository there is a contrib/ folder [1] for
template-overrides, not tested in CI nor supported by the team. Only
examples of things that may work or not about how to extend dockerfiles for
specific use cases.

As example, a patch under review to add overrides for cisco plugins [2]

Regards

[0]
https://docs.openstack.org/kolla/latest/admin/image-building.html#dockerfile-customisation
[1] https://github.com/openstack/kolla/tree/master/contrib/template-override
[2] https://review.openstack.org/#/c/552119/


El vie., 14 sept. 2018 a las 15:20, Steven Dake (stdake) ()
escribió:

> ​Shyam,
>
>
> Our policy, decided long ago, is that we would work with third party
> components (such as plugins) for nova, cinder, neutron, horizon, etc that
> were proprietary as long as the code that merges into Kolla specifically is
> ASL2.
>
>
> What is your plugin for?  if its for nova, cinder, neutron, horizon, it is
> covered by this policy pretty much wholesale.  If its a different type of
> system, some debate may be warranted by the core team.
>
>
> Cheers
>
> -steve
> --
> *From:* Shyam Biradar 
> *Sent:* Wednesday, September 12, 2018 5:01 AM
> *To:* Andreas Jaeger
> *Cc:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [kolla] Committing proprietary plugins to
> OpenStack
>
> Yes Andreas, whatever deployment scripts we will be pushing it will be
> under apache license.
>
> [image: logo]
> *Shyam Biradar*  * Software Engineer | DevOps*
> M +91 8600266938 | shyam.bira...@trilio.io | trilio.io
>
> On Wed, Sep 12, 2018 at 5:24 PM, Andreas Jaeger  wrote:
>
>> On 2018-09-12 13:21, Shyam Biradar wrote:
>>
>>> Hi,
>>>
>>> We have a proprietary openstack plugin. We want to commit deployment
>>> scripts like containers and heat templates to upstream in tripleo and kolla
>>> project but not actual product code.
>>>
>>> Is it possible? Or How can we handle this case? Any thoughts are welcome.
>>>
>>
>> It's first a legal question - is everything you are pushing under the
>> Apache license as the rest of the project that you push to?
>>
>> And then a policy of kolla project, so let me tag them
>>
>> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nür
>> nberg,
>> Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] bug deputy report week Sep 10 - 12

[Akihiro Motoki]

Hi,

I was the bug deputy for neutron last week.

The last week was really quiet, but all of them are gate failures and
need attentions.

grenade-dvr-multinode job fails
https://bugs.launchpad.net/neutron/+bug/1791989
This continuously happens last week with high failure rate.
http://grafana.openstack.org/d/Hj5IHcSmz/neutron-failure-rate?panelId=20=1

neutron_tempest_plugin: test_floatingip_port_details occasionally fails
https://bugs.launchpad.net/neutron/+bug/1792472

q-dhcp crashes with guru meditation on ironic's grenade
https://bugs.launchpad.net/neutron/+bug/1792925
This was reported this Monday. It continues to occur since at least Sep 10.

Best Regards,
Akihiro Motoki (irc: amotoki)

__
OpenStack Development Mailing 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] [election][tc]Question for candidates about global reachout

[Jeremy Stanley]

On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
[...]
> - What is the problem joining Wechat will solve (keeping in mind the
> language barrier)?

As I understand it, the suggestion is that mere presence of project
leadership in venues where this emerging subset of our community
gathers would provide a strong signal that we support them and care
about their experience with the software.

> - Isn't this problem already solved for other languages with
> existing initiatives like local ambassadors and i18n team? Why
> aren't these relevant?
[...]

It seems like there are at least couple of factors at play here:
first the significant number of users and contributors within
mainland China compared to other regions (analysis suggests there
were nearly as many contributors to the Rocky release from China as
the USA), but second there may be facets of Chinese culture which
make this sort of demonstrative presence a much stronger signal than
it would be in other cultures.

> - Pardon my ignorance here, what is the problem with email? (I
> understand some chat systems might be blocked, I thought emails
> would be fine, and the lowest common denominator).

Someone in the TC room (forgive me, I don't recall who now, maybe
Rico?) asserted that Chinese contributors generally only read the
first message in any given thread (perhaps just looking for possible
announcements?) and that if they _do_ attempt to read through some
of the longer threads they don't participate in them because the
discussion is presumed to be over and decisions final by the time
they "reach the end" (I guess not realizing that it's perfectly fine
to reply to a month-old discussion and try to help alter course on
things if you have an actual concern?).

> I also have technical questions about 'wechat' (like how do you
> use it without a smartphone?) and the relevance of tools we
> currently use, but this will open Pandora's box, and I'd rather
> not spend my energy on closing that box right now :D

Not that I was planning on running it myself, but I did look into
the logistics. Apparently there is at least one free/libre open
source wechat client under active development but you still need to
use a separate mobile device to authenticate your client's
connection to wechat's central communication service. By design, it
appears this is so that you can't avoid reporting your physical
location (it's been suggested this is to comply with government
requirements for tracking citizens participating in potentially
illegal discussions). They also go to lengths to prevent you from
running the required mobile app within an emulator, since that would
provide a possible workaround to avoid being tracked. Further, there
is some history of backdoors getting included in the software, so
you need to use it with the expectation that you're basically
handing over all communications and content for which you use that
mobile device to wechat developers/service operators and, by proxy,
the Chinese government.
-- 
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] [nova] how nova should behave when placement returns consumer generation conflict

[Jay Pipes]

Thanks Giblet,

Will review this afternoon.

Best,
-jay

On 09/17/2018 09:10 AM, Balázs Gibizer wrote:


Hi,

Reworked and rebased the series based on this thread. The series starts 
here https://review.openstack.org/#/c/591597


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


__
OpenStack Development Mailing 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] [election][tc]Question for candidates about global reachout

[Sean McGinnis]

> 
> > I also have technical questions about 'wechat' (like how do you
> > use it without a smartphone?) and the relevance of tools we
> > currently use, but this will open Pandora's box, and I'd rather
> > not spend my energy on closing that box right now :D
> 
> Not that I was planning on running it myself, but I did look into
> the logistics. Apparently there is at least one free/libre open
> source wechat client under active development but you still need to
> use a separate mobile device to authenticate your client's
> connection to wechat's central communication service. By design, it
> appears this is so that you can't avoid reporting your physical
> location (it's been suggested this is to comply with government
> requirements for tracking citizens participating in potentially
> illegal discussions).

This is correct from my experience. There are one or two desktop clients I have
found out there, but there is no way to log in to them other than logging into
your phone app, then using that to scan a QR-code like image in order to
authenticate. As far as I know, there is no way to use Wechat without
installing a smartphone app.


__
OpenStack Development Mailing 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] [election][tc]Question for candidates about global reachout

[Sylvain Bauza]

Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  a écrit :

> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
> [...]
> > - What is the problem joining Wechat will solve (keeping in mind the
> > language barrier)?
>
> As I understand it, the suggestion is that mere presence of project
> leadership in venues where this emerging subset of our community
> gathers would provide a strong signal that we support them and care
> about their experience with the software.
>
> > - Isn't this problem already solved for other languages with
> > existing initiatives like local ambassadors and i18n team? Why
> > aren't these relevant?
> [...]
>
> It seems like there are at least couple of factors at play here:
> first the significant number of users and contributors within
> mainland China compared to other regions (analysis suggests there
> were nearly as many contributors to the Rocky release from China as
> the USA), but second there may be facets of Chinese culture which
> make this sort of demonstrative presence a much stronger signal than
> it would be in other cultures.
>
> > - Pardon my ignorance here, what is the problem with email? (I
> > understand some chat systems might be blocked, I thought emails
> > would be fine, and the lowest common denominator).
>
> Someone in the TC room (forgive me, I don't recall who now, maybe
> Rico?) asserted that Chinese contributors generally only read the
> first message in any given thread (perhaps just looking for possible
> announcements?) and that if they _do_ attempt to read through some
> of the longer threads they don't participate in them because the
> discussion is presumed to be over and decisions final by the time
> they "reach the end" (I guess not realizing that it's perfectly fine
> to reply to a month-old discussion and try to help alter course on
> things if you have an actual concern?).
>
>
While I understand the technical issues that could be due using IRC in
China, I still don't get why opening the gates and saying WeChat being yet
another official channel would prevent our community from fragmenting.

Truly the usage of IRC is certainly questionable, but if we have multiple
ways to discuss, I just doubt we could prevent us to silo ourselves between
our personal usages.
Either we consider the new channels as being only for southbound
communication, or we envisage the possibility, as a community, to migrate
from IRC to elsewhere (I'm particulary not fan of the latter so I would
challenge this but I can understand the reasons)

-Sylvain

> I also have technical questions about 'wechat' (like how do you
> > use it without a smartphone?) and the relevance of tools we
> > currently use, but this will open Pandora's box, and I'd rather
> > not spend my energy on closing that box right now :D
>
> Not that I was planning on running it myself, but I did look into
> the logistics. Apparently there is at least one free/libre open
> source wechat client under active development but you still need to
> use a separate mobile device to authenticate your client's
> connection to wechat's central communication service. By design, it
> appears this is so that you can't avoid reporting your physical
> location (it's been suggested this is to comply with government
> requirements for tracking citizens participating in potentially
> illegal discussions). They also go to lengths to prevent you from
> running the required mobile app within an emulator, since that would
> provide a possible workaround to avoid being tracked. Further, there
> is some history of backdoors getting included in the software, so
> you need to use it with the expectation that you're basically
> handing over all communications and content for which you use that
> mobile device to wechat developers/service operators and, by proxy,
> the Chinese government.
> --
> Jeremy Stanley
> __
> OpenStack Development Mailing 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] About microversion setting to enable nested resource provider

[Jay Pipes]

On 09/16/2018 09:28 PM, Naichuan Sun wrote:

Hi, Sylvain,

In truth I’m worrying about the old root rp which include the vgpu 
inventory. There is no field in the inventory which can display which 
GPU/GPUG it belong to, right? Anyway,  will discuss it after you come back.


As Sylvain mentions below, you will need to have some mechanism in the 
XenAPI virt driver which creates child resource providers under the 
existing root provider (which is the compute node resource provider). 
You will need to have the virt driver persist the mapping between your 
internal physical GPU group name and the UUID of the resource provider 
record that the virt driver creates for that PGPU group.


So, for example, let's say you have two PGPU groups on the host. They 
are named PGPU_A and PGPU_B. The XenAPI virt driver will need to ask the 
ProviderTree object it receives in the update_provider_tree() virt 
driver method whether there is a resource provider named "PGPU_A" in the 
tree. If not, the virt driver needs to create a new child resource 
provider with the name "PGPU_A" with a parent provider pointing to the 
root compute node provider. The ProviderTree.new_child() method is used 
to create new child providers:


https://github.com/openstack/nova/blob/82270cc261f6c1d9d2cc386f1fb445dd66023f75/nova/compute/provider_tree.py#L411

Hope that makes sense,
-jay


Thank very much.

BR.

Naichuan Sun

*From:*Sylvain Bauza [mailto:sba...@redhat.com]
*Sent:* Friday, September 14, 2018 9:34 PM
*To:* OpenStack Development Mailing List (not for usage questions) 

*Subject:* Re: [openstack-dev] About microversion setting to enable 
nested resource provider


Le jeu. 13 sept. 2018 à 19:29, Naichuan Sun > a écrit :


Hi, Sylvain,

Thank you very much for the information. It is pity that I can’t
attend the meeting.

I have a concern about reshaper in multi-type vgpu support.

In the old vgpu support, we only have one vgpu inventory in root
resource provider, which means we only support one vgpu type. When
do reshape, placement will send allocations(which include just one
vgpu resource allocation information) to the driver, if the host
have more than one pgpu/pgpug(which support different vgpu type),
how do we know which pgpu/pgpug own the allocation information? Do
we need to communicate with hypervisor the confirm that?

The reshape will actually move the existing allocations for a VGPU 
resource class to the inventory for this class that is on the child 
resource provider now with the reshape.


Since we agreed on keeping consistent naming, there is no need to guess 
which is which. That said, you raise a point that was discussed during 
the PTG and we all agreed there was an upgrade impact as multiple vGPUs 
shouldn't be allowed until the reshape is done.


Accordingly, see my spec I reproposed for Stein which describes the 
upgrade impact https://review.openstack.org/#/c/602474/


Since I'm at the PTG, we have huge time difference between you and me, 
but we can discuss on that point next week when I'm back (my mornings 
match then your afternoons)


-Sylvain

Thank you very much.

BR.

Naichuan Sun

*From:*Sylvain Bauza [mailto:sba...@redhat.com
]
*Sent:* Thursday, September 13, 2018 11:47 PM
*To:* OpenStack Development Mailing List (not for usage questions)
mailto:openstack-dev@lists.openstack.org>>
*Subject:* Re: [openstack-dev] About microversion setting to enable
nested resource provider

Hey Naichuan,

FWIW, we discussed on the missing pieces for nested resource
providers. See the (currently-in-use) etherpad
https://etherpad.openstack.org/p/nova-ptg-stein and lookup for
"closing the gap on nested resource providers" (L144 while I speak)

The fact that we are not able to schedule yet is a critical piece
that we said we're going to work on it as soon as we can.

-Sylvain

On Thu, Sep 13, 2018 at 9:14 AM, Eric Fried mailto:openst...@fried.cc>> wrote:

There's a patch series in progress for this:

https://review.openstack.org/#/q/topic:use-nested-allocation-candidates

It needs some TLC. I'm sure gibi and tetsuro would welcome some
help...

efried


On 09/13/2018 08:31 AM, Naichuan Sun wrote:
 > Thank you very much, Jay.
 > Is there somewhere I could set microversion(some configure
file?), Or just modify the source code to set it?
 >
 > BR.
 > Naichuan Sun
 >
 > -Original Message-
 > From: Jay Pipes [mailto:jaypi...@gmail.com
]
 > Sent: Thursday, September 13, 2018 9:19 PM
 > To: Naichuan Sun mailto:naichuan@citrix.com>>; OpenStack Development Mailing
List (not for usage questions)
mailto:openstack-dev@lists.openstack.org>>
 > Cc: melanie witt 

Re: [openstack-dev] [puppet] [placement]

[Emilien Macchi]

On Mon, Sep 17, 2018 at 5:29 AM Lee Yarwood  wrote:

> FWIW I've also started work on the RDO packaging front [1] and would be
> happy to help with this puppet extraction.
>

Good to know, thanks.
Once we have the repo in place, here is a plan proposal:

* Populate the repo with cookiecutter & adjust to Placement service
* cp code from nova::placement (and nova::wsgi::apache_placement)
* package placement and puppet-placement in RDO
* start testing puppet-placement in puppet-openstack-integration
* switch tripleo-common / THT to deploy placement in nova_placement
container
* switch tripleo to use puppet-placement (in THT)
* probably rename nova_placement container/service into placement or
something generic

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

Re: [openstack-dev] About microversion setting to enable nested resource provider

[Sylvain Bauza]

On Mon, Sep 17, 2018 at 6:43 AM, Jay Pipes  wrote:

> On 09/16/2018 09:28 PM, Naichuan Sun wrote:
>
>> Hi, Sylvain,
>>
>> In truth I’m worrying about the old root rp which include the vgpu
>> inventory. There is no field in the inventory which can display which
>> GPU/GPUG it belong to, right? Anyway,  will discuss it after you come back.
>>
>
> As Sylvain mentions below, you will need to have some mechanism in the
> XenAPI virt driver which creates child resource providers under the
> existing root provider (which is the compute node resource provider). You
> will need to have the virt driver persist the mapping between your internal
> physical GPU group name and the UUID of the resource provider record that
> the virt driver creates for that PGPU group.
>

AFAICT, we even don't need to persist the mapping. As we only support one
GPU type (or group for Xen) in Rocky, you just have to know what was the
original type for Stein and then just look at the related resource provider;
That's why i wrote an upgrade impact section in my multiple-types spec (see
below) saying that in Stein, you need to make sure you only accept one type
until the reshape is fully done.

-Sylvain


> So, for example, let's say you have two PGPU groups on the host. They are
> named PGPU_A and PGPU_B. The XenAPI virt driver will need to ask the
> ProviderTree object it receives in the update_provider_tree() virt driver
> method whether there is a resource provider named "PGPU_A" in the tree. If
> not, the virt driver needs to create a new child resource provider with the
> name "PGPU_A" with a parent provider pointing to the root compute node
> provider. The ProviderTree.new_child() method is used to create new child
> providers:
>
> https://github.com/openstack/nova/blob/82270cc261f6c1d9d2cc3
> 86f1fb445dd66023f75/nova/compute/provider_tree.py#L411
>
> Hope that makes sense,
> -jay
>
> Thank very much.
>>
>> BR.
>>
>> Naichuan Sun
>>
>> *From:*Sylvain Bauza [mailto:sba...@redhat.com]
>> *Sent:* Friday, September 14, 2018 9:34 PM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] About microversion setting to enable
>> nested resource provider
>>
>> Le jeu. 13 sept. 2018 à 19:29, Naichuan Sun > > a écrit :
>>
>> Hi, Sylvain,
>>
>> Thank you very much for the information. It is pity that I can’t
>> attend the meeting.
>>
>> I have a concern about reshaper in multi-type vgpu support.
>>
>> In the old vgpu support, we only have one vgpu inventory in root
>> resource provider, which means we only support one vgpu type. When
>> do reshape, placement will send allocations(which include just one
>> vgpu resource allocation information) to the driver, if the host
>> have more than one pgpu/pgpug(which support different vgpu type),
>> how do we know which pgpu/pgpug own the allocation information? Do
>> we need to communicate with hypervisor the confirm that?
>>
>> The reshape will actually move the existing allocations for a VGPU
>> resource class to the inventory for this class that is on the child
>> resource provider now with the reshape.
>>
>> Since we agreed on keeping consistent naming, there is no need to guess
>> which is which. That said, you raise a point that was discussed during the
>> PTG and we all agreed there was an upgrade impact as multiple vGPUs
>> shouldn't be allowed until the reshape is done.
>>
>> Accordingly, see my spec I reproposed for Stein which describes the
>> upgrade impact https://review.openstack.org/#/c/602474/
>>
>> Since I'm at the PTG, we have huge time difference between you and me,
>> but we can discuss on that point next week when I'm back (my mornings match
>> then your afternoons)
>>
>> -Sylvain
>>
>> Thank you very much.
>>
>> BR.
>>
>> Naichuan Sun
>>
>> *From:*Sylvain Bauza [mailto:sba...@redhat.com
>> ]
>> *Sent:* Thursday, September 13, 2018 11:47 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> > >
>> *Subject:* Re: [openstack-dev] About microversion setting to enable
>> nested resource provider
>>
>> Hey Naichuan,
>>
>> FWIW, we discussed on the missing pieces for nested resource
>> providers. See the (currently-in-use) etherpad
>> https://etherpad.openstack.org/p/nova-ptg-stein and lookup for
>> "closing the gap on nested resource providers" (L144 while I speak)
>>
>> The fact that we are not able to schedule yet is a critical piece
>> that we said we're going to work on it as soon as we can.
>>
>> -Sylvain
>>
>> On Thu, Sep 13, 2018 at 9:14 AM, Eric Fried > > wrote:
>>
>> There's a patch series in progress for this:
>>
>> https://review.openstack.org/#/q/topic:use-nested-allocation
>> -candidates
>>
>>

Re: [openstack-dev] [nova] how nova should behave when placement returns consumer generation conflict

[Balázs Gibizer]

Hi,

Reworked and rebased the series based on this thread. The series starts 
here https://review.openstack.org/#/c/591597


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