Re: [openstack-dev] [All] [Elections] Rocky TC Election Results

[Gilles Dubreuil]

Bravo, well done!

On 01/05/18 14:14, Zhipeng Huang wrote:

Congratulations to the newly elected TC members !

On Tue, May 1, 2018 at 2:17 AM, Amy > wrote:


Congrats to all who were elected!

Amy (spotz)

Sent from my iPhone

On Apr 30, 2018, at 7:02 PM, Kendall Nelson > wrote:


Hello Everyone :)

Please join me in congratulating the 7 newly elected members of
the Technical Committee (TC)!

  * Thierry Carrez (ttx)]
  * Chris Dent (cdent)
  * Sean McGinnis (smcginnis)
  * Davanum Srinivas (dims)
  * Zane Bitter (zaneb)
  * Graham Hayes (mugsie)
  * Mohammed Naser (mnaser)


Full results:
https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_98430d99fc2ed59d



Election process details and results are also available here:
https://governance.openstack.org/election/


Thank you to all of the candidates, having a good group of
candidates helps engage the community in our democratic process.

Thank you to all who voted and who encouraged others to vote. We
need to ensure your voices are heard!

Thank you for another great round.

-Kendall Nelson (diablo_rojo)

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

__
OpenStack Development Mailing 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





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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

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

Re: [openstack-dev] [All] [Elections] Rocky TC Election Results

[Zhipeng Huang]

Congratulations to the newly elected TC members !

On Tue, May 1, 2018 at 2:17 AM, Amy  wrote:

> Congrats to all who were elected!
>
> Amy (spotz)
>
> Sent from my iPhone
>
> On Apr 30, 2018, at 7:02 PM, Kendall Nelson  wrote:
>
> Hello Everyone :)
>
> Please join me in congratulating the 7 newly elected members of the
> Technical Committee (TC)!
>
>
>- Thierry Carrez (ttx)]
>- Chris Dent (cdent)
>- Sean McGinnis (smcginnis)
>- Davanum Srinivas (dims)
>- Zane Bitter (zaneb)
>- Graham Hayes (mugsie)
>- Mohammed Naser (mnaser)
>
>
> Full results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_
> 98430d99fc2ed59d
>
> Election process details and results are also available here:
> https://governance.openstack.org/election/
>
> Thank you to all of the candidates, having a good group of candidates
> helps engage the community in our democratic process.
>
> Thank you to all who voted and who encouraged others to vote. We need to
> ensure your voices are heard!
>
> Thank you for another great round.
>
> -Kendall Nelson (diablo_rojo)
>
> [1] https://review.openstack.org/#/c/565368/
> 
>
> __
> OpenStack Development Mailing 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
>
>


-- 
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] [masakari] Masakari Project Meeting time

[Kwan, Louie]

It seems most of the team members are on vacation this week.

By the way,  03:00 UTC is fine as well.

-Original Message-
From: Bhor, Dinesh [mailto:dinesh.b...@nttdata.com] 
Sent: Wednesday, April 25, 2018 9:09 PM
To: Kwan, Louie
Cc: Sampath Priyankara (samP); openstack-dev@lists.openstack.org; Young, Ken
Subject: Re: [openstack-dev] [masakari] Masakari Project Meeting time 

+1
This time may not fit for attendees who work in IST time zone as it will 07.30 
AM in the morning.

Thanks,
Dinesh

> On Apr 26, 2018, at 12:06 AM, Kwan, Louie  wrote:
>
> Sampath, Dinesh and others,
>
> It was a good meeting last week.
>
> As briefly discussed with Sampath, I would like to check whether we can 
> adjust the meeting time.
>
> We are at EST time zone, the meeting is right on our midnight time, 12:00 am.
>
> It will be nice if the meeting can be started ~2 hours earlier e.g. Could it 
> be  started at 02:00: UTC instead?
>
> Thanks.
> Louie
>
>

Disclaimer: This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged,confidential, 
and proprietary data. If you are not the intended recipient,please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding.

__
OpenStack Development Mailing 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] Overriding project-templates in Zuul

[Joshua Hesketh]

On Tue, May 1, 2018 at 1:58 AM, James E. Blair  wrote:

> Hi,
>
> If you've had difficulty overriding jobs in project-templates, please
> read and provide feedback on this proposed change.
>
> We tried to make the Zuul v3 configuration language as intuitive as
> possible, and incorporated a lot that we learned from our years running
> Zuul v2.  One thing that we didn't anticipate was how folks would end up
> wanting to use a job in both project-templates *and* local project
> stanzas.
>
> Essentially, we had assumed that if you wanted to control how a job was
> run, you would add it to a project stanza directly rather that use a
> project-template.  It's easy to do so if you use one or the other.
> However, it turns out there are lots of good reasons to use both.  For
> example, in a project-template we may want to establish a recommended
> way to run a job, or that a job should always be run with a set of
> related jobs.  Yet a project may still want to indicate that job should
> only run on certain changes in that specific repo.
>
> To be very specific -- a very commonly expressed frustration is that a
> project can't specify a "files" or "irrelevant-files" matcher to
> override a job that appears in a project-template.
>
> Reconciling those is difficult, largely because once Zuul decides to run
> a job (for example, by a declaration in a project-template) it is
> impossible to dissuade it from running that job by adding any extra
> configuration to a project.  We need to tread carefully when fixing
> this, because quite a number of related concepts could be affected.  For
> instance, we need to preserve branch independence (a change to stop
> running a job in one branch shouldn't affect others).  And we need to
> preserve the ability for job variants to layer on to each other (a
> project-local variant should still be able to alter a variant in a
> project-template).
>
> I propose that we remedy this by making a small change to how Zuul
> determines that a job should run:
>
> When a job appears multiple times on a project (for instance if it
> appears in a project-template and also on the project itself), all of
> the project-local variants which match the item's branch must also match
> the item in order for the job to run.  In other words, if a job appears
> in a project-template used by a project and on the project, then both
> must match.
>

I might be misunderstanding at which point a job is chosen to be ran and
therefore when it's too late to dissuade it. However, if possible, would it
make more sense for the project-local copy of a job to overwrite the
supplied files and irrelevant-files? This would allow a project to run a
job when it otherwise doesn't match.

What happens when something is in both files and irrelevant-files? If the
project-template is trying to say A is in 'files', but the project-local
says A is in 'irrelevant-files', should that overwrite it?

Cheers,
Josh



>
> This effectively causes the "files" and "irrelevant-files" attributes on
> all of the project-local job definitions matching a given branch to be
> combined.  The combination of multiple files matchers behaves as a
> union, and irrelevant-files matchers as an intersection.
>
>     ===  ===
> Matcher   Template  Project  Result
>     ===  ===
> files ABBC   ABC
> irrelevant-files  ABBC   B
>     ===  ===
>
> I believe this will address the shortcoming identified above, but before
> we get too far in implementing it, I'd like to ask folks to take a
> moment and evaluate whether it will address the issues you've seen, or
> if you foresee any problems which I haven't anticipated.
>
> Thanks,
>
> Jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 01/05/18 11:31, Flint WALRUS wrote:

Yes, that’s was indeed the sens of my point.


I was just enforcing it, no worries! ;)



Openstack have to provide both endpoints type for a while for backward 
compatibility in order to smooth the transition.


For instance, that would be a good idea to contact postman devteam 
once GraphQL will start to be integrated as it will allow a lot of ops 
to keep their day to day tools by just having to convert their 
existing collections of handful requests.


Shouldn't we have a common consensus before any project start pushing 
its own GraphQL wheel?


Also I wonder how GraphQL could open new architecture avenues for OpenStack.
For example, would that make sense to also have a GraphQL broker linking 
OpenStack services?





Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil > a écrit :




On 30/04/18 20:16, Flint WALRUS wrote:

I would very much second that question! Indeed it have been one
of my own wondering since many times.

Of course GraphQL is not intended to replace REST as is and have
to live in parallel 


Effectively a standard initial architecture is to have GraphQL
sitting aside (in parallel) and wrapping REST and along the way
develop GrapgQL Schema.

It's seems too early to tell but GraphQL being the next step in
API evolution it might ultimately replace REST.



but it would likely and highly accelerate all requests within
heavily loaded environments


+1



.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil
> a écrit :

Hi,

Remember Boston's Summit presentation [1] about GraphQL [2]
and how it
addresses REST limitations.
I wonder if any project has been thinking about using
GraphQL. I haven't
find any mention or pointers about it.

GraphQL takes a complete different approach compared to REST.
So we can
finally forget about REST API Description languages
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the
hypermedia
approach which doesn't describe how to use it).

So, once passed the point where 'REST vs GraphQL' is like
comparing SQL
and no-SQL DBMS and therefore have different applications,
there are no
doubt the complexity of most OpenStack projects are good
candidates for
GraphQL.

Besides topics such as efficiency, decoupling, no version
management
need there many other powerful features such as API Schema
out of the
box and better automation down that track.

It looks like the dream of a conduit between API services and
consumers
might have finally come true so we could move-on an worry
about other
things.

So has anyone already starting looking into it?

[1]

https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
[2] http://graphql.org




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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Gilles Dubreuil

Senior Software Engineer - Red Hat - Openstack DFG Integration
Email:gil...@redhat.com 
GitHub/IRC: gildub
Mobile: +61 400 894 219



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing 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] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 01/05/18 07:21, Matt Riedemann wrote:

On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
Remember Boston's Summit presentation [1] about GraphQL [2] and how 
it addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I 
haven't find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we 
can finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing 
SQL and no-SQL DBMS and therefore have different applications, there 
are no doubt the complexity of most OpenStack projects are good 
candidates for GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and 
consumers might have finally come true so we could move-on an worry 
about other things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql 


[2] http://graphql.org


Not to speak for him, but Sean Dague had a blog post about REST API 
microversions in OpenStack and there is a Q bit at the bottom about 
GraphQL replacing the need for microversions:


https://dague.net/2017/12/11/rest-api-microversions/

Since I don't expect Sean to magically appear to reply to this thread, 
I thought I'd pass this along.




Thanks Matt for the link.

During Denver's PTG we effectively discovered consumers tend to use 3rd 
party SDK and we also discovered that, ironically, nobody - besides Sean 
;) - has the bandwidth to work full time on SDK either. That was and 
still is the driver for more automation and therefore for having 
projects to produce an API Schema.


Once aspect is about GraphQL being a descriptive language. It allow to 
decouple entirely consumers from producers. So instead of SDK, consumers 
rely on GraphQL client library (which are standardized [1]). The focus 
becomes the data and not how to transfer the data.
Effectively, services make their data available through a Schema and 
clients request a tree of data against it. Sure, at the end of the day, 
it's still a HTTP conversation taking place and returning a JSON 
structure (when not up/down loading a file or so). The big difference 
(among other things) is one and only one transaction is used.


The second aspect is about automation which can take place because the 
Schema is provided up-front, it's the Graph part.


In the Q, Sean said SDK "build their object models", yes that's true 
with GraphQL we have "fat clients" but as we've also seen the SDK is 
replaced with a GraphQL client., cutting the "man in the middle" off!


As per the rest of the Answer, it seems to me there are other aspects to 
be looked at it from different angles.


Cheers

[1] http://graphql.org/code/



__
OpenStack Development Mailing 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] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

Yes, that’s was indeed the sens of my point.

Openstack have to provide both endpoints type for a while for backward
compatibility in order to smooth the transition.

For instance, that would be a good idea to contact postman devteam once
GraphQL will start to be integrated as it will allow a lot of ops to keep
their day to day tools by just having to convert their existing collections
of handful requests.

Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil  a écrit :

>
>
> On 30/04/18 20:16, Flint WALRUS wrote:
>
> I would very much second that question! Indeed it have been one of my own
> wondering since many times.
>
> Of course GraphQL is not intended to replace REST as is and have to live
> in parallel
>
>
> Effectively a standard initial architecture is to have GraphQL sitting
> aside (in parallel) and wrapping REST and along the way develop GrapgQL
> Schema.
>
> It's seems too early to tell but GraphQL being the next step in API
> evolution it might ultimately replace REST.
>
>
> but it would likely and highly accelerate all requests within heavily
> loaded environments
>
>
> +1
>
>
> .
>
> So +1 for this question.
> Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
> écrit :
>
>> Hi,
>>
>> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
>> addresses REST limitations.
>> I wonder if any project has been thinking about using GraphQL. I haven't
>> find any mention or pointers about it.
>>
>> GraphQL takes a complete different approach compared to REST. So we can
>> finally forget about REST API Description languages
>> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
>> approach which doesn't describe how to use it).
>>
>> So, once passed the point where 'REST vs GraphQL' is like comparing SQL
>> and no-SQL DBMS and therefore have different applications, there are no
>> doubt the complexity of most OpenStack projects are good candidates for
>> GraphQL.
>>
>> Besides topics such as efficiency, decoupling, no version management
>> need there many other powerful features such as API Schema out of the
>> box and better automation down that track.
>>
>> It looks like the dream of a conduit between API services and consumers
>> might have finally come true so we could move-on an worry about other
>> things.
>>
>> So has anyone already starting looking into it?
>>
>> [1]
>>
>> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
>> [2] http://graphql.org
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> --
> Gilles Dubreuil
> Senior Software Engineer - Red Hat - Openstack DFG Integration
> Email: gil...@redhat.com
> GitHub/IRC: gildub
> Mobile: +61 400 894 219
>
>
>
__
OpenStack Development Mailing 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] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 30/04/18 20:16, Flint WALRUS wrote:
I would very much second that question! Indeed it have been one of my 
own wondering since many times.


Of course GraphQL is not intended to replace REST as is and have to 
live in parallel 


Effectively a standard initial architecture is to have GraphQL sitting 
aside (in parallel) and wrapping REST and along the way develop GrapgQL 
Schema.


It's seems too early to tell but GraphQL being the next step in API 
evolution it might ultimately replace REST.


but it would likely and highly accelerate all requests within heavily 
loaded environments


+1


.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil > a écrit :


Hi,

Remember Boston's Summit presentation [1] about GraphQL [2] and
how it
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I
haven't
find any mention or pointers about it.

GraphQL takes a complete different approach compared to REST. So
we can
finally forget about REST API Description languages
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
approach which doesn't describe how to use it).

So, once passed the point where 'REST vs GraphQL' is like
comparing SQL
and no-SQL DBMS and therefore have different applications, there
are no
doubt the complexity of most OpenStack projects are good
candidates for
GraphQL.

Besides topics such as efficiency, decoupling, no version management
need there many other powerful features such as API Schema out of the
box and better automation down that track.

It looks like the dream of a conduit between API services and
consumers
might have finally come true so we could move-on an worry about other
things.

So has anyone already starting looking into it?

[1]

https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
[2] http://graphql.org



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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

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

Re: [openstack-dev] [All] [Elections] Rocky TC Election Results

[Amy]

Congrats to all who were elected!

Amy (spotz)

Sent from my iPhone

