Re: [openstack-dev] Forum Schedule - Seeking Community Review

[Colleen Murphy]

On Mon, Oct 15, 2018, at 10:01 PM, Jimmy McArthur wrote:
> Hi -
> 
> The Forum schedule is now up 
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
> If you see a glaring content conflict within the Forum itself, please 
> let me know.
> 
> You can also view the Full Schedule in the attached PDF if that makes 
> life easier...
> 
> NOTE: BoFs and WGs are still not all up on the schedule.  No need to let 
> us know :)

Couple of things:

1. I noticed Julia's session "Community outreach when culture, time zones, and 
language differ" and Thierry's session "Getting OpenStack users involved in the 
project" are scheduled at the same time on Tuesday, but they're quite related 
topics and I think many people (especially in the TC) would want to attend both 
sessions.

2. The session "You don't know nothing about Public Cloud SDKs, yet" doesn't 
seem to have a moderator listed.

Colleen

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

[openstack-dev] [tc][all] TC Office hour time

[Ghanshyam Mann]

Hi All,

TC office hour is started on #openstack-tc channel & many of TC members (may be 
not all due to TZ) gather for next 1 hour to discuss any topic from community. 
Feel free to reach to us for anything you want discuss/input/feedback/help from 
TC.

-gmann 





__
OpenStack Development Mailing 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-community] Forum Schedule - Seeking Community Review

[Julia Kreger]

Looks Great, Thanks!

-Julia

PS - Indeed :(

On Tue, Oct 16, 2018 at 4:05 PM Jimmy McArthur  wrote:

> OK - I think I got this fixed.  I had to move a couple of things around.
> Julia, please let me know if this all works for you:
>
>
> https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=Kreger
>
> PS - You're going to have a long week :|
>
> Julia Kreger 
> October 16, 2018 at 4:44 PM
> Greetings Jimmy,
>
> Looks like it is still showing up on the schedule that way. I just
> reloaded the website page and it still has both sessions scheduled for 4:20
> PM local. Sadly, I don't have cloning technology. Perhaps someone can help
> me with that for next year? :)
>
> -Julia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Jimmy McArthur 
> October 16, 2018 at 12:15 PM
> I think you might have caught me while I was moving sessions around.  This
> shouldn't be an issue now.
>
> Thanks for checking!!
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Tim Bell 
> October 16, 2018 at 1:37 AM
> Jimmy,
>
> While it's not a clash within the forum, there are two sessions for Ironic
> scheduled at the same time on Tuesday at 14h20, each of which has Julia as
> a speaker.
>
> Tim
>
> -Original Message-
> From: Jimmy McArthur  
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  
> Date: Monday, 15 October 2018 at 22:04
> To: "OpenStack Development Mailing List (not for usage questions)"
>  ,
> "openstack-operat...@lists.openstack.org"
> 
> 
> , "commun...@lists.openstack.org"
>  
> 
> Subject: [openstack-dev] Forum Schedule - Seeking Community Review
>
> Hi -
>
> The Forum schedule is now up
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
>
> If you see a glaring content conflict within the Forum itself, please
> let me know.
>
> You can also view the Full Schedule in the attached PDF if that makes
> life easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule. No need to let
> us know :)
>
> 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
> Jimmy McArthur 
> October 15, 2018 at 3:01 PM
> Hi -
>
> The Forum schedule is now up (
> https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
> If you see a glaring content conflict within the Forum itself, please let
> me know.
>
> You can also view the Full Schedule in the attached PDF if that makes life
> easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule.  No need to let
> us know :)
>
> Cheers,
> Jimmy
> ___
> Staff mailing list
> st...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/staff
>
>
> __
> OpenStack Development Mailing 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] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

[Mohammed Naser]

I'm in support, mainly for quite a few reasons:

- The vendor data should/might need to be be released often.  If a
provider makes a change, it'd be nice that you can pick it up without
changing everything else that sits in your system (and potentially
breaking other things)
- We can add some very sort of basic gating that at least make sure
the endpoints are responding
- If we want to add a new region, we really shouldn't have to go
through many hours of OpenStack SDK jobs to pick them up

I'm all for it!
On Mon, Oct 15, 2018 at 11:04 PM Monty Taylor  wrote:
>
> Heya,
>
> Tobias and I were chatting at OpenStack Days Nordic about the Public
> Cloud Working Group potentially taking over as custodians of the vendor
> profile information [0][1] we keep in openstacksdk (and previously in
> os-client-config)
>
> I think this is a fine idea, but we've got some dancing to do I think.
>
> A few years ago Dean and I talked about splitting the vendor data into
> its own repo. We decided not to at the time because it seemed like extra
> unnecessary complication. But I think we may have reached that time.
>
> We should split out a new repo to hold the vendor data json files. We
> can manage this repo pretty much how we manage the
> service-types-authority [2] data now. Also similar to that (and similar
> to tzdata) these are files that contain information that is true
> currently and is not release specific - so it should be possible to
> update to the latest vendor files without updating to the latest
> openstacksdk.
>
> If nobody objects, I'll start working through getting a couple of new
> repos created. I'm thinking openstack/vendor-profile-data, owned/managed
> by Public Cloud WG, with the json files, docs, json schema, etc, and a
> second one, openstack/os-vendor-profiles - owned/managed by the
> openstacksdk team that's just like os-service-types [3] and is a
> tiny/thin library that exposes the files to python (so there's something
> to depend on) and gets proposed patches from zuul when new content is
> landed in openstack/vendor-profile-data.
>
> How's that sound?
>
> Thanks!
> Monty
>
> [0]
> http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors
> [1]
> https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html
> [2] http://git.openstack.org/cgit/openstack/service-types-authority
> [3] http://git.openstack.org/cgit/openstack/os-service-types
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [openstack-community] Forum Schedule - Seeking Community Review

[Jimmy McArthur]

OK - I think I got this fixed.  I had to move a couple of things around. 
Julia, please let me know if this all works for you:


https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=Kreger

PS - You're going to have a long week :|


Julia Kreger 
October 16, 2018 at 4:44 PM
Greetings Jimmy,

Looks like it is still showing up on the schedule that way. I just 
reloaded the website page and it still has both sessions scheduled for 
4:20 PM local. Sadly, I don't have cloning technology. Perhaps someone 
can help me with that for next year? :)


-Julia


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
October 16, 2018 at 12:15 PM
I think you might have caught me while I was moving sessions around.  
This shouldn't be an issue now.


Thanks for checking!!


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Tim Bell 
October 16, 2018 at 1:37 AM
Jimmy,

While it's not a clash within the forum, there are two sessions for 
Ironic scheduled at the same time on Tuesday at 14h20, each of which 
has Julia as a speaker.


Tim

-Original Message-
From: Jimmy McArthur 
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)" 

Date: Monday, 15 October 2018 at 22:04
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
"openstack-operat...@lists.openstack.org" 
, 
"commun...@lists.openstack.org" 

Subject: [openstack-dev] Forum Schedule - Seeking Community Review

Hi -

The Forum schedule is now up
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262). 


If you see a glaring content conflict within the Forum itself, please
let me know.

You can also view the Full Schedule in the attached PDF if that makes
life easier...

NOTE: BoFs and WGs are still not all up on the schedule. No need to let
us know :)

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
Jimmy McArthur 
October 15, 2018 at 3:01 PM
Hi -

The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
If you see a glaring content conflict within the Forum itself, please 
let me know.


You can also view the Full Schedule in the attached PDF if that makes 
life easier...


NOTE: BoFs and WGs are still not all up on the schedule.  No need to 
let us know :)


Cheers,
Jimmy
___
Staff mailing list
st...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/staff


__
OpenStack Development Mailing 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-community] Forum Schedule - Seeking Community Review

[Jimmy McArthur]

Doh! You seriously need it!  Working on a fix :)


Julia Kreger 
October 16, 2018 at 4:44 PM
Greetings Jimmy,

Looks like it is still showing up on the schedule that way. I just 
reloaded the website page and it still has both sessions scheduled for 
4:20 PM local. Sadly, I don't have cloning technology. Perhaps someone 
can help me with that for next year? :)


-Julia


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
October 16, 2018 at 12:15 PM
I think you might have caught me while I was moving sessions around.  
This shouldn't be an issue now.


Thanks for checking!!


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Tim Bell 
October 16, 2018 at 1:37 AM
Jimmy,

While it's not a clash within the forum, there are two sessions for 
Ironic scheduled at the same time on Tuesday at 14h20, each of which 
has Julia as a speaker.


Tim

-Original Message-
From: Jimmy McArthur 
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)" 

Date: Monday, 15 October 2018 at 22:04
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
"openstack-operat...@lists.openstack.org" 
, 
"commun...@lists.openstack.org" 

Subject: [openstack-dev] Forum Schedule - Seeking Community Review

Hi -

The Forum schedule is now up
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262). 


If you see a glaring content conflict within the Forum itself, please
let me know.

You can also view the Full Schedule in the attached PDF if that makes
life easier...

NOTE: BoFs and WGs are still not all up on the schedule. No need to let
us know :)

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
Jimmy McArthur 
October 15, 2018 at 3:01 PM
Hi -

The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
If you see a glaring content conflict within the Forum itself, please 
let me know.


You can also view the Full Schedule in the attached PDF if that makes 
life easier...


NOTE: BoFs and WGs are still not all up on the schedule.  No need to 
let us know :)


Cheers,
Jimmy
___
Staff mailing list
st...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/staff


__
OpenStack Development Mailing 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-community] Forum Schedule - Seeking Community Review

[Julia Kreger]

Greetings Jimmy,

Looks like it is still showing up on the schedule that way. I just reloaded
the website page and it still has both sessions scheduled for 4:20 PM
local. Sadly, I don't have cloning technology. Perhaps someone can help me
with that for next year? :)

-Julia


On Tue, Oct 16, 2018 at 11:15 AM Jimmy McArthur  wrote:

> I think you might have caught me while I was moving sessions around.  This
> shouldn't be an issue now.
>
> Thanks for checking!!
>
> Tim Bell 
> October 16, 2018 at 1:37 AM
> Jimmy,
>
> While it's not a clash within the forum, there are two sessions for Ironic
> scheduled at the same time on Tuesday at 14h20, each of which has Julia as
> a speaker.
>
> Tim
>
> -Original Message-
> From: Jimmy McArthur  
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  
> Date: Monday, 15 October 2018 at 22:04
> To: "OpenStack Development Mailing List (not for usage questions)"
>  ,
> "openstack-operat...@lists.openstack.org"
> 
> 
> , "commun...@lists.openstack.org"
>  
> 
> Subject: [openstack-dev] Forum Schedule - Seeking Community Review
>
> Hi -
>
> The Forum schedule is now up
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
>
> If you see a glaring content conflict within the Forum itself, please
> let me know.
>
> You can also view the Full Schedule in the attached PDF if that makes
> life easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule. No need to let
> us know :)
>
> Cheers,
> Jimmy
>
>
> ___
> Community mailing list
> commun...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/community
> Jimmy McArthur 
> October 15, 2018 at 3:01 PM
> Hi -
>
> The Forum schedule is now up (
> https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
> If you see a glaring content conflict within the Forum itself, please let
> me know.
>
> You can also view the Full Schedule in the attached PDF if that makes life
> easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule.  No need to let
> us know :)
>
> Cheers,
> Jimmy
> ___
> Staff mailing list
> st...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/staff
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] [requirements] Stepping down as core reviewer

[Sean McGinnis]

