Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Tony Breeds]

On Thu, Apr 13, 2017 at 04:58:12PM -0700, Samuel Cassiba wrote:
> Hi Tony,
> 
> I’m not the PTL, but I asked in our channel. You can EOL Chef OpenStack as 
> well. Thanks!

Cool.

I've added the Chef repos to the EOL list.

Yours Tony.


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] [watcher] Pike-1 release

[Alexander Chadin]

Hello Watcher contributors,

We have just tagged our Pike-1 milestone. All the unfinished BPs and bug fixes 
have been moved to Pike-2.
You can see our progress for Pike-1 at 
https://launchpad.net/watcher/+milestone/pike-1

Congratulations to all who have contributed to Watcher! If you have any 
questions, don’t hesitate to contact me.

Best Regards,
_
Alexander Chadin
OpenStack Developer
Servionica LTD
a.cha...@servionica.ru
__
OpenStack Development Mailing 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] [glance] virtual midcycle April 20

[Brian Rosmaita]

As discussed at today's Glance weekly meeting, we'll hold the virtual
midcycle next week on Thursday, April 20.

We'll keep it short, just 3 hours from 14:00-17:00 UTC.  Please plan
ahead and have breakfast/lunch/snacks/dinner ready at your workstation
so we can work straight through.

Agenda and signup for discussion topics:
  https://etherpad.openstack.org/p/glance-pike-virtual-midcycle

I'm proposing to use zoom for communications, but would like to test it
first.  If you're willing to help out, send me an email with a date and
time and I'll send you the link so we can try it out.  I'm especially
interested in testing connectivity with Europe and APAC.

cheers,
brian


__
OpenStack Development Mailing 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] Voting for the TC Election is now open

[Kendall Nelson]

Hello All!

Voting for the TC Election is now open and will remain open until 23:45
April 20th, 2017 UTC.

We are selecting 7 TC members, please rank all candidates in your order of
preference.

You are eligible to vote if you are a Foundation individual member[1] that
also has committed to one of the official programs projects[2] over the
Newton-Ocata timeframe (Apr 07, 2016 00:00 UTC to Feb 22, 2017 23:59 UTC)
or if you are one of the extra-atcs.[3]

What to do if you don't see the email and have a commit in at least one of
the official programs projects[2]:
  * check the trash or spam folder of your gerrit Preferred Email
address[4], in case it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project repos[2]
and email the election officials[1]. If we can confirm that you are
entitled to vote, we will add you to the voters list and you will be
emailed a ballot.

Our democratic process is important to the health of OpenStack, please
exercise your right to vote.

Candidate statements/platforms can be found linked to Candidate names[6].

Happy voting,
Thank you,

Kendall Nelson(diablo_rojo)

[1]: http://www.openstack.org/community/members/
[2]:
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=jan-2017-elections
[3]: Look for the extra-atcs element in [2]
[4]: Sign into review.openstack.org: Go to Settings > Contact Information.
Look at the email listed as your Preferred Email. That is where the ballot
has been sent.
[5]: http://governance.openstack.org/election/#election-officials
[6]: http://governance.openstack.org/election/#pike-tc-candidates
__
OpenStack Development Mailing 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] [api-wg] Question about 'OpenStack-API-Version' header

[Qiming Teng]

According to the microversion specification [1], the
'OpenStack-API-Version' header is optional. When it is omitted, the
server should act as if the minimum supported version was specified.

Recently, we have received some complaints from users that for new APIs
added, we should state that the header is required. The new APIs are
valid only after a specific microversion. If the 'OpenStack-APi-Version'
header is missing, our server returns a 404 resource not found error.
It is confusing.

So ... I'm reaching out to you for some comments and suggestions.
Are there any best practices on this?

- Qiming

[1]
https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.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] [nova] Why don't we unbind ports or terminate volume connections on shelve offload?

[Matt Riedemann]

On 4/13/2017 6:53 PM, Andrew Laski wrote:



On Thu, Apr 13, 2017, at 12:45 PM, Matt Riedemann wrote:

This came up in the nova/cinder meeting today, but I can't for the life
of me think of why we don't unbind ports or terminate the connection
volumes when we shelve offload an instance from a compute host.

When you unshelve, if the instance was shelved offloaded, the conductor
asks the scheduler for a new set of hosts to build the instance on
(unshelve it). That could be a totally different host.

So am I just missing something super obvious? Or is this the most latent
bug ever?


It's at the very least a hack, and may be a bug depending on what
behaviour is being seen while the instance is offloaded or unshelved.

The reason that networks and volumes are left in place is because it
is/was the only way to prevent them from being used by another instance
and causing a subsequent unshelve to fail. During the unshelve operation
it is expected that they will then be shifted over to the new host the
instance lands on if it switches hosts.

This is similar to how resize is handled.  From an implementation point
of view you can think of shelve as being a really really long
resize/migration operation.

There very well may be issues with this approach.



--

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



I'm not advocating that we detach the volumes or ports - we can totally 
leave those coupled with the instance in the database (the 
port.device_id still points at the instance even though the port's 
binding details don't have a host set). The thing with the volume though 
is we need to terminate the connection to the backend for that host 
before we offload, because when we unshelve and initialize a new volume 
connection, there will now be two connections.


As noted elsewhere in the thread, there is a reported bug for this and 
some history around it. Calling terminate_connection will fix the issue 
for some backends in Cinder but not all (like it won't fix LVM). There 
is some other internal 'remove_export' call in Cinder that fixes it for 
LVM, but that is not exposed out of the API *except* through the 
os-detach API, which is precisely the thing we can't call for shelve 
offload for the reason you described.


--

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] [all] blog post about being PTL in OpenStack

[Emilien Macchi]

Exceptionally, I'll self-promote a blog post that I wrote about my
personal experience of being PTL in OpenStack.

http://my1.fr/blog/my-journey-as-an-openstack-ptl/

My hope is to engage some discussion about what our community thinks
about this role and how we could bring more leaders in OpenStack.
This blog post also explains why I won't run for PTL during the next cycle.

Happy week-end,
-- 
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] [all][stable][ptls] Tagging mitaka as EOL

[Tony Breeds]

On Thu, Apr 13, 2017 at 04:48:34PM -0700, Sumit Naiksatam wrote:
> Hi Tony, Kindly do not EOL openstack/group-based-policy, we are
> maintaining this branch.

Done.

Tony.


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] [all][stable][ptls] Tagging mitaka as EOL

[Samuel Cassiba]

Hi Tony,

I’m not the PTL, but I asked in our channel. You can EOL Chef OpenStack as 
well. Thanks!

--
Best,

Samuel Cassiba


signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] Why don't we unbind ports or terminate volume connections on shelve offload?

[Andrew Laski]

On Thu, Apr 13, 2017, at 12:45 PM, Matt Riedemann wrote:
> This came up in the nova/cinder meeting today, but I can't for the life 
> of me think of why we don't unbind ports or terminate the connection 
> volumes when we shelve offload an instance from a compute host.
> 
> When you unshelve, if the instance was shelved offloaded, the conductor 
> asks the scheduler for a new set of hosts to build the instance on 
> (unshelve it). That could be a totally different host.
> 
> So am I just missing something super obvious? Or is this the most latent 
> bug ever?

It's at the very least a hack, and may be a bug depending on what
behaviour is being seen while the instance is offloaded or unshelved.

The reason that networks and volumes are left in place is because it
is/was the only way to prevent them from being used by another instance
and causing a subsequent unshelve to fail. During the unshelve operation
it is expected that they will then be shifted over to the new host the
instance lands on if it switches hosts.

This is similar to how resize is handled.  From an implementation point
of view you can think of shelve as being a really really long
resize/migration operation.

There very well may be issues with this approach.

> 
> -- 
> 
> 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 Development Mailing 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][stable][ptls] Tagging mitaka as EOL

[Sumit Naiksatam]

Hi Tony, Kindly do not EOL openstack/group-based-policy, we are
maintaining this branch.

Thanks,
~Sumit.



On Thu, Apr 13, 2017 at 4:40 PM, Tony Breeds  wrote:
> On Thu, Apr 13, 2017 at 08:20:50AM -0600, Alex Schultz wrote:
>
>> I would not include puppet-midonet without verification from those
>> devs. I believe it is still in use.
>
> Okay I'll leave them in the NOT EOLing list.  I assumed that puppet-midonet
> would just plain fail once there wasn't a stable/mitaka branch in the otehr
> repos.
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Tony Breeds]

On Thu, Apr 13, 2017 at 08:20:50AM -0600, Alex Schultz wrote:

> I would not include puppet-midonet without verification from those
> devs. I believe it is still in use.

Okay I'll leave them in the NOT EOLing list.  I assumed that puppet-midonet
would just plain fail once there wasn't a stable/mitaka branch in the otehr
repos.

Yours Tony.


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] [all][stable][ptls] Tagging mitaka as EOL

[Tony Breeds]

On Thu, Apr 13, 2017 at 03:55:56PM +0100, Andy McCrae wrote:

> Can the openstack-ansible repository be skipped until other repo's are
> EOL'd, please? The reason is that we'd like the mitaka-eol tag for OSA to
> point to the mitaka-eol tag of the appropriate upstream projects, in order
> for that to happen those tags need to exist. That would mean we need an
> extra week or so. This would just be for the openstack-ansible integrated
> repository, and not for all the other role repositories, those can be eol'd
> as normal.

Yup no problem.  I'll modify my script to handle cycle-trailing projects
in a seperate pass.

> For now I've gone ahead and abandoned open patches for the stable/mitaka
> branch on OSA repositories.

Thanks

Yours Tony.


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] [keystone][horizon] weekly meeting

[Lance Bragstad]

Happy Thursday folks,

Rob and I have noticed that the weekly attendance for the Keystone/Horizon
[0] meeting has dropped significantly in the last month or two. We
contemplated changing the frequency of this meeting to be monthly instead
of weekly. We still think it is important to have a sync point between the
two projects, but maybe it doesn't need to be as often as we were expecting.

Does anyone have any objections to making this a monthly meeting?

Does anyone have a preference on the week or day of the month (i.e. 3rd
Thursday of the month)?

Once we have consensus on a time, I'll submit a patch for the meeting
agenda.

Thanks and have a great weekend!

[0] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting
__
OpenStack Development Mailing 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] [glance] spec freeze extension

[Brian Rosmaita]

It has come to my attention that the deadline to have Glance-related
specs merged for Pike is in the middle of religious
holidays/institutional holidays in the EU.  Hence, the spec freeze is
extended to 23:59 UTC on Wednesday 19 April 2017.

Here's a link to the spec tracking etherpad:
https://etherpad.openstack.org/p/glance-pike-specs-review

Thank you, and enjoy any holidays you may be celebrating,
brian

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

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Ildiko Vancsa]

> +1 for us to publish sets of projects that work together for specific
> scenarios. I heard this idea first from Allison Randall and it
> immediately struck a chord. To be fair folks like Jay Pipes have
> always said (paraphrasing) "OpenStack is a toolbox". So it's the next
> step i guess. Lauren Sell was mentioning yesterday about hearing
> confusion around "Big Tent", i do feel that when we put forth a set of
> constellations we can start deprecating the "Big Tent" terminology if
> appropriate.

I think what we are missing here is more of guidelines and more examples to 
give ideas how to build a platform from the blocks. I see “Big Tent” as a 
terminology that covers our governance as well, therefore I would not go that 
far to deprecate it as of now.

On the other hand, I know at least one other community where a very similar 
concept than the set of constellations here is causing just as much frustration 
as the “Big Tent” currently in our case. I think we need to improve on 
communication and guidance first regardless of whether we get to the conclusion 
of changing the terminology finally or not.

Thanks,
Ildikó


__
OpenStack Development Mailing 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] [openstack] [summit] Speed Mentoring at Boston summit, updated time!

[Emily K Hugenbruch]