> On Apr 30, 2018, at 7:02 PM, Kendall Nelson  wrote:
> 
> Hello Everyone :) 
> 
> Please join me in congratulating the 7 newly elected members of the Technical 
> Committee (TC)!
> 
> Thierry Carrez (ttx)]
> Chris Dent (cdent)
> Sean McGinnis (smcginnis) 
> Davanum Srinivas (dims)
> Zane Bitter (zaneb) 
> Graham Hayes (mugsie)
> Mohammed Naser (mnaser)
> 
> Full results: 
> https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_98430d99fc2ed59d  
> 
> Election process details and results are also available here: 
> https://governance.openstack.org/election/ 
> 
> Thank you to all of the candidates, having a good group of candidates helps 
> engage the community in our democratic process.
> 
> Thank you to all who voted and who encouraged others to vote. We need to 
> ensure your voices are heard!
> 
> Thank you for another great round.
> 
> -Kendall Nelson (diablo_rojo)
> 
> [1] https://review.openstack.org/#/c/565368/
> __
> OpenStack Development Mailing 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] [All] [Elections] Rocky TC Election Results

[Kendall Nelson]

Hello Everyone :)

Please join me in congratulating the 7 newly elected members of the
Technical Committee (TC)!


   - Thierry Carrez (ttx)]
   - Chris Dent (cdent)
   - Sean McGinnis (smcginnis)
   - Davanum Srinivas (dims)
   - Zane Bitter (zaneb)
   - Graham Hayes (mugsie)
   - Mohammed Naser (mnaser)


Full results:
https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_98430d99fc2ed59d

Election process details and results are also available here:
https://governance.openstack.org/election/

Thank you to all of the candidates, having a good group of candidates helps
engage the community in our democratic process.

Thank you to all who voted and who encouraged others to vote. We need to
ensure your voices are heard!

Thank you for another great round.

-Kendall Nelson (diablo_rojo)

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

__
OpenStack Development Mailing 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] Overriding project-templates in Zuul

[Emilien Macchi]

On Mon, Apr 30, 2018 at 8:58 AM, James E. Blair  wrote:
[...]

>     ===  ===
> Matcher   Template  Project  Result
>     ===  ===
> files ABBC   ABC
> irrelevant-files  ABBC   B
>     ===  ===
>
> I believe this will address the shortcoming identified above, but before
> we get too far in implementing it, I'd like to ask folks to take a
> moment and evaluate whether it will address the issues you've seen, or
> if you foresee any problems which I haven't anticipated.
>

It'll address a need we have in TripleO where we have complex file rules
and heavily rely on templates.
The matrix proposal looks good to me and will allow us to simplify a bit
our templates.

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

[openstack-dev] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)


Weekly priorities
-
- Bios interface support
- BIOS Settings: Add BIOSInterface : https://review.openstack.org/507793
- BIOS Settings: Add BIOS caching: https://review.openstack.org/512200
- Add Node BIOS support - REST API: https://review.openstack.org/512579
- Hardware type cleanup
- https://review.openstack.org/#/q/status:open+topic:hw-types
- https://review.openstack.org/#/q/topic:api-jobs to unblock api CI test 
cleanup
- Python-ironicclient things
- Accept a version on set_provision_state
- https://review.openstack.org/#/c/557850/
- Wire in header microversion into client negotiation
- https://review.openstack.org/#/c/558027/
- Remaining Rescue patches
- https://review.openstack.org/#/c/528699/ - Tempest tests with nova (This 
can land after nova work is done. But, it should be ready to get the nova patch 
reviewed.) (Rebased by TheJulia 20180416)
- Management interface boot_mode change
- https://review.openstack.org/#/c/526773/
- Bug Fixes
- Any this week?
- House Keeping:

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
None
irmc:
None - a few works are work in progress
oneview:
None at this time - No subteam at present.
xclarity:
Fix XClarity parameters discrepancy: 
https://review.openstack.org/#/c/561405/

Bugs (dtantsur, vdrok, TheJulia)

- (TheJulia) Ironic has moved to Storyboard. Dtantsur has indicated he will 
update the tool that generates these stats.
- initial version (much fewer features): 
https://github.com/dtantsur/ironic-bug-report
- Stats (new version, no diff this time):
- Total bugs: 283
-  of them untriaged: 256
- Total RFEs: 238
-  of them untriaged: 27
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/ MERGED - Backport to stable/queens 
proposed

Priorities
==

Deploy Steps (rloo, mgoddard)
-
- spec for deployment steps framework has merged: 
https://review.openstack.org/#/c/549493/
- waiting for code from rloo, no timeframe yet

BIOS config framework(zshi, yolanda, mgoddard, hshiina)
---
- status as of 30 April 2018:
- Spec: 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/generic-bios-config.html
- List of ordered patches:
- BIOS Settings: Add DB model: https://review.openstack.org/511162
agreed that column type of bios setting value is string, blocked by the gate 
failure MERGED
- Add bios_interface db field https://review.openstack.org/528609   
   many +2s, can be merged soon after the patch above is merged MERGED
- BIOS Settings: Add DB API: https://review.openstack.org/511402
1x +1, actively reviewed and updated MERGED
- BIOS Settings: Add RPC object https://review.openstack.org/511714 
MERGED
- Add BIOSInterface to base driver class 
https://review.openstack.org/507793
- BIOS Settings: Add BIOS caching: https://review.openstack.org/512200
- Add Node BIOS support - REST API: https://review.openstack.org/512579

Conductor Location Awareness (jroll, dtantsur)
--
- story: https://storyboard.openstack.org/#!/story/2001795
- (April 30) spec has good feedback, one issue to resolve, should be able to 
land this week
- https://review.openstack.org/#/c/559420/ needs update

Reference architecture guide (dtantsur, jroll)
--
- story: https://storyboard.openstack.org/#!/story/2001745
- status as of 30 April 2018:
- Dublin PTG consensus was to start with small architectural building 
blocks.
- list of cases from the Denver PTG - see in the story
- nothing new this week

Graphical console interface (mkrai, anup-d-navare, TheJulia)

- status as of 30 Apr 2018:
- No update - Have not had a chance to get to this yet this cycle. Goal for 
the cycle was a plan, not 

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

[Doug Hellmann]