On Tue, Oct 16, 2018 at 06:03:54PM +0530, ʂʍɒρƞįł Ҟưȴķɒʁʉɨ wrote:
> Dear OpenStackers,
> 
> For a few months now, I am not able to contribute to code or reviewing
> Kolla and Requirements actively given my current responsibilities, I
> would like to take a step back and release my core reviewer ability
> for the Kolla and Requirements repositories.
> 
> I want to use this moment to thank the everyone I have had a chance to
> work alongside with and I may have troubled. It has been both an honor
> and privilege to serve this community and I will continue to do so.
> 
> In the new cloudy world I am sure the paths will cross again. Till
> then, Sayo Nara, Take Care.
> 
> Best Regards,
> Swapnil (coolsvap)
> 

Thanks for all you've been able to do Swapnil!

Sean

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

Re: [openstack-dev] [placement] devstack, grenade, database management

[Matt Riedemann]

On 10/16/2018 5:48 AM, Chris Dent wrote:

* We need to address database creation scripts and database migrations.

   There's a general consensus that we should use alembic, and start
   things from a collapsed state. That is, we don't need to represent
   already existing migrations in the new repo, just the present-day
   structure of the tables.

   Right now the devstack code relies on a stubbed out command line
   tool at https://review.openstack.org/#/c/600161/ to create tables
   with a metadata.create_all(). This is a useful thing to have but
   doesn't follow the "db_sync" pattern set elsewhere, so I haven't
   followed through on making it pretty but can do so if people think
   it is useful. Whether we do that or not, we'll still need some
   kind of "db_sync" command. Do people want me to make a cleaned up
   "create" command?

   Ed has expressed some interest in exploring setting up alembic and
   the associated tools but that can easily be a more than one person
   job. Is anyone else interested?

It would be great to get all this stuff working sooner than later.
Without it we can't do two important tasks:

* Integration tests with the extracted placement [1].
* Hacking on extracted placement in/with devstack.


Another thing that came up today in IRC [1] which is maybe not as 
obvious from this email is what happens with the one online data 
migration we have for placement (create_incomplete_consumers). If we 
drop that online data migration from the placement repo, then ideally 
we'd have something to check it's done before people upgrade to stein 
and the extracted placement repo. There are some options there: 
placement-manage db sync could fail if there are missing consumers or we 
could simply have a placement-status upgrade check for it.




Another issue that needs some attention, but is not quite as urgent
is the desire to support other databases during the upgrade,
captured in this change

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


I have a grenade patch to test the postgresql-migrate-db.sh script now. [2]

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-10-16.log.html#t2018-10-16T19:37:25

[2] https://review.openstack.org/#/c/611020/

--

Thanks,

Matt

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

[openstack-dev] [nova] spec review day is ON for next tuesday oct 23

[melanie witt]

Thanks everyone for your replies on the thread to help organize this.

Looks like most of the team is available to participate, so we will have 
a spec review day next week on Tuesday October 23.


See ya at the nova-specs gerrit,
-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] Ops Meetups - Call for Hosts

[Erik McCormick]

Hello all,

The Ops Meetup team has embarked on a mission to revive the
traditional Operators Meetup that have historically been held between
Summits. With the upcoming merger of the PTG into the Summit week, and
the merger of most Ops discussion sessions at Summits into the Forum,
we felt that we needed to get back to our original format.

With that in mind, we are beginning the process of selecting venues
for both 2019 Meetups. Some guidelines for what is needed to host can
be found here:
https://wiki.openstack.org/wiki/Operations/Meetups#Venue_Selection

Each of the etherpads below contains a template to collect information
about the potential host and venue. If you are interested in hosting a
meetup, simply copy and paste the template into a blank etherpad, fill
it out, and place a link above the template on the original etherpad.

Ops Meetup 2019 #1 - Late February / Early March - Somewhere in Europe
https://etherpad.openstack.org/p/ops-meetup-venue-discuss-1st-2019

Ops Meetup 2019 #2 - Late July / Early August - Somewhere in North America
https://etherpad.openstack.org/p/ops-meetup-venue-discuss-2nd-2019

Reply back to this thread with any questions or comments. If you are
coming to the Berlin Summit, we will be having an Ops Meetup Team
catch-up Forum session. We encourage all of you to join in making
these events a success.

Cheers,
Erik

__
OpenStack Development Mailing 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-community] Forum Schedule - Seeking Community Review

[Jimmy McArthur]

I think you might have caught me while I was moving sessions around.  
This shouldn't be an issue now.


Thanks for checking!!


Tim Bell 
October 16, 2018 at 1:37 AM
Jimmy,

While it's not a clash within the forum, there are two sessions for 
Ironic scheduled at the same time on Tuesday at 14h20, each of which 
has Julia as a speaker.


Tim

-Original Message-
From: Jimmy McArthur 
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)" 

Date: Monday, 15 October 2018 at 22:04
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
"openstack-operat...@lists.openstack.org" 
, 
"commun...@lists.openstack.org" 

Subject: [openstack-dev] Forum Schedule - Seeking Community Review

Hi -

The Forum schedule is now up
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262). 


If you see a glaring content conflict within the Forum itself, please
let me know.

You can also view the Full Schedule in the attached PDF if that makes
life easier...

NOTE: BoFs and WGs are still not all up on the schedule. No need to let
us know :)

Cheers,
Jimmy


___
Community mailing list
commun...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/community
Jimmy McArthur 
October 15, 2018 at 3:01 PM
Hi -

The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
If you see a glaring content conflict within the Forum itself, please 
let me know.


You can also view the Full Schedule in the attached PDF if that makes 
life easier...


NOTE: BoFs and WGs are still not all up on the schedule.  No need to 
let us know :)


Cheers,
Jimmy
___
Staff mailing list
st...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/staff


__
OpenStack Development Mailing 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] [requirements] Stepping down as core reviewer

[Matthew Thode]