Hello,
We are so pleased to again offer Speed Mentoring on the first day of the
Boston summit.   The time has recently moved from Monday morning (too
early!) to Monday lunch.  We have 20 fabulous mentors signed up and 5 great
volunteers.  We have space for lots more mentees!
So if you know of someone new to the community, coming to their first
summit, or just looking to grow their network, please invite them to come
to Speed Mentoring.


Speed Mentoring Lunch sponsored by Intel - Monday May 8,
12:50-1:50PM
Open to anyone of any gender or experience looking for
technical or career advice.


How will it go?


You'll meet with a mentor in a small group of mentees
in short intervals.  Mentors will answer questions and share
their experience about how to grow in the community. It's a
fast-paced event and a great way to meet new people, start the
summit, and be welcomed into the OpenStack community. Mentees
are asked to provide 3 questions they would like answered when
they sign up.  We'll ask mentors to focus their answers around
these questions.


Sign up here:

https://www.openstack.org/summit/boston-2017/summit-schedule/events/18680/speed-mentoring-lunch-sponsored-by-intel

Thanks!



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

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Ildiko Vancsa]

> […]
> What's the one platform will be in your own words? What's your proposal and 
> your focus to help one platform vision being achieved?

In my view it means that OpenStack contains the blocks to build platforms that 
can serve as a base for different use cases and workloads. We need to keep the 
API’s consistent and the interfaces between the services well defined and 
stable.

In addition, for me, one platform on high level means enablement, flexibility, 
consciousness about the needs of the industry and support of the integration 
points towards related projects/technologies. We need OpenStack to be modular 
with clear communication about the purpose of each service and guidance on how 
to build a platform by using them as Lego pieces, like how you have sample 
photos on the side of the box to give you ideas on what you might want.

I think if we can achieve people seeing OpenStack as a box of Lego, tools, you 
name it, that enables them to build what they need as a base platform to run 
their applications on top we are on the right track. This needs good design, 
consistency and clear communication.

Thanks,
Ildikó


> 
> Best Regards
> Chaoyi Huang (joehuang)
> __
> OpenStack Development Mailing 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] [horizon] Pike-1 Tagged

[Rob Cresswell]

Hey everyone,

So we've just tagged our first milestone for Pike. I've checked launchpad and 
bumped anything unfinished to pike-2. You can see our progress for pike-1 at 
https://launchpad.net/horizon/+milestone/pike-1

5 blueprints implemented and 73 bugs closed, as well as many minor bugs that 
didn't have attached reports. Great job so far!

I'm away until Tuesday (Friday and Monday are public holidays in the UK) but 
afterwards I'll be reviewing pike-2 and making sure we're on target. I'd also 
like to remind the cores to ensure that patches have bug reports in most cases; 
while its okay to let minor patches through, for the most part we want to be 
able to track milestone and backport progress via launchpad.

Thanks again for everyone's hard work!

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

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Ed Leafe]

On Apr 11, 2017, at 9:54 PM, joehuang  wrote:

> Can all these efforts lead us to one platform vision? We have to think over 
> the question.
> 
> What's the one platform will be in your own words? What's your proposal and 
> your focus to help one platform vision being achieved?

I think the word "platform" is critical here. OpenStack is not a single "thing" 
that everyone can use the same way. It's a collection of pieces that work 
together to help solve many different workloads. The key to that is having a 
solid base and consistent interfaces among the various projects to create a 
platform that solutions can be built upon.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] Why don't we unbind ports or terminate volume connections on shelve offload?

[Chris Friesen]

On 04/13/2017 10:45 AM, Matt Riedemann wrote:

This came up in the nova/cinder meeting today, but I can't for the life of me
think of why we don't unbind ports or terminate the connection volumes when we
shelve offload an instance from a compute host.

When you unshelve, if the instance was shelved offloaded, the conductor asks the
scheduler for a new set of hosts to build the instance on (unshelve it). That
could be a totally different host.

So am I just missing something super obvious? Or is this the most latent bug 
ever?


Does anyone actually use shelve?

Chris

__
OpenStack Development Mailing 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][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Vikram Hosakote (vhosakot)]

I like the idea and would love to help with mentoring.

I’ve learned a lot being a Kolla core.

I think every contributor is the same – core or not ☺.  At the end of the 
mentorship, I
think we need to make sure that non-cores feel no different than cores, and 
that every
contributor is the same, welcome, helped and mentored in the community ☺.

I’ll add my name is the signup sheet!

Regards,
Vikram Hosakote
IRC:  vhosakot

From: "Steven Dake (stdake)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, April 13, 2017 at 9:19 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

Ok sounds fair.  I guess I had misunderstood what nova had done, and thought it 
was a path to success.

I’m happy we can have the conversation about a mentorship program now at least 
in the Kolla project.

I’m not sure how to evaluate the cost of the mentorship program in terms of 
core reviewer time.  Perhaps we should start there.  I know core reviewers are 
swamped for bandwidth, however, I also feel making time for mentorship is 
essential to the project’s long term health.

I am also not sure if we have more individuals interested.  If only Rich is 
interested, that is only one person to mentor.  If 100 people are interested, 
that is beyond our capacity as a team to handle ☺

To help sort out the time commitment for core reviewers, I have started a 
“sign-up sheet” for folks interested in mentoring here:
https://etherpad.openstack.org/p/kolla-mentorship-signup

Regards
-steve


From: "Serguei Bezverkhi (sbezverk)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, April 13, 2017 at 8:45 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

The idea is great, no doubt here, meaning mentoring and everything, but it 
should not come with price of reducing quality control. 2 x +2 +w should still 
be required from “regular” cores for PS to merge.

Serguei

From: Richard Wellum [mailto:richwel...@gmail.com]
Sent: Thursday, April 13, 2017 7:02 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

As a relatively new member of the openstack community I think the idea of a 
mentorship program is a good one; I'd like to throw my hat in the ring if the 
kolla community needs a guinea-pig to try this on. :)

Rich

On Wed, Apr 12, 2017 at 7:53 PM Matt Riedemann 
mailto:mriede...@gmail.com>> wrote:
On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:
> Matt,
>
> Thanks for the response.  It is helpful.
>
> Regards
> -steve
>
> -Original Message-
> From: Matt Riedemann mailto:mriede...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Date: Wednesday, April 12, 2017 at 4:36 PM
> To: 
> "openstack-dev@lists.openstack.org" 
> mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer 
> mentorship program for Kolla deliverables
>
> On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> > Hey folks,
> >
> >
> >
> > In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> > “protocore” mentorship program for Kolla.  We would like to know what
> > nova has learned from this effort.
> >
> >
> >
> > In today’s Kolla meeting we had broad consensus on the following:
> >
> > 1)   Kolla has participants that want to be core reviewers
> >
> > 2)   These participants don’t know how to become core reviewers
> >
> > 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> > on how to do good reviews
> >
> >
> >
> > From that, we concluded some form of mentorship program for potential
> > core reviewers was in order.  We got into some debate about _/how/_ the
> > program should be rolled out.  Let’s use this thread to discuss how it
> > should be rolled out since that seems to be the sticking point of the
> > discussion.  I saw no dissent in the discussion that the basic concepts
> > were a negative change.
> >
> >
> >
> > I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> > from a core reviewer prior to merge.  Nova cores – would you mind
> > defining your process (on the ml is fine) more thoroughly and your
> > experiences so we can learn from you?
> >
> >
> >
> > All kolla contributors, feel free to debate the **how** such a
> > mentorship program should be rolled out.  I think we have a lot 

[openstack-dev] [all][api] POST /api-wg/news

[michael mccune]

Greetings OpenStack community,

This week's meeting was lightly attended but provided a useful 
discussion about the future of the working group and how we will 
continue to improve the API experience for all OpenStack users. The 
group is considering its role with respect to the guidelines that it 
creates and how to not only increase our membership but also explore 
other options for improving the overall state of API usability and 
consistency within OpenStack. Although no firm actions have resulted 
from this discussion, we have agreed to keep the topic open, have more 
face to face conversations about it at the upcoming forum event, and to 
reach out to other working groups with the intent to learn more about 
community expectations and usages with regards to the APIs in OpenStack.


# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Define pagination guidelines
  https://review.openstack.org/#/c/446716/

* Create a set of api interoperability guidelines
  https://review.openstack.org/#/c/421846/

* Recommend the correct HTTP method for tags
  https://review.openstack.org/451536

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
  https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/
  On hold.

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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] Why don't we unbind ports or terminate volume connections on shelve offload?

[Matt Riedemann]

This came up in the nova/cinder meeting today, but I can't for the life 
of me think of why we don't unbind ports or terminate the connection 
volumes when we shelve offload an instance from a compute host.


When you unshelve, if the instance was shelved offloaded, the conductor 
asks the scheduler for a new set of hosts to build the instance on 
(unshelve it). That could be a totally different host.


So am I just missing something super obvious? Or is this the most latent 
bug ever?


--

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] [tc] version document for project navigator

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-04-13 18:03:41 +0200:
> Monty Taylor wrote:
> > On 04/13/2017 08:28 AM, Jimmy McArthur wrote:
> >> Just checking on the progress of this. :)
> > 
> > Unfortunately a good portion of the TC was away this week at the
> > leadership training so getting a final ok on it was a bit stalled. It's
> > seeming like the multi-file version is the one most people like though,
> > so I'm mostly expecting that to be what we end up with. We should be
> > able to get final approval by Tuesday, and then can work on getting all
> > of the project info filled in.
> 
> Do we really need the TC approval on this ? It's not a formal governance
> change or anything.
> 
> Whoever has rights on that repo could approve it now and ask for
> forgiveness later :)
> 

+1

The multi-file format was what the navigator team wanted, and there's
plenty of support for it among other reviewers. Let's move this forward.

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] [kubernetes][kolla][openstack-helm][magnum] Kubernetes Day at OpenStack Summit NA 2017 announced!

[Ihor Dvoretskyi]

Hello everyone,

I'm pleased to announce that the event schedule is published - you may find
it at the event page [1].

Please, join us on May 9 at OpenStack Summit venue in Boston!

Ihor

1. https://www.cncf.io/event/openstack-north-america-2017

On Tue, Feb 28, 2017 at 12:44 AM, Ihor Dvoretskyi 
wrote:

> Hello everyone,
>
> On behalf of Kubernetes Community and OpenStack SpeciaI Interest Group
> [0], I'm happy to announce Kubernetes Day at OpenStack Summit NA 2017. The
> event will be hosted by CNCF as a part of OpenStack’s Open Source Days in
> Boston [1].
>
> The CFP process is already open - feel free to submit your talk. More
> detailed information about the event you may find at the CNCF's event page
> [2].
>
> Special thanks to CNCF, OpenStack Foundation, and individuals who made
> this happen.
>
> 0. https://github.com/kubernetes/community/blob/master/sig-
> openstack/README.md
> 1. https://www.openstack.org/summit/boston-2017/open-source-days/
> 2. https://www.cncf.io/event/openstack-north-america-2017
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] version document for project navigator

[Thierry Carrez]

Monty Taylor wrote:
> On 04/13/2017 08:28 AM, Jimmy McArthur wrote:
>> Just checking on the progress of this. :)
> 
> Unfortunately a good portion of the TC was away this week at the
> leadership training so getting a final ok on it was a bit stalled. It's
> seeming like the multi-file version is the one most people like though,
> so I'm mostly expecting that to be what we end up with. We should be
> able to get final approval by Tuesday, and then can work on getting all
> of the project info filled in.

Do we really need the TC approval on this ? It's not a formal governance
change or anything.

Whoever has rights on that repo could approve it now and ask for
forgiveness later :)

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [ironic] 3rdparty CI status and how we can help to make it green

[Rajini.Ram]

Dell - Internal Use - Confidential
Thanks for starting the discussion. Will attend

-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: Thursday, April 13, 2017 10:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [ironic] 3rdparty CI status and how we can help to 
make it green

Hi all, especially maintainers of 3rdparty CI for Ironic :)

I've been watching our 3rdparty CI results recently. While things have improved 
compared to e.g. a month ago, most of jobs still finish with failures. I've 
written a simple script [1] to fetch CI runs information from my local Gertty 
database, the results [2] show that some jobs still fail surprisingly often (> 
50% of cases):