Excerpts from Alex Schultz's message of 2018-04-30 15:43:16 -0600:
> On Mon, Apr 30, 2018 at 3:16 PM, Ben Nemec  wrote:
> > Resending from an address that is subscribed to the list.  Apologies to
> > those of you who get this twice.
> >
> > On 04/30/2018 10:06 AM, Doug Hellmann wrote:
> >>
> >> It would be useful to have more input from PTLs on this issue, so I'm
> >> CCing all of them to get their attention.
> >>
> >> Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
> >>>
> >>> It's time to talk about the next steps in our migration from python
> >>> 2 to python 3.
> >>>
> >>> Up to this point we have mostly focused on reaching a state where
> >>> we support both versions of the language. We are not quite there
> >>> with all projects, as you can see by reviewing the test coverage
> >>> status information at
> >>>
> >>> https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects
> >>>
> >>> Still, we need to press on to the next phase of the migration, which
> >>> I have been calling "Python 3 first". This is where we use python
> >>> 3 as the default, for everything, and set up the exceptions we need
> >>> for anything that still requires python 2.
> >>>
> >>> To reach that stage, we need to:
> >>>
> >>> 1. Change the documentation and release notes jobs to use python 3.
> >>> (The Oslo team recently completed this, and found that we did
> >>> need to make a few small code changes to get them to work.)
> >>> 2. Change (or duplicate) all functional test jobs to run under
> >>> python 3.
> >>> 3. Change the packaging jobs to use python 3.
> >>> 4. Update devstack to use 3 by default and require setting a flag to
> >>> use 2. (This may trigger other job changes.)
> >>>
> >>> At that point, all of our deliverables will be produced using python
> >>> 3, and we can be relatively confident that if we no longer had
> >>> access to python 2 we could still continue operating. We could also
> >>> start updating deployment tools to use either python 3 or 2, so
> >>> that users could actually deploy using the python 3 versions of
> >>> services.
> >>>
> >>> Somewhere in that time frame our third-party CI systems will need
> >>> to ensure they have python 3 support as well.
> >>>
> >>> After the "Python 3 first" phase is completed we should release
> >>> one series using the packages built with python 3. Perhaps Stein?
> >>> Or is that too ambitious?
> >>>
> >>> Next, we will be ready to address the prerequisites for "Python 3
> >>> only," which will allow us to drop Python 2 support.
> >>>
> >>> We need to wait to drop python 2 support as a community, rather
> >>> than going one project at a time, to avoid doubling the work of
> >>> downstream consumers such as distros and independent deployers. We
> >>> don't want them to have to package all (or even a large number) of
> >>> the dependencies of OpenStack twice because they have to install
> >>> some services running under python 2 and others under 3. Ideally
> >>> they would be able to upgrade all of the services on a node together
> >>> as part of their transition to the new version, without ending up
> >>> with a python 2 version of a dependency along side a python 3 version
> >>> of the same package.
> >>>
> >>> The remaining items could be fixed earlier, but this is the point
> >>> at which they would block us:
> >>>
> >>> 1. Fix oslo.service functional tests -- the Oslo team needs help
> >>> maintaining this library. Alternatively, we could move all
> >>> services to use cotyledon (https://pypi.org/project/cotyledon/).
> >
> >
> > For everyone's awareness, we discussed this in the Oslo meeting today and
> > our first step is to see how many, if any, services are actually relying on
> > the oslo.service functionality that doesn't work in Python 3 today.  From
> > there we will come up with a plan for how to move forward.
> >
> > https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.
> >
> >>>
> >>> 2. Finish the unit test and functional test ports so that all of
> >>> our tests can run under python 3 (this implies that the services
> >>> all run under python 3, so there is no more porting to do).
> >
> >
> > And integration tests?  I know for the initial python 3 goal we said just
> > unit and functional, but it seems to me that we can't claim full python 3
> > compatibility until we can run our tempest jobs against python 3-based
> > OpenStack.
> >
> >>>
> >>> Finally, after we have *all* tests running on python 3, we can
> >>> safely drop python 2.
> >>>
> >>> We have previously discussed the end of the T cycle as the point
> >>> at which we would have all of those tests running, and if that holds
> >>> true we could reasonably drop python 2 during the beginning of the
> >>> U cycle, in late 2019 and before the 2020 cut-off point when upstream
> >>> python 2 support will be dropped.
> >>>
> >>> I need some info from the deployment tool teams to understand 

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

[Doug Hellmann]

Excerpts from Ben Nemec's message of 2018-04-30 16:16:35 -0500:
> Resending from an address that is subscribed to the list.  Apologies to 
> those of you who get this twice.
> 
> On 04/30/2018 10:06 AM, Doug Hellmann wrote:
> > It would be useful to have more input from PTLs on this issue, so I'm
> > CCing all of them to get their attention.
> > 
> > Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
> >> It's time to talk about the next steps in our migration from python
> >> 2 to python 3.
> >>
> >> Up to this point we have mostly focused on reaching a state where
> >> we support both versions of the language. We are not quite there
> >> with all projects, as you can see by reviewing the test coverage
> >> status information at
> >> https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects
> >>
> >> Still, we need to press on to the next phase of the migration, which
> >> I have been calling "Python 3 first". This is where we use python
> >> 3 as the default, for everything, and set up the exceptions we need
> >> for anything that still requires python 2.
> >>
> >> To reach that stage, we need to:
> >>
> >> 1. Change the documentation and release notes jobs to use python 3.
> >> (The Oslo team recently completed this, and found that we did
> >> need to make a few small code changes to get them to work.)
> >> 2. Change (or duplicate) all functional test jobs to run under
> >> python 3.
> >> 3. Change the packaging jobs to use python 3.
> >> 4. Update devstack to use 3 by default and require setting a flag to
> >> use 2. (This may trigger other job changes.)
> >>
> >> At that point, all of our deliverables will be produced using python
> >> 3, and we can be relatively confident that if we no longer had
> >> access to python 2 we could still continue operating. We could also
> >> start updating deployment tools to use either python 3 or 2, so
> >> that users could actually deploy using the python 3 versions of
> >> services.
> >>
> >> Somewhere in that time frame our third-party CI systems will need
> >> to ensure they have python 3 support as well.
> >>
> >> After the "Python 3 first" phase is completed we should release
> >> one series using the packages built with python 3. Perhaps Stein?
> >> Or is that too ambitious?
> >>
> >> Next, we will be ready to address the prerequisites for "Python 3
> >> only," which will allow us to drop Python 2 support.
> >>
> >> We need to wait to drop python 2 support as a community, rather
> >> than going one project at a time, to avoid doubling the work of
> >> downstream consumers such as distros and independent deployers. We
> >> don't want them to have to package all (or even a large number) of
> >> the dependencies of OpenStack twice because they have to install
> >> some services running under python 2 and others under 3. Ideally
> >> they would be able to upgrade all of the services on a node together
> >> as part of their transition to the new version, without ending up
> >> with a python 2 version of a dependency along side a python 3 version
> >> of the same package.
> >>
> >> The remaining items could be fixed earlier, but this is the point
> >> at which they would block us:
> >>
> >> 1. Fix oslo.service functional tests -- the Oslo team needs help
> >> maintaining this library. Alternatively, we could move all
> >> services to use cotyledon (https://pypi.org/project/cotyledon/).
> 
> For everyone's awareness, we discussed this in the Oslo meeting today 
> and our first step is to see how many, if any, services are actually 
> relying on the oslo.service functionality that doesn't work in Python 3 
> today.  From there we will come up with a plan for how to move forward.
> 
> https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.
> 
> >>
> >> 2. Finish the unit test and functional test ports so that all of
> >> our tests can run under python 3 (this implies that the services
> >> all run under python 3, so there is no more porting to do).
> 
> And integration tests?  I know for the initial python 3 goal we said 
> just unit and functional, but it seems to me that we can't claim full 
> python 3 compatibility until we can run our tempest jobs against python 
> 3-based OpenStack.

Good point. The wiki page lists the integrated-gate-py35 job for
many projects, but not all will use that particular test job. I'm
not sure what other sort of integration jobs we do have, but I agree
we should have versions of them working for python 3.

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

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

[Alex Schultz]

On Mon, Apr 30, 2018 at 3:16 PM, Ben Nemec  wrote:
> Resending from an address that is subscribed to the list.  Apologies to
> those of you who get this twice.
>
> On 04/30/2018 10:06 AM, Doug Hellmann wrote:
>>
>> It would be useful to have more input from PTLs on this issue, so I'm
>> CCing all of them to get their attention.
>>
>> Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
>>>
>>> It's time to talk about the next steps in our migration from python
>>> 2 to python 3.
>>>
>>> Up to this point we have mostly focused on reaching a state where
>>> we support both versions of the language. We are not quite there
>>> with all projects, as you can see by reviewing the test coverage
>>> status information at
>>>
>>> https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects
>>>
>>> Still, we need to press on to the next phase of the migration, which
>>> I have been calling "Python 3 first". This is where we use python
>>> 3 as the default, for everything, and set up the exceptions we need
>>> for anything that still requires python 2.
>>>
>>> To reach that stage, we need to:
>>>
>>> 1. Change the documentation and release notes jobs to use python 3.
>>> (The Oslo team recently completed this, and found that we did
>>> need to make a few small code changes to get them to work.)
>>> 2. Change (or duplicate) all functional test jobs to run under
>>> python 3.
>>> 3. Change the packaging jobs to use python 3.
>>> 4. Update devstack to use 3 by default and require setting a flag to
>>> use 2. (This may trigger other job changes.)
>>>
>>> At that point, all of our deliverables will be produced using python
>>> 3, and we can be relatively confident that if we no longer had
>>> access to python 2 we could still continue operating. We could also
>>> start updating deployment tools to use either python 3 or 2, so
>>> that users could actually deploy using the python 3 versions of
>>> services.
>>>
>>> Somewhere in that time frame our third-party CI systems will need
>>> to ensure they have python 3 support as well.
>>>
>>> After the "Python 3 first" phase is completed we should release
>>> one series using the packages built with python 3. Perhaps Stein?
>>> Or is that too ambitious?
>>>
>>> Next, we will be ready to address the prerequisites for "Python 3
>>> only," which will allow us to drop Python 2 support.
>>>
>>> We need to wait to drop python 2 support as a community, rather
>>> than going one project at a time, to avoid doubling the work of
>>> downstream consumers such as distros and independent deployers. We
>>> don't want them to have to package all (or even a large number) of
>>> the dependencies of OpenStack twice because they have to install
>>> some services running under python 2 and others under 3. Ideally
>>> they would be able to upgrade all of the services on a node together
>>> as part of their transition to the new version, without ending up
>>> with a python 2 version of a dependency along side a python 3 version
>>> of the same package.
>>>
>>> The remaining items could be fixed earlier, but this is the point
>>> at which they would block us:
>>>
>>> 1. Fix oslo.service functional tests -- the Oslo team needs help
>>> maintaining this library. Alternatively, we could move all
>>> services to use cotyledon (https://pypi.org/project/cotyledon/).
>
>
> For everyone's awareness, we discussed this in the Oslo meeting today and
> our first step is to see how many, if any, services are actually relying on
> the oslo.service functionality that doesn't work in Python 3 today.  From
> there we will come up with a plan for how to move forward.
>
> https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.
>
>>>
>>> 2. Finish the unit test and functional test ports so that all of
>>> our tests can run under python 3 (this implies that the services
>>> all run under python 3, so there is no more porting to do).
>
>
> And integration tests?  I know for the initial python 3 goal we said just
> unit and functional, but it seems to me that we can't claim full python 3
> compatibility until we can run our tempest jobs against python 3-based
> OpenStack.
>
>>>
>>> Finally, after we have *all* tests running on python 3, we can
>>> safely drop python 2.
>>>
>>> We have previously discussed the end of the T cycle as the point
>>> at which we would have all of those tests running, and if that holds
>>> true we could reasonably drop python 2 during the beginning of the
>>> U cycle, in late 2019 and before the 2020 cut-off point when upstream
>>> python 2 support will be dropped.
>>>
>>> I need some info from the deployment tool teams to understand whether
>>> they would be ready to take the plunge during T or U and start
>>> deploying only the python 3 version. Are there other upgrade issues
>>> that need to be addressed to support moving from 2 to 3? Something
>>> that might be part of the platform(s), rather 

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

[Matthew Treinish]

On Mon, Apr 30, 2018 at 04:16:35PM -0500, Ben Nemec wrote:
> Resending from an address that is subscribed to the list.  Apologies to
> those of you who get this twice.
> 
> On 04/30/2018 10:06 AM, Doug Hellmann wrote:
> > It would be useful to have more input from PTLs on this issue, so I'm
> > CCing all of them to get their attention.
> > 
> > Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
> > > It's time to talk about the next steps in our migration from python
> > > 2 to python 3.
> > > 
> > > Up to this point we have mostly focused on reaching a state where
> > > we support both versions of the language. We are not quite there
> > > with all projects, as you can see by reviewing the test coverage
> > > status information at
> > > https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects
> > > 
> > > Still, we need to press on to the next phase of the migration, which
> > > I have been calling "Python 3 first". This is where we use python
> > > 3 as the default, for everything, and set up the exceptions we need
> > > for anything that still requires python 2.
> > > 
> > > To reach that stage, we need to:
> > > 
> > > 1. Change the documentation and release notes jobs to use python 3.
> > > (The Oslo team recently completed this, and found that we did
> > > need to make a few small code changes to get them to work.)
> > > 2. Change (or duplicate) all functional test jobs to run under
> > > python 3.
> > > 3. Change the packaging jobs to use python 3.
> > > 4. Update devstack to use 3 by default and require setting a flag to
> > > use 2. (This may trigger other job changes.)
> > > 
> > > At that point, all of our deliverables will be produced using python
> > > 3, and we can be relatively confident that if we no longer had
> > > access to python 2 we could still continue operating. We could also
> > > start updating deployment tools to use either python 3 or 2, so
> > > that users could actually deploy using the python 3 versions of
> > > services.
> > > 
> > > Somewhere in that time frame our third-party CI systems will need
> > > to ensure they have python 3 support as well.
> > > 
> > > After the "Python 3 first" phase is completed we should release
> > > one series using the packages built with python 3. Perhaps Stein?
> > > Or is that too ambitious?
> > > 
> > > Next, we will be ready to address the prerequisites for "Python 3
> > > only," which will allow us to drop Python 2 support.
> > > 
> > > We need to wait to drop python 2 support as a community, rather
> > > than going one project at a time, to avoid doubling the work of
> > > downstream consumers such as distros and independent deployers. We
> > > don't want them to have to package all (or even a large number) of
> > > the dependencies of OpenStack twice because they have to install
> > > some services running under python 2 and others under 3. Ideally
> > > they would be able to upgrade all of the services on a node together
> > > as part of their transition to the new version, without ending up
> > > with a python 2 version of a dependency along side a python 3 version
> > > of the same package.
> > > 
> > > The remaining items could be fixed earlier, but this is the point
> > > at which they would block us:
> > > 
> > > 1. Fix oslo.service functional tests -- the Oslo team needs help
> > > maintaining this library. Alternatively, we could move all
> > > services to use cotyledon (https://pypi.org/project/cotyledon/).
> 
> For everyone's awareness, we discussed this in the Oslo meeting today and
> our first step is to see how many, if any, services are actually relying on
> the oslo.service functionality that doesn't work in Python 3 today.  From
> there we will come up with a plan for how to move forward.
> 
> https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.
> 
> > > 
> > > 2. Finish the unit test and functional test ports so that all of
> > > our tests can run under python 3 (this implies that the services
> > > all run under python 3, so there is no more porting to do).
> 
> And integration tests?  I know for the initial python 3 goal we said just
> unit and functional, but it seems to me that we can't claim full python 3
> compatibility until we can run our tempest jobs against python 3-based
> OpenStack.

They already are running, and have been since the Atlanta PTG (which was the
same cycle as the goal):

https://review.openstack.org/#/c/436540/

You can see the gate jobs history here:

http://status.openstack.org/openstack-health/#/job/tempest-full-py3

-Matt Treinish

> 
> > > 
> > > Finally, after we have *all* tests running on python 3, we can
> > > safely drop python 2.
> > > 
> > > We have previously discussed the end of the T cycle as the point
> > > at which we would have all of those tests running, and if that holds
> > > true we could reasonably drop python 2 during the beginning of the
> > > U cycle, in late 2019 and before the 

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Matt Riedemann]

On 4/30/2018 11:41 AM, Mathieu Gagné wrote:

[6] Used to filter Ironic nodes based on the 'reserved_for_user_id'
Ironic node property.
 This is mainly used when enrolling existing nodes already living
on a different system.
 We reserve the node to a special internal user so the customer
cannot reserve
 the node by mistake until the process is completed.
 Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.


See https://review.openstack.org/#/c/565340/ for context on the 
regression mentioned about RequestSpec.user_id.


Thanks Mathieu for jumping in #openstack-nova and discussing it.

--

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] [api] REST limitations and GraghGL inception?

[Matt Riedemann]

On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
Remember Boston's Summit presentation [1] about GraphQL [2] and how it 
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I haven't 
find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we can 
finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing SQL 
and no-SQL DBMS and therefore have different applications, there are no 
doubt the complexity of most OpenStack projects are good candidates for 
GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and consumers 
might have finally come true so we could move-on an worry about other 
things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql 


[2] http://graphql.org


Not to speak for him, but Sean Dague had a blog post about REST API 
microversions in OpenStack and there is a Q bit at the bottom about 
GraphQL replacing the need for microversions:


https://dague.net/2017/12/11/rest-api-microversions/

Since I don't expect Sean to magically appear to reply to this thread, I 
thought I'd pass this along.


--

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

[Ben Nemec]

Resending from an address that is subscribed to the list.  Apologies to 
those of you who get this twice.


On 04/30/2018 10:06 AM, Doug Hellmann wrote:

It would be useful to have more input from PTLs on this issue, so I'm
CCing all of them to get their attention.

Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:

It's time to talk about the next steps in our migration from python
2 to python 3.

Up to this point we have mostly focused on reaching a state where
we support both versions of the language. We are not quite there
with all projects, as you can see by reviewing the test coverage
status information at
https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects

Still, we need to press on to the next phase of the migration, which
I have been calling "Python 3 first". This is where we use python
3 as the default, for everything, and set up the exceptions we need
for anything that still requires python 2.

To reach that stage, we need to:

1. Change the documentation and release notes jobs to use python 3.
(The Oslo team recently completed this, and found that we did
need to make a few small code changes to get them to work.)
2. Change (or duplicate) all functional test jobs to run under
python 3.
3. Change the packaging jobs to use python 3.
4. Update devstack to use 3 by default and require setting a flag to
use 2. (This may trigger other job changes.)

At that point, all of our deliverables will be produced using python
3, and we can be relatively confident that if we no longer had
access to python 2 we could still continue operating. We could also
start updating deployment tools to use either python 3 or 2, so
that users could actually deploy using the python 3 versions of
services.

Somewhere in that time frame our third-party CI systems will need
to ensure they have python 3 support as well.

After the "Python 3 first" phase is completed we should release
one series using the packages built with python 3. Perhaps Stein?
Or is that too ambitious?

Next, we will be ready to address the prerequisites for "Python 3
only," which will allow us to drop Python 2 support.

We need to wait to drop python 2 support as a community, rather
than going one project at a time, to avoid doubling the work of
downstream consumers such as distros and independent deployers. We
don't want them to have to package all (or even a large number) of
the dependencies of OpenStack twice because they have to install
some services running under python 2 and others under 3. Ideally
they would be able to upgrade all of the services on a node together
as part of their transition to the new version, without ending up
with a python 2 version of a dependency along side a python 3 version
of the same package.

The remaining items could be fixed earlier, but this is the point
at which they would block us:

1. Fix oslo.service functional tests -- the Oslo team needs help
maintaining this library. Alternatively, we could move all
services to use cotyledon (https://pypi.org/project/cotyledon/).


For everyone's awareness, we discussed this in the Oslo meeting today 
and our first step is to see how many, if any, services are actually 
relying on the oslo.service functionality that doesn't work in Python 3 
today.  From there we will come up with a plan for how to move forward.


https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.



2. Finish the unit test and functional test ports so that all of
our tests can run under python 3 (this implies that the services
all run under python 3, so there is no more porting to do).


And integration tests?  I know for the initial python 3 goal we said 
just unit and functional, but it seems to me that we can't claim full 
python 3 compatibility until we can run our tempest jobs against python 
3-based OpenStack.




Finally, after we have *all* tests running on python 3, we can
safely drop python 2.

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

I need some info from the deployment tool teams to understand whether
they would be ready to take the plunge during T or U and start
deploying only the python 3 version. Are there other upgrade issues
that need to be addressed to support moving from 2 to 3? Something
that might be part of the platform(s), rather than OpenStack itself?


Alex can probably expand on this, but I know TripleO has some challenges 
in this area.  Specifically the fact that CentOS 7 will only ever 
support Python 2 and CentOS 8 is planned to only support Python 3. Since 
CentOS 8 is not a thing yet and no release dates are announced they're 
having to use Fedora for Python 3 testing, which isn't something that 
will be supported long-term.  

Re: [openstack-dev] [neutron] Bug deputy report 23-29 April

[Paweł Suder]

Hello Team,

I forgot about this:

Deleting port doesnt delete dns records
https://bugs.launchpad.net/neutron/+bug/1741079
Re-open, confirmed.

Cheers,
Paweł

W dniu 30.04.2018, pon o godzinie 08∶26 +0200, użytkownik Paweł Suder
napisał:
> Hello Team,
> 
> Last week starting from 23 April until 29 April I was bug deputy for
> Neutron project.
> 
> Following bugs/RFEs were opened:
> 
> [RFE] Create host-routes for routed networks (segments)
> https://bugs.launchpad.net/neutron/+bug/1766380
> RFE, importance not set. Seems to be very interesting. Confirmed by
> Miguel (thx!). Need to be discussed by drivers team.
> 
> Trunk Tests are failing often in dvr-multinode scenario job
> https://bugs.launchpad.net/neutron/+bug/1766701
> High, confirmed based on logs from failing jobs.
> 
> Periodic job * neutron-dynamic-routing-dsvm-tempest-with-ryu-master-
> scenario-ipv4 fails
> https://bugs.launchpad.net/neutron/+bug/1766702
> High, confirmed based on logs from failing jobs.
> 
> Rally tests job is reaching job timeout often
> https://bugs.launchpad.net/neutron/+bug/1766703
> High, confirmed based on logs from failing jobs.
> 
> [NEED ATTENTION] the machine running dhcp agent will have very high
> cpu
> load when start dhcp agent after the agent down more than 150 seconds
> https://bugs.launchpad.net/neutron/+bug/1766812
> Not yet clarified, due to scale, it will be not easy to triage it.
> Some
> logs are attached, but still issue might be very environmental. Not
> marked as confirmed, importance not set.
> [OPEN QUESTION]: should be reproduced somehow?
> 
> loadbalancer can't create with chinese character name
> https://bugs.launchpad.net/neutron/+bug/1767028
> It could be related to Octavia. Not confirmed, do not know version of
> used OpenStack. Logs from Neutron attached. Importance not set.
> [OPEN QUESTION]: how to link with other project?
> 
> character of set image property multiqueue command is wrong
> https://bugs.launchpad.net/neutron/+bug/1767267
> Confirmed doc issue, some typos/command syntax issues. Importance not
> set.
> 
> Neutron agent internal ports remain untagged for some time, which
> makes
> them trunk ports
> https://bugs.launchpad.net/neutron/+bug/1767422
> Confirmed. Fix proposed.
> 
> [DVR] br-int in compute node will send unknown unicast to sg-xxx
> https://bugs.launchpad.net/neutron/+bug/1767811
> Clarifying.
> 
> Cheers,
> Paweł
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [barbican] barbican migrated to storyboard

[Ade Lee]

Hi all, 

Thanks to the hard work done by Kendall and Jeremy, Barbican has now
been been migrated to storyboard.

The new link for the Barbican storyboard is https://storyboard.openstac
k.org/#!/project_group/81

This is the starting point for :
python-barbicanclient, castellan-ui, barbican-tempest-plugin, barbican-
specs and openstack-barbican

Note, that because castellan is under oslo control, it has not yet been
migrated at this time.

Thanks Kendall and Jeremy!

Ade 


__
OpenStack Development Mailing 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] The Forum Schedule is now live

[Arkady.Kanevsky]

LOL

From: Jimmy McArthur [mailto:ji...@openstack.org]
Sent: Monday, April 30, 2018 1:22 PM
To: Kanevsky, Arkady
Cc: a...@demarco.com; openstack-dev@lists.openstack.org; 
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] The Forum Schedule is now 
live

We don't support deprecated browsers, I'm afraid.




arkady.kanev...@dell.com
April 30, 2018 at 1:14 PM
Interesting.
It does work on Chrome but not on IE.
Here is IE screenshot.
Thanks,
Arkady

From: Jimmy McArthur [mailto:ji...@openstack.org]
Sent: Monday, April 30, 2018 11:22 AM
To: Kanevsky, Arkady
Cc: a...@demarco.com; 
openstack-dev@lists.openstack.org; 
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] The Forum Schedule is now 
live