On 18-10-16 18:03:54, ʂʍɒρƞįł Ҟưȴķɒʁʉɨ wrote:
> Dear OpenStackers,
> 
> For a few months now, I am not able to contribute to code or reviewing
> Kolla and Requirements actively given my current responsibilities, I
> would like to take a step back and release my core reviewer ability
> for the Kolla and Requirements repositories.
> 
> I want to use this moment to thank the everyone I have had a chance to
> work alongside with and I may have troubled. It has been both an honor
> and privilege to serve this community and I will continue to do so.
> 
> In the new cloudy world I am sure the paths will cross again. Till
> then, Sayo Nara, Take Care.
> 

Sad to see you go, hope to see you around though.  Good luck on your
journey.  It was nice working with you.

-- 
Matthew Thode (prometheanfire)


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] [kolla] [requirements] Stepping down as core reviewer

[Steven Dake (stdake)]

Swapnil,

Pleasure working with you - hope to see you around the computerverse.

Cheers
-steve


On 10/16/18, 5:34 AM, "ʂʍɒρƞįł Ҟưȴķɒʁʉɨ"  wrote:

Dear OpenStackers,

For a few months now, I am not able to contribute to code or reviewing
Kolla and Requirements actively given my current responsibilities, I
would like to take a step back and release my core reviewer ability
for the Kolla and Requirements repositories.

I want to use this moment to thank the everyone I have had a chance to
work alongside with and I may have troubled. It has been both an honor
and privilege to serve this community and I will continue to do so.

In the new cloudy world I am sure the paths will cross again. Till
then, Sayo Nara, Take Care.

Best Regards,
Swapnil (coolsvap)

__
OpenStack Development Mailing 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] [python3] Enabling py37 unit tests

[Corey Bryant]

On Tue, Oct 16, 2018 at 10:58 AM Zane Bitter  wrote:

> On 15/10/18 8:00 PM, Monty Taylor wrote:
> > On 10/15/2018 06:39 PM, Zane Bitter wrote:
> >>
> >> In fact, as far as we know the version we have to support in CentOS
> >> may actually be 3.5, which seems like a good reason to keep it working
> >> for long enough that we can find out for sure one way or the other.
> >
> > I certainly hope this is not what ends up happening, but seeing as how I
> > actually do not know - I agree, I cannot discount the possibility that
> > such a thing would happen.
>
> I'm right there with ya.
>
> > That said - until such a time as we get to actually drop python2, I
> > don't see it as an actual issue. The reason being - if we test with 2.7
> > and 3.7 - the things in 3.6 that would break 3.5 get gated by the
> > existence of 2.7 for our codebase.
> >
> > Case in point- the instant 3.6 is our min, I'm going to start replacing
> > every instance of:
> >
> >"foo {bar}".format(bar=bar)
> >
> > in any code I spend time in with:
> >
> >f"foo {bar}"
> >
> > It TOTALLY won't parse on 3.5 ... but it also won't parse on 2.7.
> >
> > If we decide as a community to shift our testing of python3 to be 3.6 -
> > or even 3.7 - as long as we still are testing 2.7, I'd argue we're
> > adequately covered for 3.5.
>
> Yeah, that is a good point. There are only a couple of edge-case
> scenarios where that might not prove to be the case. One is where we
> install a different (or a different version of a) 3rd-party library on
> py2 vs. py3. The other would be where you have some code like:
>
>if six.PY3:
>   some_std_lib_function_added_in_3_6()
>else:
>   py2_code()
>
> It may well be that we can say this is niche enough that we don't care.
>
> In theory the same thing could happen between versions of python3 (e.g.
> if we only tested on 3.5 & 3.7, and not 3.6). There certainly exist
> places where we check the minor version.* However, that's so much less
> likely again that it definitely seems negligible.
>
> * e.g.
>
> https://git.openstack.org/cgit/openstack/oslo.service/tree/oslo_service/service.py#n207
>
> > The day we decide we can drop 2.7 - if we've been testing 3.7 for
> > python3 and it turns out RHEL/CentOS 8 ship with python 3.5, then
> > instead of just deleting all of the openstack-tox-py27 jobs, we'd
> > probably just need to replace them with openstack-tox-py35 jobs, as that
> > would be our new low-water mark.
> >
> > Now, maybe we'll get lucky and RHEL/CentOS 8 will be a future-looking
> > release and will ship with python 3.7 AND so will the corresponding
> > Ubuntu LTS - and we'll get to only care about one release of python for
> > a minute. :)
> >
> > Come on - I can dream, right?
>
> Sure, but let's not get complacent - 3.8 is right around the corner :)
>
>
Btw I confirmed this morning that the plan for 20.04 LTS is to have 3.8, so
it really is around the corner.

Thanks,
Corey

cheers,
> Zane.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Forum Schedule - Seeking Community Review

[Sean McGinnis]

On Mon, Oct 15, 2018 at 03:01:07PM -0500, Jimmy McArthur wrote:
> Hi -
> 
> The Forum schedule is now up
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
> If you see a glaring content conflict within the Forum itself, please let me
> know.
> 

I have updated the Forum wiki page in preparation for the topic etherpads:

https://wiki.openstack.org/wiki/Forum/Berlin2018

Please add your working session etherpad links once they are available so
everyone has one spot to go to to find all relevant links.

Thanks!
Sean

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

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

[Lance Bragstad]

It happened. Documentation is hot off the press and ready for you to read
[0]. As always, feel free to raise concerns, comments, or questions any
time.

I appreciate everyone's help in nailing this down.

[0]
https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies

On Sat, Oct 13, 2018 at 6:07 AM Ghanshyam Mann 
wrote:

>   On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad <
> lbrags...@gmail.com> wrote 
>  > Sending a follow up here quick.
>  > The reviewers actively participating in [0] are nearing a conclusion.
> Ultimately, the convention is going to be:
>  >
>  
> :[:][:]:[:]
>  > Details about what that actually means can be found in the review [0].
> Each piece is denoted as being required or optional, along with examples. I
> think this gives us a pretty good starting place, and the syntax is
> flexible enough to support almost every policy naming convention we've
> stumbled across.
>  > Now is the time if you have any final input or feedback. Thanks for
> sticking with the discussion.
>
> Thanks Lance for working on this. Current version lgtm. I would like to
> see some operators feedback also if  this standard policy name format is
> clear and easy understandable.
>
> -gmann
>
>  > Lance
>  > [0] https://review.openstack.org/#/c/606214/
>  >
>  > On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad 
> wrote:
>  >
>  > On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann 
> wrote:
>  >   On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
> lbrags...@gmail.com> wrote 
>  >   >
>  >   > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki 
> wrote:
>  >   > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
>  >   >   wrote:
>  >   >  >
>  >   >  > Ideally I would like to see it in the form of least specific to
> most specific. But more importantly in a way that there is no additional
> delimiters between the service type and the resource. Finally, I do not
> like the change of plurality depending on action type.
>  >   >  >
>  >   >  > I propose we consider
>  >   >  >
>  >   >  > ::[:]
>  >   >  >
>  >   >  > Example for keystone (note, action names below are strictly
> examples I am fine with whatever form those actions take):
>  >   >  > identity:projects:create
>  >   >  > identity:projects:delete
>  >   >  > identity:projects:list
>  >   >  > identity:projects:get
>  >   >  >
>  >   >  > It keeps things simple and consistent when you're looking
> through overrides / defaults.
>  >   >  > --Morgan
>  >   >  +1 -- I think the ordering if `resource` comes before
>  >   >  `action|subaction` will be more clean.
>  >   >
>  >   > ++
>  >   > These are excellent points. I especially like being able to omit
> the convention about plurality. Furthermore, I'd like to add that I think
> we should make the resource singular (e.g., project instead or projects).
> For example:
>  >   > compute:server:list
>  >   >
> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize
> (or confirm-resize)
>  >
>  >  Do we need "action" word there? I think action name itself should
> convey the operation. IMO below notation without "äction" word looks clear
> enough. what you say?
>  >
>  >  compute:server:reboot
>  >  compute:server:confirm_resize
>  >
>  > I agree. I simplified this in the current version up for review.
>  >  -gmann
>  >
>  >   >
>  >   > Otherwise, someone might mistake compute:servers:get, as "list".
> This is ultra-nick-picky, but something I thought of when seeing the usage
> of "get_all" in policy names in favor of "list."
>  >   > In summary, the new convention based on the most recent feedback
> should be:
>  >   > ::[:]
>  >   > Rules:service-type is always defined in the service types authority
>  >   > resources are always singular
>  >   > Thanks to all for sticking through this tedious discussion. I
> appreciate it.
>  >   >  /R
>  >   >
>  >   >  Harry
>  >   >  >
>  >   >  > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <
> lbrags...@gmail.com> wrote:
>  >   >  >>
>  >   >  >> Bumping this thread again and proposing two conventions based
> on the discussion here. I propose we decide on one of the two following
> conventions:
>  >   >  >>
>  >   >  >> ::
>  >   >  >>
>  >   >  >> or
>  >   >  >>
>  >   >  >> :_
>  >   >  >>
>  >   >  >> Where  is the corresponding service type of the
> project [0], and  is either create, get, list, update, or delete. I
> think decoupling the method from the policy name should aid in consistency,
> regardless of the underlying implementation. The HTTP method specifics can
> still be relayed using oslo.policy's DocumentedRuleDefault object [1].
>  >   >  >>
>  >   >  >> I think the plurality of the resource should default to what
> makes sense for the operation being carried out (e.g., list:foobars,
> create:foobar).
>  >   >  >>
>  >   >  >> I don't mind the first one because it's clear about what the
> delimiter is and it doesn't look weird when projects have 

[openstack-dev] [publiccloud-wg] Reminder weekly meeting Public Cloud WG

[Tobias Rydberg]

Hi everyone,

Time for a new meeting for PCWG - tomorrow Wednesday 0700 UTC in 
#openstack-publiccloud! Agenda found at 
https://etherpad.openstack.org/p/publiccloud-wg


Cheers,
Tobias

--
Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


__
OpenStack Development Mailing 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] [python3] Enabling py37 unit tests

[Zane Bitter]

On 15/10/18 8:00 PM, Monty Taylor wrote:

On 10/15/2018 06:39 PM, Zane Bitter wrote:


In fact, as far as we know the version we have to support in CentOS 
may actually be 3.5, which seems like a good reason to keep it working 
for long enough that we can find out for sure one way or the other.


I certainly hope this is not what ends up happening, but seeing as how I 
actually do not know - I agree, I cannot discount the possibility that 
such a thing would happen.


I'm right there with ya.

That said - until such a time as we get to actually drop python2, I 
don't see it as an actual issue. The reason being - if we test with 2.7 
and 3.7 - the things in 3.6 that would break 3.5 get gated by the 
existence of 2.7 for our codebase.


Case in point- the instant 3.6 is our min, I'm going to start replacing 
every instance of:


   "foo {bar}".format(bar=bar)

in any code I spend time in with:

   f"foo {bar}"

It TOTALLY won't parse on 3.5 ... but it also won't parse on 2.7.

If we decide as a community to shift our testing of python3 to be 3.6 - 
or even 3.7 - as long as we still are testing 2.7, I'd argue we're 
adequately covered for 3.5.


Yeah, that is a good point. There are only a couple of edge-case 
scenarios where that might not prove to be the case. One is where we 
install a different (or a different version of a) 3rd-party library on 
py2 vs. py3. The other would be where you have some code like:


  if six.PY3:
 some_std_lib_function_added_in_3_6()
  else:
 py2_code()

It may well be that we can say this is niche enough that we don't care.

In theory the same thing could happen between versions of python3 (e.g. 
if we only tested on 3.5 & 3.7, and not 3.6). There certainly exist 
places where we check the minor version.* However, that's so much less 
likely again that it definitely seems negligible.


* e.g. 
https://git.openstack.org/cgit/openstack/oslo.service/tree/oslo_service/service.py#n207