- job: tempest-dsvm-ironic-agent-irmc
rate: 0.9857142857142858
- job: tempest-dsvm-ironic-iscsi-irmc
rate: 0.9771428571428571
- job: dell-hw-tempest-dsvm-ironic-pxe_drac
rate: 0.9682539682539683
- job: gate-tempest-ironic-ilo-driver-iscsi_ilo
rate: 0.9582463465553236
- job: dell-hw-tempest-dsvm-ironic-pxe_ipmitool
rate: 0.9111
- job: tempest-dsvm-ironic-pxe-irmc
rate: 0.8171428571428572
- job: gate-tempest-ironic-ilo-driver-pxe_ilo
rate: 0.791231732776618

I would like to start the discussion on how we (as a team) can help people 
maintaining the CI to keep failure rate closer to one of our virtual CI (< 30% 
of cases, judging by [2]).

I'm thinking of the following potential problems:

1. Our devstack plugin changes too often.

I've head this complaint at least once. Should we maybe freeze our devstack at 
some point to allow the vendor folks to catch up? Then we should start looking 
at the CI results more carefully when modifying it.

2. Our devstack plugin is inconvenient for hardware, and requires hacks.

This is something Miles (?) told me when trying to set up an environment for 
his hardware lab. If so, can we get a list of pain problems, preferably in a 
form of reported bugs? Myself and hopefully other folks can certainly dedicate 
some time to make your life easier.

3. The number of jobs to run on is too high.

I've noticed that 3rdparty CI runs even on patches that clearly don't require 
it, e.g. docs-only changes. I suggest the maintainers to adopt some exclude 
rules similar to [3].

Also, most of the vendors run 3-4 jobs for different flavors of their drivers 
(and it is going to increase with the driver composition work). I wonder if we 
should recommend switching from ironic the baremetal_basic_ops test to what we 
call "standalone" tests [4]. This will allow to have only one job testing 
several drivers/combinations of interfaces within the same time frame.

Finally, I've proposed this topic for the virtual meetup [5] planned in the end 
of April. Please feel free to stop by and let us know how we can help.

Thanks,
Dmitry.

P.S.
I've seen expired or self-signed HTTPS certificates on logs sites of some 
3rdparty CI. Please try to fix such issues as soon as possible to allow the 
community to understand failures.

[1] https://github.com/dtantsur/ci-report
[2] http://paste.openstack.org/show/606467/
[3]
https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L1375-L1385
[4]
https://github.com/openstack/ironic/blob/master/ironic_tempest_plugin/tests/scenario/ironic_standalone/test_basic_ops.py
[5] https://etherpad.openstack.org/p/ironic-virtual-meetup

__
OpenStack Development Mailing 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] [fuel] Weekly meeting April 13th is cancelled

[Vladimir Kuklin]

Fuelers

Agenda is empty for today, so the meeting is cancelled.
-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.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] [tc][election] Questions for Candidates

[Ildiko Vancsa]

> You all have proven yourselves to be crucial parts of the community and I 
> just wanted to say good luck to each one of you in the upcoming election!

Thank you. :)

> -What is one trait you have that makes it difficult to work in groups like 
> the TC and how do you counteract it? 

I can be too obsessed with the ‘big picture’ and get distracted by it when it 
comes to details and defining the next steps. While it is very important to 
keep in mind, I need to learn to map it to practical actions in a faster and 
more efficient way.

Being aware of and conscious about our own weaknesses and take steps to improve 
them is crucial, but it is also what makes the TC a diverse group. In my view 
many of the traits mentioned in this thread are traits for the individuals but 
become strength for the group when it operates as a team by having the broad, 
strategic view, the technical depth and the awareness of new and emerging 
technologies all represented and being part of the decision making.

> - What do you see as the biggest roadblock in the upcoming releases for the 
> TC?

For me it is finding the balance, as making OpenStack an innovative and 
continuously evolving environment while keeping the software stable and 
flexible within all the circumstances mentioned in this thread is challenging. 
We need to keep moving away from the perception that OpenStack is a large, 
monolithic software package and help our users and operators to find the best 
setup that fulfills their needs. In addition we should be more open to provide 
the space and opportunity to people to experiment with their ideas, let that be 
new functionality or an attempt to improve something existing.

Reflecting back to what Thierry mentioned about involving our users and 
operators more, I think that would help with the aforementioned challenges and 
points towards a more balanced environment. I would mention Telecom operators 
as an area where we have good examples to community involvement already and I 
get more and more questions about how our community works and how operators 
could get more involved. As these companies are sometimes new to open source 
they need help from us in order to take the next steps and succeed.

> And one lighthearted question: 
> 
> -What is your favorite thing about OpenStack? 

My favorite thing is to feel extremely lucky every day to be part of it! :)

This community made me a better person by becoming more optimistic, 
collaborative and forward looking. It is of course the people who build this 
amazing environment where I found friends, mentors and technology experts, the 
individuals who care, share knowledge, keep you up to date with new technology, 
remind you to add more tests to your patch, or simply make you laugh on a 
hopeless Monday.

Thank you All!

Best Regards,
Ildikó


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


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

[openstack-dev] [ironic] 3rdparty CI status and how we can help to make it green

[Dmitry Tantsur]

Hi all, especially maintainers of 3rdparty CI for Ironic :)

I've been watching our 3rdparty CI results recently. While things have improved 
compared to e.g. a month ago, most of jobs still finish with failures. I've 
written a simple script [1] to fetch CI runs information from my local Gertty 
database, the results [2] show that some jobs still fail surprisingly often (> 
50% of cases):


- job: tempest-dsvm-ironic-agent-irmc
  rate: 0.9857142857142858
- job: tempest-dsvm-ironic-iscsi-irmc
  rate: 0.9771428571428571
- job: dell-hw-tempest-dsvm-ironic-pxe_drac
  rate: 0.9682539682539683
- job: gate-tempest-ironic-ilo-driver-iscsi_ilo
  rate: 0.9582463465553236
- job: dell-hw-tempest-dsvm-ironic-pxe_ipmitool
  rate: 0.9111
- job: tempest-dsvm-ironic-pxe-irmc
  rate: 0.8171428571428572
- job: gate-tempest-ironic-ilo-driver-pxe_ilo
  rate: 0.791231732776618

I would like to start the discussion on how we (as a team) can help people 
maintaining the CI to keep failure rate closer to one of our virtual CI (< 30% 
of cases, judging by [2]).


I'm thinking of the following potential problems:

1. Our devstack plugin changes too often.

  I've head this complaint at least once. Should we maybe freeze our devstack 
at some point to allow the vendor folks to catch up? Then we should start 
looking at the CI results more carefully when modifying it.


2. Our devstack plugin is inconvenient for hardware, and requires hacks.

  This is something Miles (?) told me when trying to set up an environment for 
his hardware lab. If so, can we get a list of pain problems, preferably in a 
form of reported bugs? Myself and hopefully other folks can certainly dedicate 
some time to make your life easier.


3. The number of jobs to run on is too high.

 I've noticed that 3rdparty CI runs even on patches that clearly don't require 
it, e.g. docs-only changes. I suggest the maintainers to adopt some exclude 
rules similar to [3].


  Also, most of the vendors run 3-4 jobs for different flavors of their drivers 
(and it is going to increase with the driver composition work). I wonder if we 
should recommend switching from ironic the baremetal_basic_ops test to what we 
call "standalone" tests [4]. This will allow to have only one job testing 
several drivers/combinations of interfaces within the same time frame.


Finally, I've proposed this topic for the virtual meetup [5] planned in the end 
of April. Please feel free to stop by and let us know how we can help.


Thanks,
Dmitry.

P.S.
I've seen expired or self-signed HTTPS certificates on logs sites of some 
3rdparty CI. Please try to fix such issues as soon as possible to allow the 
community to understand failures.


[1] https://github.com/dtantsur/ci-report
[2] http://paste.openstack.org/show/606467/
[3] 
https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L1375-L1385
[4] 
https://github.com/openstack/ironic/blob/master/ironic_tempest_plugin/tests/scenario/ironic_standalone/test_basic_ops.py

[5] https://etherpad.openstack.org/p/ironic-virtual-meetup

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

Re: [openstack-dev] [tc] version document for project navigator

[Monty Taylor]

On 04/13/2017 08:28 AM, Jimmy McArthur wrote:

Just checking on the progress of this. :)


Unfortunately a good portion of the TC was away this week at the 
leadership training so getting a final ok on it was a bit stalled. It's 
seeming like the multi-file version is the one most people like though, 
so I'm mostly expecting that to be what we end up with. We should be 
able to get final approval by Tuesday, and then can work on getting all 
of the project info filled in.



Monty Taylor 
April 7, 2017 at 7:05 AM


There is a new repo now:

http://git.openstack.org/cgit/openstack/project-navigator-data

I have pushed up two different patches with two different approaches:

https://review.openstack.org/#/c/454691
https://review.openstack.org/#/c/454688

One is a single file per release. The other is a file per service per
release.

Benefits of the single-file are that it's a single file to pull and
parse.

Benefits of the multi-file approach are that projects can submit
documents for themselves as patches without fear of merge conflicts,
and that the format is actually _identical_ to the format for version
discovery from the API-WG, minus the links section.

I think I prefer the multi-file approach, but would be happy either way.

__

OpenStack Development Mailing 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 6, 2017 at 3:51 PM
Cool. Thanks Monty!


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Monty Taylor 
April 6, 2017 at 3:21 PM
On 04/06/2017 11:58 AM, Jimmy McArthur wrote:

Assuming this format is accepted, do you all have any sense of when this
data will be complete for all projects?


Hopefully "soon" :)

Honestly, it's not terribly difficult data to produce, so once we're
happy with it and where it goes, crowdsourcing filling it all in
should go quickly.


Jimmy McArthur 
April 5, 2017 at 8:59 AM
FWIW, from my perspective on the Project Navigator side, this format
works great. We can actually derive the age of the project from this
information as well by identifying the first release that has API data
for a particular project. I'm indifferent about where it lives, so I'd
defer to you all to determine the best spot.

I really appreciate you all putting this together!

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
Thierry Carrez 
April 5, 2017 at 5:28 AM

Somehow missed this thread, so will repost here comments I made
elsewhere:

This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any information we
need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to collect
it from projects.

That way there is a clear place to go to to propose fixes to the
project
navigator data. Not knowing how to fix that data is a common complaint,
so if we can point people to a git repo (and redirect people from there
to the places where other bits of information happen to live) that
would
be great.

Monty Taylor 
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document
format for reporting versions to the project navigator. I stuck it in
the releases repo:

  https://review.openstack.org/453361

Because there was already per-release information there, and the
governance repo did not have that structure.

I've included pseudo-code and a human explanation of how to get from a
service's version discovery document to the data in this document, but
also how it can be maintained- which is likely to be easier by hand
than by automation - but who knows, maybe we decide we want to make a
devstack job for each service that runs on tag events that submits a
patch to the releases repo. That sounds like WAY more work than once a
cycle someone adding a few lines of json to a repo - but *shrug*.

Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery
Do

[openstack-dev] OpenStack Summit Boston Prices Increase Tomorrow!

[Kendall Waters]

Hi everyone, 

It’s your last chance to save on your OpenStack Summit Boston 
 tickets before prices increase 
tomorrow Friday, April 14 at 11:59pm PDT (April 15 at 6:59 UTC).

Haven’t booked your hotel yet? You can purchase a Full Access Summit ticket 
with a 4-night hotel stay at a hotel walkable to the Summit venue for just 
$1,599 USD! Hurry—purchase now before prices increase tomorrow! 

REGISTER AND BOOK YOUR HOTEL HERE: 
https://openstacksummit2017boston.eventbrite.com 
 

If you have a registration code, it must be redeemed by May 3. 
Note: Registration codes only apply to Weeklong Full Access Passes.

Contact sum...@openstack.org  if you have any 
questions. 