Hmm. I see both populated with all of the relevant sessions.  Can you send me a 
screencap of what you're seeing?




Jimmy McArthur
April 30, 2018 at 11:22 AM
Hmm. I see both populated with all of the relevant sessions.  Can you send me a 
screencap of what you're seeing?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
arkady.kanev...@dell.com
April 30, 2018 at 10:58 AM
Both are currently empty.

From: Jimmy McArthur [mailto:ji...@openstack.org]
Sent: Monday, April 30, 2018 10:48 AM
To: Amy Marrich
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] The Forum Schedule is now 
live

Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223

As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218




Jimmy McArthur
April 30, 2018 at 10:47 AM
Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223

As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Amy Marrich
April 30, 2018 at 10:44 AM
Emilien,

I believe that the Project Updates are separate from the Forum? I know I saw 
some in the schedule before the Forum submittals were even closed. Maybe 
contact speaker support or Jimmy will answer here.

Thanks,

Amy (spotz)

__
OpenStack Development Mailing 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] [os-upstream-institute] Meeting reminder

[Ildiko Vancsa]

Hi,

Don’t forget that we switched to the US - Europe slot only till the training in 
Vancouver.

See you on #openstack-meeting-3 at 2000 UTC!

Thanks,
Ildikó (IRC: ildikov)



__
OpenStack Development Mailing 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] The Forum Schedule is now live

[Jimmy McArthur]

We don't support deprecated browsers, I'm afraid.




arkady.kanev...@dell.com 
April 30, 2018 at 1:14 PM

Interesting.

It does work on Chrome but not on IE.

Here is IE screenshot.

Thanks,

Arkady

*From:*Jimmy McArthur [mailto:ji...@openstack.org]
*Sent:* Monday, April 30, 2018 11:22 AM
*To:* Kanevsky, Arkady
*Cc:* a...@demarco.com; openstack-dev@lists.openstack.org; 
openstack-operat...@lists.openstack.org
*Subject:* Re: [Openstack-operators] [openstack-dev] The Forum 
Schedule is now live


Hmm. I see both populated with all of the relevant sessions.  Can you 
send me a screencap of what you're seeing?



Jimmy McArthur 
April 30, 2018 at 11:22 AM
Hmm. I see both populated with all of the relevant sessions.  Can you 
send me a screencap of what you're seeing?



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
arkady.kanev...@dell.com 
April 30, 2018 at 10:58 AM

Both are currently empty.

*From:*Jimmy McArthur [mailto:ji...@openstack.org]
*Sent:* Monday, April 30, 2018 10:48 AM
*To:* Amy Marrich
*Cc:* OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
*Subject:* Re: [Openstack-operators] [openstack-dev] The Forum 
Schedule is now live


Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223


As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218



Jimmy McArthur 
April 30, 2018 at 10:47 AM
Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223


As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Amy Marrich 
April 30, 2018 at 10:44 AM
Emilien,

I believe that the Project Updates are separate from the Forum? I know 
I saw some in the schedule before the Forum submittals were even 
closed. Maybe contact speaker support or Jimmy will answer here.


Thanks,

Amy (spotz)


__
OpenStack Development Mailing 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] Thank you TryStack!!

[Jimmy McArthur]

OK - got it :)


Jeremy Stanley 
April 30, 2018 at 12:29 PM
[...]

I was thrown by the fact that DNS currently has
trystack.openstack.org as a CNAME alias for trystack.org, but
reviewing logs on static.openstack.org it seems it may have
previously pointed there (was receiving traffic up until around
13:15 UTC today) so if you want to just glom that onto the current
trystack.org redirect that may make the most sense and we can move
forward tearing down the old infrastructure for it.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
April 30, 2018 at 12:10 PM
Yeah... my only concern is that if traffic is actually getting there, 
a redirect to the same place trystack.org is going might be helpful.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jeremy Stanley 
April 30, 2018 at 12:02 PM
On 2018-04-30 11:07:27 -0500 (-0500), Jimmy McArthur wrote:
[...]
[...]

Since I don't think the trystack.o.o site ever found its way fully
into production, it may make more sense for us to simply delete the
records for it from DNS. Someone else probably knows more about the
prior state of it than I though.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
April 30, 2018 at 11:07 AM



Jeremy Stanley 
April 30, 2018 at 10:12 AM
[...]

Yes, before the TryStack effort was closed down, there had been a
plan for trystack.org to redirect to a trystack.openstack.org site
hosted in the community infrastructure. 
When we talked to trystack we agreed to redirect trystack.org to 
https://openstack.org/software/start since that presents alternative 
options for people to "try openstack".  My suggestion would be to 
redirect trystack.openstack.org to the same spot, but certainly open 
to other suggestions :)

At this point I expect we
can just rip out the section for it from
https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/static.pp
as DNS appears to no longer be pointed there.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
April 30, 2018 at 9:34 AM
I'm working on redirecting trystack.openstack.org to 
openstack.org/software/start.  We have redirects in place for 
trystack.org, but didn't realize trystack.openstack.org as a thing as 
well.



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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Paul Belanger 
April 30, 2018 at 9:23 AM
The code is hosted by openstack-infra[1], if somebody would like to 
propose a

patch with the new information.

[1] http://git.openstack.org/cgit/openstack-infra/trystack-site

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jens Harbott 
April 30, 2018 at 4:37 AM

Seems it would be great if https://trystack.openstack.org/ would be
updated with this information, according to comments in #openstack
users are still landing on that page and try to get a stack there in
vain.

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy Mcarthur 
March 26, 2018 at 5:51 PM
Hi everyone,

We recently made the tough decision, in conjunction with the 
dedicated volunteers that run TryStack, to end the service as of 
March 29, 2018.  For those of you that used it, thank you for being 
part of the TryStack 

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

[Andrey Pavlov]

Hi Doug,

There is no ec2-api project on the link.
But we have voted job  openstack-tox-py35


Regards,
Andrey Pavlov.

On Mon, Apr 30, 2018 at 6:06 PM, Doug Hellmann 
wrote:

> It would be useful to have more input from PTLs on this issue, so I'm
> CCing all of them to get their attention.
>
> Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
> > It's time to talk about the next steps in our migration from python
> > 2 to python 3.
> >
> > Up to this point we have mostly focused on reaching a state where
> > we support both versions of the language. We are not quite there
> > with all projects, as you can see by reviewing the test coverage
> > status information at
> > https://wiki.openstack.org/wiki/Python3#Python_3_Status_
> of_OpenStack_projects
> >
> > Still, we need to press on to the next phase of the migration, which
> > I have been calling "Python 3 first". This is where we use python
> > 3 as the default, for everything, and set up the exceptions we need
> > for anything that still requires python 2.
> >
> > To reach that stage, we need to:
> >
> > 1. Change the documentation and release notes jobs to use python 3.
> >(The Oslo team recently completed this, and found that we did
> >need to make a few small code changes to get them to work.)
> > 2. Change (or duplicate) all functional test jobs to run under
> >python 3.
> > 3. Change the packaging jobs to use python 3.
> > 4. Update devstack to use 3 by default and require setting a flag to
> >use 2. (This may trigger other job changes.)
> >
> > At that point, all of our deliverables will be produced using python
> > 3, and we can be relatively confident that if we no longer had
> > access to python 2 we could still continue operating. We could also
> > start updating deployment tools to use either python 3 or 2, so
> > that users could actually deploy using the python 3 versions of
> > services.
> >
> > Somewhere in that time frame our third-party CI systems will need
> > to ensure they have python 3 support as well.
> >
> > After the "Python 3 first" phase is completed we should release
> > one series using the packages built with python 3. Perhaps Stein?
> > Or is that too ambitious?
> >
> > Next, we will be ready to address the prerequisites for "Python 3
> > only," which will allow us to drop Python 2 support.
> >
> > We need to wait to drop python 2 support as a community, rather
> > than going one project at a time, to avoid doubling the work of
> > downstream consumers such as distros and independent deployers. We
> > don't want them to have to package all (or even a large number) of
> > the dependencies of OpenStack twice because they have to install
> > some services running under python 2 and others under 3. Ideally
> > they would be able to upgrade all of the services on a node together
> > as part of their transition to the new version, without ending up
> > with a python 2 version of a dependency along side a python 3 version
> > of the same package.
> >
> > The remaining items could be fixed earlier, but this is the point
> > at which they would block us:
> >
> > 1. Fix oslo.service functional tests -- the Oslo team needs help
> >maintaining this library. Alternatively, we could move all
> >services to use cotyledon (https://pypi.org/project/cotyledon/).
> >
> > 2. Finish the unit test and functional test ports so that all of
> >our tests can run under python 3 (this implies that the services
> >all run under python 3, so there is no more porting to do).
> >
> > Finally, after we have *all* tests running on python 3, we can
> > safely drop python 2.
> >
> > We have previously discussed the end of the T cycle as the point
> > at which we would have all of those tests running, and if that holds
> > true we could reasonably drop python 2 during the beginning of the
> > U cycle, in late 2019 and before the 2020 cut-off point when upstream
> > python 2 support will be dropped.
> >
> > I need some info from the deployment tool teams to understand whether
> > they would be ready to take the plunge during T or U and start
> > deploying only the python 3 version. Are there other upgrade issues
> > that need to be addressed to support moving from 2 to 3? Something
> > that might be part of the platform(s), rather than OpenStack itself?
> >
> > What else have I missed in these phases? Other jobs? Other blocking
> > conditions?
> >
> > 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] Thank you TryStack!!

[Jeremy Stanley]

On 2018-04-30 12:10:29 -0500 (-0500), Jimmy McArthur wrote:
> Yeah... my only concern is that if traffic is actually getting
> there, a redirect to the same place trystack.org is going might be
> helpful.
[...]

I was thrown by the fact that DNS currently has
trystack.openstack.org as a CNAME alias for trystack.org, but
reviewing logs on static.openstack.org it seems it may have
previously pointed there (was receiving traffic up until around
13:15 UTC today) so if you want to just glom that onto the current
trystack.org redirect that may make the most sense and we can move
forward tearing down the old infrastructure for it.
-- 
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] [Openstack-operators] The Forum Schedule is now live

[Emilien Macchi]

On Mon, Apr 30, 2018 at 10:05 AM, Jimmy McArthur 
wrote:
>
> It looks like we have a spot held for you, but did not receive
> confirmation that TripleO would be moving forward with Project Update.  If
> you all will be recording this, we have you down for Wednesday from 11:25 -
> 11:45am.  Just let me know and I'll get it up on the schedule.
>

This slot is perfect, and I'll run it with one of my tripleo co-workers
(Alex won't be here).

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] [Openstack-operators] [nova] Default scheduler filters survey

[Mathieu Gagné]

On Mon, Apr 30, 2018 at 1:06 PM, Jay Pipes  wrote:
> Mathieu,
>
> How do you handle issues where compute nodes are associated with multiple
> aggregates and both aggregates have different values for a particular filter
> key?
>
> Is that a human-based validation process to ensure you don't have that
> situation?
>

It's human-based and we are fine with it.

We also have automatic reports which generate stats on those aggregates.
You will visually see it if some hosts are part of multiple aggregates.

If we need an intersection of 2 aggregates, we create a new one and
use it instead.

--
Mathieu

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

Re: [openstack-dev] Thank you TryStack!!

[Jimmy McArthur]

Yeah... my only concern is that if traffic is actually getting there, a 
redirect to the same place trystack.org is going might be helpful.



Jeremy Stanley 
April 30, 2018 at 12:02 PM
On 2018-04-30 11:07:27 -0500 (-0500), Jimmy McArthur wrote:
[...]
[...]

Since I don't think the trystack.o.o site ever found its way fully
into production, it may make more sense for us to simply delete the
records for it from DNS. Someone else probably knows more about the
prior state of it than I though.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
April 30, 2018 at 11:07 AM



Jeremy Stanley 
April 30, 2018 at 10:12 AM
[...]

Yes, before the TryStack effort was closed down, there had been a
plan for trystack.org to redirect to a trystack.openstack.org site
hosted in the community infrastructure. 
When we talked to trystack we agreed to redirect trystack.org to 
https://openstack.org/software/start since that presents alternative 
options for people to "try openstack".  My suggestion would be to 
redirect trystack.openstack.org to the same spot, but certainly open 
to other suggestions :)

At this point I expect we
can just rip out the section for it from
https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/static.pp
as DNS appears to no longer be pointed there.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
April 30, 2018 at 9:34 AM
I'm working on redirecting trystack.openstack.org to 
openstack.org/software/start.  We have redirects in place for 
trystack.org, but didn't realize trystack.openstack.org as a thing as 
well.



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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Paul Belanger 
April 30, 2018 at 9:23 AM
The code is hosted by openstack-infra[1], if somebody would like to 
propose a

patch with the new information.

[1] http://git.openstack.org/cgit/openstack-infra/trystack-site

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jens Harbott 
April 30, 2018 at 4:37 AM

Seems it would be great if https://trystack.openstack.org/ would be
updated with this information, according to comments in #openstack
users are still landing on that page and try to get a stack there in
vain.

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy Mcarthur 
March 26, 2018 at 5:51 PM
Hi everyone,

We recently made the tough decision, in conjunction with the 
dedicated volunteers that run TryStack, to end the service as of 
March 29, 2018.  For those of you that used it, thank you for being 
part of the TryStack community.