The day we decide we can drop 2.7 - if we've been testing 3.7 for 
python3 and it turns out RHEL/CentOS 8 ship with python 3.5, then 
instead of just deleting all of the openstack-tox-py27 jobs, we'd 
probably just need to replace them with openstack-tox-py35 jobs, as that 
would be our new low-water mark.


Now, maybe we'll get lucky and RHEL/CentOS 8 will be a future-looking 
release and will ship with python 3.7 AND so will the corresponding 
Ubuntu LTS - and we'll get to only care about one release of python for 
a minute. :)


Come on - I can dream, right?


Sure, but let's not get complacent - 3.8 is right around the corner :)

cheers,
Zane.

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

[openstack-dev] [goals][upgrade-checkers] Call for Volunteers to work on upgrade-checkers stein goal

[Ghanshyam Mann]

Hi All,

I was discussing with mriedem [1] about idea of building a volunteer team which 
can work with him on upgrade-checkers goal [2]. There are lot of work needed 
for this goal[3], few projects which does not have upgrade impact yet needs CLI 
framework with placeholder only and other projects with upgrade impact need 
actual upgrade checks implementation.

Idea is to build the volunteer team who can work with goal champion to finish 
the work early. This will help to share some work from goal champion as well 
from project side.

 - This email is request to call for volunteers (upstream developers from any 
projects) who can work closely with mriedem on upgrade-checkers goal.
 - Currently two developers has volunteered.  
1. Akhil Jain (IRC: akhil_jain, email: akhil.j...@india.nec.com) 
2. Rajat Dhasmana (IRC: whoami-rajat email: rajatdhasm...@gmail.com)
 - Anyone who would like to help on this work, feel free to reply this email or 
ping mriedem  on IRC. 
 - As next step, mriedem will plan the work distribution to volunteers. 

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-16.log.html#t2018-10-16T13:37:59
 
[2] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html
[3] https://storyboard.openstack.org/#!/story/2003657

-gmann 





__
OpenStack Development Mailing 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] [oslo][glance][cinder][nova][keystone] healthcheck

[Florian Engelmann]

Thank you very much for your detailed answer. Keystone healthcheck is 
working fine and as you said out of the box. I got trouble with, eg. 
neutron-server and cinder-api. While nova is happy with:


[filter:healthcheck]
paste.filter_factory = oslo_middleware:Healthcheck.factory
backends = disable_by_file
disable_by_file_path = /var/log/kolla/nova/healthcheck_disable

and some changes to the pipeline:

[pipeline:oscomputeversions]
pipeline = healthcheck cors faultwrap request_log http_proxy_to_wsgi 
oscomputeversionapp



I was not able to get the same thing working with neutron-server as it's 
paste configuration is very different:


[composite:neutron]
use = egg:Paste#urlmap
/: neutronversions_composite
/v2.0: neutronapi_v2_0

[composite:neutronapi_v2_0]
use = call:neutron.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id catch_errors extensions 
neutronapiapp_v2_0
keystone = cors http_proxy_to_wsgi request_id catch_errors authtoken 
keystonecontext extensions neutronapiapp_v2_0


[composite:neutronversions_composite]
use = call:neutron.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi neutronversions
keystone = cors http_proxy_to_wsgi neutronversions

[filter:request_id]
paste.filter_factory = oslo_middleware:RequestId.factory

[filter:catch_errors]
paste.filter_factory = oslo_middleware:CatchErrors.factory

[filter:cors]
paste.filter_factory = oslo_middleware.cors:filter_factory
oslo_config_project = neutron

[filter:http_proxy_to_wsgi]
paste.filter_factory = 
oslo_middleware.http_proxy_to_wsgi:HTTPProxyToWSGI.factory


[filter:keystonecontext]
paste.filter_factory = neutron.auth:NeutronKeystoneContext.factory

[filter:authtoken]
paste.filter_factory = keystonemiddleware.auth_token:filter_factory

[filter:extensions]
paste.filter_factory = 
neutron.api.extensions:plugin_aware_extension_middleware_factory


[app:neutronversions]
paste.app_factory = neutron.pecan_wsgi.app:versions_factory

[app:neutronapiapp_v2_0]
paste.app_factory = neutron.api.v2.router:APIRouter.factory

[filter:osprofiler]
paste.filter_factory = osprofiler.web:WsgiMiddleware.factory

#[filter:healthcheck]
#paste.filter_factory = oslo_middleware:Healthcheck.factory
#backends = disable_by_file
#disable_by_file_path = /var/log/kolla/neutron/healthcheck_disable

I did read the oslo middleware documentation a couple of times but I 
still don't get what to do to enable the healthcheck API with 
neutron-server.


Is there any "tutorial" that could help?


Am 10/12/18 um 7:50 PM schrieb Morgan Fainberg:
Keystone no longer uses paste (since Rocky) as paste is unmaintained. 
The healthcheck app is permanently enabled for keystone at 
/healthcheck. We chose to make it a default bit of 
functionality in how we have Keystone deployed. We also have unit tests 
in place to ensure we don't regress and healthcheck changes behavior 
down the line (future releases). You should be able to configure 
additional bits for healthcheck in keystone.conf (e.g. detailed mode, 
disable-by-file, etc).


Cheers,
--Morgan

On Fri, Oct 12, 2018 at 3:07 AM Florian Engelmann 
mailto:florian.engelm...@everyware.ch>> 
wrote:


Hi,

I tried to configure the healthcheck framework (/healthcheck) for nova,
cinder, glance and keystone but it looks like paste is not used with
keystone anymore?


https://github.com/openstack/keystone/commit/8bf335bb015447448097a5c08b870da8e537a858

In our rocky deployment the healthcheck is working for keystone only
and
I failed to configure it for, eg. nova-api.

Nova seems to use paste?

Is there any example nova api-paste.ini with the olso healthcheck
middleware enabled? To documentation is hard to understand - at least
for me.

Thank you for your help.