Cheers,
Kendall

Kendall Waters
OpenStack Marketing
kend...@openstack.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

Re: [openstack-dev] [tc] [elections] Available time and top priority

[Julien Danjou]

On Wed, Apr 12 2017, Thierry Carrez wrote:

> One idea I've been considering is eliminating the one and only sacred
> one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
> #openstack-dev for example) between change proposers and smaller groups
> of TC members present in the same timezone. That would give us a good
> feel of what everyone thinks, reduce noise, and happen at various times
> during the day on a public forum, giving an opportunity for more people
> to jump in the discussion. The informal nature of those discussions
> would make the governance reviews the clear focal point for coordination
> and final decision.
>
> It's clearly not the perfect silver bullet though, so I'd very much like
> to hear other ideas :)

+1

We ditched meeting a while ago in Telemetry without any regret.
Discussions happen when needed on IRC and when people are around, and if
they're not or it requires more thinking we just go to email.

Requiring people to connect and block a full hour at any time of the day
(or night) never have been a good and productive idea. Sometimes I feel
like OpenStack stole this idea from "Worst Ideas In Enterprise
Management Practice". ;)

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Michał Jastrzębski]

Thanks sdake!

I added this topic to next meeting agenda. Way I see it it might not
be any more load on core reviewer as answering questions and reviewing
is part of our job already. However having some "trusted" person to
ask can mean a lot to new reviewer as it will lower this fear of being
ashamed by asking in public (there is nothing to fear, but that's how
our brains are wired). Also direct cores attention to comment on
mantee review to improve quality. Also mentor can start actual core
voting (or ask me to start the voting) when mantee will be ready.

Let's give it a try. I'm very hopeful for it!

Cheers,
Michal

On 13 April 2017 at 06:19, Steven Dake (stdake)  wrote:
> Ok sounds fair.  I guess I had misunderstood what nova had done, and thought
> it was a path to success.
>
>
>
> I’m happy we can have the conversation about a mentorship program now at
> least in the Kolla project.
>
>
>
> I’m not sure how to evaluate the cost of the mentorship program in terms of
> core reviewer time.  Perhaps we should start there.  I know core reviewers
> are swamped for bandwidth, however, I also feel making time for mentorship
> is essential to the project’s long term health.
>
>
>
> I am also not sure if we have more individuals interested.  If only Rich is
> interested, that is only one person to mentor.  If 100 people are
> interested, that is beyond our capacity as a team to handle J
>
>
>
> To help sort out the time commitment for core reviewers, I have started a
> “sign-up sheet” for folks interested in mentoring here:
>
> https://etherpad.openstack.org/p/kolla-mentorship-signup
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> From: "Serguei Bezverkhi (sbezverk)" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Thursday, April 13, 2017 at 8:45 AM
>
>
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer
> mentorship program for Kolla deliverables
>
>
>
> The idea is great, no doubt here, meaning mentoring and everything, but it
> should not come with price of reducing quality control. 2 x +2 +w should
> still be required from “regular” cores for PS to merge.
>
>
>
> Serguei
>
>
>
> From: Richard Wellum [mailto:richwel...@gmail.com]
> Sent: Thursday, April 13, 2017 7:02 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer
> mentorship program for Kolla deliverables
>
>
>
> As a relatively new member of the openstack community I think the idea of a
> mentorship program is a good one; I'd like to throw my hat in the ring if
> the kolla community needs a guinea-pig to try this on. :)
>
>
>
> Rich
>
>
>
> On Wed, Apr 12, 2017 at 7:53 PM Matt Riedemann  wrote:
>
> On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:
>> Matt,
>>
>> Thanks for the response.  It is helpful.
>>
>> Regards
>> -steve
>>
>> -Original Message-
>> From: Matt Riedemann 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Wednesday, April 12, 2017 at 4:36 PM
>> To: "openstack-dev@lists.openstack.org"
>> 
>> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer
>> mentorship program for Kolla deliverables
>>
>> On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
>> > Hey folks,
>> >
>> >
>> >
>> > In today’s Kolla team meeting, the idea was proposed of adopting
>> nova’s
>> > “protocore” mentorship program for Kolla.  We would like to know
>> what
>> > nova has learned from this effort.
>> >
>> >
>> >
>> > In today’s Kolla meeting we had broad consensus on the following:
>> >
>> > 1)   Kolla has participants that want to be core reviewers
>> >
>> > 2)   These participants don’t know how to become core reviewers
>> >
>> > 3)   The core reviewers in Kolla should mentor “protocore”
>> reviewers
>> > on how to do good reviews
>> >
>> >
>> >
>> > From that, we concluded some form of mentorship program for
>> potential
>> > core reviewers was in order.  We got into some debate about _/how/_
>> the
>> > program should be rolled out.  Let’s use this thread to discuss how
>> it
>> > should be rolled out since that seems to be the sticking point of
>> the
>> > discussion.  I saw no dissent in the discussion that the basic
>> concepts
>> > were a negative change.
>> >
>> >
>> >
>> > I am aware that nova uses a +1 review from a “protocore” and a +2/+w
>> > from a core reviewer prior to merge.  Nova cores – would you mind
>> > defining your process (on the ml is fine) more thoroughly and your
>> > experiences so we can learn from you?
>> >
>> >
>> >
>> > All kolla contributors, feel free to debate the **how** such a
>> > mentorship program should be rolled out.  I think we have a lot to
>> learn
>> > from our peers in the Op

Re: [openstack-dev] [kolla][all][tc] Starting a core reviewer mentorship program for Kolla deliverables

[John Dickinson]

On 12 Apr 2017, at 18:54, Michał Jastrzębski wrote:

> I was also thinking of having "cores just for single thing" in Kolla,
> but I think that won't really work as most of our code is variation of
> other parts with very little unique things to this, it's tuning up
> details that takes most of our work (aside of already split
> kolla-ansible and kolla-kubernetes).
>
> That being said I fully support any effort to train new core team
> members. In fact, I'd like to explore few ideas for that and maybe ask
> for opinions of broader community:
>
> 1. Mentorship program
> Every person who wants to be a core but doesn't feel confident about
> his/hers ability can ask core team for mentor. This mentor-mantee
> relationship will work in a way that mantee can ask mentor to
> re-review his/hers review (+2 of my +1 or -1 with explanation what did
> I miss), technical questions and things like that. I would be happy to
> act as first point of contact to pair mantees with mentors (once we
> establish some mechanism for that).
>
> 2. +1 matters
> One thing that I see happening is misconception that +1 doesn't
> matter. It does, but maybe we need to do something to break that
> impression. Frankly I don't have good ideas for that, any experiences
> anyone?
>
> I think we, as broader OpenStack community could make this full
> fledged cross project discussion and trade experiences (that's why I
> broaden subject tags a little:)).


Thanks for broadening the subject tags. I hadn't seen this thread yet.

While I don't have "answers" for you questions (of course I have ideas and 
opinions though), the mentorship idea and starting to break the "+1 doesn't 
matter" meme are both great! Thank you for bring up the topic.


--John





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

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Andy McCrae]

Hi Tony,


> Please look over both lists by 2017-04-17 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of
> EOLing and
>   why.  Note doing this will amost certainly reduce the testing coverage
> you
>   have in the gate.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing
>
> Any projects that will be EOL'd will need all open reviews abandoned
> before it
> can be processed.  I'm very happy to do this, or if I don't have
> permissios to
> do it ask a gerrit admin to do it.
>
>
Can the openstack-ansible repository be skipped until other repo's are
EOL'd, please? The reason is that we'd like the mitaka-eol tag for OSA to
point to the mitaka-eol tag of the appropriate upstream projects, in order
for that to happen those tags need to exist. That would mean we need an
extra week or so. This would just be for the openstack-ansible integrated
repository, and not for all the other role repositories, those can be eol'd
as normal.

For now I've gone ahead and abandoned open patches for the stable/mitaka
branch on OSA repositories.

Thanks for the help!
Andy
__
OpenStack Development Mailing 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][stable][ptls] Tagging mitaka as EOL

[Alex Schultz]

On Wed, Apr 12, 2017 at 6:21 PM, Tony Breeds  wrote:
> On Wed, Apr 12, 2017 at 07:53:17AM -0600, Alex Schultz wrote:
>
>> Please EOL the Puppet OpenStack projects that have the stable/mitaka branch.
>
> Thanks Alex!  I've added:
> openstack/puppet-aodh
> openstack/puppet-ceilometer
> openstack/puppet-cinder
> openstack/puppet-designate
> openstack/puppet-glance
> openstack/puppet-gnocchi
> openstack/puppet-heat
> openstack/puppet-horizon
> openstack/puppet-ironic
> openstack/puppet-keystone
> openstack/puppet-manila
> openstack/puppet-mistral
> openstack/puppet-murano
> openstack/puppet-neutron
> openstack/puppet-nova
> openstack/puppet-openstack-integration
> openstack/puppet-openstack_extras
> openstack/puppet-openstack_spec_helper
> openstack/puppet-openstacklib
> openstack/puppet-sahara
> openstack/puppet-swift
> openstack/puppet-tempest
> openstack/puppet-trove
> openstack/puppet-vswitch
> openstack/puppet-zaqar
> openstack/puppet-midonet
>
> To the list of projects/repos to EOL.  Note openstack/puppet-midonet isn't 
> part
> of the "Puppet OpenStack" project but I'm erring on the side of including it.
>

I would not include puppet-midonet without verification from those
devs. I believe it is still in use.

Thanks,
-Alex

> Yours Tony.
>
> __
> OpenStack Development Mailing 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] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core

[Julien Danjou]

On Wed, Apr 12 2017, Monty Taylor wrote:

> Recently Stephen Finucane (sfinucan) has stepped up to the plate to help sort
> out issues we've been having. He's shown a lack of fear of the codebase and an
> understanding of what's going on. He's also following through on patches to
> projects themselves when needed, which is a huge part of the game. And most
> importantly he knows when to suggest we _not_ do something.

+1, he's done a good job. :)

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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

Re: [openstack-dev] [tc] version document for project navigator

[Jimmy McArthur]

Just checking on the progress of this. :)


Monty Taylor 
April 7, 2017 at 7:05 AM


There is a new repo now:

http://git.openstack.org/cgit/openstack/project-navigator-data

I have pushed up two different patches with two different approaches:

https://review.openstack.org/#/c/454691
https://review.openstack.org/#/c/454688

One is a single file per release. The other is a file per service per 
release.


Benefits of the single-file are that it's a single file to pull and 
parse.


Benefits of the multi-file approach are that projects can submit 
documents for themselves as patches without fear of merge conflicts, 
and that the format is actually _identical_ to the format for version 
discovery from the API-WG, minus the links section.


I think I prefer the multi-file approach, but would be happy either way.

__ 


OpenStack Development Mailing 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 6, 2017 at 3:51 PM
Cool. Thanks Monty!


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Monty Taylor 
April 6, 2017 at 3:21 PM
On 04/06/2017 11:58 AM, Jimmy McArthur wrote:

Assuming this format is accepted, do you all have any sense of when this
data will be complete for all projects?


Hopefully "soon" :)

Honestly, it's not terribly difficult data to produce, so once we're 
happy with it and where it goes, crowdsourcing filling it all in 
should go quickly.



Jimmy McArthur 
April 5, 2017 at 8:59 AM
FWIW, from my perspective on the Project Navigator side, this format
works great. We can actually derive the age of the project from this
information as well by identifying the first release that has API data
for a particular project. I'm indifferent about where it lives, so I'd
defer to you all to determine the best spot.

I really appreciate you all putting this together!

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
Thierry Carrez 
April 5, 2017 at 5:28 AM

Somehow missed this thread, so will repost here comments I made 
elsewhere:


This looks good, but I would rather not overload the releases
repository. My personal preference (which was also expressed by
Doug in the TC meeting) would be to set this information up in a
"project-navigator" git repo that we would reuse for any information we
need to collect from projects for accurate display on the project
navigator. If the data is not maintained anywhere else (or easily
derivable from existing data), we would use that repository to collect
it from projects.