The good news is that you can find more resources to try OpenStack at 
http://www.openstack.org/start, including the Passport Program 
, where you can test on any 
participating public cloud. If you are looking to test different 
tools or application stacks with OpenStack clouds, you should check 
out Open Lab .


Thank you very much to Will Foster, Kambiz Aghaiepour, Rich Bowen, 
and the many other volunteers who have managed this valuable service 
for the last several years!  Your contribution to OpenStack was 
noticed and appreciated by many in the community.


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 Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Jay Pipes]

Mathieu,

How do you handle issues where compute nodes are associated with 
multiple aggregates and both aggregates have different values for a 
particular filter key?


Is that a human-based validation process to ensure you don't have that 
situation?


Best,
-jay

On 04/30/2018 12:41 PM, Mathieu Gagné wrote:

Hi,

On Sun, Apr 29, 2018 at 5:29 PM, Ed Leafe  wrote:

On Apr 29, 2018, at 1:34 PM, Artom Lifshitz  wrote:


Based on that, we can definitely say that SameHostFilter and
DifferentHostFilter do *not* belong in the defaults. In fact, we got
our defaults pretty spot on, based on this admittedly very limited
dataset. The only frequently occurring filter that's not in our
defaults is AggregateInstanceExtraSpecsFilter.


Another data point that might be illuminating is: how many sites use a custom 
(i.e., not in-tree) filter or weigher? One of the original design tenets of the 
scheduler was that we did not want to artificially limit what people could use 
to control their deployments, but inside of Nova there is a lot of confusion as 
to whether anyone is using anything but the included filters.

So - does anyone out there rely on a filter and/or weigher that they wrote 
themselves, and maintain outside of OpenStack?


Yes and we have a bunch.

Here are our filters and weighers with explanations.

Filters for cells:
* InstanceTypeClassFilter [0]

Filters for cloud/virtual cells:
* RetryFilter
* AvailabilityZoneFilter
* RamFilter
* ComputeFilter
* AggregateCoreFilter
* ImagePropertiesFilter
* AggregateImageOsTypeIsolationFilter [1]
* AggregateInstanceExtraSpecsFilter
* AggregateProjectsIsolationFilter [2]

Weighers for cloud/virtual cells:
* MetricsWeigher
* AggregateRAMWeigher [3]

Filters for baremetal cells:
* ComputeFilter
* NetworkModelFilter [4]
* TenantFilter [5]
* UserFilter [6]
* RetryFilter
* AvailabilityZoneFilter
* ComputeCapabilitiesFilter
* ImagePropertiesFilter
* ExactRamFilter
* ExactDiskFilter
* ExactCoreFilter

Weighers for baremetal cells:
* ReservedHostForTenantWeigher [7]
* ReservedHostForUserWeigher [8]

[0] Used to scheduler instances based on flavor class found in
extra_specs (virtual/baremetal)
[1] Allows to properly isolated hosts for licensing purposes.
 The upstream filter is not strict as per bugs/reviews/specs:
 * https://bugs.launchpad.net/nova/+bug/1293444
 * https://bugs.launchpad.net/nova/+bug/1677217
 * https://review.openstack.org/#/c/56420/
 * https://review.openstack.org/#/c/85399/
 Our custom implementation for Mitaka:
 https://gist.github.com/mgagne/462e7fa8417843055aa6da7c5fd51c00
[2] Similar filter to AggregateImageOsTypeIsolationFilter but for projects.
 Our custom implementation for Mitaka:
 https://gist.github.com/mgagne/d729ccb512b0434568ffb094441f643f
[3] Allows to change stacking behavior based on the 'ram_weight_multiplier'
 aggregate key. (emptiest/fullest)
 Our custom implementation for Mitaka:
 https://gist.github.com/mgagne/65f033cbc5fdd4c8d1f45e90c943a5f4
[4] Used to filter Ironic nodes based on supported network models as requested
 by flavor extra_specs. We support JIT network configuration (flat/bond) and
 need to know which nodes support what network models beforehand.
[5] Used to filter Ironic nodes based on the 'reserved_for_tenant_id'
Ironic node property.
 This is used to reserve Ironic node to specific projects.
 Some customers order lot of machines in advance. We reserve those for them.
[6] Used to filter Ironic nodes based on the 'reserved_for_user_id'
Ironic node property.
 This is mainly used when enrolling existing nodes already living
on a different system.
 We reserve the node to a special internal user so the customer
cannot reserve
 the node by mistake until the process is completed.
 Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.
[7] Used to favor reserved host over non-reserved ones based on project.
[8] Used to favor reserved host over non-reserved ones based on user.
 Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.

--
Mathieu

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



__
OpenStack Development Mailing 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] The Forum Schedule is now live

[Jimmy McArthur]

Alex,

It looks like we have a spot held for you, but did not receive 
confirmation that TripleO would be moving forward with Project Update.  
If you all will be recording this, we have you down for Wednesday from 
11:25 - 11:45am.  Just let me know and I'll get it up on the schedule.


Thanks!
Jimmy


Alex Schultz 
April 30, 2018 at 11:52 AM
On Mon, Apr 30, 2018 at 9:47 AM, Jimmy McArthur  wrote:

Project Updates are in their own track:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223



TripleO is still missing?

Thanks,
-Alex


As are SIG, BoF and Working Groups:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218

Amy Marrich
April 30, 2018 at 10:44 AM
Emilien,

I believe that the Project Updates are separate from the Forum? I know I saw
some in the schedule before the Forum submittals were even closed. Maybe
contact speaker support or Jimmy will answer here.

Thanks,

Amy (spotz)


___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Emilien Macchi
April 30, 2018 at 10:33 AM



Hello all -

Please take a look here for the posted Forum schedule:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
You should also see it update on your Summit App.

Why TripleO doesn't have project update?
Maybe we could combine it with TripleO - Project Onboarding if needed but it
would be great to have it advertised as a project update!

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
Jimmy McArthur
April 27, 2018 at 11:04 AM
Hello all -

Please take a look here for the posted Forum schedule:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
You should also see it update on your Summit App.

Thank you and see you in Vancouver!
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 Development Mailing 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-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Jimmy McArthur 
April 30, 2018 at 10:47 AM
Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223


As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Amy Marrich 
April 30, 2018 at 10:44 AM
Emilien,

I believe that the Project Updates are separate from the Forum? I know 
I saw some in the schedule before the Forum submittals were even 
closed. Maybe contact speaker support or Jimmy will answer here.


Thanks,

Amy (spotz)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Emilien Macchi 
April 30, 2018 at 10:33 AM


Hello all -

Please take a look here for the posted Forum schedule:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
 
You should also see it update on your Summit App.


Why TripleO doesn't have project update?
Maybe we could combine it with TripleO - Project Onboarding if needed 
but it would be great to have it advertised as a project update!


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
Jimmy McArthur 
April 27, 

Re: [openstack-dev] Thank you TryStack!!

[Jeremy Stanley]

On 2018-04-30 11:07:27 -0500 (-0500), Jimmy McArthur wrote:
[...]
> When we talked to trystack we agreed to redirect trystack.org to
> https://openstack.org/software/start since that presents
> alternative options for people to "try openstack".  My suggestion
> would be to redirect trystack.openstack.org to the same spot, but
> certainly open to other suggestions :)
[...]

Since I don't think the trystack.o.o site ever found its way fully
into production, it may make more sense for us to simply delete the
records for it from DNS. Someone else probably knows more about the
prior state of it than I though.
-- 
Jeremy Stanley


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

[openstack-dev] [Oslo][Nova][Sahara][Tempest][Cinder][Magnum] Removing broken tox missing requirements tests

[Ken Giusti]

Folks,

Here in Oslo land a number of projects define a tox test for missing
dependencies. These tests are based on a tool - pip-check-reqs - that
no longer functions under the latest release of pip.  The project's
upstream github repo hasn't had any commit activity in a year and
appears to no longer be maintained.

See my previous email about this tool:
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129697.html

In lieu of a suitable replacement, I've started removing the broken
tox tests from the oslo project to prevent anyone else having that
"Hmm - why doesn't this test pass?" moment I hit last week.

I've created a epad that lists the projects that define tox tests
based on this tool:

https://etherpad.openstack.org/p/pip_(missing|check)_reqs

There are other non-Oslo projects - Nova, Cinder, etc - that may want
to also remove that test. See the epad for details.

I've started patches for a couple of projects, but if anyone is
willing to help out please use the epad so we don't step on each
other's toes.

thanks,

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

Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live

[Alex Schultz]

On Mon, Apr 30, 2018 at 9:47 AM, Jimmy McArthur  wrote:
> Project Updates are in their own track:
> https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223
>

TripleO is still missing?

Thanks,
-Alex

> As are SIG, BoF and Working Groups:
> https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218
>
> Amy Marrich
> April 30, 2018 at 10:44 AM
> Emilien,
>
> I believe that the Project Updates are separate from the Forum? I know I saw
> some in the schedule before the Forum submittals were even closed. Maybe
> contact speaker support or Jimmy will answer here.
>
> Thanks,
>
> Amy (spotz)
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> Emilien Macchi
> April 30, 2018 at 10:33 AM
>
>
>> Hello all -
>>
>> Please take a look here for the posted Forum schedule:
>> https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
>> You should also see it update on your Summit App.
>
>
> Why TripleO doesn't have project update?
> Maybe we could combine it with TripleO - Project Onboarding if needed but it
> would be great to have it advertised as a project update!
>
> 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
> Jimmy McArthur
> April 27, 2018 at 11:04 AM
> Hello all -
>
> Please take a look here for the posted Forum schedule:
> https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
> You should also see it update on your Summit App.
>
> Thank you and see you in Vancouver!
> 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 Development Mailing 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] z/VM introducing a new config driveformat

[melanie witt]

On Mon, 30 Apr 2018 12:42:40 -0400, Matthew Treinish wrote:

On Mon, Apr 30, 2018 at 09:21:22AM -0700, melanie witt wrote:

On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote:

According to requirements and comments, now we opened the CI runs with
run_validation = True
And according to [1] below, for example, [2] need the ssh validation
passed the test

And there are a couple of comments need some enhancement on the logs of
CI such as format and legacy incorrect links of logs etc
the newest logs sample can be found [3] (take n-cpu as example and those
logs are with _white.html)

Also, the blueprint [4] requested by previous discussion post here again
for reference


Thank you for alerting us about the completion of the work on the z/VM CI.
The logs look much improved and ssh connectivity and metadata functionality
via config drive is being verified by tempest.

The only strange thing I noticed is it appears tempest starts multiple times
in the log [0]. Do you know what's going on there?


This is normal, it's an artifact of a few things. The first time config is
dumped to the logs is because of tempest verify-config being run as part of
devstack:

https://github.com/openstack-dev/devstack/blob/master/lib/tempest#L590

You also see the API requests this command is making being logged. Then
when the tempest tests are actually being run the config is dumped to the logs
once per test worker process. Basically every time we parse the config file at
debug log levels it get's printed to the log file.

FWIW, you can also see this in a gate run too:
http://logs.openstack.org/90/539590/10/gate/tempest-full/4b0a136/controller/logs/tempest_log.txt

A-ha, thanks for sharing all of that info. I have learned something new. :)

-melanie





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

[openstack-dev] [nova] review runway status

[melanie witt]

Howdy everyone,

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


* XenAPI: Support a new image handler for non-FS based SRs 
https://blueprints.launchpad.net/nova/+spec/xenapi-image-handler-option-improvement 
(jianghuaw_) [END DATE: 2018-05-11] series starting at 
https://review.openstack.org/497201


* Consoles database backend: 
https://blueprints.launchpad.net/nova/+spec/convert-consoles-to-objects 
(melwitt) [END DATE: 2018-05-01] series starting at 
https://review.openstack.org/325414


* Add z/VM driver 
https://blueprints.launchpad.net/nova/+spec/add-zvm-driver-rocky 
(jichen) [END DATE: 2018-05-15] spec amendment 
https://review.openstack.org/562154 and implementation series starting 
at https://review.openstack.org/523387


Cheers,
-melanie

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

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

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Matthew Treinish]

On Mon, Apr 30, 2018 at 09:21:22AM -0700, melanie witt wrote:
> On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote:
> > According to requirements and comments, now we opened the CI runs with
> > run_validation = True
> > And according to [1] below, for example, [2] need the ssh validation
> > passed the test
> > 
> > And there are a couple of comments need some enhancement on the logs of
> > CI such as format and legacy incorrect links of logs etc
> > the newest logs sample can be found [3] (take n-cpu as example and those
> > logs are with _white.html)
> > 
> > Also, the blueprint [4] requested by previous discussion post here again
> > for reference
> 
> Thank you for alerting us about the completion of the work on the z/VM CI.
> The logs look much improved and ssh connectivity and metadata functionality
> via config drive is being verified by tempest.
> 
> The only strange thing I noticed is it appears tempest starts multiple times
> in the log [0]. Do you know what's going on there?

This is normal, it's an artifact of a few things. The first time config is
dumped to the logs is because of tempest verify-config being run as part of
devstack:

https://github.com/openstack-dev/devstack/blob/master/lib/tempest#L590

You also see the API requests this command is making being logged. Then
when the tempest tests are actually being run the config is dumped to the logs
once per test worker process. Basically every time we parse the config file at
debug log levels it get's printed to the log file.

FWIW, you can also see this in a gate run too:
http://logs.openstack.org/90/539590/10/gate/tempest-full/4b0a136/controller/logs/tempest_log.txt

-Matt Treinish


> 
> That said, since things are looking good with z/VM CI now, we've added the
> z/VM patch series back into a review runway today.
> 
> Cheers,
> -melanie
> 
> [0] 
> http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-17444/logs/tempest.log
> from https://review.openstack.org/527658
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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] [Openstack-operators] [nova] Default scheduler filters survey

[Mathieu Gagné]

Hi,

On Sun, Apr 29, 2018 at 5:29 PM, Ed Leafe  wrote:
> On Apr 29, 2018, at 1:34 PM, Artom Lifshitz  wrote:
>>
>> Based on that, we can definitely say that SameHostFilter and
>> DifferentHostFilter do *not* belong in the defaults. In fact, we got
>> our defaults pretty spot on, based on this admittedly very limited
>> dataset. The only frequently occurring filter that's not in our
>> defaults is AggregateInstanceExtraSpecsFilter.
>
> Another data point that might be illuminating is: how many sites use a custom 
> (i.e., not in-tree) filter or weigher? One of the original design tenets of 
> the scheduler was that we did not want to artificially limit what people 
> could use to control their deployments, but inside of Nova there is a lot of 
> confusion as to whether anyone is using anything but the included filters.
>
> So - does anyone out there rely on a filter and/or weigher that they wrote 
> themselves, and maintain outside of OpenStack?

Yes and we have a bunch.

Here are our filters and weighers with explanations.