All the best,
Florian
__
OpenStack Development Mailing 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



--

EveryWare AG
Florian Engelmann
Systems Engineer
Zurlindenstrasse 52a
CH-8003 Zürich

tel: +41 44 466 60 00
fax: +41 44 466 60 10
mail: mailto:florian.engelm...@everyware.ch
web: http://www.everyware.ch


smime.p7s
Description: S/MIME cryptographic 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] [python3] Enabling py37 unit tests

[Monty Taylor]

On 10/15/2018 08:24 PM, Tim Burke wrote:


On Oct 15, 2018, at 5:00 PM, Monty Taylor > wrote:


If we decide as a community to shift our testing of python3 to be 3.6 
- or even 3.7 - as long as we still are testing 2.7, I'd argue we're 
adequately covered for 3.5.


That's not enough for me to be willing to declare support. I'll grant 
that we'd catch the obvious SyntaxErrors, but that could be achieved 
just as easily (and probably more cheaply, resource-wise) with multiple 
linter jobs. The reason you want unit tests to actually run is to catch 
the not-so-obvious bugs.


For example: there are a bunch of places in Swift's proxy-server where 
we get a JSON response from a backend server, loads() it up, and do some 
work based on it. As I've been trying to get the proxy ported to py3, I 
keep writing json.loads(rest.body.decode()). I'll sometimes get pushback 
from reviewers saying this shouldn't be necessary, and then I need to 
point out that while json.loads() is happy to accept either bytes or 
unicode on both py27 and py36, bytes will cause a TypeError on py35. And 
since https://bugs.python.org/issue17909 was termed an enhancement and 
not a regression (I guess the contract is str-or-unicode, for whatever 
str is?), I'm not expecting a backport.


TLDR; if we want to say that something works, best to actually test that 
it works. I might be willing to believe that py35 and py37 working 
implies that py36 will work, but py27 -> py3x tells me little about 
whether py3w works for any w < x.


Fair point - you've convinced 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] [all] Pycharm

[ʂʍɒρƞįł Ҟưȴķɒʁʉɨ]

I will continue to be maintaining PyCharm community edition licenses
for active OpenStack community contributors. If you have additional
queries, please refer [1] for additional details or shoot me an email,
I am happy to assist.

Best Regards,
Swapnil

[1] https://wiki.openstack.org/wiki/Pycharm

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

[openstack-dev] [kolla] [requirements] Stepping down as core reviewer

[ʂʍɒρƞįł Ҟưȴķɒʁʉɨ]

Dear OpenStackers,

For a few months now, I am not able to contribute to code or reviewing
Kolla and Requirements actively given my current responsibilities, I
would like to take a step back and release my core reviewer ability
for the Kolla and Requirements repositories.

I want to use this moment to thank the everyone I have had a chance to
work alongside with and I may have troubled. It has been both an honor
and privilege to serve this community and I will continue to do so.

In the new cloudy world I am sure the paths will cross again. Till
then, Sayo Nara, Take Care.

Best Regards,
Swapnil (coolsvap)

__
OpenStack Development Mailing 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] [placement] devstack, grenade, database management

[Chris Dent]

TL;DR: We need reviews on
https://review.openstack.org/#/q/topic:cd/placement-solo+status:open
and work on database management command line tools. More detail
within.

The stack of code, mostly put together by Matt, to get migrating
placement-in-nova to placement-in-placement working is passing its
tests. You can see the remaining pieces of not yet merged code at

https://review.openstack.org/#/q/topic:cd/placement-solo+status:open

Once that is fully merged, the first bullet point on the extraction
plan at


http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html

will be complete and we'll have a model for how the next two bullet
points can be done.

At this time, there are two main sticking points to getting things
merged:

* The devstack, grenade, and devstack-gate changes need some review
  to make sure that some of the tricks Matt and I performed are
  acceptable to everyone. They are at:

  https://review.openstack.org/600162
  https://review.openstack.org/604454
  https://review.openstack.org/606853

* We need to address database creation scripts and database migrations.

  There's a general consensus that we should use alembic, and start
  things from a collapsed state. That is, we don't need to represent
  already existing migrations in the new repo, just the present-day
  structure of the tables.

  Right now the devstack code relies on a stubbed out command line
  tool at https://review.openstack.org/#/c/600161/ to create tables
  with a metadata.create_all(). This is a useful thing to have but
  doesn't follow the "db_sync" pattern set elsewhere, so I haven't
  followed through on making it pretty but can do so if people think
  it is useful. Whether we do that or not, we'll still need some
  kind of "db_sync" command. Do people want me to make a cleaned up
  "create" command?

  Ed has expressed some interest in exploring setting up alembic and
  the associated tools but that can easily be a more than one person
  job. Is anyone else interested?

It would be great to get all this stuff working sooner than later.
Without it we can't do two important tasks:

* Integration tests with the extracted placement [1].
* Hacking on extracted placement in/with devstack.

Another issue that needs some attention, but is not quite as urgent
is the desire to support other databases during the upgrade,
captured in this change

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

[1] There's a stack of code for enabling placement integration tests
starting at https://review.openstack.org/#/c/601614/ . It depends on
the devstack changes.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] [goals][upgrade-checkers] Week R-26 Update

[Ghanshyam Mann]

  On Sat, 13 Oct 2018 07:05:53 +0900 Matt Riedemann  