That way there is a clear place to go to to propose fixes to the 
project

navigator data. Not knowing how to fix that data is a common complaint,
so if we can point people to a git repo (and redirect people from there
to the places where other bits of information happen to live) that 
would

be great.

Monty Taylor 
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document
format for reporting versions to the project navigator. I stuck it in
the releases repo:

  https://review.openstack.org/453361

Because there was already per-release information there, and the
governance repo did not have that structure.

I've included pseudo-code and a human explanation of how to get from a
service's version discovery document to the data in this document, but
also how it can be maintained- which is likely to be easier by hand
than by automation - but who knows, maybe we decide we want to make a
devstack job for each service that runs on tag events that submits a
patch to the releases repo. That sounds like WAY more work than once a
cycle someone adding a few lines of json to a repo - but *shrug*.

Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery
Document" is a thing people might want to do and want to do
consistently across services.

* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few
minor ways that do not actually matter but make life harder for our
users.

Thoughts and feedback more than welcome!
Monty

___

Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Steven Dake (stdake)]

Ok sounds fair.  I guess I had misunderstood what nova had done, and thought it 
was a path to success.

I’m happy we can have the conversation about a mentorship program now at least 
in the Kolla project.

I’m not sure how to evaluate the cost of the mentorship program in terms of 
core reviewer time.  Perhaps we should start there.  I know core reviewers are 
swamped for bandwidth, however, I also feel making time for mentorship is 
essential to the project’s long term health.

I am also not sure if we have more individuals interested.  If only Rich is 
interested, that is only one person to mentor.  If 100 people are interested, 
that is beyond our capacity as a team to handle ☺

To help sort out the time commitment for core reviewers, I have started a 
“sign-up sheet” for folks interested in mentoring here:
https://etherpad.openstack.org/p/kolla-mentorship-signup

Regards
-steve


From: "Serguei Bezverkhi (sbezverk)" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, April 13, 2017 at 8:45 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

The idea is great, no doubt here, meaning mentoring and everything, but it 
should not come with price of reducing quality control. 2 x +2 +w should still 
be required from “regular” cores for PS to merge.

Serguei

From: Richard Wellum [mailto:richwel...@gmail.com]
Sent: Thursday, April 13, 2017 7:02 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

As a relatively new member of the openstack community I think the idea of a 
mentorship program is a good one; I'd like to throw my hat in the ring if the 
kolla community needs a guinea-pig to try this on. :)

Rich

On Wed, Apr 12, 2017 at 7:53 PM Matt Riedemann 
mailto:mriede...@gmail.com>> wrote:
On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:
> Matt,
>
> Thanks for the response.  It is helpful.
>
> Regards
> -steve
>
> -Original Message-
> From: Matt Riedemann mailto:mriede...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Date: Wednesday, April 12, 2017 at 4:36 PM
> To: 
> "openstack-dev@lists.openstack.org" 
> mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer 
> mentorship program for Kolla deliverables
>
> On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> > Hey folks,
> >
> >
> >
> > In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> > “protocore” mentorship program for Kolla.  We would like to know what
> > nova has learned from this effort.
> >
> >
> >
> > In today’s Kolla meeting we had broad consensus on the following:
> >
> > 1)   Kolla has participants that want to be core reviewers
> >
> > 2)   These participants don’t know how to become core reviewers
> >
> > 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> > on how to do good reviews
> >
> >
> >
> > From that, we concluded some form of mentorship program for potential
> > core reviewers was in order.  We got into some debate about _/how/_ the
> > program should be rolled out.  Let’s use this thread to discuss how it
> > should be rolled out since that seems to be the sticking point of the
> > discussion.  I saw no dissent in the discussion that the basic concepts
> > were a negative change.
> >
> >
> >
> > I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> > from a core reviewer prior to merge.  Nova cores – would you mind
> > defining your process (on the ml is fine) more thoroughly and your
> > experiences so we can learn from you?
> >
> >
> >
> > All kolla contributors, feel free to debate the **how** such a
> > mentorship program should be rolled out.  I think we have a lot to learn
> > from our peers in the OpenStack community and learning from their
> > experiences may be helpful.
> >
> >
> >
> > Regards
> >
> > -steve
> >
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> Nova has this thing? That's news to me. :)
>
> I don't think Nova has a formal process for something like this. There
> was t

Re: [openstack-dev] [libvirt] Whether kvm supports NVIDIA VGPU

[Steve Gordon]

- Original Message -
> From: "文峰sx-9149" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Wednesday, April 12, 2017 10:53:41 PM
> Subject: [openstack-dev]  [libvirt] Whether kvm supports NVIDIA VGPU
> 
> Will the openstack or libvirt (kvm) support NVIDIA VGPU? I am here to see a
>  mail introduction libvirt kvm support VGPU. But I do not know the current
>  development situation of this feature. Who can tell me about VGPU in
>  Openstack?Thanks.

Hi there,

With regards to OpenStack support there is a spec being written here:

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

The intent is to come up with something flexible enough that it will work with 
both the NVIDIA and Intel hardware as well as multiple Nova drivers, should 
they choose to implement it.

Thanks,

Steve

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

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Doug Hellmann]

Excerpts from joehuang's message of 2017-04-13 00:47:53 +:
>  Interesting to know the idea considering OpenStack as group of 
> constellations. Does it mean even
> Nova/Cinder/Neutron are not necessary to be tied together in some user cases?

To me, the important aspect of calling OpenStack "one thing"
(platform, product, toolbox, whatever) has always been that when
used together the components appear cohesive. They have similar
APIs, similar deployment patterns, etc. There are obviously going
to be some underlying differences because a block storage service
is not a VM manager -- they provide different features and need
different inputs.  But the differences should not be surprising or
arbitrary (returning different payloads from the "version" API, to
take an example from another recent thread). It should look like
the teams producing the different components like each other and
get together in person regularly to collaborate.

If we have that, then it doesn't matter so much whether every
deployer installs every single component, or only the ones they
need for their use cases.

Doug

> 
> Seems that "one platform" has not been got consensus yet. But the marketing 
> material of
> OpenStack is claiming "one platform" [1][2]
> 
> [1] 
> https://www.openstack.org/assets/marketing/OpenStack-101-Modular-Deck-1.pptx
> [2] OpenStack 101,  https://www.openstack.org/marketing/#tab=collateral
> 
> Best Regards
> Chaoyi Huang (joehuang)
> 
> 
> From: John Garbutt [j...@johngarbutt.com]
> Sent: 12 April 2017 18:51
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc][elections]questions about one platform  
>   vision
> 
> On 12 April 2017 at 03:54, joehuang  wrote:
> > What's the one platform will be in your own words? What's your proposal and
> > your focus to help one platform vision being achieved?
> 
> The more I think about this, the less I like the phrase "one platform".
> 
> I like to think of OpenStack as group of constellations. Those
> constellations are groups of projects that are built to be used
> together around a shared set of use cases and users. Note that many
> (all?) of those constellations involve open source projects that were
> born and live outside of OpenStack.
> 
> I am trying to kick start the "VM and baremetal" working group to get
> feedback on a specific constellation as a group of projects. Here I am
> thinking about running Nova, Cinder, Neutron, Keystone, etc to give
> you (in some sense) a Software Defined Data Center. Many applications
> and services need to consume and integrate with that platform, like
> Heat, Trove and Magnum, to can get access to the compute, networking
> and storage they need to execute their workloads, such as containers.
> Its like the next generation of consolidation to get to the next level
> of utilization/efficiency. If you look at this constellation the
> database and message queue are important non-OpenStack components of
> the constellation. Maybe this is a false constellation, and there is a
> different set of things that people use together. Thats some of the
> feedback I hope we get at the forum.
> 
> The work ttx mentions is important. I hope the project maps will help
> communicate how users can meet their needs by running various
> combinations of OpenStack and non-OpenStack projects together.
> 
> To be clear, I am not claiming to have the answers here, this is just
> my current thinking. I look forward to all the debate and discussions
> around this topic, and all the interesting things I will learn about
> along that journey, things that will likely make me change my mind.
> 
> Thanks,
> johnthetubaguy
> 

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

Re: [openstack-dev] [tc][elections]questions about one platform vision

[Flavio Percoco]

On 12/04/17 02:54 +, joehuang wrote:

Hello,

I heard the one platform vision in OpenStack now and then: One platform for 
virtual machines, containers and bare metal.

I also learned that there are some groups working on making Kubernets being 
able to manage virtual machines. Except running containers in virtual machine, 
there is also the need for running containers in bare metal.

There are several projects connecting OpenStack to container world: Zun, 
Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, ...

Can all these efforts lead us to one platform vision? We have to think over the 
question.

What's the one platform will be in your own words? What's your proposal and 
your focus to help one platform vision being achieved?




TBH, I think the answer here is a combination of some of the answers from other
folks in this thread. I've always liked to think of OpenStack as one platform in
the sense that it's set of teams (or projects even) working towards providing a
solution for clouds. I also like to think about these set of projects as an
independent, combinable, group of tools that constitue the one platform.

The key here is that I don't like to think about OpenStack as a massive project
that is all or nothing. This has been one of my most common discussions ever
since I started working on OpenStack. It's also one thing I loved about Glance
and that drove some of the decisions when we created Zaqar.

We naming we'll use will help representing what OpenStack is with the fewer
words possible (one platform, constellations, maps, sets, etc). What really
matters in the end are the properties of these projects and how they will
interact with each other. This is what makes this question critical and
difficult to answer (so thanks :).

Providing a set of combinations, maps/constallations is a good excersice. It
helps consumers to picture OpenStack and understand its capabilities better. In
the end, however, I'd prefer the users to create their own constellations/groups
based on what they need.

Flavio

--
@flaper87
Flavio Percoco


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] [Release-job-failures][telemetry][gnocchi] Release of openstack/python-gnocchiclient failed

[Doug Hellmann]

Excerpts from Mehdi Abaakouk's message of 2017-04-13 07:51:36 +0200:
> Thanks for the investigation.
> 
> I see two things:
> 
> * I have forgotten than pushing tag will build the tarball
>   automatically.
> * I have thought I should do the tagging manually because of [1]
> 
> For the second point, if I was wrong and we should continue to use the
> release repo, I have prepared two reviews to regularize the already
> tagged releases and retag a versions to fix the jobs.
> 
> - gnocchiclient: https://review.openstack.org/#/c/456448/
> - gnocchi: https://review.openstack.org/#/c/456449/
> 
> If I was right, I will manually retag a new version without uploading the
> tarballs myself this time and wait for the tooling to do it.

Because Gnocchi is an independent project, you can choose to push
the tags yourself. You should still rely on the automation to build
and upload the artifacts, though. Some jobs, like the announce job,
may not work properly because they require metadata in the tag
message that is added by the release tools but not necessarily
present when you tag by hand. You may end up having to send your
own release announcements (or use the tools by hand, instead of
just running git tag).

As an official project, we would still like to have correct release
information for gnocchi recorded in the openstack/releases repository,
even if you do tag it yourself. So, either

1. tag and then update openstack/releases, or
2. use openstack/releases to start the release (taking full advantage of
   the automation), or
3. remove references to the deliverables from openstack/releases so we
   do not have incomplete information there

Doug