Filters for cells:
* InstanceTypeClassFilter [0]

Filters for cloud/virtual cells:
* RetryFilter
* AvailabilityZoneFilter
* RamFilter
* ComputeFilter
* AggregateCoreFilter
* ImagePropertiesFilter
* AggregateImageOsTypeIsolationFilter [1]
* AggregateInstanceExtraSpecsFilter
* AggregateProjectsIsolationFilter [2]

Weighers for cloud/virtual cells:
* MetricsWeigher
* AggregateRAMWeigher [3]

Filters for baremetal cells:
* ComputeFilter
* NetworkModelFilter [4]
* TenantFilter [5]
* UserFilter [6]
* RetryFilter
* AvailabilityZoneFilter
* ComputeCapabilitiesFilter
* ImagePropertiesFilter
* ExactRamFilter
* ExactDiskFilter
* ExactCoreFilter

Weighers for baremetal cells:
* ReservedHostForTenantWeigher [7]
* ReservedHostForUserWeigher [8]

[0] Used to scheduler instances based on flavor class found in
extra_specs (virtual/baremetal)
[1] Allows to properly isolated hosts for licensing purposes.
The upstream filter is not strict as per bugs/reviews/specs:
* https://bugs.launchpad.net/nova/+bug/1293444
* https://bugs.launchpad.net/nova/+bug/1677217
* https://review.openstack.org/#/c/56420/
* https://review.openstack.org/#/c/85399/
Our custom implementation for Mitaka:
https://gist.github.com/mgagne/462e7fa8417843055aa6da7c5fd51c00
[2] Similar filter to AggregateImageOsTypeIsolationFilter but for projects.
Our custom implementation for Mitaka:
https://gist.github.com/mgagne/d729ccb512b0434568ffb094441f643f
[3] Allows to change stacking behavior based on the 'ram_weight_multiplier'
aggregate key. (emptiest/fullest)
Our custom implementation for Mitaka:
https://gist.github.com/mgagne/65f033cbc5fdd4c8d1f45e90c943a5f4
[4] Used to filter Ironic nodes based on supported network models as requested
by flavor extra_specs. We support JIT network configuration (flat/bond) and
need to know which nodes support what network models beforehand.
[5] Used to filter Ironic nodes based on the 'reserved_for_tenant_id'
Ironic node property.
This is used to reserve Ironic node to specific projects.
Some customers order lot of machines in advance. We reserve those for them.
[6] Used to filter Ironic nodes based on the 'reserved_for_user_id'
Ironic node property.
This is mainly used when enrolling existing nodes already living
on a different system.
We reserve the node to a special internal user so the customer
cannot reserve
the node by mistake until the process is completed.
Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.
[7] Used to favor reserved host over non-reserved ones based on project.
[8] Used to favor reserved host over non-reserved ones based on user.
Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.

--
Mathieu

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

Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live

[Jimmy McArthur]

Hmm. I see both populated with all of the relevant sessions.  Can you 
send me a screencap of what you're seeing?



arkady.kanev...@dell.com 
April 30, 2018 at 10:58 AM

Both are currently empty.

*From:*Jimmy McArthur [mailto:ji...@openstack.org]
*Sent:* Monday, April 30, 2018 10:48 AM
*To:* Amy Marrich
*Cc:* OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
*Subject:* Re: [Openstack-operators] [openstack-dev] The Forum 
Schedule is now live


Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223


As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218



Jimmy McArthur 
April 30, 2018 at 10:47 AM
Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223


As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Amy Marrich 
April 30, 2018 at 10:44 AM
Emilien,

I believe that the Project Updates are separate from the Forum? I know 
I saw some in the schedule before the Forum submittals were even 
closed. Maybe contact speaker support or Jimmy will answer here.


Thanks,

Amy (spotz)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Emilien Macchi 
April 30, 2018 at 10:33 AM


Hello all -

Please take a look here for the posted Forum schedule:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
 
You should also see it update on your Summit App.


Why TripleO doesn't have project update?
Maybe we could combine it with TripleO - Project Onboarding if needed 
but it would be great to have it advertised as a project update!


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
Jimmy McArthur 
April 27, 2018 at 11:04 AM
Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224  
You should also see it update on your Summit App.


Thank you and see you in Vancouver!
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 Development Mailing 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] z/VM introducing a new config driveformat

[melanie witt]

On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote:
According to requirements and comments, now we opened the CI runs with 
run_validation = True
And according to [1] below, for example, [2] need the ssh validation 
passed the test


And there are a couple of comments need some enhancement on the logs of 
CI such as format and legacy incorrect links of logs etc
the newest logs sample can be found [3] (take n-cpu as example and those 
logs are with _white.html)


Also, the blueprint [4] requested by previous discussion post here again 
for reference


Thank you for alerting us about the completion of the work on the z/VM 
CI. The logs look much improved and ssh connectivity and metadata 
functionality via config drive is being verified by tempest.


The only strange thing I noticed is it appears tempest starts multiple 
times in the log [0]. Do you know what's going on there?


That said, since things are looking good with z/VM CI now, we've added 
the z/VM patch series back into a review runway today.


Cheers,
-melanie

[0] 
http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-17444/logs/tempest.log 
from https://review.openstack.org/527658





__
OpenStack Development Mailing 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] Thank you TryStack!!

[Jimmy McArthur]

Jeremy Stanley 
April 30, 2018 at 10:12 AM
[...]

Yes, before the TryStack effort was closed down, there had been a
plan for trystack.org to redirect to a trystack.openstack.org site
hosted in the community infrastructure.
When we talked to trystack we agreed to redirect trystack.org to 
https://openstack.org/software/start since that presents alternative 
options for people to "try openstack".  My suggestion would be to 
redirect trystack.openstack.org to the same spot, but certainly open to 
other suggestions :)

At this point I expect we
can just rip out the section for it from
https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/static.pp
as DNS appears to no longer be pointed there.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
April 30, 2018 at 9:34 AM
I'm working on redirecting trystack.openstack.org to 
openstack.org/software/start.  We have redirects in place for 
trystack.org, but didn't realize trystack.openstack.org as a thing as 
well.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Paul Belanger 
April 30, 2018 at 9:23 AM
The code is hosted by openstack-infra[1], if somebody would like to 
propose a

patch with the new information.

[1] http://git.openstack.org/cgit/openstack-infra/trystack-site

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jens Harbott 
April 30, 2018 at 4:37 AM

Seems it would be great if https://trystack.openstack.org/ would be
updated with this information, according to comments in #openstack
users are still landing on that page and try to get a stack there in
vain.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy Mcarthur 
March 26, 2018 at 5:51 PM
Hi everyone,

We recently made the tough decision, in conjunction with the dedicated 
volunteers that run TryStack, to end the service as of March 29, 
2018.  For those of you that used it, thank you for being part of the 
TryStack community.


The good news is that you can find more resources to try OpenStack at 
http://www.openstack.org/start, including the Passport Program 
, where you can test on any 
participating public cloud. If you are looking to test different tools 
or application stacks with OpenStack clouds, you should check out Open 
Lab .


Thank you very much to Will Foster, Kambiz Aghaiepour, Rich Bowen, and 
the many other volunteers who have managed this valuable service for 
the last several years!  Your contribution to OpenStack was noticed 
and appreciated by many in the community.


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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Monthly bug day?

[Dmitry Tantsur]

I've created a bluejeans channel for this meeting: 
https://bluejeans.com/309964257. I may be late for it, but I've set it up to be 
usable even without me.


On 04/30/2018 02:39 PM, Michael Turek wrote:

Just tried this and seems like Firefox does still require a browser plugin.

Julia, could we use your bluejeans line again?

Thanks!
Mike Turek 


On 4/30/18 7:33 AM, Dmitry Tantsur wrote:

Hi,

On 04/29/2018 10:17 PM, Michael Turek wrote:
Awesome! If everyone doesn't mind the short notice, we'll have it again this 
Thursday @ 1:00 PM to 3:00 PM UTC.


++



I can provide video conferencing through hangouts here https://goo.gl/xSKBS4
Let's give that a shot this time!


Note that the last time I checked Hangouts video messaging required a 
proprietary browser plugin (and hence did not work in Firefox). Using it may 
exclude people not accepting proprietary software and/or avoiding using Chromium.




We can adjust times, tooling, and regular agenda over the next couple 
meetings and see where we settle. If anyone has any questions or suggestions, 
don't hesitate to reach out to me!


Thanks,
Mike Turek 


On 4/25/18 12:11 PM, Julia Kreger wrote:

On Mon, Apr 23, 2018 at 12:04 PM, Michael Turek
 wrote:


What does everyone think about having Bug Day the first Thursday of every
month?

All for it!

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



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



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



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



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

Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live

[Arkady.Kanevsky]

Both are currently empty.

From: Jimmy McArthur [mailto:ji...@openstack.org]
Sent: Monday, April 30, 2018 10:48 AM
To: Amy Marrich
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] The Forum Schedule is now 
live

Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223

As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218


Amy Marrich
April 30, 2018 at 10:44 AM
Emilien,

I believe that the Project Updates are separate from the Forum? I know I saw 
some in the schedule before the Forum submittals were even closed. Maybe 
contact speaker support or Jimmy will answer here.

Thanks,

Amy (spotz)

___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Emilien Macchi
April 30, 2018 at 10:33 AM


Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224  You 
should also see it update on your Summit App.

Why TripleO doesn't have project update?
Maybe we could combine it with TripleO - Project Onboarding if needed but it 
would be great to have it advertised as a project update!

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
Jimmy McArthur
April 27, 2018 at 11:04 AM
Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224  You 
should also see it update on your Summit App.

Thank you and see you in Vancouver!
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 Development Mailing 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] Overriding project-templates in Zuul

[James E. Blair]

Hi,

If you've had difficulty overriding jobs in project-templates, please
read and provide feedback on this proposed change.

We tried to make the Zuul v3 configuration language as intuitive as
possible, and incorporated a lot that we learned from our years running
Zuul v2.  One thing that we didn't anticipate was how folks would end up
wanting to use a job in both project-templates *and* local project
stanzas.

Essentially, we had assumed that if you wanted to control how a job was
run, you would add it to a project stanza directly rather that use a
project-template.  It's easy to do so if you use one or the other.
However, it turns out there are lots of good reasons to use both.  For
example, in a project-template we may want to establish a recommended
way to run a job, or that a job should always be run with a set of
related jobs.  Yet a project may still want to indicate that job should
only run on certain changes in that specific repo.

To be very specific -- a very commonly expressed frustration is that a
project can't specify a "files" or "irrelevant-files" matcher to
override a job that appears in a project-template.

Reconciling those is difficult, largely because once Zuul decides to run
a job (for example, by a declaration in a project-template) it is
impossible to dissuade it from running that job by adding any extra
configuration to a project.  We need to tread carefully when fixing
this, because quite a number of related concepts could be affected.  For
instance, we need to preserve branch independence (a change to stop
running a job in one branch shouldn't affect others).  And we need to
preserve the ability for job variants to layer on to each other (a
project-local variant should still be able to alter a variant in a
project-template).

I propose that we remedy this by making a small change to how Zuul
determines that a job should run:

When a job appears multiple times on a project (for instance if it
appears in a project-template and also on the project itself), all of
the project-local variants which match the item's branch must also match
the item in order for the job to run.  In other words, if a job appears
in a project-template used by a project and on the project, then both
must match.

This effectively causes the "files" and "irrelevant-files" attributes on
all of the project-local job definitions matching a given branch to be
combined.  The combination of multiple files matchers behaves as a
union, and irrelevant-files matchers as an intersection.

    ===  ===
Matcher   Template  Project  Result
    ===  ===
files ABBC   ABC
irrelevant-files  ABBC   B
    ===  ===

I believe this will address the shortcoming identified above, but before
we get too far in implementing it, I'd like to ask folks to take a
moment and evaluate whether it will address the issues you've seen, or
if you foresee any problems which I haven't anticipated.

Thanks,

Jim

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

Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live

[Jimmy McArthur]

Project Updates are in their own track: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=223


As are SIG, BoF and Working Groups: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=218



Amy Marrich 
April 30, 2018 at 10:44 AM
Emilien,

I believe that the Project Updates are separate from the Forum? I know 
I saw some in the schedule before the Forum submittals were even 
closed. Maybe contact speaker support or Jimmy will answer here.


Thanks,

Amy (spotz)


___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Emilien Macchi 
April 30, 2018 at 10:33 AM


Hello all -

Please take a look here for the posted Forum schedule:
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
 
You should also see it update on your Summit App.


Why TripleO doesn't have project update?
Maybe we could combine it with TripleO - Project Onboarding if needed 
but it would be great to have it advertised as a project update!


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
Jimmy McArthur 
April 27, 2018 at 11:04 AM
Hello all -

Please take a look here for the posted Forum schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224  
You should also see it update on your Summit App.


Thank you and see you in Vancouver!
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 Development Mailing 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] The Forum Schedule is now live

[Amy Marrich]

Emilien,

I believe that the Project Updates are separate from the Forum? I know I
saw some in the schedule before the Forum submittals were even closed.
Maybe contact speaker support or Jimmy will answer here.

Thanks,

Amy (spotz)

On Mon, Apr 30, 2018 at 10:33 AM, Emilien Macchi  wrote:

>
>
> On Fri, Apr 27, 2018 at 9:04 AM, Jimmy McArthur 
> wrote:
>
>> Hello all -
>>
>> Please take a look here for the posted Forum schedule:
>> https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
>> You should also see it update on your Summit App.
>>
>
> Why TripleO doesn't have project update?
> Maybe we could combine it with TripleO - Project Onboarding if needed but
> it would be great to have it advertised as a project update!
>
> 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
>
>
__
OpenStack Development Mailing 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] The Forum Schedule is now live

[Emilien Macchi]

On Fri, Apr 27, 2018 at 9:04 AM, Jimmy McArthur  wrote:

> Hello all -
>
> Please take a look here for the posted Forum schedule:
> https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224
> You should also see it update on your Summit App.
>

Why TripleO doesn't have project update?
Maybe we could combine it with TripleO - Project Onboarding if needed but
it would be great to have it advertised as a project update!

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] Thank you TryStack!!

[Jeremy Stanley]

On 2018-04-30 09:34:15 -0500 (-0500), Jimmy McArthur wrote:
> I'm working on redirecting trystack.openstack.org to
> openstack.org/software/start.  We have redirects in place for
> trystack.org, but didn't realize trystack.openstack.org as a thing
> as well.
[...]

Yes, before the TryStack effort was closed down, there had been a
plan for trystack.org to redirect to a trystack.openstack.org site
hosted in the community infrastructure. At this point I expect we
can just rip out the section for it from
https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/static.pp
as DNS appears to no longer be pointed there.
-- 
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] Thank you TryStack!!

[Jeremy Stanley]

On 2018-04-30 10:23:34 -0400 (-0400), Paul Belanger wrote:
[...]
> The code is hosted by openstack-infra[1], if somebody would like
> to propose a patch with the new information.
> 
> [1] http://git.openstack.org/cgit/openstack-infra/trystack-site