wrote  
 > The big update this week is version 0.1.0 of oslo.upgradecheck was 
 > released. The documentation along with usage examples can be found here 
 > [1]. A big thanks to Ben Nemec for getting that done since a few 
 > projects were waiting for it.
 > 
 > In other updates, some changes were proposed in other projects [2].
 > 
 > And finally, Lance Bragstad and I had a discussion this week [3] about 
 > the validity of upgrade checks looking for deleted configuration 
 > options. The main scenario I'm thinking about here is FFU where someone 
 > is going from Mitaka to Pike. Let's say a config option was deprecated 
 > in Newton and then removed in Ocata. As the operator is rolling through 
 > from Mitaka to Pike, they might have missed the deprecation signal in 
 > Newton and removal in Ocata. Does that mean we should have upgrade 
 > checks that look at the configuration for deleted options, or options 
 > where the deprecated alias is removed? My thought is that if things will 
 > not work once they get to the target release and restart the service 
 > code, which would definitely impact the upgrade, then checking for those 
 > scenarios is probably OK. If on the other hand the removed options were 
 > just tied to functionality that was removed and are otherwise not 
 > causing any harm then I don't think we need a check for that. It was 
 > noted that oslo.config has a new validation tool [4] so that would take 
 > care of some of this same work if run during upgrades. So I think 
 > whether or not an upgrade check should be looking for config option 
 > removal ultimately depends on the severity of what happens if the manual 
 > intervention to handle that removed option is not performed. That's 
 > pretty broad, but these upgrade checks aren't really set in stone for 
 > what is applied to them. I'd like to get input from others on this, 
 > especially operators and if they would find these types of checks useful.
 > 
 > [1] https://docs.openstack.org/oslo.upgradecheck/latest/
 > [2] https://storyboard.openstack.org/#!/story/2003657
 > [3] 
 > http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-10-10.log.html#t2018-10-10T15:17:17
 > [4] 
 > http://lists.openstack.org/pipermail/openstack-dev/2018-October/135688.html

Other point is about policy change and how we should accommodate those in 
upgrade-checks.

There are below categorization of policy changes:
1. Policy rule name has been changed. 
Upgrade Impact: If that policy rule is overridden in policy.json then, yes 
we need to tell this in upgrade-check CLI. If not overridden which means 
operators depends on policy in code then, it would not impact their upgrade. 
2. Policy rule (deprecated) has been removed
Upgrade Impact: YES, as it can impact their API access after upgrade.  This 
needs to be cover in upgrade-checks
3. Default value (including scope) of Policy rule has been changed
Upgrade Impact: YES, this can change the access level of their API after 
upgrade. This needs to be cover in upgrade-checks
4. New Policy rule introduced
Upgrade Impact: YES, same reason. 

 I think policy changes can be added in upgrade checker by checking all the 
above category because everything will impact upgrade? 

For Example, cinder policy change [1]:

"Add granularity to the volume_extension:volume_type_encryption policy with the 
addition of distinct actions for create, get, update, and delete:

volume_extension:volume_type_encryption:create
volume_extension:volume_type_encryption:get
volume_extension:volume_type_encryption:update
volume_extension:volume_type_encryption:delete
To address backwards compatibility, the new rules added to the volume_type.py 
policy file, default to the existing rule, 
volume_extension:volume_type_encryption, if it is set to a non-default value. "

[1] https://docs.openstack.org/releasenotes/cinder/unreleased.html#upgrade-notes

-gmann

 > 
 > -- 
 > 
 > Thanks,
 > 
 > Matt
 > 
 > ___
 > OpenStack-operators mailing list
 > openstack-operat...@lists.openstack.org
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 > 



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

Re: [openstack-dev] [nova] shall we do a spec review day next tuesday oct 23?

[Stephen Finucane]

On Mon, 2018-10-15 at 10:07 -0700, melanie witt wrote:
> Hey all,
> 
> Milestone s-1 is coming up next week on Thursday Oct 25 [1] and I was 
> thinking it would be a good idea to have a spec review day next week on 
> Tuesday Oct 23 to spend some focus on spec reviews together.
> 
> Spec freeze is s-2 Jan 10, so the review day isn't related to any 
> deadlines, but would just be a way to organize and make sure we have 
> initial review on the specs that have been proposed so far.
> 
> How does Tuesday Oct 23 work for everyone? Let me know if another day 
> works better.
> 
> So far, efried and mriedem are on board when I asked in the 
> #openstack-nova channel. I'm sending this mail to gather more responses 
> asynchronously.
> 
> Cheers,
> -melanie
> 
> [1] https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule

Good by me.

Stephen


__
OpenStack Development Mailing 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] shall we do a spec review day next tuesday oct 23?

[Balázs Gibizer]

On Mon, Oct 15, 2018 at 7:07 PM, melanie witt  
wrote:
> Hey all,
> 
> Milestone s-1 is coming up next week on Thursday Oct 25 [1] and I was 
> thinking it would be a good idea to have a spec review day next week 
> on Tuesday Oct 23 to spend some focus on spec reviews together.
> 
> Spec freeze is s-2 Jan 10, so the review day isn't related to any 
> deadlines, but would just be a way to organize and make sure we have 
> initial review on the specs that have been proposed so far.
> 
> How does Tuesday Oct 23 work for everyone? Let me know if another day 
> works better.

22nd and 23rd are public holidays in Hungary os I will try to do some 
review on this Friday as a compromise.

Cheers,
gibi

> 
> So far, efried and mriedem are on board when I asked in the 
> #openstack-nova channel. I'm sending this mail to gather more 
> responses asynchronously.
> 
> Cheers,
> -melanie
> 
> [1] https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule
> 
> __
> OpenStack Development Mailing 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] Forum Schedule - Seeking Community Review

[Tim Bell]

Jimmy,

While it's not a clash within the forum, there are two sessions for Ironic 
scheduled at the same time on Tuesday at 14h20, each of which has Julia as a 
speaker.

Tim

-Original Message-
From: Jimmy McArthur 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 15 October 2018 at 22:04
To: "OpenStack Development Mailing List (not for usage questions)" 
, "openstack-operat...@lists.openstack.org" 
, "commun...@lists.openstack.org" 

Subject: [openstack-dev] Forum Schedule - Seeking Community Review

Hi -

The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
If you see a glaring content conflict within the Forum itself, please 
let me know.

You can also view the Full Schedule in the attached PDF if that makes 
life easier...

NOTE: BoFs and WGs are still not all up on the schedule.  No need to let 
us know :)

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