> 
> [1] https://review.openstack.org/#/c/447438/
> 
> On Wed, Apr 12, 2017 at 01:49:54PM -0400, Doug Hellmann wrote:
> >Gnocchi team,
> >
> >The client release you tagged had a build failure.  It looks like
> >the tag was pushed directly, so I will relay the results of the
> >debugging work but let you decide how to deal with it.
> >
> >Clark determined that the files on PyPI do not exactly match the files
> >on our tarballs server. One of the JSON metadata files was regenerated,
> >and because dictionaries are unordered it came out in a different order.
> >
> >Clark also checked the MD5 sum on PyPI and found that the signatures
> >match.
> >
> >It's not clear why the job failed. Subsequent jobs have passed. One
> >course of action you could take is to retag the same commit with a new
> >version number to get new packages, just to be safe.
> >
> >If you choose to stick with the existing packages, you will need to
> >manually submit the constraint update, since that job was skipped after
> >the upload job reported a failure.
> >
> >Please also file the update in the releases repository, so that
> >there is a record of the fact that the release was made.
> >
> >Excerpts from jenkins's message of 2017-04-12 09:29:09 +:
> >> Build failed.
> >>
> >> - python-gnocchiclient-tarball 
> >> http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-tarball/61adb8c/
> >>  : SUCCESS in 3m 52s
> >> - python-gnocchiclient-tarball-signing 
> >> http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-tarball-signing/c7dd0a8/
> >>  : SUCCESS in 11s
> >> - python-gnocchiclient-pypi-both-upload 
> >> http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-pypi-both-upload/0ad195d/
> >>  : FAILURE in 48s
> >> - python-gnocchiclient-announce-release 
> >> python-gnocchiclient-announce-release : SKIPPED
> >> - propose-python-gnocchiclient-update-constraints 
> >> propose-python-gnocchiclient-update-constraints : SKIPPED
> >>
> >
> >__
> >OpenStack Development Mailing 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][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Serguei Bezverkhi (sbezverk)]

The idea is great, no doubt here, meaning mentoring and everything, but it 
should not come with price of reducing quality control. 2 x +2 +w should still 
be required from “regular” cores for PS to merge.

Serguei

From: Richard Wellum [mailto:richwel...@gmail.com]
Sent: Thursday, April 13, 2017 7:02 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

As a relatively new member of the openstack community I think the idea of a 
mentorship program is a good one; I'd like to throw my hat in the ring if the 
kolla community needs a guinea-pig to try this on. :)

Rich

On Wed, Apr 12, 2017 at 7:53 PM Matt Riedemann 
mailto:mriede...@gmail.com>> wrote:
On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:
> Matt,
>
> Thanks for the response.  It is helpful.
>
> Regards
> -steve
>
> -Original Message-
> From: Matt Riedemann mailto:mriede...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Date: Wednesday, April 12, 2017 at 4:36 PM
> To: 
> "openstack-dev@lists.openstack.org" 
> mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer 
> mentorship program for Kolla deliverables
>
> On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> > Hey folks,
> >
> >
> >
> > In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> > “protocore” mentorship program for Kolla.  We would like to know what
> > nova has learned from this effort.
> >
> >
> >
> > In today’s Kolla meeting we had broad consensus on the following:
> >
> > 1)   Kolla has participants that want to be core reviewers
> >
> > 2)   These participants don’t know how to become core reviewers
> >
> > 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> > on how to do good reviews
> >
> >
> >
> > From that, we concluded some form of mentorship program for potential
> > core reviewers was in order.  We got into some debate about _/how/_ the
> > program should be rolled out.  Let’s use this thread to discuss how it
> > should be rolled out since that seems to be the sticking point of the
> > discussion.  I saw no dissent in the discussion that the basic concepts
> > were a negative change.
> >
> >
> >
> > I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> > from a core reviewer prior to merge.  Nova cores – would you mind
> > defining your process (on the ml is fine) more thoroughly and your
> > experiences so we can learn from you?
> >
> >
> >
> > All kolla contributors, feel free to debate the **how** such a
> > mentorship program should be rolled out.  I think we have a lot to learn
> > from our peers in the OpenStack community and learning from their
> > experiences may be helpful.
> >
> >
> >
> > Regards
> >
> > -steve
> >
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> Nova has this thing? That's news to me. :)
>
> I don't think Nova has a formal process for something like this. There
> was talk at the BCN summit about giving some people +2 rights on parts
> of the tree but not full core on everything. We never implemented that.
>
> Maybe what you're referring to is how we consider a +1 from a domain
> expert like a +2, or at least something that's good to have before cores
> are looking into the change in more detail? For example, gibi is the
> lead for the versioned notifications effort and we/I generally look for
> his +1 on a change before digging into it, or approving it. We have
> similar unofficial things like this in other parts of Nova, or subteams,
> like Timofey and Pawel with the live migration subteam.
>
> To be sure, someone that is leading a subteam effort and is looked to
> for their opinion on a whole series of changes eventually gets into the
> conversation when we're talking about potential core reviewers, in part
> because, at least I personally, am looking for not only strong code
> review skills but also leadership/ownership within the project, because
> those are also the people that tend to stick around awhile so I'm more
> comfortable investing my time into them (and building a trust
> relationship with them).
>
>  

Re: [openstack-dev] [tc][election] Questions for Candidates

[Flavio Percoco]

On 12/04/17 16:19 +, Kendall Nelson wrote:

Hello Candidates!
-What is one trait you have that makes it difficult to work in groups like
the TC and how do you counteract it?


I love agreement, I'd rather have everyone agree everytime. This makes it hard
for me to drive some conversations. I'd rather have everyone happy but that is
not something we can always afford.

I work hard not to have disagreement but to find ways we can all agree when
there's disagreement. At the very least, find the things that we can live by.


- What do you see as the biggest roadblock in the upcoming releases for the
TC?


As there hadn't been enough change, I believe we're about to go through a new
change (or phase of realizations if you will). The work to define the vision is
ongoing and we're also working out how we like to think about OpenStack. These
changes/conversations require the community to work together, they require lots
of discussions.

I don't think these conversations/changes are roadblocks but they will require
focus and contributions from the entire community, which is struggling to stay
focused and find contributions in some areas.



And one lighthearted question:

-What is your favorite thing about OpenStack?


The community! I know other's have said this but it is the thing I like the
most. I talk about it[0] whenever I can. I share our experiences and how it's
grown (and helped me grow). It's like a common (huge) Italian family. You don't
always know everyone, there are discussions, disagreements, etc. but we always
work towards a common goal. Oh, and we love eating and drinking :D

Flavio

[0] 
https://speakerdeck.com/flaper87/keeping-up-with-the-pace-of-a-fast-growing-community-without-dying


--
@flaper87
Flavio Percoco


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] [ heat ]

[venkata mahesh]

Hi team,

I am creating a stack which is having nested templates. So while issuing
the heat stack-create command I got error " Failed to fetch the remote
template < template name >". My heat version is 0.2.8 . Can you please help
how to overcome the issue?

Regards,
VenkataMahesh
__
OpenStack Development Mailing 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] [devstack] uwsgi for API services

[Sean Dague]

One of the many reasons for getting all our API services running wsgi
under a real webserver is to get out of the custom ports for all
services game. However, because of some of the limits of apache
mod_wsgi, we really haven't been able to do that in our development
enviroment. Plus, the moment we go to mod_wsgi for some services, the
entire development workflow for "change this library, refresh the
following services" changes dramatically.

It would be better to have a consistent story here.

So there is some early work up to use apache mod_proxy_uwsgi as the
listener, and uwsgi processes running under systemd for all the
services. These bind only to a unix local socket, not to a port.
https://review.openstack.org/#/c/456344/

Early testing locally has been showing progress. We still need to prove
out a few things, but this should simplify a bunch of the setup. And
coming with systemd will converge us back to a more consistent
development workflow when updating common code in a project that has
both API services and workers.

For projects that did the mod_wsgi thing in a devstack plugin, this is
going to require some adjustment. Exactly what is not yet clear, but
it's going to be worth following that patch.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [tripleo][manila] Ganesha deployment

[Jan Provaznik]

On Tue, Apr 11, 2017 at 9:45 PM, Ben Nemec  wrote:
>
>
> On 04/11/2017 02:00 PM, Giulio Fidente wrote:
>>
>> On Tue, 2017-04-11 at 16:50 +0200, Jan Provaznik wrote:
>>>
>>> On Mon, Apr 10, 2017 at 6:55 PM, Ben Nemec 
>>> wrote:

 On 04/10/2017 03:22 AM, Jan Provaznik wrote:
 Well, on second thought it might be possible to make the Storage
 network
 only routable within overcloud Neutron by adding a bridge mapping
 for the
 Storage network and having the admin configure a shared Neutron
 network for
 it.  That would be somewhat more secure since it wouldn't require
 the
 Storage network to be routable by the world.  I also think this
 would work
 today in TripleO with no changes.

>>>
>>> This sounds interesting, I was searching for more info how bridge
>>> mapping should be done in this case and how specific setup steps
>>> should look like, but the process is still not clear to me, I would
>>> be
>>> grateful for more details/guidance with this.
>>
>>
>> I think this will be represented in neutron as a provider network,
>> which has to be created by the overcloud admin, after the overcloud
>> deployment is finished
>>
>> While based on Kilo, this was one of the best docs I could find and it
>> includes config examples [1]
>>
>> It assumes that the operator created a bridge mapping for it when
>> deploying the overcloud
>>
 I think the answer here will be the same as for vanilla Ceph.  You
 need to
 make the network routable to instances, and you'd have the same
 options as I
 discussed above.

>>>
>>> Yes, it seems that using the mapping to provider network would solve
>>> the existing problem when using ceph directly and when using ganesha
>>> servers in future (it would be just matter of to which network is
>>> exposed).
>>
>>
>> +1
>>
>> regarding the composability questions, I think this represents a
>> "composable HA" scenario where we want to manage a remote service with
>> pacemaker using pacemaker-remote
>>
>> yet at this stage I think we want to add support for new services by
>> running them in containers first (only?) and pacemaker+containers is
>> still a work in progress so there aren't easy answers
>>
>> containers will have access to the host networks though, so the case
>> for a provider network in the overcloud remains valid
>>
>> 1. https://docs.openstack.org/kilo/networking-guide/scenario_provider_o
>> vs.html
>>
>
> I think there are three major pieces that would need to be in place to have
> a storage provider network:
>
> 1) The storage network must be bridged in the net-iso templates.  I don't
> think our default net-iso templates do that, but there are examples of
> bridged networks in them:
> https://github.com/openstack/tripleo-heat-templates/blob/master/network/config/multiple-nics/compute.yaml#L121
> For the rest of the steps I will assume the bridge was named br-storage.
>
> 2) Specify a bridge mapping when deploying the overcloud.  The environment
> file would look something like this (datacentre is the default value, so I'm
> including it too):
>
> parameter_defaults:
>   NeutronBridgeMappings: 'datacentre:br-ex,storage:br-storage'
>
> 3) Create a provider network after deployment as described in the link
> Giulio provided.  The specific command will depend on the network
> architecture, but it would need to include "--provider:physical_network
> storage".
>
> We might need to add the ability to do 3 as part of the deployment,
> depending what is needed for the Ganesha deployment itself.  We've typically
> avoided creating network resources like this in the deployment because of
> the huge variations in what people want, but this might be an exceptional
> case since the network will be a required part of the overcloud.
>
>

Thank you both for your help, based on steps suggested above I was
able to mount ceph volume in user instance when Overcloud was deployed
with net-iso with net-single-nic-with-vlans (which is the easiest one
I can deploy in my virtualenv). For net-single-nic-with-vlans I
skipped creation of additional bridge (since single bridge is used for
all networks in this case) and deployed OC as usually, then I
configured networking:
neutron net-create storage --shared --provider:physical_network
datacentre --provider:network_type vlan --provider:segmentation_id 30
neutron subnet-create --name storage-subnet --allocation-pool
start=172.16.1.100,end=172.16.1.120--enable-dhcp storage
172.16.1.0/24

and created user instance with tenant and storage network:
| f7d4e619-c8f5-4de3-a4c3-4120eea818d1 | Server1 | ACTIVE | -
| Running | default-net=192.168.2.107, 192.168.24.100;
storage=172.16.1.110 |

The obstacle I'm hitting though is that the second interface with
storage network doesn't come up automatically on instance boot:
3: eth1:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether fa:16:3e:71:90:df brd ff:ff:ff:ff:ff:ff

from cloud-init log:
ci-info: ++

Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Richard Wellum]

As a relatively new member of the openstack community I think the idea of a
mentorship program is a good one; I'd like to throw my hat in the ring if
the kolla community needs a guinea-pig to try this on. :)