Yes, ideally it'd just be something along the lines of a README.rst
with a sentence or two about what happened, and removing the other
content from the repository. Basically it can just follow our
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
directions.
-- 
Jeremy Stanley


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

[openstack-dev] Zuul memory improvements

[James E. Blair]

Hi,

We recently made some changes to Zuul which you may want to know about
if you interact with a large number of projects.

Previously, each change to Zuul which updated Zuul's configuration
(e.g., a change to a project's zuul.yaml file) would consume a
significant amount of memory.  If we had too many of these in the queue
at a time, the server would run out of RAM.  To mitigate this, we asked
folks who regularly submit large numbers of configuration changes to
only submit a few at a time.

We have updated Zuul so it now caches much more of its configuration,
and the cost in memory of an additional configuration change is very
small.  An added bonus: they are computed more quickly as well.

Of course, there's still a cost to every change pushed up to Gerrit --
each one uses test nodes, for instance, so if you need to make a large
number of changes, please do consider the impact to the whole system and
other users.  However, there's no longer a need to severely restrict
configuration changes as a class -- consider them as any other change.

-Jim

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

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

[Doug Hellmann]

Excerpts from Clark Boylan's message of 2018-04-26 11:22:15 -0700:
> On Thu, Apr 26, 2018, at 7:27 AM, Sean McGinnis wrote:
> > On Wed, Apr 25, 2018 at 04:54:46PM -0400, Doug Hellmann wrote:
> > > It's time to talk about the next steps in our migration from python
> > > 2 to python 3.
> > > 
> > > [...]
> > > 
> > > 2. Change (or duplicate) all functional test jobs to run under
> > >python 3.
> > 
> > As a test I ran Cinder functional and unit test jobs on bionic using 3.6. 
> > All
> > went well.
> > 
> > That made me realize something though - right now we have jobs that 
> > explicitly
> > say py35, both for unit tests and functional tests. But I realized setting 
> > up
> > these test jobs that it works to just specify "basepython = python3" or run
> > unit tests with "tox -e py3". Then with that, it just depends on whether the
> > job runs on xenial or bionic as to whether the job is run with py35 or py36.
> > 
> > It is less explicit, so I see some downside to that, but would it make 
> > sense to
> > change jobs to drop the minor version to make it more flexible and easy to 
> > make
> > these transitions?
> 
> One reason to use it would be local user simplicity. Rather than need to 
> explicitly add new python3 releases to the default env list so that it does 
> what we want every year or two we can just list py3,py2,linters in the 
> default list and get most of the way there for local users. Then we can 
> continue to be more specific in the CI jobs if that is desirable.
> 
> I do think we likely want to be explicit about the python versions we are 
> using in CI testing. This makes it clear to developers who may need to 
> reproduce or just understand why failures happen what platform is used. It 
> also makes it explicit that "openstack runs on $pythonversion".
> 
> Clark
> 

Including support for local users to refer to "py3" makes sense, as long
as we don't come to rely on it in CI. Users can also always be more
explicit if they need to be when running tests locally.

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] [Nova] z/VM introducing a new config driveformat

[Dan Smith]

> According to requirements and comments, now we opened the CI runs with
> run_validation = True And according to [1] below, for example, [2]
> need the ssh validation passed the test
>
> And there are a couple of comments need some enhancement on the logs
> of CI such as format and legacy incorrect links of logs etc the newest
> logs sample can be found [3] (take n-cpu as example and those logs are
> with _white.html)
>
> Also, the blueprint [4] requested by previous discussion post here
> again for reference
>
> please let us know whether the procedure -2 can be removed in order to
> proceed . thanks for your help

The CI log format issues look fixed to me and validation is turned on
for the stuff supported, which is what was keeping it out of the
runway.

I still plan to leave the -2 on there until the next few patches have
agreement, just so we don't land an empty shell driver before we are
sure we're going to land spawn/destroy, etc. That's pretty normal
procedure and I'll be around to remove it when appropriate.

--Dan

__
OpenStack Development Mailing 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] [Zun][Kolla][Kolla-ansible] Verify Zun deployment in Kolla gate

[Mark Goddard]

Hi,

This is something I've been thinking about recently. In particular, I
noticed a patch go by to fix the same issue in the magnum role that has
been broken and fixed previously. Kolla needs to up its game in terms of CI
testing.

At the very least, we need tests that verify that services can be deployed.
Even if we don't verify that the deployed service is functional, this will
be an improvement from where we are today.

As with many things, we won't get there in a single leap, but should look
to incrementally improve test coverage, perhaps with a set of milestones
spanning multiple releases.

I suggest our first step should be to add a set of experimental jobs for
testing particular services. These would not run against every patch, but
could be invoked on demand by commenting 'check experimental' on a patch in
Gerrit. For many services this could be done simply by setting
'enable_=true' in config.

There are many paths we could take from there, but perhaps this would be
best discussed at the next PTG?

Cheers,
Mark

On Mon, 30 Apr 2018, 14:07 Jeffrey Zhang,  wrote:

> Thanks hongbin
>
> In Kolla, one job is used to test multi OpenStack services. there are
> already two test scenarios.
>
> 1. without ceph
> 2. with ceph
>
> each scenario test a serial of OpenStack services. like nova, neutron,
> cinder etc.
> Zun or kuryr is not tested now.  But i think it is OK to add a new
> scenario to test network related
> service, like zun and kuryr.
>
> for tempest testing, there is a WIP bp for this[0]
>
> [0] https://blueprints.launchpad.net/kolla-ansible/+spec/tempest-gate
>
> On Sun, Apr 29, 2018 at 5:14 AM, Hongbin Lu  wrote:
>
>> Hi Kolla team,
>>
>> Recently, I saw there are users who tried to install Zun by using
>> Kolla-ansible and reported bugs to us whenever they ran into issues (e.g.
>> https://bugs.launchpad.net/kolla-ansible/+bug/1766151). The increase of
>> this usage pattern (Kolla + Zun) made me think that we need to have CI
>> coverage to verify the Zun deployment setup by Kolla.
>>
>> IMHO, the ideal CI workflow should be:
>>
>> * Create a VM with different distros (i.e. Ubuntu, CentOS).
>> * Use Kolla-ansible to stand up a Zun deployment.
>> * Run Zun's tempest test suit [1] against the deployment.
>>
>> My question for Kolla team is if it is reasonable to setup a Zuul job as
>> described above? or such CI jobs already exist? If not, how to create one?
>>
>> [1] https://github.com/openstack/zun-tempest-plugin
>>
>> Best regards,
>> Hongbin
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
> __
> OpenStack Development Mailing 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] Thank you TryStack!!

[Jimmy McArthur]

I'm working on redirecting trystack.openstack.org to 
openstack.org/software/start.  We have redirects in place for 
trystack.org, but didn't realize trystack.openstack.org as a thing as well.



Paul Belanger 
April 30, 2018 at 9:23 AM
The code is hosted by openstack-infra[1], if somebody would like to 
propose a

patch with the new information.

[1] http://git.openstack.org/cgit/openstack-infra/trystack-site

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jens Harbott 
April 30, 2018 at 4:37 AM

Seems it would be great if https://trystack.openstack.org/ would be
updated with this information, according to comments in #openstack
users are still landing on that page and try to get a stack there in
vain.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy Mcarthur 
March 26, 2018 at 5:51 PM
Hi everyone,

We recently made the tough decision, in conjunction with the dedicated 
volunteers that run TryStack, to end the service as of March 29, 
2018.  For those of you that used it, thank you for being part of the 
TryStack community.


The good news is that you can find more resources to try OpenStack at 
http://www.openstack.org/start, including the Passport Program 
, where you can test on any 
participating public cloud. If you are looking to test different tools 
or application stacks with OpenStack clouds, you should check out Open 
Lab .


Thank you very much to Will Foster, Kambiz Aghaiepour, Rich Bowen, and 
the many other volunteers who have managed this valuable service for 
the last several years!  Your contribution to OpenStack was noticed 
and appreciated by many in the community.


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 Development Mailing 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] Thank you TryStack!!

[Paul Belanger]

On Mon, Apr 30, 2018 at 09:37:21AM +, Jens Harbott wrote:
> 2018-03-26 22:51 GMT+00:00 Jimmy Mcarthur :
> > Hi everyone,
> >
> > We recently made the tough decision, in conjunction with the dedicated
> > volunteers that run TryStack, to end the service as of March 29, 2018.  For
> > those of you that used it, thank you for being part of the TryStack
> > community.
> >
> > The good news is that you can find more resources to try OpenStack at
> > http://www.openstack.org/start, including the Passport Program, where you
> > can test on any participating public cloud. If you are looking to test
> > different tools or application stacks with OpenStack clouds, you should
> > check out Open Lab.
> >
> > Thank you very much to Will Foster, Kambiz Aghaiepour, Rich Bowen, and the
> > many other volunteers who have managed this valuable service for the last
> > several years!  Your contribution to OpenStack was noticed and appreciated
> > by many in the community.
> 
> Seems it would be great if https://trystack.openstack.org/ would be
> updated with this information, according to comments in #openstack
> users are still landing on that page and try to get a stack there in
> vain.
> 
The code is hosted by openstack-infra[1], if somebody would like to propose a
patch with the new information.

[1] http://git.openstack.org/cgit/openstack-infra/trystack-site

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

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Mikhail Medvedev]

On Mon, Apr 30, 2018 at 8:46 AM, Jay Pipes  wrote:
> On 04/30/2018 09:18 AM, Mikhail Medvedev wrote:
>>
>> On Sun, Apr 29, 2018 at 4:29 PM, Ed Leafe  wrote:
>>>
>>>
>>> Another data point that might be illuminating is: how many sites use a
>>> custom (i.e., not in-tree) filter or weigher? One of the original design
>>> tenets of the scheduler was that we did not want to artificially limit what
>>> people could use to control their deployments, but inside of Nova there is a
>>> lot of confusion as to whether anyone is using anything but the included
>>> filters.
>>>
>>> So - does anyone out there rely on a filter and/or weigher that they
>>> wrote themselves, and maintain outside of OpenStack?
>>>
>>
>> Internal cloud that is used for Power KVM CI single use VMs:
>>
>> AvailabilityZoneFilter
>> AggregateMultiTenancyIsolation
>> RetryFilter
>> RamFilter
>> ComputeFilter
>> ComputeCapabilitiesFilter
>> ImagePropertiesFilter
>> CoreFilter
>> NumInstancesFilter *
>> NUMATopologyFilter
>>
>> NumInstancesFilter is a custom weigher I have added that returns
>> negative number of instances on a host. Using it this way gives an
>> even spread of instances over the compute nodes up to a point the
>> compute cores are filled up evenly, then it overflows to the compute
>> nodes with more CPU cores. Maybe it is possible to achieve the same
>> with existing filters, at the time I did not see how.

Correction: above describes custom weigher I've added, not the in-tree
NumInstancesFilter.

>
>
> Hi Mikhail,
>
> Did you mean to say you created a new *weigher*, not filter?

Jay, thanks for spotting this, been awhile since I've done it.
NumInstancesFilter is a standard filter, so I obviously did not write
it.

I've added a custom weigher that I have created
(scheduler_weight_classes=pkvmci-os.nova.scheduler.weights.instance.InstanceWeigher)
and maintain locally.

>
> 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] [Openstack-operators] [nova] Default scheduler filters survey

[Jay Pipes]

On 04/30/2018 09:18 AM, Mikhail Medvedev wrote:

On Sun, Apr 29, 2018 at 4:29 PM, Ed Leafe  wrote:


Another data point that might be illuminating is: how many sites use a custom 
(i.e., not in-tree) filter or weigher? One of the original design tenets of the 
scheduler was that we did not want to artificially limit what people could use 
to control their deployments, but inside of Nova there is a lot of confusion as 
to whether anyone is using anything but the included filters.

So - does anyone out there rely on a filter and/or weigher that they wrote 
themselves, and maintain outside of OpenStack?



Internal cloud that is used for Power KVM CI single use VMs:

AvailabilityZoneFilter
AggregateMultiTenancyIsolation
RetryFilter
RamFilter
ComputeFilter
ComputeCapabilitiesFilter
ImagePropertiesFilter
CoreFilter
NumInstancesFilter *
NUMATopologyFilter

NumInstancesFilter is a custom weigher I have added that returns
negative number of instances on a host. Using it this way gives an
even spread of instances over the compute nodes up to a point the
compute cores are filled up evenly, then it overflows to the compute
nodes with more CPU cores. Maybe it is possible to achieve the same
with existing filters, at the time I did not see how.


Hi Mikhail,

Did you mean to say you created a new *weigher*, not filter?

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] [Openstack-operators] [nova] Default scheduler filters survey

[Mikhail Medvedev]

On Sun, Apr 29, 2018 at 4:29 PM, Ed Leafe  wrote:
>
> Another data point that might be illuminating is: how many sites use a custom 
> (i.e., not in-tree) filter or weigher? One of the original design tenets of 
> the scheduler was that we did not want to artificially limit what people 
> could use to control their deployments, but inside of Nova there is a lot of 
> confusion as to whether anyone is using anything but the included filters.
>
> So - does anyone out there rely on a filter and/or weigher that they wrote 
> themselves, and maintain outside of OpenStack?
>

Internal cloud that is used for Power KVM CI single use VMs:

AvailabilityZoneFilter
AggregateMultiTenancyIsolation
RetryFilter
RamFilter
ComputeFilter
ComputeCapabilitiesFilter
ImagePropertiesFilter
CoreFilter
NumInstancesFilter *
NUMATopologyFilter

NumInstancesFilter is a custom weigher I have added that returns
negative number of instances on a host. Using it this way gives an
even spread of instances over the compute nodes up to a point the
compute cores are filled up evenly, then it overflows to the compute
nodes with more CPU cores. Maybe it is possible to achieve the same
with existing filters, at the time I did not see how.

---
Mikhail Medvedev
IBM

__
OpenStack Development Mailing 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] [Zun][Kolla][Kolla-ansible] Verify Zun deployment in Kolla gate

[Jeffrey Zhang]

Thanks hongbin

In Kolla, one job is used to test multi OpenStack services. there are
already two test scenarios.

1. without ceph
2. with ceph

each scenario test a serial of OpenStack services. like nova, neutron,
cinder etc.
Zun or kuryr is not tested now.  But i think it is OK to add a new scenario
to test network related
service, like zun and kuryr.

for tempest testing, there is a WIP bp for this[0]

[0] https://blueprints.launchpad.net/kolla-ansible/+spec/tempest-gate

On Sun, Apr 29, 2018 at 5:14 AM, Hongbin Lu  wrote:

> Hi Kolla team,
>
> Recently, I saw there are users who tried to install Zun by using
> Kolla-ansible and reported bugs to us whenever they ran into issues (e.g.
> https://bugs.launchpad.net/kolla-ansible/+bug/1766151). The increase of
> this usage pattern (Kolla + Zun) made me think that we need to have CI
> coverage to verify the Zun deployment setup by Kolla.
>
> IMHO, the ideal CI workflow should be:
>
> * Create a VM with different distros (i.e. Ubuntu, CentOS).
> * Use Kolla-ansible to stand up a Zun deployment.
> * Run Zun's tempest test suit [1] against the deployment.
>
> My question for Kolla team is if it is reasonable to setup a Zuul job as
> described above? or such CI jobs already exist? If not, how to create one?
>
> [1] https://github.com/openstack/zun-tempest-plugin
>
> Best regards,
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [ironic] [all] The last reminder about the classic drivers removal

[Dmitry Tantsur]

Hi all,

This is the last reminder that the classic drivers will be removed from ironic. 
We plan on finish the removal before Rocky-2. See below for the information on 
migration.


If for some reason we need to delay the removal, please speak up NOW. Note that 
I'm personally not inclined to delay it past Rocky, since it requires my time 
and effort to track this process.


Cheers,
Dmitry

On 03/06/2018 12:11 PM, Dmitry Tantsur wrote:

Hi all,

As you may already know, we have deprecated classic drivers in the Queens 
release. We don't have specific removal plans yet. But according to the 
deprecation policy we may remove them at any time after May 1st, which will be 
half way to Rocky milestone 2. Personally, I'd like to do it around then.


The `online_data_migrations` script will handle migrating nodes, if all required 
hardware interfaces and types are enabled before the upgrade to Queens. 
Otherwise, check the documentation [1] on how to update your nodes.


Dmitry

[1] 
https://docs.openstack.org/ironic/latest/admin/upgrade-to-hardware-types.html



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

Re: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project

[Jeffrey Zhang]

Thanks all guys. Per the voting result, we will retire kolla-kubernetes
project.

On Tue, Apr 24, 2018 at 10:48 PM, Surya Singh 
wrote:

> +1
>
> As we don't have active core team in Kolla-kubernetes since months,
> unfortunately going for sunset is reasonable.
>
> Though happy to help in running OpenStack on kubernetes.
>
> ---
> Thanks
> Surya
>
>
>
> On Wed, Apr 18, 2018 at 7:21 AM, Jeffrey Zhang 
> wrote:
> > Since many of the contributors in the kolla-kubernetes project are moved
> to
> > other things. And there is no active contributor for months.  On the
> other
> > hand, there is another comparable project, openstack-helm, in the
> community.
> > For less confusion and disruptive community resource, I propose to retire
> > the kolla-kubernetes project.
> >
> > More discussion about this you can check the mail[0] and patch[1]
> >
> > please vote +1 to retire the repo, or -1 not to retire the repo. The vote
> > will be open until everyone has voted, or for 1 week until April 25th,
> 2018.
> >
> > [0]
> > http://lists.openstack.org/pipermail/openstack-dev/2018-
> March/128822.html
> > [1] https://review.openstack.org/552531
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > 
> __
> > OpenStack Development Mailing 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing 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] Thank you TryStack!!

[Jimmy McArthur]

Hmm. It appears our redirects have stopped working.  Checking on this...


Jens Harbott 
April 30, 2018 at 4:37 AM

Seems it would be great if https://trystack.openstack.org/ would be
updated with this information, according to comments in #openstack
users are still landing on that page and try to get a stack there in
vain.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy Mcarthur 
March 26, 2018 at 5:51 PM
Hi everyone,

We recently made the tough decision, in conjunction with the dedicated 
volunteers that run TryStack, to end the service as of March 29, 
2018.  For those of you that used it, thank you for being part of the 
TryStack community.


The good news is that you can find more resources to try OpenStack at 
http://www.openstack.org/start, including the Passport Program 
, where you can test on any 
participating public cloud. If you are looking to test different tools 
or application stacks with OpenStack clouds, you should check out Open 
Lab .


Thank you very much to Will Foster, Kambiz Aghaiepour, Rich Bowen, and 
the many other volunteers who have managed this valuable service for 
the last several years!  Your contribution to OpenStack was noticed 
and appreciated by many in the community.


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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Monthly bug day?

[Michael Turek]

Just tried this and seems like Firefox does still require a browser plugin.

Julia, could we use your bluejeans line again?

Thanks!
Mike Turek 


On 4/30/18 7:33 AM, Dmitry Tantsur wrote:

Hi,

On 04/29/2018 10:17 PM, Michael Turek wrote:
Awesome! If everyone doesn't mind the short notice, we'll have it 
again this Thursday @ 1:00 PM to 3:00 PM UTC.


++



I can provide video conferencing through hangouts here 
https://goo.gl/xSKBS4

Let's give that a shot this time!


Note that the last time I checked Hangouts video messaging required a 
proprietary browser plugin (and hence did not work in Firefox). Using 
it may exclude people not accepting proprietary software and/or 
avoiding using Chromium.




We can adjust times, tooling, and regular agenda over the next couple 
meetings and see where we settle. If anyone has any questions or 
suggestions, don't hesitate to reach out to me!


Thanks,
Mike Turek 


On 4/25/18 12:11 PM, Julia Kreger wrote:

On Mon, Apr 23, 2018 at 12:04 PM, Michael Turek
 wrote:

What does everyone think about having Bug Day the first Thursday of 
every

month?

All for it!

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [ironic] Monthly bug day?

[Dmitry Tantsur]

Hi,

On 04/29/2018 10:17 PM, Michael Turek wrote:
Awesome! If everyone doesn't mind the short notice, we'll have it again this 
Thursday @ 1:00 PM to 3:00 PM UTC.


++



I can provide video conferencing through hangouts here https://goo.gl/xSKBS4
Let's give that a shot this time!


Note that the last time I checked Hangouts video messaging required a 
proprietary browser plugin (and hence did not work in Firefox). Using it may 
exclude people not accepting proprietary software and/or avoiding using Chromium.




We can adjust times, tooling, and regular agenda over the next couple meetings 
and see where we settle. If anyone has any questions or suggestions, don't 
hesitate to reach out to me!


Thanks,
Mike Turek 


On 4/25/18 12:11 PM, Julia Kreger wrote:

On Mon, Apr 23, 2018 at 12:04 PM, Michael Turek
 wrote:


What does everyone think about having Bug Day the first Thursday of every
month?

All for it!

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



__
OpenStack Development Mailing 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] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

I would very much second that question! Indeed it have been one of my own
wondering since many times.

Of course GraphQL is not intended to replace REST as is and have to live in
parallel but it would likely and highly accelerate all requests within
heavily loaded environments.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
écrit :

> Hi,
>
> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
> addresses REST limitations.
> I wonder if any project has been thinking about using GraphQL. I haven't
> find any mention or pointers about it.
>
> GraphQL takes a complete different approach compared to REST. So we can
> finally forget about REST API Description languages
> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
> approach which doesn't describe how to use it).
>
> So, once passed the point where 'REST vs GraphQL' is like comparing SQL
> and no-SQL DBMS and therefore have different applications, there are no
> doubt the complexity of most OpenStack projects are good candidates for
> GraphQL.
>
> Besides topics such as efficiency, decoupling, no version management
> need there many other powerful features such as API Schema out of the
> box and better automation down that track.
>
> It looks like the dream of a conduit between API services and consumers
> might have finally come true so we could move-on an worry about other
> things.
>
> So has anyone already starting looking into it?
>
> [1]
>
> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
> [2] http://graphql.org
>
>
>
> __
> OpenStack Development Mailing 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] Thank you TryStack!!

[Jens Harbott]

2018-03-26 22:51 GMT+00:00 Jimmy Mcarthur :
> Hi everyone,
>
> We recently made the tough decision, in conjunction with the dedicated
> volunteers that run TryStack, to end the service as of March 29, 2018.  For
> those of you that used it, thank you for being part of the TryStack
> community.
>
> The good news is that you can find more resources to try OpenStack at
> http://www.openstack.org/start, including the Passport Program, where you
> can test on any participating public cloud. If you are looking to test
> different tools or application stacks with OpenStack clouds, you should
> check out Open Lab.
>
> Thank you very much to Will Foster, Kambiz Aghaiepour, Rich Bowen, and the
> many other volunteers who have managed this valuable service for the last
> several years!  Your contribution to OpenStack was noticed and appreciated
> by many in the community.

Seems it would be great if https://trystack.openstack.org/ would be
updated with this information, according to comments in #openstack
users are still landing on that page and try to get a stack there in
vain.

__
OpenStack Development Mailing 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] [watcher] May’s holidays

[Чадин Александр]

Hi Watcher team.

I won’t be available in IRC till Wednesday because of national holidays. Some 
reviews and patch sets will be done during this time.

Have a nice day!

——
Alex
__
OpenStack Development Mailing 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] Is there any way to recheck only one job?

[Jens Harbott]

2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski :
> Hi,
>
> I wonder if there is any way to recheck only one type of job instead of 
> rechecking everything.
> For example sometimes I have to debug some random failure in specific job 
> type, like „neutron-fullstack” and I want to collect some additional data or 
> test something. So in such case I push some „Do not merge” patch and waits 
> for job result - but I really don’t care about e.g. pep8 or UT results so 
> would be good is I could run (recheck) only job which I want. That could safe 
> some resources for other jobs and speed up my tests a little as I could be 
> able to recheck only my job faster :)
>
> Is there any way that I can do it with gerrit and zuul currently? Or maybe it 
> could be consider as a new feature to add? What do You think about it?

This is intentionally not implemented as it could be used to trick
patches leading to unstable behaviour into passing too easily, hiding
possible issues.

As an alternative, you could include a change to .zuul.yaml into your
test patch, removing all jobs except the one you are interested in.
This would still run the jobs defined in project-config, but may be
good enough for your scenario.

__
OpenStack Development Mailing 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] Is there any way to recheck only one job?

[Lenny Berkhovsky]

If your CI is using zuul, then you can try updating your zuul gerrit event 
comment in /etc/zuul/layout/layout.yaml accordingly.
Since most ( if not all ) Cis are triggered by 'recheck' comment you can use 
your custom one.

precedence: low
trigger:
  gerrit:
- event: patchset-created
- event: change-restored
- event: comment-added
  comment: 

Lenny

-Original Message-
From: Slawomir Kaplonski [mailto:skapl...@redhat.com] 
Sent: Monday, April 30, 2018 10:13 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] Is there any way to recheck only one job?

Hi,

I wonder if there is any way to recheck only one type of job instead of 
rechecking everything.
For example sometimes I have to debug some random failure in specific job type, 
like „neutron-fullstack” and I want to collect some additional data or test 
something. So in such case I push some „Do not merge” patch and waits for job 
result - but I really don’t care about e.g. pep8 or UT results so would be good 
is I could run (recheck) only job which I want. That could safe some resources 
for other jobs and speed up my tests a little as I could be able to recheck 
only my job faster :)

Is there any way that I can do it with gerrit and zuul currently? Or maybe it 
could be consider as a new feature to add? What do You think about it?

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev=02%7C01%7Clennyb%40mellanox.com%7C2e90994f3c63470d179108d5ae69da93%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636606692019701457=pd7%2FN8Tlpsxo7fYW7bbyy1UV4JlRTT6OWlnVp6qMZ44%3D=0
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Is there any way to recheck only one job?

[Slawomir Kaplonski]

Hi,

I wonder if there is any way to recheck only one type of job instead of 
rechecking everything.
For example sometimes I have to debug some random failure in specific job type, 
like „neutron-fullstack” and I want to collect some additional data or test 
something. So in such case I push some „Do not merge” patch and waits for job 
result - but I really don’t care about e.g. pep8 or UT results so would be good 
is I could run (recheck) only job which I want. That could safe some resources 
for other jobs and speed up my tests a little as I could be able to recheck 
only my job faster :)

Is there any way that I can do it with gerrit and zuul currently? Or maybe it 
could be consider as a new feature to add? What do You think about it?

— 
Best regards
Slawek Kaplonski
skapl...@redhat.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] [Zun][k8s] AWS Fargate and OpenStack Zun

[Kumari, Madhuri]

Thank you Hongbin. The article is very helpful.

Regards,
Madhuri

From: Hongbin Lu [mailto:hongbin...@gmail.com]
Sent: Sunday, April 29, 2018 5:16 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Zun][k8s] AWS Fargate and OpenStack Zun

Hi folks,

FYI. I wrote a blog post about a comparison between AWS Fargate and OpenStack 
Zun. It mainly covers the following:

* The basic concepts of OpenStack Zun and AWS Fargate
* The Kubernetes integration plan

Here is the link: 
https://www.linkedin.com/pulse/aws-fargate-openstack-zun-comparing-serverless-container-hongbin-lu/

Best regards,
Hongbin
__
OpenStack Development Mailing 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 23-29 April

[Paweł Suder]

Hello Team,

Last week starting from 23 April until 29 April I was bug deputy for
Neutron project.

Following bugs/RFEs were opened:

[RFE] Create host-routes for routed networks (segments)
https://bugs.launchpad.net/neutron/+bug/1766380
RFE, importance not set. Seems to be very interesting. Confirmed by
Miguel (thx!). Need to be discussed by drivers team.

Trunk Tests are failing often in dvr-multinode scenario job
https://bugs.launchpad.net/neutron/+bug/1766701
High, confirmed based on logs from failing jobs.

Periodic job * neutron-dynamic-routing-dsvm-tempest-with-ryu-master-
scenario-ipv4 fails
https://bugs.launchpad.net/neutron/+bug/1766702
High, confirmed based on logs from failing jobs.

Rally tests job is reaching job timeout often
https://bugs.launchpad.net/neutron/+bug/1766703
High, confirmed based on logs from failing jobs.

[NEED ATTENTION] the machine running dhcp agent will have very high cpu
load when start dhcp agent after the agent down more than 150 seconds
https://bugs.launchpad.net/neutron/+bug/1766812
Not yet clarified, due to scale, it will be not easy to triage it. Some
logs are attached, but still issue might be very environmental. Not
marked as confirmed, importance not set.
[OPEN QUESTION]: should be reproduced somehow?

loadbalancer can't create with chinese character name
https://bugs.launchpad.net/neutron/+bug/1767028
It could be related to Octavia. Not confirmed, do not know version of
used OpenStack. Logs from Neutron attached. Importance not set.
[OPEN QUESTION]: how to link with other project?

character of set image property multiqueue command is wrong
https://bugs.launchpad.net/neutron/+bug/1767267
Confirmed doc issue, some typos/command syntax issues. Importance not
set.

Neutron agent internal ports remain untagged for some time, which makes
them trunk ports
https://bugs.launchpad.net/neutron/+bug/1767422
Confirmed. Fix proposed.

[DVR] br-int in compute node will send unknown unicast to sg-xxx
https://bugs.launchpad.net/neutron/+bug/1767811
Clarifying.

Cheers,
Paweł

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