Rich

On Wed, Apr 12, 2017 at 7:53 PM Matt Riedemann  wrote:

> On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:
> > Matt,
> >
> > Thanks for the response.  It is helpful.
> >
> > Regards
> > -steve
> >
> > -Original Message-
> > From: Matt Riedemann 
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> > Date: Wednesday, April 12, 2017 at 4:36 PM
> > To: "openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> > Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer
> mentorship program for Kolla deliverables
> >
> > On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> > > Hey folks,
> > >
> > >
> > >
> > > In today’s Kolla team meeting, the idea was proposed of adopting
> nova’s
> > > “protocore” mentorship program for Kolla.  We would like to know
> what
> > > nova has learned from this effort.
> > >
> > >
> > >
> > > In today’s Kolla meeting we had broad consensus on the following:
> > >
> > > 1)   Kolla has participants that want to be core reviewers
> > >
> > > 2)   These participants don’t know how to become core reviewers
> > >
> > > 3)   The core reviewers in Kolla should mentor “protocore”
> reviewers
> > > on how to do good reviews
> > >
> > >
> > >
> > > From that, we concluded some form of mentorship program for
> potential
> > > core reviewers was in order.  We got into some debate about
> _/how/_ the
> > > program should be rolled out.  Let’s use this thread to discuss
> how it
> > > should be rolled out since that seems to be the sticking point of
> the
> > > discussion.  I saw no dissent in the discussion that the basic
> concepts
> > > were a negative change.
> > >
> > >
> > >
> > > I am aware that nova uses a +1 review from a “protocore” and a
> +2/+w
> > > from a core reviewer prior to merge.  Nova cores – would you mind
> > > defining your process (on the ml is fine) more thoroughly and your
> > > experiences so we can learn from you?
> > >
> > >
> > >
> > > All kolla contributors, feel free to debate the **how** such a
> > > mentorship program should be rolled out.  I think we have a lot to
> learn
> > > from our peers in the OpenStack community and learning from their
> > > experiences may be helpful.
> > >
> > >
> > >
> > > Regards
> > >
> > > -steve
> > >
> > >
> > >
> > >
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > Nova has this thing? That's news to me. :)
> >
> > I don't think Nova has a formal process for something like this.
> There
> > was talk at the BCN summit about giving some people +2 rights on
> parts
> > of the tree but not full core on everything. We never implemented
> that.
> >
> > Maybe what you're referring to is how we consider a +1 from a domain
> > expert like a +2, or at least something that's good to have before
> cores
> > are looking into the change in more detail? For example, gibi is the
> > lead for the versioned notifications effort and we/I generally look
> for
> > his +1 on a change before digging into it, or approving it. We have
> > similar unofficial things like this in other parts of Nova, or
> subteams,
> > like Timofey and Pawel with the live migration subteam.
> >
> > To be sure, someone that is leading a subteam effort and is looked to
> > for their opinion on a whole series of changes eventually gets into
> the
> > conversation when we're talking about potential core reviewers, in
> part
> > because, at least I personally, am looking for not only strong code
> > review skills but also leadership/ownership within the project,
> because
> > those are also the people that tend to stick around awhile so I'm
> more
> > comfortable investing my time into them (and building a trust
> > relationship with them).
> >
> > So that's all unofficial non-formal stuff and basically grew up
> > organically around the subteam efforts that started several releases
> > ago. I don't know if this helps you or not.
> >
> > --
> >
> > Thanks,
> >
> > Matt
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject

Re: [openstack-dev] [tc][election] Questions for Candidates

[John Garbutt]

On 12 April 2017 at 17:19, Kendall Nelson  wrote:
> -What is one trait you have that makes it difficult to work in groups like
> the TC and how do you counteract it?

My inability to say no to more work (and being too interested in everything).

I think I am slowly getting better at focusing, delegating and saying
no. (Although folks who were in the Nova PTG room might be laughing
and rolling around on the floor right now.)

> - What do you see as the biggest roadblock in the upcoming releases for the
> TC?

In terms of the TC making progress on the vision, getting distracted
by minucia and the past is probably two big traps.

Overall progress for the whole of OpenStack, I think its all about
retaining contributors and making it easier to get deeply involved.
The need for a more diverse set of sponsoring companies for the top
5-10% of contributors is possibly just a symptom, but its very
related.

> -What is your favorite thing about OpenStack?

Its the people, their passion and the general spirit of collaboration.
(I was thinking hard to say something new... but its totally the people)

Thanks,
johnthetubaguy

__
OpenStack Development Mailing 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] [openstack][keystonemiddleware][oslo_context]

[lương hữu tuấn]

Hi,

I am now trying to refactor the mistral context by using oslo_context.
However, it turns out the error in testing of keystone (this test belongs
to mistral unittest). What i saw in the error that, the below statement
does not return value:

auth_url = CONF.keystone_authtoken.auth_uri
(
https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py#L48
)

and then keystone client can not authenticate since auth_url is not
provided. I did not change anything just refactor the context. Master
branch is still going well with this test.

Does any one have information about it? Thanks in advanced

Br,

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

Re: [openstack-dev] [tc][election] Questions for Candidates

[Thierry Carrez]

Kendall Nelson wrote:
> -What is one trait you have that makes it difficult to work in groups
> like the TC and how do you counteract it? 

I dislike conflict, and would always like everyone to win. I consider
most people in this community as good friends and I like when they are
all happy. This drives me to look for solutions that accommodate
everyone in our community, which are not necessarily the best technical
solution. That said, I've been getting better at saying "no" and having
hard discussions lately. It's just a natural bias I need to be aware of,
and keep under control.

> - What do you see as the biggest roadblock in the upcoming releases for
> the TC?

As others have mentioned, I think our biggest challenge is to handle the
drop in contributions, or rather handle the transition from an era of
too many contributors to an era of not enough contributors. Our
challenge used to be to handle the growth and not collapse under the
in-take. Our new challenge is to scale back to more "normal" levels of
contribution, focus more, operate horizontal services with less humans,
and transition from a mostly vendor-driven contributor base to a more
balanced contributor base. This will require tweaking a few old rules,
and facilitating direct involvement from users (which we have plenty of)
in development.

> And one lighthearted question: 
> 
> -What is your favorite thing about OpenStack? 

Beyond the awesome community, the shared openness values and principles,
I like the social experiment. OpenStack upstream project governance is
pretty unique, being under control of the contributors with all-elected
leadership positions, and no paid-for seats. I think this ownership
feeling is one of the reasons that make people attached to the project,
beyond the organization they are affiliated with. This model is not
without flaws, but I believe it's a good long-term model, and would
definitely like to see where it goes.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [heat] change in behavior from Mitaka to Newton, is this a bug ?

[Saverio Proto]

Hello,

I confirm that setting:

[oslo_middleware]
enable_proxy_headers_parsing = true

Fixes the problem, and the 'links' property when I create new stacks
gets again the https:// URL.

THANK YOU !!! :)

Anyway we should document this change in the Release notes for people
upgrading to Newton.

I never had:
secure_proxy_ssl_header=X-Forwarded-Proto

in my Mitaka config, because that was the default setting, it was not
necessary to set it explicit.

Also according to:
https://docs.openstack.org/newton/config-reference/orchestration/api.html
the setting is deprecated but not removed.

Adding the enable_proxy_headers_parsing parameter we are also changing
the default behavior, and this is bad if it is not written in the heat
release notes.

https://docs.openstack.org/releasenotes/heat/liberty.html
https://docs.openstack.org/releasenotes/heat/mitaka.html
https://docs.openstack.org/releasenotes/heat/newton.html

Please correct me if I am wrong. But I cannot find anything in the
release (upgrade) notes that warns you should flag this to true if you
are running behind a proxy.

Is it possible to integrate the release notes for Newton now adding a
file in releasenotes/notes/ ? How does it work ?

thank you

Saverio



On 13/04/17 09:52, Rabi Mishra wrote:
> On Thu, Apr 13, 2017 at 1:04 PM, Saverio Proto  > wrote:
> 
> Hello,
> 
> I am looking at a strange change in default behavior in heat, after the
> upgrade from Mitaka to Newton.
> 
> when you do
> 
> openstack stack show uuid
> 
> you get a table, and there is a property called 'links'
> 
> In Mitaka the value was something like
> 
> - href: https://URL
>   rel: self
> 
> After I upgraded to Newton the 'links' field changed to
> 
> http://URL (self)
> 
> Also in the process the 's' from https went missing.
> 
> 
> Though not sure, may be related to http_proxy_to_wsgi middleware related
> change as mentioned here[1] in newton?
> 
> [1] https://bugs.launchpad.net/heat/+bug/1630778
> 
> May be add the below in heat.conf and check.
> 
> [oslo_middleware]
> enable_proxy_headers_parsing = true
> 
>  
> 
> This broke first of all our rally tests, that now fail with "Prohibited
> endpoint redirect"
> 
> It also broke Horizon, because if I click on the stack name, I am not
> able to get to the page with the stack property, but I get a red box
> "Error: Unable to retrieve stack.".
> 
> Before opening a strange bug that will be marked as "Invalid" I would
> like to understand better what is this 'links' property of the stack,
> and why it changed from Mitaka to Newton ? Is possible this is a
> regression bug ?
> 
> Thank you
> 
> Saverio
> 
> 
> 
> 
> 
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch ,
> http://www.switch.ch
> 
> http://www.switch.ch/stories
> 
> __
> OpenStack Development Mailing 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,
> Rabi Misra
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing 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] Tags, revisions, dockerhub

[Bogdan Dobrelya]

On 13.04.2017 0:59, Michał Jastrzębski wrote:
> My dear Kollegues,
> 
> Today we had discussion about how to properly name/tag images being
> pushed to dockerhub. That moved towards general discussion on revision
> mgmt.
> 
> Problem we're trying to solve is this:
> If you build/push images today, your tag is 4.0
> if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
> we tag new release.

+1 that this should be improved, indeed.

> 
> But image built today is not equal to image built tomorrow, so we
> would like something like 4.0.0-1, 4.0.0-2.

Please take a look the build flow for a neighbour project Kubernetes
[0]. I believe it addresses each of the possible versioning aspects,
like stable branch builds, master builds, infrastructure vs local builds
and so on. Kolla could reuse some build scripts and follow the similar
versioning scheme from that project and save time as well.

[0] https://github.com/kubernetes/kubernetes/tree/master/build#basic-flow

> While we can reasonably detect history of revisions in dockerhub,
> local env will be extremely hard to do.
> 
> I'd like to ask you for opinions on desired behavior and how we want
> to deal with revision management in general.
> 
> Cheers,
> Michal
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] What is the difference between default_schedule_zone and default_availability_zone?

[Sylvain Bauza]

Le 12/04/2017 18:24, Matt Riedemann a écrit :
> I'm hoping someone more learned can teach me. These two options sound
> very similar, and are thus very confusing. They are also both in the
> [DEFAULT] config option group, but defined in different places [1][2].
> 
> The help text for one says:
> 
> "This option determines the availability zone to be used when it is not
> specified in the VM creation request."
> 
> The help text for the other says:
> 
> "Availability zone to use when user doesn't specify one.
> This option is used by the scheduler to determine which availability
> zone to place a new VM instance into if the user did not specify one
> at the time of VM boot request."
> 
> It looks like one goes on the instance record itself, and the other goes
> into an aggregate metadata if the zone is specified for the aggregate.
> 
> So while they sound the exact same, they are not? Or are they in the
> end? See how this is terrible?
> 


So, the upstream documentation mentions a bit of that :
https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs

To be clear :
 - default_availability_zone is related to compute nodes. If one node is
not in an aggregate having an AZ metadata, then the availability_zones
API will return the node into the default AZ named by this opt (default
is "nova").
 - default_schedule_zone is related to instances. If a user doesn't
provide --availability-zone flag when booting the instance, then the
compute API will set the instance.az field to be this conf opt (default
is None). That conf opt value is not returned when you nova show an
instance, because OS-EXT-AZ:availability_zone attribute is rather
getting you the related AZ for the node where the instance is (ie.
either the aggregate AZ metadata where the host belongs to, or
default_availability_zone opt value).



To be clear, default_availability_zone is used for API related concerns
where we want to provide a consistent UX if people want to see a cloud
by AZs, while default_schedule_zone is rather for an internal use for
knowing whether we should force by default instances to be within a
specific AZ or if they should be AZ-free (and then move operations
wouldn't be constrained by AZs).


HTH,
-Sylvain


> [1]
> https://github.com/openstack/nova/blob/5a556a720f5a7394cab4c84fa6202976c6190b23/nova/conf/availability_zone.py#L34
> 
> [2]
> https://github.com/openstack/nova/blob/5a556a720f5a7394cab4c84fa6202976c6190b23/nova/conf/compute.py#L49
> 
> 

__
OpenStack Development Mailing 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] [Tacker][OSC] Command naming specs

[Trinath Somanchi]

Thanks Akihiro for suggestions and comments.
Thanks,
Trinath Somanchi.

Digital Networking | NXP – Hyderabad – INDIA.
Email: trinath.soman...@nxp.com
Mobile: +91 9866235130 | Off: +91 4033504051


From: Akihiro Motoki [mailto:amot...@gmail.com]
Sent: Thursday, April 13, 2017 8:17 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs

networking-sfc has many overlapping areas with tacker and the command names can 
conflict, so I believe it is worth shared in this thread.

networking-sfc team is now implementing OSC commands (as neutronclient OSC 
plugin).
Their command name proposal can be found at 
https://review.openstack.org/#/c/409759/
and command names are like 
https://review.openstack.org/#/c/409759/30/doc/source/usage/osc/v2/networking-sfc.rst

As of now, networking-sfc commands are like:
  openstack sfc port chain create
  openstack sfc port pair group create
  openstack sfc port pair create
  openstack sfc flow classifier create

We would like to use 'sfc' (or 'network sfc') and
hope the tacker team avoid conflicts and confusions between tacker and 
networking-sfc commands.

Personally, 'sfc' is not a well-known abbreviation, but the full spelling 
'service function chaining' looks too long.
I don't think users want to type 'openstack service function chaining port 
chain group create' :-(  It loses usability significantly.

Thanks,
Akihiro

2017-04-13 8:23 GMT+09:00 Trinath Somanchi 
mailto:trinath.soman...@nxp.com>>:
But if we don’t prefix, then we are afraid we might confuse users with command 
names and conflict with other projects.

Example, ‘network-service’ if we follow the existing way, then

$> openstack network service create

might confuse the user in context that it’s a neutron/networking command. Is 
that not True?

Also, for some other commands, like sfc, we might end up conflict with 
networking-sfc.

Like, $> openstack  sfc show  (or) openstack service function chain show

With some of the other commands, there are abbreviations like

$> openstack vnffgd create

If the above command must be split to words, it spells like,

$> openstack virtual network function forwarding graph descriptor create  


If we elaborate this way the command itself will be a lengthy string where user 
has a very lengthy command.

Any suggestions for these?
Thanks,
Trinath Somanchi.

Digital Networking | NXP – Hyderabad – INDIA.
Email: trinath.soman...@nxp.com
Mobile: +91 9866235130 | Off: +91 
4033504051


From: Dean Troyer [mailto:dtro...@gmail.com]
Sent: Wednesday, April 12, 2017 10:17 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs

On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi 
mailto:trinath.soman...@nxp.com>> wrote:
Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the prefix.

Note that OSC itself does not use 'command prefixes', it names resources with 
enough specificity to make them unique.  Sometimes that looks like a proefix, 
but it is not.


For the below commands, for readability, we have added ‘-‘ within the command 
names.
Like,
  network-service,  vnf-forwarding-graph, service-function-chain,
network-flow-classifier, network-forwarding-path.

But the existing OSC commands don’t have a ‘-‘ in between the command names.

The OSC command structure specifically does not use dashes or underscores as 
separators, it uses spaces.  We want commands to be words.  Dashes are only 
used in option names due to option parsing rules.

Specifically in networking there are a large number of resources that are hard 
to concisely name.  Plugins are of course free to do what they want but we 
encourage them to use the OSC guidelines, and we know that users _really_ 
appreciate staying consistent.

There are places where you may feel forced to use abbreviations ('vnf' in your 
example above).  Those are discouraged, but we also recognize that they are 
often the most common usage ('IP' in IP address for example) and where that 
usage is common is fine.  Again, networking is an area where many things are 
commonly known only by their abbreviation, and this usage is in fact expected 
by users.  In the end, picking commands that are what users would expect to 
search for is what they appreciate the most.

dt

--

Dean Troyer
dtro...@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] [heat] change in behavior from Mitaka to Newton, is this a bug ?

[Rabi Mishra]

On Thu, Apr 13, 2017 at 1:04 PM, Saverio Proto 
wrote:

> Hello,
>
> I am looking at a strange change in default behavior in heat, after the
> upgrade from Mitaka to Newton.
>
> when you do
>
> openstack stack show uuid
>
> you get a table, and there is a property called 'links'
>
> In Mitaka the value was something like
>
> - href: https://URL
>   rel: self
>
> After I upgraded to Newton the 'links' field changed to
>
> http://URL (self)
>
> Also in the process the 's' from https went missing.
>
>
Though not sure, may be related to http_proxy_to_wsgi middleware related
change as mentioned here[1] in newton?

[1] https://bugs.launchpad.net/heat/+bug/1630778

May be add the below in heat.conf and check.

[oslo_middleware]
enable_proxy_headers_parsing = true



> This broke first of all our rally tests, that now fail with "Prohibited
> endpoint redirect"
>
> It also broke Horizon, because if I click on the stack name, I am not
> able to get to the page with the stack property, but I get a red box
> "Error: Unable to retrieve stack.".
>
> Before opening a strange bug that will be marked as "Invalid" I would
> like to understand better what is this 'links' property of the stack,
> and why it changed from Mitaka to Newton ? Is possible this is a
> regression bug ?
>
> Thank you
>
> Saverio
>
>
>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing 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,
Rabi Misra
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] change in behavior from Mitaka to Newton, is this a bug ?

[Saverio Proto]

Hello,

I am looking at a strange change in default behavior in heat, after the
upgrade from Mitaka to Newton.

when you do

openstack stack show uuid

you get a table, and there is a property called 'links'

In Mitaka the value was something like

- href: https://URL
  rel: self

After I upgraded to Newton the 'links' field changed to

http://URL (self)

Also in the process the 's' from https went missing.

This broke first of all our rally tests, that now fail with "Prohibited
endpoint redirect"

It also broke Horizon, because if I click on the stack name, I am not
able to get to the page with the stack property, but I get a red box
"Error: Unable to retrieve stack.".

Before opening a strange bug that will be marked as "Invalid" I would
like to understand better what is this 'links' property of the stack,
and why it changed from Mitaka to Newton ? Is possible this is a
regression bug ?

Thank you

Saverio





-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

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

Re: [openstack-dev] [TripleO][Heat] Conditionally passing properties in Heat

[Rabi Mishra]

On Thu, Apr 13, 2017 at 2:14 AM, Dan Sneddon  wrote:

> On 04/12/2017 01:22 PM, Thomas Herve wrote:
> > On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon 
> wrote:
> >> I'm implementing predictable control plane IPs for spine/leaf, and I'm
> >> running into a problem implementing this in the TripleO Heat templates.
> >>
> >> I have a review in progress [1] that works, but fails on upgrade, so I'm
> >> looking for an alternative approach. I'm trying to influence the IP
> >> address that is selected for overcloud nodes' Control Plane IP. Here is
> >> the current construct:
> >>
> >>   Controller:
> >> type: OS::TripleO::Server
> >> metadata:
> >>   os-collect-config:
> >> command: {get_param: ConfigCommand}
> >> properties:
> >>   image: {get_param: controllerImage}
> >>   image_update_policy: {get_param: ImageUpdatePolicy}
> >>   flavor: {get_param: OvercloudControlFlavor}
> >>   key_name: {get_param: KeyName}
> >>   networks:
> >> - network: ctlplane  # <- Here's where the port is created
> >>
> >> If I add fixed_ip: to the networks element at the end of the above, I
> >> can select an IP address from the 'ctlplane' network, like this:
> >>
> >>   networks:
> >> - network: ctlplane
> >>   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
> >>
> >> But the problem is that if I pass a blank string to fixed_ip, I get an
> >> error on deployment. This means that the old behavior of automatically
> >> selecting an IP doesn't work.
> >>
> >> I thought I has solved this by passing an external Neutron port, like
> this:
> >>
> >>   networks:
> >> - network: ctlplane
> >>   port: {get_attr: [ControlPlanePort, port_id]}
> >>
> >> Which works for deployments, but that fails on upgrades, since the
> >> original port was created as part of the Nova::Server resource, instead
> >> of being an external resource.
> >
> > Can you detail how it fails? I was under the impression we never
> > replaced servers no matter what (or we try to do that, at least). Is
> > the issue that your new port is not the correct one?
> >
> >> I'm now looking for a way to use Heat conditionals to apply the fixed_ip
> >> only if the value is not unset. Looking at the intrinsic functions [2],
> >> I don't see a way to do this. Is what I'm trying to do with Heat
> possible?
> >
> > You should be able to write something like that (not tested):
> >
> > networks:
> >   if:
> > - 
> > - network: ctlplane
> >   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
> > - network: ctlplane
> >
> > The question is how to define your condition. Maybe:
> >
> > conditions:
> >   fixed_ip_condition:
> >  not:
> > equals:
> >   - {get_attr: [ControlPlanePort, ip_address]}
> >   - ''
> >
> > To get back to the problem you stated first.
> >
> >
> >> Another option I'm exploring is conditionally applying resources. It
> >> appears that would require duplicating the entire TripleO::Server stanza
> >> in *-role.yaml so that there is one that uses fixed_ip and one that does
> >> not. Which one is applied would be based on a condition that tested
> >> whether fixed_ip was blank or not. The downside of that is that it would
> >> make the role definition confusing because there would be a large
> >> resource that was implemented twice, with only one line difference
> >> between them.
> >
> > You can define properties with conditions, so you shouldn't need to
> > rewrite everything.
> >
>
> Thomas,
>
> Thanks, I will try your suggestions and that should get me closer.
>
> The full error log is available here:
> http://logs.openstack.org/78/413278/11/check-tripleo/gate-
> tripleo-ci-centos-7-ovb-updates/8d91762/console.html
>
> We do an interface_detach/attach when a port is replaced.
It seems to be failing[1] as this is not implemented for ironic/baremetal
driver.  I could see a patch[2] to add that functionality though.

[1]
http://logs.openstack.org/78/413278/11/check-tripleo/gate-tripleo-ci-centos-7-ovb-updates/8d91762/logs/undercloud/var/log/nova/nova-compute.txt.gz#_2017-04-12_00_26_15_475

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

We retry a few times to check whether the detach/attach is complete(it's an
async operation in nova and takes time), so the cryptic error below is
coming from tenacity library which fails after the configured number of
attempts.

Here are the errors I am getting:
>
> 2017-04-12 00:26:34.436655 | 2017-04-12 00:26:29Z
> [overcloud-CephStorage-bkucn6ign34i-0-2yq2jbtwuu7k.CephStorage]:
> UPDATE_FAILED  RetryError: resources.CephStorage: RetryError[ 0xdd62550 state=finished returned bool>]
> 2017-04-12 00:26:34.436808 | 2017-04-12 00:26:29Z
> [overcloud-CephStorage-bkucn6ign34i-0-2yq2jbtwuu7k]: UPDATE_FAILED
> RetryError: resources.CephStorage: RetryError[ state=finished returned bool>]
> 2017-04-12 00:26:34.436903 | 2017-04-12 00:26:29Z
> [overcloud-CephStorage-bkucn6ign34i.0]: UPDATE_FAILED  resources[0]:
>