[openstack-dev] [diskimage-builder] Restarting bi-weekly meeting

[Ian Wienand]

Hi,

We've let this meeting [1] lapse, to our communications detriment.  I
will restart it, starting next week [2].  Of course agenda items are
welcome, otherwise we will use it as a session to make sure patches
are moving in the right direction.

If the matter is urgent, and not getting attention, an agenda item in
the weekly infra meeting would be appropriate.

Ping me off list if you're interested but this time doesn't work.  If
there's a few, we can move it.

Thanks,

-i

[1] http://eavesdrop.openstack.org/#Diskimage_Builder_Team_Meeting
[2] https://review.openstack.org/468270

__
OpenStack Development Mailing 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] [mistral][freezer] adopting oslo.context for logging debugging and tracing

[Renat Akhmerov]

Thanks Doug. We’ll look into this.

@Tuan, is there any roadblocks with the patch you’re working on? [1]

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


Renat

On 26 May 2017, 01:54 +0700, Doug Hellmann , wrote:
> The new work to add the exception information and request ID tracing
> depends on using both oslo.context and oslo.log to have all of the
> relevant pieces of information available as log messages are emitted.
>
> In the course of reviewing the "done" status for those initiatives,
> I noticed that although mistral and freezer are using oslo.log,
> neither uses oslo.context. That means neither project will get the
> extra debugging information, and neither project will see the global
> request ID in logs.
>
> I started looking at updating mistral's context to use oslo.context
> as a base class, but ran into some issues because of some extensions
> made to the existing class. I wasn't able to find where freezer is
> doing anything at all with an API request context.
>
> I'm available to help, if someone else wants to pick up the work.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] nominating Mike Fedosin for glance core

[feilong]

Welcome back, Mike.


On 26/05/17 16:21, Kekane, Abhishek wrote:


+1, agree with Nikhil.

Abhishek

*From:*Nikhil Komawar [mailto:nik.koma...@gmail.com]
*Sent:* Friday, May 26, 2017 6:04 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [glance] nominating Mike Fedosin for 
glance core


This is great news. Always +2 for Mike, he's been great (dev, glancer, 
stacker ..) all the years. Let's not wait so long for reinstatement if 
folks are on-board, as having another core will only help.


On Thu, May 25, 2017 at 11:53 AM, Brian Rosmaita 
> wrote:


As you've no doubt read elsewhere on the ML, we've lost several glance
cores recently due to employment changes.  Luckily, Mike Fedosin
informed me at today's Glance weekly meeting that he will have time
for the next few months to devote some time to Glance reviewing.

For those who don't know Mike (mfedosin on IRC), he was a Glance core
for several years.  He provided a lot of notes that were used to write
the Glance architecture documentation that is so helpful to new
contributors, so he's extremely knowledgeable about the design
patterns used in Glance.

Most recently, Mike's been working on the Glare project, which has a
lot in common with Glance.  While Mike says he can't commit much time
to Glance development, he has proposed porting some of the Glare tests
over to Glance, which will certainly help with our code coverage, and
would be a helpful addition to Glance.

(Mike agreed at today's Glance meeting not to propose re-integrating
Glare into the Glance project until the Queens PTG (if at all), so I'm
not worried about that being a distraction during the Pike cycle when
we are so short-handed.)

I'd like to reinstate Mike as a Glance core contributor at the next
Glance weekly meeting.  Please reply to this message with any comments
or concerns before 23:59 UTC on Wednesday 31 May 2017.

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




--

--

Thanks,

Nikhil


__
Disclaimer: This email and any attachments are sent in strictest 
confidence

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

or forwarding.


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


--
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
OpenStack Development Mailing 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] [glance] nominating Mike Fedosin for glance core

[Kekane, Abhishek]

+1, agree with Nikhil.

Abhishek

From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
Sent: Friday, May 26, 2017 6:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] nominating Mike Fedosin for glance core

This is great news. Always +2 for Mike, he's been great (dev, glancer, stacker 
..) all the years.  Let's not wait so long for reinstatement if folks are 
on-board, as having another core will only help.

On Thu, May 25, 2017 at 11:53 AM, Brian Rosmaita 
> wrote:
As you've no doubt read elsewhere on the ML, we've lost several glance
cores recently due to employment changes.  Luckily, Mike Fedosin
informed me at today's Glance weekly meeting that he will have time
for the next few months to devote some time to Glance reviewing.

For those who don't know Mike (mfedosin on IRC), he was a Glance core
for several years.  He provided a lot of notes that were used to write
the Glance architecture documentation that is so helpful to new
contributors, so he's extremely knowledgeable about the design
patterns used in Glance.

Most recently, Mike's been working on the Glare project, which has a
lot in common with Glance.  While Mike says he can't commit much time
to Glance development, he has proposed porting some of the Glare tests
over to Glance, which will certainly help with our code coverage, and
would be a helpful addition to Glance.

(Mike agreed at today's Glance meeting not to propose re-integrating
Glare into the Glance project until the Queens PTG (if at all), so I'm
not worried about that being a distraction during the Pike cycle when
we are so short-handed.)

I'd like to reinstate Mike as a Glance core contributor at the next
Glance weekly meeting.  Please reply to this message with any comments
or concerns before 23:59 UTC on Wednesday 31 May 2017.

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



--
--
Thanks,
Nikhil

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuxi][kuryr] Where to commit codes for Fuxi-golang

[zengchen]

Hi john:
I have seen your updates on the bp. I agree with your plan on how to 
develop the codes.
However, there is one issue I have to remind you that at present, Fuxi not 
only can convert
 Cinder volume to Docker, but also Manila file. So, do you consider to involve 
Manila part of codes
 in the new Fuxi-golang? Besides, IMO, It is better to create a repository for 
Fuxi-golang, because
 Fuxi is the project of Openstack,


   Thanks very much!


Best Wishes!
zengchen





At 2017-05-25 22:47:29, "John Griffith"  wrote:





On Thu, May 25, 2017 at 5:50 AM, zengchen  wrote:

Very sorry to foget attaching the link for bp of rewriting Fuxi with go 
language.
https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang




At 2017-05-25 19:46:54, "zengchen"  wrote:

Hi guys:
hongbin had committed a bp of rewriting Fuxi with go language[1]. My 
question is where to commit codes for it.
We have two choice, 1. create a new repository, 2. create a new branch.  IMO, 
the first one is much better. Because
there are many differences in the layer of infrastructure, such as CI.  What's 
your opinion? Thanks very much
 
Best Wishes
zengchen

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


Hi Zengchen,


For now I was thinking just use Github and PR's outside of the OpenStack 
projects to bootstrap things and see how far we can get.  I'll update the BP 
this morning with what I believe to be the key tasks to work through.


Thanks,
John

__
OpenStack Development Mailing 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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

[John Griffith]

On Thu, May 25, 2017 at 6:25 PM, Zhipeng Huang 
wrote:

> Hi John and Zeng,
>
> The OpenSDS community already developed a golang client for the
> os-brick[1], I think we could host the new golang os-brick code there as a
> new repo and after things settled port the code back to OpenStack
>
> [1]https://github.com/opensds/opensds/blob/master/pkg/dock/
> plugins/connector/connector.go
>
> On Thu, May 25, 2017 at 10:47 PM, John Griffith 
> wrote:
>
>>
>>
>> On Thu, May 25, 2017 at 5:50 AM, zengchen  wrote:
>>
>>> Very sorry to foget attaching the link for bp of rewriting Fuxi with go
>>> language.
>>> https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang
>>>
>>>
>>> At 2017-05-25 19:46:54, "zengchen"  wrote:
>>>
>>> Hi guys:
>>> hongbin had committed a bp of rewriting Fuxi with go language[1]. My
>>> question is where to commit codes for it.
>>> We have two choice, 1. create a new repository, 2. create a new branch.
>>> IMO, the first one is much better. Because
>>> there are many differences in the layer of infrastructure, such as CI.
>>> What's your opinion? Thanks very much
>>>
>>> Best Wishes
>>> zengchen
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> ​Hi Zengchen,
>>
>> For now I was thinking just use Github and PR's outside of the OpenStack
>> projects to bootstrap things and see how far we can get.  I'll update the
>> BP this morning with what I believe to be the key tasks to work through.
>>
>> Thanks,
>> John​
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ​I like the idea of the service version of brick, and then the golang
bindings.  There's a lot of good investment already in os-brick that it
would be great to leverage.  Walt and Ivan mentioned that they had a POC
for this a while back, might be worth considering taking the fork
referenced in the BP and submitting that upstream for the community?
 #openstack-cinder IRC channel would be a great place to sync up on these
aspects in real time if folks would like.

Thanks,
John​
__
OpenStack Development Mailing 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] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Zhenguo Niu]

On Thu, May 25, 2017 at 9:37 PM, Loo, Ruby  wrote:

> Hi Zhenguo,
>
>
>
> Thanks for bringing this up. Naming is hard :-(
>
>
>
> Maybe this is a dumb question but your phrase "We copied nova's server
> resource concept here, so users may easily to accept the 'baremetal
> server'" made me wonder. I'm not a user of Mogan so I don't know if this
> would work, but OSC already has
>
> openstack server  
>
> openstack flavor  
>
> openstack keypair  
>
>
>
> Why can't we use the existing OSC commands, and add an option eg '--bm' to
> indicate that the server is baremetal, not a VM?
>
>
>

Not sure if it's possible to achieve this by two different OSC plugins, and
as we use different options/parameters with nova when creating a baremetal
server, so I think it's hard to control by only a '--bm' option to
distinguish.
And compared with vm servers, baremetal servers have different
capabilities, it will make more confusing if you use 'openstack server
create' to create a baremetal instance, but you can't apply below commands
to it.

openstack server --bm pause/unpause
openstack server --bm shelve/unshelve
openstack server --bm migrate


> Of course, having asked this, how does the user know/distinguish between
> getting a baremetal instance via mogan or via nova... (and should the end
> user actually know that there is a difference...) But I suspect I am
> digressing.
>
>
>
As I understand, baremetal instance in nova is a 'specical virtual
machine'(raw performance). Users claim the instance by specifying a flavor
with 'vcpus', 'memory', "root_gb" instead of real hardware specs like (cpu
model/cores, hard drives type/amount, nics type/amount), then he get an
instance with properties like 'vm_state' and other 'virtual' stuff. As
baremetal in nova use the same model and same set of API that designed for
vms, so even for end users, it's not that easy to know which instance is a
baremetal server, so maybe it's good to call that baremetal server a
special vm instance.

So, yes the end user actually know that there is a difference between
getting a bremetal instance via mogan or via nova :)


> --ruby
>
>
>
> *From: *Zhenguo Niu 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Thursday, May 25, 2017 at 5:38 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same
> keyword 'baremetal'?
>
>
>
>
>
> On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur 
> wrote:
>
> On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
>
> hi all,
>
>
> Hi!
>
>
> I'm from the Mogan team, we chose the same keyward 'baremetal' when
> implementing a OSC plugin [1]. As we think the baremetal command is
> representative of a baremetal resource, not a service, so it makes sense
> for different projects to share the top level resource name that OpenStack
> can provide.
>
>
> We do not "own" the word "baremetal", so nothing prevents you from using
> it. However, in my experience:
> 1. This does confuse users, as they expect "openstack baremetal" to be a
> prefix belonging to Ironic.
> 2. Collisions may happen. We had two collisions with TripleO already, one
> resulted in us killing a TripleO command abruptly.
>
>
>
> Alternatively, I don't mind to change this to 'bm' or something like that
> for Mogan, but some operators told me that it will confuse users more to
> have both 'baremetal' and 'bm' in there CLI.
>
> And as I understand, ironic commands are not used frequently, and it's
> even less if ironic inspector can help to automatically enroll nodes/ports.
>
>
>
>
>
>
> The commands we have implemented are listed below, seems there's no
> collision with Ironic presently, and Ironic doesn't manage such resources.
>
> * openstack baremetal server  
> * openstack bareemtal flavor  
> * openstack baremetal keypair  
> * openstack baremetal availability zone  
>
>
> Ironic does not have any notion of either of these, so it should be fine.
>
> I'm still a bit on a -1 side because of potential users confusion. I
> wonder how can we send a message across that prefixes do not designate a
> specific project, but are rather just part of a "sentence". I'm
> specifically worried about confusing "baremetal server" of Mogan with
> "baremetal node" of Ironic. For many people these can be synonyms.
>
>
>
> We copied nova's server resource concept here, so users may easily to
> accept the 'baremetal server'. For 'baremetal node', seems only
> operators/administrators may use such commands, so seems the synonyms is
> not a big problem as they are for different roles.
>
>
>
>
> So, we'd like to ask if our CLI pattern is allowed before we release the
> client.
>
> Thanks in advance!
>
>
> [1] https://github.com/openstack/python-moganclient
>
> --
> Best Regards,
> Zhenguo Niu
>
>
> 

Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Zhenguo Niu]

On Thu, May 25, 2017 at 9:29 PM, Mark Goddard  wrote:

> On 25 May 2017 at 11:03, Dmitry Tantsur  wrote:
>
>> On 05/25/2017 11:38 AM, Zhenguo Niu wrote:
>>
>>>
>>> On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur >> > wrote:
>>>
>>> On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
>>>
>>> hi all,
>>>
>>>
>>> Hi!
>>>
>>>
>>> I'm from the Mogan team, we chose the same keyward 'baremetal'
>>> when
>>> implementing a OSC plugin [1]. As we think the baremetal command
>>> is
>>> representative of a baremetal resource, not a service, so it
>>> makes sense
>>> for different projects to share the top level resource name that
>>> OpenStack can provide.
>>>
>>>
>>> We do not "own" the word "baremetal", so nothing prevents you from
>>> using it.
>>> However, in my experience:
>>> 1. This does confuse users, as they expect "openstack baremetal" to
>>> be a
>>> prefix belonging to Ironic.
>>> 2. Collisions may happen. We had two collisions with TripleO
>>> already, one
>>> resulted in us killing a TripleO command abruptly.
>>>
>>>
>>> Alternatively, I don't mind to change this to 'bm' or something like
>>> that for Mogan, but some operators told me that it will confuse users more
>>> to have both 'baremetal' and 'bm' in there CLI.
>>> And as I understand, ironic commands are not used frequently, and it's
>>> even less if ironic inspector can help to automatically enroll nodes/ports.
>>>
>>
>> I don't share this understanding, depends on a situation. A user of a
>> purely baremetal cloud, or an installer like TripleO, may use the baremetal
>> commands all the time.
>>
>>
>>>
>>> The commands we have implemented are listed below, seems there's
>>> no
>>> collision with Ironic presently, and Ironic doesn't manage such
>>> resources.
>>>
>>> * openstack baremetal server  
>>> * openstack bareemtal flavor  
>>> * openstack baremetal keypair  
>>> * openstack baremetal availability zone  
>>>
>>>
>>> Ironic does not have any notion of either of these, so it should be
>>> fine.
>>>
>>
> When using the openstack CLI I'm often in a 'discovery' mode, particularly
> if I'm interacting with a service that I don't often interact with. I often
> use the tab autocomplete and fuzzy match features of OSC as I explore.
> Having command prefix match multiple services could be confusing,
> particularly if I have python-moganclient installed but no mogan service
> exists.
>
> If there were an additional command prefix for mogan as is used for ironic
> inspector (openstack baremetal introspection ...), this would at least
> group the mogan commands.
>
> * openstack baremetal foo server  
> * openstack baremetal foo flavor  
> * openstack baremetal foo keypair  
> * openstack baremetal foo availability zone  
>
>
In fact, at first we used an additional prefix for mogan (openstack
baremetal compute) like ironic inspector to group our commands, but then we
find there's no collision with the existing commands if we remove the
prefix and
only using 'baremetal'makes users type less. But seems we make this change
from the point of view of an OpenStack developer instead of the OSC users.

We can change to use 'openstack baremetal compute' if it makes less
confusing, It looks like a good alternative to me :)


>
>>> I'm still a bit on a -1 side because of potential users confusion. I
>>> wonder
>>> how can we send a message across that prefixes do not designate a
>>> specific
>>> project, but are rather just part of a "sentence". I'm specifically
>>> worried
>>> about confusing "baremetal server" of Mogan with "baremetal node" of
>>> Ironic.
>>> For many people these can be synonyms.
>>>
>>>
>>> We copied nova's server resource concept here, so users may easily to
>>> accept the 'baremetal server'. For 'baremetal node', seems only
>>> operators/administrators may use such commands, so seems the synonyms is
>>> not a big problem as they are for different roles.
>>>
>>
>> It's not obvious from a command name, though. They'll just get 403 when
>> trying to use them.
>>
>>
>>>
>>> So, we'd like to ask if our CLI pattern is allowed before we
>>> release the
>>> client.
>>>
>>> Thanks in advance!
>>>
>>>
>>> [1] https://github.com/openstack/python-moganclient
>>> 
>>>
>>> -- Best Regards,
>>> Zhenguo Niu
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> >> subscribe>
>>> 

Re: [openstack-dev] [QA] Proposed changes to the team meeting time

[zhu.fanglei]

+1, thanks!




zhufl












Original Mail



Sender:  ＜andrea.fritt...@gmail.com＞
To:  ＜openstack-dev@lists.openstack.org＞
Date: 2017/05/25 21:19
Subject: [openstack-dev] [QA] Proposed changes to the team meeting time






Hello team,

our current QA team meeting schedule alternates between 9:00 UTC and 17:00 UTC.
The 9:00 meetings is a bit towards the end of the day for out contributors in 
APAC, so I'm proposing to move the meeting to 8:00 UTC.


Please respond with +1 / -1 and/or comments, I will leave the poll open for 
about 10 days to make sure everyone interested gets a chance to comment.


Thank you


andrea__
OpenStack Development Mailing 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] uWSGI help for Congress

[Eric K]

On 5/22/17, 8:54 PM, "gordon chung"  wrote:

>
>
>On 22/05/17 05:48 PM, Eric K wrote:
>> If someone out there knows uWSGI and has a couple spare cycles to help
>> Congress project, we'd super appreciate it.
>>
>> The regular contributors to Congress don't have experience with uWSGI
>> and could definitely use some help getting started with this goal.
>> Thanks a ton!
>>
>
>it shouldn't be much different from mod_wsgi. you just need to create a
>uwsgi.ini file which points to the appropriate .wsgi file. here's
>sileht's patch in gnocchi from a while back:
>https://review.openstack.org/#/c/292077. apparently pbr provides wsgi
>file now (not sure what version though):
>https://github.com/gnocchixyz/gnocchi/commit/6377e25bdcca68be66fadf65aa16a
>6f174cfaa99

Thank you Gordon for the references. We have a wsgi app but have not made
it work with mod_wsgi or uwsgi yet.
So I think we still have some steps to go before we¹re at this step. Glad
to have a good reference for when we get there. Thanks!

Eric



__
OpenStack Development Mailing 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] [upgrades][skip-level][leapfrog] - RFC - Skipping releases when upgrading

[Carter, Kevin]

Hello Stackers,

As I'm sure many of you know there was a talk about doing "skip-level"[0]
upgrades at the OpenStack Summit which quite a few folks were interested
in. Today many of the interested parties got together and talked about
doing more of this in a formalized capacity. Essentially we're looking for
cloud upgrades with the possibility of skipping releases, ideally enabling
an N+3 upgrade. In our opinion it would go a very long way to solving cloud
consumer and deployer problems it folks didn't have to deal with an upgrade
every six months. While we talked about various issues and some of the
current approaches being kicked around we wanted to field our general chat
to the rest of the community and request input from folks that may have
already fought such a beast. If you've taken on an adventure like this how
did you approach it? Did it work? Any known issues, gotchas, or things
folks should be generally aware of?


During our chat today we generally landed on an in-place upgrade with known
API service downtime and little (at least as little as possible) data plane
downtime. The process discussed was basically:
a1. Create utility "thing-a-me" (container, venv, etc) which contains the
required code to run a service through all of the required upgrades.
a2. Stop service(s).
a3. Run migration(s)/upgrade(s) for all releases using the utility
"thing-a-me".
a4. Repeat for all services.

b1. Once all required migrations are complete run a deployment using the
target release.
b2. Ensure all services are restarted.
b3. Ensure cloud is functional.
b4. profit!

Obviously, there's a lot of hand waving here but such a process is being
developed by the OpenStack-Ansible project[1]. Currently, the OSA tooling
will allow deployers to upgrade from Juno/Kilo to Newton using Ubuntu
14.04. While this has worked in the lab, it's early in development (YMMV).
Also, the tooling is not very general purpose or portable outside of OSA
but it could serve as a guide or just a general talking point. Are there
other tools out there that solve for the multi-release upgrade? Are there
any folks that might want to share their expertise? Maybe a process outline
that worked? Best practices? Do folks believe tools are the right way to
solve this or would comprehensive upgrade documentation be better for the
general community?

As most of the upgrade issues center around database migrations, we
discussed some of the potential pitfalls at length. One approach was to
roll-up all DB migrations into a single repository and run all upgrades for
a given project in one step. Another was to simply have mutliple python
virtual environments and just run in-line migrations from a version
specific venv (this is what the OSA tooling does). Does one way work better
than the other? Any thoughts on how this could be better? Would having
N+2/3 migrations addressable within the projects, even if they're not
tested any longer, be helpful?

It was our general thought that folks would be interested in having the
ability to skip releases so we'd like to hear from the community to
validate our thinking. Additionally, we'd like to get more minds together
and see if folks are wanting to work on such an initiative, even if this
turns into nothing more than a co-op/channel where we can "phone a friend".
Would it be good to try and secure some PTG space to work on this? Should
we try and create working group going?

If you've made it this far, please forgive my stream of consciousness. I'm
trying to ask a lot of questions and distill long form conversation(s) into
as little text as possible all without writing a novel. With that said, I
hope this finds you well, I look forward to hearing from (and working with)
you soon.

[0] https://etherpad.openstack.org/p/BOS-forum-skip-level-upgrading
[1] https://github.com/openstack/openstack-ansible-ops/tree/
master/leap-upgrades


--

Kevin Carter
IRC: Cloudnull
__
OpenStack Development Mailing 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] uWSGI help for Congress

[Eric K]

On 5/23/17, 5:37 AM, "Chris Dent"  wrote:

>On Mon, 22 May 2017, Eric K wrote:
>
>> If someone out there knows uWSGI and has a couple spare cycles to help
>> Congress project, we'd super appreciate it.
>>
>> The regular contributors to Congress don't have experience with uWSGI
>>and
>> could definitely use some help getting started with this goal. Thanks a
>>ton!
>
>Is the issue that you need get WSGI working at all (that is, need to
>create a WSGI app for running the api service), or existing WSGI
>tooling, made to work with mod_wsgi, needs to be adapted to work
>with uwsgi?
>In either case, if you're able to point me at existing
>api service code I might be able to provide some pointers.
>
>In the meantime some potentially useful links:
>
>* some notes I took on switching nova and devstack over to uwsg:
>
> https://etherpad.openstack.org/p/devstack-uwsgi
>
>* devstack code for nova+uwsgi
>
> https://review.openstack.org/#/c/457715/
>
>* rewrite of nova's wsgi application to start up properly
>
> https://review.openstack.org/#/c/457283/
>
>This last one might be most useful as it looks like congress is
>using an api startup model (for the non-WSGI case) similar to
>nova's.

Thanks a lot for the references Chris! I¹m very new to this matter so
please excuse my ignorance.
We have a WSGI app but have not made it deployable with either mod_wsgi or
uwsgi, only directly running with paste http server.

Here is the app (wrapper):
https://github.com/openstack/congress/blob/master/congress/api/application.
py#L34

Here¹s the app factory that makes it work with paste:
https://github.com/openstack/congress/blob/master/congress/service.py#L43

Here¹s the routing logic (not relevant I think):
https://github.com/openstack/congress/blob/master/congress/api/webservice.p
y

There is also a wsgi.py file but it appears to be used only for Keystone
context:
https://github.com/openstack/congress/blob/master/congress/common/wsgi.py

As far as I can figure out, the first step is to adapt the existing wsgi
app so it works right with uwsgi. It looks like what we are missing is the
equivalent of this file:
https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi_app.p
y (basically your third link)

Is that right?

I¹ve read the following as well as several wsgi related patches but still
feel quite ungrounded. Any other suggested reading?

http://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html
http://docs.webob.org/en/stable/do-it-yourself.html
http://docs.webob.org/en/stable/api/dec.html

Thanks a ton!

Eric



__
OpenStack Development Mailing 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] [QA] Proposed changes to the team meeting time

[Ghanshyam Mann]

+1

-gmann


On Thu, May 25, 2017 at 10:03 PM, Andrea Frittoli
 wrote:
> Hello team,
>
> our current QA team meeting schedule alternates between 9:00 UTC and 17:00
> UTC.
> The 9:00 meetings is a bit towards the end of the day for out contributors
> in APAC, so I'm proposing to move the meeting to 8:00 UTC.
>
> Please respond with +1 / -1 and/or comments, I will leave the poll open for
> about 10 days to make sure everyone interested gets a chance to comment.
>
> Thank you
>
> andrea
>
> __
> OpenStack Development Mailing 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] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[joehuang]

I think a option 2 is better.

Best Regards
Chaoyi Huang (joehuang)

From: Lance Bragstad [lbrags...@gmail.com]
Sent: 25 May 2017 3:47
To: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [openstack-dev] 
[keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

I'd like to fill in a little more context here. I see three options with the 
current two proposals.

Option 1

Use a special admin project to denote elevated privileges. For those unfamiliar 
with the approach, it would rely on every deployment having an "admin" project 
defined in configuration [0].

How it works:

Role assignments on this project represent global scope which is denoted by a 
boolean attribute in the token response. A user with an 'admin' role assignment 
on this project is equivalent to the global or cloud administrator. Ideally, if 
a user has a 'reader' role assignment on the admin project, they could have 
access to list everything within the deployment, pending all the proper changes 
are made across the various services. The workflow requires a special project 
for any sort of elevated privilege.

Pros:
- Almost all the work is done to make keystone understand the admin project, 
there are already several patches in review to other projects to consume this
- Operators can create roles and assign them to the admin_project as needed 
after the upgrade to give proper global scope to their users

Cons:
- All global assignments are linked back to a single project
- Describing the flow is confusing because in order to give someone global 
access you have to give them a role assignment on a very specific project, 
which seems like an anti-pattern
- We currently don't allow some things to exist in the global sense (i.e. I 
can't launch instances without tenancy), the admin project could own resources
- What happens if the admin project disappears?
- Tooling or scripts will be written around the admin project, instead of 
treating all projects equally

Option 2

Implement global role assignments in keystone.

How it works:

Role assignments in keystone can be scoped to global context. Users can then 
ask for a globally scoped token

Pros:
- This approach represents a more accurate long term vision for role 
assignments (at least how we understand it today)
- Operators can create global roles and assign them as needed after the upgrade 
to give proper global scope to their users
- It's easier to explain global scope using global role assignments instead of 
a special project
- token.is_global = True and token.role = 'reader' is easier to understand than 
token.is_admin_project = True and token.role = 'reader'
- A global token can't be associated to a project, making it harder for 
operations that require a project to consume a global token (i.e. I shouldn't 
be able to launch an instance with a globally scoped token)

Cons:
- We need to start from scratch implementing global scope in keystone, steps 
for this are detailed in the spec

Option 3

We do option one and then follow it up with option two.

How it works:

We implement option one and continue solving the admin-ness issues in Pike by 
helping projects consume and enforce it. We then target the implementation of 
global roles for Queens.

Pros:
- If we make the interface in oslo.context for global roles consistent, then 
consuming projects shouldn't know the difference between using the 
admin_project or a global role assignment

Cons:
- It's more work and we're already strapped for resources
- We've told operators that the admin_project is a thing but after Queens they 
will be able to do real global role assignments, so they should now migrate 
*again*
- We have to support two paths for solving the same problem in keystone, more 
maintenance and more testing to ensure they both behave exactly the same way
  - This can get more complicated for projects dedicated to testing policy and 
RBAC, like Patrole


Looking for feedback here as to which one is preferred given timing and payoff, 
specifically from operators who would be doing the migrations to implement and 
maintain proper scope in their deployments.

Thanks for reading!


[0] 
https://github.com/openstack/keystone/blob/3d033df1c0fdc6cc9d2b02a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342

On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad 
> wrote:
Hey all,

To date we have two proposed solutions for tackling the admin-ness issue we 
have across the services. One builds on the existing scope concepts by scoping 
to an admin project [0]. The other introduces global role assignments [1] as a 
way to denote elevated privileges.

I'd like to get some feedback from operators, as well as developers from other 
projects, on each approach. Since work is required in keystone, it would be 
good to get consensus before spec freeze (June 9th). If you have 

Re: [openstack-dev] [glance] nominating Mike Fedosin for glance core

[Nikhil Komawar]

This is great news. Always +2 for Mike, he's been great (dev, glancer,
stacker ..) all the years.  Let's not wait so long for reinstatement if
folks are on-board, as having another core will only help.

On Thu, May 25, 2017 at 11:53 AM, Brian Rosmaita  wrote:

> As you've no doubt read elsewhere on the ML, we've lost several glance
> cores recently due to employment changes.  Luckily, Mike Fedosin
> informed me at today's Glance weekly meeting that he will have time
> for the next few months to devote some time to Glance reviewing.
>
> For those who don't know Mike (mfedosin on IRC), he was a Glance core
> for several years.  He provided a lot of notes that were used to write
> the Glance architecture documentation that is so helpful to new
> contributors, so he's extremely knowledgeable about the design
> patterns used in Glance.
>
> Most recently, Mike's been working on the Glare project, which has a
> lot in common with Glance.  While Mike says he can't commit much time
> to Glance development, he has proposed porting some of the Glare tests
> over to Glance, which will certainly help with our code coverage, and
> would be a helpful addition to Glance.
>
> (Mike agreed at today's Glance meeting not to propose re-integrating
> Glare into the Glance project until the Queens PTG (if at all), so I'm
> not worried about that being a distraction during the Pike cycle when
> we are so short-handed.)
>
> I'd like to reinstate Mike as a Glance core contributor at the next
> Glance weekly meeting.  Please reply to this message with any comments
> or concerns before 23:59 UTC on Wednesday 31 May 2017.
>
> 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
>



-- 
--
Thanks,
Nikhil
__
OpenStack Development Mailing 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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

[Zhipeng Huang]

Hi John and Zeng,

The OpenSDS community already developed a golang client for the
os-brick[1], I think we could host the new golang os-brick code there as a
new repo and after things settled port the code back to OpenStack

[1]
https://github.com/opensds/opensds/blob/master/pkg/dock/plugins/connector/connector.go


On Thu, May 25, 2017 at 10:47 PM, John Griffith 
wrote:

>
>
> On Thu, May 25, 2017 at 5:50 AM, zengchen  wrote:
>
>> Very sorry to foget attaching the link for bp of rewriting Fuxi with go
>> language.
>> https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang
>>
>>
>> At 2017-05-25 19:46:54, "zengchen"  wrote:
>>
>> Hi guys:
>> hongbin had committed a bp of rewriting Fuxi with go language[1]. My
>> question is where to commit codes for it.
>> We have two choice, 1. create a new repository, 2. create a new branch.
>> IMO, the first one is much better. Because
>> there are many differences in the layer of infrastructure, such as CI.
>> What's your opinion? Thanks very much
>>
>> Best Wishes
>> zengchen
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ​Hi Zengchen,
>
> For now I was thinking just use Github and PR's outside of the OpenStack
> projects to bootstrap things and see how far we can get.  I'll update the
> BP this morning with what I believe to be the key tasks to work through.
>
> Thanks,
> John​
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

[Nikhil Komawar]

Kendall, Thanks for that pointer and to those who sent emails. I guess the
pre-summit time was a bit weird this time around (for many cores/liaisons)
and may be the next round we will see someone from Glance participate.

Unfortunately, I can't be a Glance liaison at the moment. I hope someone
will be more willing to step up.

Thanks again for making this effort easier for the entire community.

Cheers

On Wed, May 24, 2017 at 6:20 PM, Kendall Nelson 
wrote:

> @Nikhil, we (the organizers of Upstream Institute) sent a few emails
> [1][2] out to the dev mailing list asking for help and representatives from
> various projects to attend and get involved. We are also working on
> building a network of project liaisons to direct newcomers to in each
> project. Would you be interested in being our Glance liaison?
>
> Let me know if you have any other Upstream Institute questions!
>
> - Kendall(diablo_rojo)
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> January/110788.html
> [2]  http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/108084.html
>
> On Wed, May 24, 2017 at 4:03 PM Nikhil Komawar 
> wrote:
>
>> Project:  Glance
>>
>> Attendees: ~15
>>
>> What was done:
>>
>> We started by introducing the core team (or whatever existed then), did a
>> run down of Glance API documentation especially for developers, other
>> references like notes for ops, best practices. We went through the
>> architecture of the project. A few were interested in knowing more details
>> and going in depth so we discussed the design patterns that exist today,
>> scope of improvements and any blackholes therein, auxiliary services and
>> performance tradeoffs etc. A lot of the discussion was free form so people
>> asked questions and session was interactive.
>>
>>
>> What worked:
>>
>> 1. The projector worked!
>>
>> 2. Session was free form, there was good turnout and it was interactive.
>> (all the good things)
>>
>> 3. People were serious about contributing as per their
>> availability/capacity to do upstream and one person showed up asking to do
>> reviews.
>>
>>
>> Lessons:
>>
>> 1. Could have been advertised more at least the session description more
>> customized.
>>
>> 2. A representative from the team could have been officially invited to
>> the upstream institute training.
>>
>> 3. The community building sessions and on-boarding sessions seem to
>> overlap a bit so a representative from the team could be help in those
>> sessions for Q or more interaction. Probably more collaboration/prep
>> before the summit for such things. ($0.02)
>>
>>
>> Cheers
>>
>> On Wed, May 24, 2017 at 1:27 PM, Jay S Bryant 
>> wrote:
>>
>>> Project:  Cinder
>>>
>>> Attendees: Approximately 30
>>>
>>> I was really pleased by the number of people that attended the Cinder
>>> session and the fact that they people in the room seemed engaged with the
>>> presentation and asked good questions showing interest in the project.  I
>>> think having the on-boardings rooms was beneficial and hopefully something
>>> that we can continue.
>>>
>>> Given the number of people in the room we didn't go around and introduce
>>> everyone.  I did have the Sean McGinnis introduce himself as PTL and had
>>> the other Cinder Core members introduce themselves so that the attendees
>>> could put faces with our names.
>>>
>>> From there we kicked off the presentation [1] which covered the
>>> following high level topics:
>>>
>>>- Introduction of Cinder's Repos and components
>>>- Quick overview of Cinder's architecture/organization
>>>- Pointers to the Upstream Institute education (Might have done a
>>>bit of a sales pitch for the next session here ;-))
>>>- Expanded upon the Upstream Institute education to explain how what
>>>was taught there specifically applied to Cinder
>>>- Walked through the main Cinder code tree
>>>- Described how to test changes to Cinder
>>>
>>> My presentation was designed to assume that attendees had been through
>>> Upstream Institute.  I had coverage in the slides in case they had not been
>>> through the education.  Unfortunately most of the class had not been
>>> through the education so I did spend a portion of time re-iterating those
>>> concepts and less time was able to be spent at the end going through real
>>> world examples of working with changes in Cinder.  I got feedback from a
>>> few people that having some real hands on coding examples would have been
>>> helpful.
>>>
>>> One way we could possible handle this is to split the on-boarding to a
>>> introduction section and then a more advanced second session.  The other
>>> option is that we require people who are attending the on-boarding to have
>>> been through Upstream Institute.  Something to think about.
>>>
>>> I think it was unfortunate that the session wasn't recorded.  We shared
>>> a lot of good information (between good questions and having a 

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

[Matt Riedemann]

On 5/23/2017 10:23 AM, Zane Bitter wrote:
Yes! Everything is much easier if you tell all the users to re-architect 
their applications from scratch :) Which, I mean, if you can... great! 
Meanwhile here on planet Earth, it's 2017 and 95% of payment card 
transactions are still processed using COBOL at some point. (Studies 
show that 79% of statistics are made up, but I actually legit read this 
last week.)


That's one reason I don't buy any of the 'OpenStack is dead' commentary. 
If we respond appropriately to the needs of users who run a *mixture* of 
legacy, cloud-aware, and cloud-native applications then OpenStack will 
be relevant for a very long time indeed.


I enjoyed this, thank you.

--

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] Is the pendulum swinging on PaaS layers?

[Matt Riedemann]

On 5/22/2017 11:01 AM, Zane Bitter wrote:
If the user does a stack update that changes the network from 'auto' to 
'none', or vice-versa.


OK I guess we should make this a side discussion at some point, or hit 
me up in IRC, but if you're requesting networks='none' with microversion 
>= 2.37 then nova should not allocate any networking, it should not 
event attempt to do so.


Maybe the issue is the server is created with networks='auto' and has a 
port, and then when you 'update the stack' it doesn't delete that server 
and create a new one, but it tries to do something with the same server, 
and in this case you'd have to detach the port(s) that were previously 
created?


I don't know how Heat works, but if that's the case, then yeah that 
doesn't sound fun, but I think Nova provides the APIs to be able to do this.


--

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] [release] Issues with reno

[Matt Riedemann]

On 5/24/2017 2:46 PM, Doug Hellmann wrote:

Please take a look at
the results and let me know if that's doing what you all expect.


Tested this out locally and it fixes my issue. Thanks Doug!

--

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] [glance] spec to fix a security issue

[Brian Rosmaita]

Hello Glancers,

As discussed in today's meeting, I've put up a spec to address
OSSN-0075, which is an issue I'd really like to see fixed (or at least
better mitigated) in Pike.  Please take a look at the patch and leave
some comments:

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

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] [congress] policy library tasks

[Eric K]

Hi all!

I have organized the tasks for policy library here:
https://bugs.launchpad.net/congress/+bugs?field.tag=policy-lib
Please take a look and feel free to pick up, comment, modify, etc.

The four non-GUI high importance items are essential for rolling out this
feature.
The high importance GUI item
(https://bugs.launchpad.net/congress/+bug/1670535) would be really great
to have for usability and demo-ability.

The medium importance items relate to supporting policy library CRUD and
are desirable but not essential.

Cheers!

Eric



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

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

[Chris Friesen]

On 05/20/2017 10:36 AM, Monty Taylor wrote:

On 05/19/2017 03:13 PM, Monty Taylor wrote:

On 05/19/2017 01:53 PM, Sean Dague wrote:

On 05/19/2017 02:34 PM, Dean Troyer wrote:

On Fri, May 19, 2017 at 1:04 PM, Sean Dague  wrote:

These should be used as ways to experiment with the kinds of interfaces
we want cheaply, then take them back into services (which is a more
expensive process involving compatibility stories, deeper
documentation,
performance implications, and the like), not an end game on their own.


I totally agree here.  But I also see the rate of progress for many
and varied reasons, and want to make users lives easier now.

Have any of the lessons already learned from Shade or OSC made it into
services yet?  I think a few may have, "get me a network" being the
obvious one.  But that still took a lot of work (granted that one _is_
complicated).


Doing hard things is hard. I don't expect changing APIs to be easy at
this level of deployedness of OpenStack.


You can get the behavior. It also has other behaviors. I'm not sure any
user has actually argued for "please make me do more rest calls to
create a server".


Maybe not in those words, but "give me the tools to do what I need"
has been heard often.  Sometimes those tools are composable
primitives, sometimes they are helpful opinionated interfaces.  I've
already done the helpful opinionated stuff in OSC here (accept flavor
and image names when the non-unique names _do_ identify a single
result).  Having that control lets me give the user more options in
handling edge cases.


Sure, it does. The fact that it makes 3 API calls every time when doing
flavors by name (404 on the name, list all flavors, local search, get
the flavor by real id) on mostly read only data (without any caching) is
the kind of problem that rises from "just fix it in an upper layer". So
it does provide an experience at a cost.


We also searching of all resources by name-or-id in shade. But it's one
call - GET /images - and then we test to see if the given value matches
the name field or the id field. And there is caching, so the list call
is done once in the session.

The thing I'm the saddest about is the Nova flavor "extra_info" that one
needs to grab for backwards compat but almost never has anything useful
in it. This causes me to make a billion API calls for the initial flavor
list (which is then cached of course) It would be WAY nicer if there was
a GET /flavors/detail that would just get me the whole lot in one go, fwiw.


Quick follow up on this one.

It was "extra_specs" I was thinking about - not "extra_info"

It used to be in the flavor as part of an extension (with a longer name) - we
fetch them in shade for backwards compat with the past when they were just
there. However, I've also learned from a follow up in IRC that these aren't
really things that were intended for me.


For what it's worth, there are cases where extra_specs are important to normal 
users because they constrain what image properties you are allowed to set.


Things like cpu_policy, cpu_thread_policy, memory page size, number of NUMA 
nodes, etc. can all be set in both places, and they behave differently if there 
is a mismatch between the flavor extra_spec and the image property.


Because of this I think it makes sense for a normal person to be able to look at 
flavor extra_specs so that they can create an image with suitable properties to 
be able to boot up an instance with that image on that flavor.


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] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

On Thu, May 25, 2017 at 2:36 PM, Marc Heckmann 
wrote:

> First of all @Lance, thanks for taking the time to write and summarize
> this for us. It's much appreciated.
>

Absolutely! it helps me think about it, too.


>
> While I'm not aware of all the nuances, based on my own testing, I feel
> that we are really close with option 1.
>
> That being said, as you already stated, option 2 is clearly more inline
> with the idea of having a "global" Cloud Admin role. So long term, #2 is
> more desirable.
>
> Given the two sentences above, I certainly would prefer option 3 so that
> we can have a usable solution quickly. I certainly will continue to test
> and provide feedback for the option 1 part.
>
>
It sounds like eventually migrating everything from the is_admin_project to
true global roles is a migration you're willing to make. This might be a
loaded question and it will vary across deployments, but how long would you
expect that migration to take for you're specific deployment(s)?


-m
>
>
>
>
> On Thu, 2017-05-25 at 10:42 +1200, Adrian Turjak wrote:
>
>
>
> On 25/05/17 07:47, Lance Bragstad wrote:
> 
>
> *Option 2*
>
> Implement global role assignments in keystone.
>
> *How it works:*
>
> Role assignments in keystone can be scoped to global context. Users can
> then ask for a globally scoped token
>
> Pros:
> - This approach represents a more accurate long term vision for role
> assignments (at least how we understand it today)
> - Operators can create global roles and assign them as needed after the
> upgrade to give proper global scope to their users
> - It's easier to explain global scope using global role assignments
> instead of a special project
> - token.is_global = True and token.role = 'reader' is easier to understand
> than token.is_admin_project = True and token.role = 'reader'
> - A global token can't be associated to a project, making it harder for
> operations that require a project to consume a global token (i.e. I
> shouldn't be able to launch an instance with a globally scoped token)
>
> Cons:
> - We need to start from scratch implementing global scope in keystone,
> steps for this are detailed in the spec
>
> 
>
>
> On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad 
> wrote:
>
> Hey all,
>
> To date we have two proposed solutions for tackling the admin-ness issue
> we have across the services. One builds on the existing scope concepts by
> scoping to an admin project [0]. The other introduces global role
> assignments [1] as a way to denote elevated privileges.
>
> I'd like to get some feedback from operators, as well as developers from
> other projects, on each approach. Since work is required in keystone, it
> would be good to get consensus before spec freeze (June 9th). If you have
> specific questions on either approach, feel free to ping me or drop by the
> weekly policy meeting [2].
>
> Thanks!
>
>
> Please option 2. The concept of being an "admin" while you are only scoped
> to a project is stupid when that admin role gives you super user power yet
> you only have it when scoped to just that project. That concept never
> really made sense. Global scope makes so much more sense when that is the
> power the role gives.
>
> At same time, it kind of would be nice to make scope actually matter. As
> admin you have a role on Project X, yet you can now (while scoped to this
> project) pretty much do anything anywhere! I think global roles is a great
> step in the right direction, but beyond and after that we need to seriously
> start looking at making scope itself matter, so that giving someone 'admin'
> or some such on a project actually only gives them something akin to
> project_admin or some sort of admin-lite powers scoped to that project and
> sub-projects. That though falls into the policy work being done, but should
> be noted, as it is related.
>
> Still, at least global scope for roles make the superuser case make some
> actual sense, because (and I can't speak for other deployers), we have one
> project pretty much dedicated as an "admin_project" and it's just odd to
> actually need to give our service users roles in a project when that
> project is empty and a pointless construct for their purpose.
>
> Also thanks for pushing this! I've been watching your global roles spec
> review in hopes we'd go down that path. :)
>
> -Adrian
>
> ___
> OpenStack-operators mailing 
> listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] ptgbot: how to make "what's currently happening" emerge

[Telles Nobrega]

Great idea, +1

On Mon, May 22, 2017 at 10:19 AM Thierry Carrez 
wrote:

> Thierry Carrez wrote:
> > [...]
> > I have POC code for this bot already. Before I publish it (and start
> > work to make infra support it), I just wanted to see if this is the
> > right direction and if I should continue to work on it :) I feel like
> > it's an incremental improvement that preserves the flexibility and
> > self-scheduling while addressing the main visibility concern. If you
> > have better ideas, please let me know !
>
> Thanks for the feedback ! Since the idea seems to have some support, I
> updated and published the code at:
>
> https://github.com/ttx/ptgbot
>
> It's still pretty basic -- in particular it's missing all the code to
> make it extract information from cells in ethercalc and seamlessly merge
> that onto the rendered page. It also is pretty permissive about what is
> a "room" and who can issue orders to it.
>
> I'll work to push it in an OpenStack hosted repository, and then to be
> autodeployed on OpenStack infrastructure.
>
> --
> 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
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
OpenStack Development Mailing 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] [requirements][tripleo][heat] Projects holding back requirements updates

[Ben Nemec]

Tagging with tripleo and heat teams for the os-*-config projects.  I'm 
not sure which owns them now, but it sounds like we need a new release.


On 05/22/2017 10:32 AM, Matthew Thode wrote:

This is just a friendly reminder that without a release from master, if
your project still caps a requirement then it may be either holding back
a package or not be included in upper-constraints updates.

http://logs.openstack.org/76/466476/5/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/d71b8f6/console.html#_2017-05-22_09_38_53_142301

http://logs.openstack.org/76/466476/4/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/27cb570/console.html#_2017-05-21_09_00_14_624413

The following packages are taken from those lists and holding back
requirements updates.

Holding back updates from upstream to be consumed by other openstack
projects:

mistral - holding back sqlalchemy (no release that uncaps sqlalchemy)
django-openstack-auth - holding back django

Being held back from being updated and being consumed, all these is
because they don't have a release that uncaps pbr.

mistral
os-apply-config
os-collect-config
os-refresh-config
os-vif

If these projects could make a release (something fetchable by pypi) off
of master that's all that's needed.  They all have updated their
requirements in master, just no consumable release.



__
OpenStack Development Mailing 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] Onboarding rooms postmortem, what did you do, what worked, lessons learned

[Kendall Nelson]

Thanks Amrith! I added you to our wiki[1] feel free to make changes if any
of the info is incorrect.

-Kendall(diablo_rojo)

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

On Thu, May 25, 2017 at 7:41 AM Amrith Kumar  wrote:

> Kendall,
>
> I would like to be the Trove liaison, and would like to participate in
> Upstream University next time around.
>
> With that said, the answers to Sean's original question.
>
> I ran the room for the Trove team, I think it was a welcome addition.
>
> What went well: I think it was a good opportunity for the project to get
> new contributors (update: if you are interested in contributing to an
> openstack project, trove is looking for new participants).
>
> It would have been nice to have them video taped.
>
> -amrith
>
>
> -amrith
>
> --
> Amrith Kumar
> Phone: +1-978-563-9590 <(978)%20563-9590>
>
>
> On Wed, May 24, 2017 at 6:20 PM, Kendall Nelson 
> wrote:
>
>> @Nikhil, we (the organizers of Upstream Institute) sent a few emails
>> [1][2] out to the dev mailing list asking for help and representatives from
>> various projects to attend and get involved. We are also working on
>> building a network of project liaisons to direct newcomers to in each
>> project. Would you be interested in being our Glance liaison?
>>
>> Let me know if you have any other Upstream Institute questions!
>>
>> - Kendall(diablo_rojo)
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-January/110788.html
>> [2]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-November/108084.html
>>
>> On Wed, May 24, 2017 at 4:03 PM Nikhil Komawar 
>> wrote:
>>
>>> Project:  Glance
>>>
>>> Attendees: ~15
>>>
>>> What was done:
>>>
>>> We started by introducing the core team (or whatever existed then), did
>>> a run down of Glance API documentation especially for developers, other
>>> references like notes for ops, best practices. We went through the
>>> architecture of the project. A few were interested in knowing more details
>>> and going in depth so we discussed the design patterns that exist today,
>>> scope of improvements and any blackholes therein, auxiliary services and
>>> performance tradeoffs etc. A lot of the discussion was free form so people
>>> asked questions and session was interactive.
>>>
>>>
>>> What worked:
>>>
>>> 1. The projector worked!
>>>
>>> 2. Session was free form, there was good turnout and it was interactive.
>>> (all the good things)
>>>
>>> 3. People were serious about contributing as per their
>>> availability/capacity to do upstream and one person showed up asking to do
>>> reviews.
>>>
>>>
>>> Lessons:
>>>
>>> 1. Could have been advertised more at least the session description more
>>> customized.
>>>
>>> 2. A representative from the team could have been officially invited to
>>> the upstream institute training.
>>>
>>> 3. The community building sessions and on-boarding sessions seem to
>>> overlap a bit so a representative from the team could be help in those
>>> sessions for Q or more interaction. Probably more collaboration/prep
>>> before the summit for such things. ($0.02)
>>>
>>>
>>> Cheers
>>>
>>> On Wed, May 24, 2017 at 1:27 PM, Jay S Bryant 
>>> wrote:
>>>
 Project:  Cinder

 Attendees: Approximately 30

 I was really pleased by the number of people that attended the Cinder
 session and the fact that they people in the room seemed engaged with the
 presentation and asked good questions showing interest in the project.  I
 think having the on-boardings rooms was beneficial and hopefully something
 that we can continue.

 Given the number of people in the room we didn't go around and
 introduce everyone.  I did have the Sean McGinnis introduce himself as PTL
 and had the other Cinder Core members introduce themselves so that the
 attendees could put faces with our names.

 From there we kicked off the presentation [1] which covered the
 following high level topics:

- Introduction of Cinder's Repos and components
- Quick overview of Cinder's architecture/organization
- Pointers to the Upstream Institute education (Might have done a
bit of a sales pitch for the next session here ;-))
- Expanded upon the Upstream Institute education to explain how
what was taught there specifically applied to Cinder
- Walked through the main Cinder code tree
- Described how to test changes to Cinder

 My presentation was designed to assume that attendees had been through
 Upstream Institute.  I had coverage in the slides in case they had not been
 through the education.  Unfortunately most of the class had not been
 through the education so I did spend a portion of time re-iterating those
 concepts and less time was able to be spent at the end going through real
 world examples of working 

[openstack-dev] [mistral][freezer] adopting oslo.context for logging debugging and tracing

[Doug Hellmann]

The new work to add the exception information and request ID tracing
depends on using both oslo.context and oslo.log to have all of the
relevant pieces of information available as log messages are emitted.

In the course of reviewing the "done" status for those initiatives,
I noticed that although mistral and freezer are using oslo.log,
neither uses oslo.context. That means neither project will get the
extra debugging information, and neither project will see the global
request ID in logs.

I started looking at updating mistral's context to use oslo.context
as a base class, but ran into some issues because of some extensions
made to the existing class. I wasn't able to find where freezer is
doing anything at all with an API request context.

I'm available to help, if someone else wants to pick up the work.

Doug

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

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

[michael mccune]

Greetings OpenStack community,

Today was a relatively short meeting with most the time being devoted to 
a discussion of Monty Taylor's document chain regarding using the 
service catalog for version discovery[4]. The group was largely in 
agreement that work is proceeding well and with a few more minor tweaks 
should be ready for freeze.


We also discussed a plan[5] to create a new mailing list targetted at 
users, developers, and operators who consume the OpenStack APIs and have 
a higher degree of interest in helping to shape them from an SDK 
perspective. This was welcomed as a "good thing"(TM), and everyone seemd 
to agree that having a space for people to discuss SDK and API related 
issues specifically is a nice step forward.


Finally, we had a small side-track discussing Sean Dague's progress[6] 
on the global request ID implementation efforts. This seems like great 
work that will help improve the state of tracking and monitoring within 
OpenStack.


# Newly Published Guidelines

Nothing new at this time.

# API Guidelines Proposed for Freeze

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

None at this time but please check out the reviews below.

# Guidelines Currently Under Review [3]

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

* A suite of several documents about using the service catalog and doing 
version discovery

  Start at https://review.openstack.org/#/c/462814/

* 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

[4] Start at https://review.openstack.org/#/c/462814/
[5] https://review.openstack.org/#/c/468046/
[6] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117367.html


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

Re: [openstack-dev] [nova][vlan trunking] Guest networking configuration for vlan trunk

[Robert Li (baoli)]

I created a nova bug for this: https://bugs.launchpad.net/nova/+bug/1693535. I 
am currently working on a code patch for it.

--Robert

On 5/24/17, 3:52 PM, "Robert Li (baoli)" 
> wrote:

Thanks for the pointer. I think your suggestion in comments #14 
https://bugs.launchpad.net/neutron/+bug/1631371/comments/14 makes sense. I 
actually meant to address the nova side so that trunk details can be exposed in 
the metadata and configdrive.

-Robert



On 5/24/17, 1:52 PM, "Armando M." > 
wrote:



On 24 May 2017 at 08:53, Robert Li (baoli) 
> wrote:
Hi Kevin,

In that case, I will start working on it. Should this be considered a RFE or a 
regular bug?

There have been discussions in the past about this [1]. The conclusion of the 
discussion was: Nova should have everything it needs to expose trunk details to 
guest via the metadata API/config drive and at this stage nothing is required 
from the neutron end (and hence there's no point in filing a Neutron RFE).

While notifying trunk changes to nova require a simple minor enhancement in 
neutron, it seems premature to go down that path when there's no nova 
scaffolding yet. Someone should then figure out how the guest itself gets 
notified of trunk changes so that it can rearrange its networking stack. That 
might as well be left to some special sauce added to the guest image, though no 
meaningful discussion has taken place on how to crack this particular nut.

HTH
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1631371



Thanks,
Robert

On 5/23/17, 12:12 AM, "Kevin Benton" 
> wrote:

I think we just need someone to volunteer to do the work to expose it as 
metadata to the VM in Nova.

On May 22, 2017 1:27 PM, "Robert Li (baoli)" 
> wrote:
Hi Levi,

Thanks for the info. I noticed that support in the nova code, but was wondering 
why something similar is not available for vlan trunking.

--Robert


On 5/22/17, 3:34 PM, "Moshe Levi" 
> wrote:

Hi Robert,
The closes thing that I know about is tagging of SR-IOV physical function’s 
VLAN tag to guests see [1]
Maybe you can leverage the same mechanism to config vlan trunking in guest.

[1] - 
https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/sriov-pf-passthrough-neutron-port-vlan.html


From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, May 22, 2017 8:49 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova][vlan trunking] Guest networking configuration 
for vlan trunk

Hi,

I’m trying to find out if there is support in nova (in terms of metadata and 
cfgdrive) to configure vlan trunking in the guest. In the ‘CLI usage example’ 
provided in this wiki https://wiki.openstack.org/wiki/Neutron/TrunkPort, it 
indicates:

# The typical cloud image will auto-configure the first NIC (eg. eth0) only and 
not the vlan interfaces (eg. eth0.VLAN-ID).
ssh VM0-ADDRESS sudo ip link add link eth0 name eth0.101 type vlan id 101

I’d like to understand why the support of configuring vlan interfaces in the 
guest is not added. And should it be added?

Thanks,
Robert

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

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

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

[openstack-dev] [Openstack-dev] [Designate]

[Carmine Annunziata]

Hi everyone,
I integrated Designate in Openstack by devstack, now i'm using the new
default commands like zone create/delete, etc. I got this problem:

+--+---+-++++
| id   | name  | type|
serial | status | action |
+--+---+-++++
| fd80ab02-c8d7-4b06-9a4a-6026c3ca7a1c | example1.net. | PRIMARY |
1495725108 | ERROR  | DELETE |
| bfd19d7d-b259-4f88-afe0-b56d21d09ebe | example2.net. | PRIMARY |
1495726327 | ERROR  | DELETE |
| a33bf1fc-0112-48de-8f43-51c34845f011 | example1.com. | PRIMARY |
1495727006 | ERROR  | CREATE |
+--+---+-++++

Same on dashboard.

Cheers,
-- 
Carmine
__
OpenStack Development Mailing 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] priorities for the coming week (05/26-06/01)

[Brian Rosmaita]

As discussed at today's Glance meeting, here are the priorities for this week:

0  Glanceclient release
We plan to cut a release of the python-glanceclient on Wednesday 31
May.  There are two patches outstanding that would be good to have in
the release.  They need to be merged by 12:00 UTC on Tuesday 30 May.
Please give them your attention:
- https://review.openstack.org/444104
- https://review.openstack.org/445318

1  WSGI community goal
Matt Treinish has patches up implementing the "control plane API
endpoints deployment via WSGI" community goal.  Let's get them
reviewed and merged this week so they'll be in the P-2 milestone
release:
- 
https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:goal-deploy-api-in-wsgi
- https://review.openstack.org/#/c/459451/

2  Image import refactor
Erno has two patches stalled if anyone has time to help troubleshoot:
- https://review.openstack.org/#/c/391442/
- https://review.openstack.org/#/c/443632/

Other items:
I'm proposing reinstating Mike Fedosin as a Glance core:
- http://lists.openstack.org/pipermail/openstack-dev/2017-May/117489.html
Please reply to the above message if you have comments or concerns.


Have a productive week, and happy towel day!
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] [glance] nominating Mike Fedosin for glance core

[Brian Rosmaita]

As you've no doubt read elsewhere on the ML, we've lost several glance
cores recently due to employment changes.  Luckily, Mike Fedosin
informed me at today's Glance weekly meeting that he will have time
for the next few months to devote some time to Glance reviewing.

For those who don't know Mike (mfedosin on IRC), he was a Glance core
for several years.  He provided a lot of notes that were used to write
the Glance architecture documentation that is so helpful to new
contributors, so he's extremely knowledgeable about the design
patterns used in Glance.

Most recently, Mike's been working on the Glare project, which has a
lot in common with Glance.  While Mike says he can't commit much time
to Glance development, he has proposed porting some of the Glare tests
over to Glance, which will certainly help with our code coverage, and
would be a helpful addition to Glance.

(Mike agreed at today's Glance meeting not to propose re-integrating
Glare into the Glance project until the Queens PTG (if at all), so I'm
not worried about that being a distraction during the Pike cycle when
we are so short-handed.)

I'd like to reinstate Mike as a Glance core contributor at the next
Glance weekly meeting.  Please reply to this message with any comments
or concerns before 23:59 UTC on Wednesday 31 May 2017.

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] [murano][barbican] Encrypting sensitive properties

[Paul Bourke]

Hi all,

I've been looking at a blueprint[0] logged for Murano which involves 
encrypting parts of the object model stored in the database that may 
contain passwords or sensitive information.


I wanted to see if people had any thoughts or preferences on how this 
should be done. On the face of it, it seems Barbican is a good choice 
for solving this, and have read a lengthy discussion around this on the 
mailing list from earlier this year[1]. Overall the benefits of Barbican 
seem to be that we can handle the encryption and management of secrets 
in a common and standard way, and avoid having to implement and maintain 
this ourselves. The main drawback for Barbican seems to be that we 
impose another service dependency on the operator, though this complaint 
seems to be in some way appeased by Castellan, which offers alternative 
backends to just Barbican (though unsure right now what those are?). The 
alternative to integrating Barbican/Castellan is to use a more 
lightweight "roll your own" encryption such as what Glance is using[2].


After we decide on how we want to implement the encryption there is also 
the question of how best to expose this feature to users. My current 
thought is that we can use Murano attributes, so application authors can 
do something like this:


- name: appPassword
  type: password
  encrypt: true

This would of course be transparent to the end user of the application. 
Any thoughts on both issues are very welcome, I hope to have a prototype 
in the next few days which may help solidify this also.


Regards,
-Paul.

[0] 
https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html
[2] 
https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/crypt.py


__
OpenStack Development Mailing 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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

[John Griffith]

On Thu, May 25, 2017 at 5:50 AM, zengchen  wrote:

> Very sorry to foget attaching the link for bp of rewriting Fuxi with go
> language.
> https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang
>
>
> At 2017-05-25 19:46:54, "zengchen"  wrote:
>
> Hi guys:
> hongbin had committed a bp of rewriting Fuxi with go language[1]. My
> question is where to commit codes for it.
> We have two choice, 1. create a new repository, 2. create a new branch.
> IMO, the first one is much better. Because
> there are many differences in the layer of infrastructure, such as CI.
> What's your opinion? Thanks very much
>
> Best Wishes
> zengchen
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ​Hi Zengchen,

For now I was thinking just use Github and PR's outside of the OpenStack
projects to bootstrap things and see how far we can get.  I'll update the
BP this morning with what I believe to be the key tasks to work through.

Thanks,
John​
__
OpenStack Development Mailing 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] Update re: debian packages?

[Paul Belanger]

On Thu, May 25, 2017 at 08:30:46AM -0500, Andrew Bogott wrote:
> I've just noticed that, as predicted, Mirantis has switched off their
> Openstack package repos (e.g. http://liberty-jessie.pkgs.mirantis.com/).
> Are there any updates about a replacement repo, or a newly-reconstituted
> packaging team?
> 
> I remember being convinced back in February that people were on the
> case, but I was unable to attend the Boston summit, and the lists have been
> dead silent on the subject since the original thread announcing the end of
> Mirantis support.
> 
I believe zigo was trying to migrate that work to openstack-infra, which
currently lives at debian-openstack[1] repo. However, there hasn't been much
activity this year.

I know wendar has expressed interest in the past also.

[1] http://mirror.dfw.rax.openstack.org/debian-openstack/dists/

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

[openstack-dev] [oslo][all][logging] logging debugging improvement work status

[Doug Hellmann]

One outcome from the forum session about improving logging debugging
was agreement that the proposal to add more details about exceptions
to the logs. The spec [1] was updated and has been approved, and
the patches to implement the work in oslo.log have also been approved
[2].

The changes should be included in the Oslo releases next week. I
think it makes sense to hold off until then, given the holiday
weekend for many of the Oslo team members. As soon as the constraints
are updated to allow the new version of oslo.log, the log output
produced by devstack will change so that any log message emitted
in the context of handling an exception will include that exception
detail at the end of the log message (see the spec for details about
configuring that behavior).

After we start seeing this run in the gate for a bit, we can evaluate
if we need to tweak the format or skip any other of Python's built-in
exception types.

Thanks to Dims, Flavio, gcb, and Eric Fried for their help with
code reviews, and to the rest of the Oslo team and everyone who
participated in the discussion of the spec online and in Boston.

Doug

[1] 
http://specs.openstack.org/openstack/oslo-specs/specs/pike/improving-logging-debugging.html
[2] https://review.openstack.org/#/q/topic:improve-logging-debugging

__
OpenStack Development Mailing 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] [glance] Stepping Down

[Brian Rosmaita]

Dharini, on behalf of the Glance community, thank you for your service
to the project.  You were always willing to help out in any way
necessary, and your good work is much appreciated.

We all wish you luck in your future endeavors, and we hope you'll find
some time for Glance again at some point.

cheers,
brian

On Mon, May 22, 2017 at 8:46 PM, Chandrasekar, Dharini
 wrote:
> Hello Glancers,
>
>
>
> Due to a change in my job role with my employer, I unfortunately do not have
> the bandwidth to contribute to Glance in the capacity of a Core Contributor.
>
> I hence would have to step down from my role of a Core Contibutor in Glance.
>
>
>
> I had a great experience working in OpenStack Glance. Thank you all for your
> help and support. I wish you all, good luck in all your endeavors.
>
>
>
> Thanks,
>
> Dharini.
>
>
> __
> OpenStack Development Mailing 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] [glance] Stepping Down

[Brian Rosmaita]

Hemanth, on behalf of the Glance community, thank you for your long
and very productive service to the project.

We all wish you luck in your future endeavors, and we hope you'll find
some time for Glance again at some point.

cheers,
brian

On Fri, May 19, 2017 at 5:49 PM, Hemanth Makkapati  wrote:
> Glancers,
> Due to a significant change to my job description, I wouldn't be able to
> contribute to Glance in the capacity of a core reviewer going forward.
> Hence, I'd like to step down from my role immediately.
> For the same reason, I'd like to step down from Glance coresec and release
> liaison roles as well.
>
> Thanks for all the help!
>
> Rooting for Glance to do great things,
> Hemanth Makkapati
>
>
> __
> OpenStack Development Mailing 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] [trove] Trove reboot meeting

[MCCASLAND, TREVOR]

The time has come! I have opened the hangout, You can join now!

Please only join if you plan on participating in the discussion as there is a 
limit on these calls.
Given the number of people who responded on the doodle poll we should have room 
for a few extras.

https://hangouts.google.com/call/dhxlygwb4vbvffgfjjaerg3geiu

-Original Message-
From: MCCASLAND, TREVOR 
Sent: Monday, May 22, 2017 12:31 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove] Trove reboot meeting

*** Security Advisory: This Message Originated Outside of AT ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

Justin, that time is just as good. 



Thursday 1400 UTC will be the time for the meeting unless we have any other 
objections.



From: Justin Cook [mailto:jhc...@secnix.com] 

Sent: Monday, May 22, 2017 12:18 PM

To: OpenStack Development Mailing List (not for usage questions) 


Subject: Re: [openstack-dev] [trove] Trove reboot meeting



Trevor,



1500 UTC is 1600 BST and 1700 CEST which is quite late for the French. Our 
friends in Berlin may be up for it. I recommend 1500 BST which is 1400 UTC. Of 
course, your suggestion works well for the US west coast. 



Cheers,



Justin

On 22 May 2017 at 17:50:10, MCCASLAND, TREVOR (mailto:tm2...@att.com) wrote:

The results show a meeting time for Thursday 1500 UTC; I'll message the join 
link on this thread 15 min prior and in the #openstack-trove 



It has come to my attention that the poll time zones were not clear, I was 
under the impression everyone had their own view based on their IP's location. 

However, I think everyone made the correct assumptions and we have agreed to 
meet at 1500 UTC on Thursday. 



If you have any questions you can ask them on this thread or raise them during 
the trove meeting this Wednesday at 1500-1600 UTC Wednesday. 



Sharing google calendar events can be a pain but it only gives us a 
notification for our calendars so.. I'm not going to bother with it that much. 
If you really want it on your calendar you can email me and I will add you to 
the event but you don' need to do this. 



-Original Message- 

From: MCCASLAND, TREVOR 

Sent: Friday, May 19, 2017 2:35 PM 

To: OpenStack Development Mailing List (not for usage questions) 
 

Subject: [openstack-dev] [trove] Trove reboot meeting 



*** Security Advisory: This Message Originated Outside of AT ***. 

Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. 



As a result of a large number of new contributors looking for direction from 
our project, we would like to host a focused meeting on the project's scope. 



Please let us know your availability for this one time meeting by using this 
doodle poll[1] 



We have brainstormed a few ideas for discussion [2], the project's scope is not 
limited to these ideas so if you would like to include something, please add 
it. 



Traditionally these kind of meetings are done at the PTG but we wanted to get 
ahead of that timeline to keep the interest going. 



The current meeting time and place is not decided yet but it will most likely 
be an impromptu virtual meeting on google hangouts or some variant but we will 
also try our best to loop the conversation back in to the mailing list, our 
channel #openstack-trove and/or our project's meeting time. 



When the time is right, probably Tuesday morning. I will announce what time 
works the best for everyone, how and where to participate. 



[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__beta.doodle.com_poll_s36ywdz5mfwqkdvu=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=grsR5Fg0eE2KeSRz0GJGD3ynjfBCiSUG8JWqdxVdI4o=PpMZu9e7ngwvol1PXZjsHpdi0zgnchuPkLcmIP59-9o=
 

[2] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_trove-2Dreboot=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=grsR5Fg0eE2KeSRz0GJGD3ynjfBCiSUG8JWqdxVdI4o=sOtPMJkzBnO0cjt3GBq3sNPQIxwn5UjkuPBENK0QhEA=
 





__ 

OpenStack Development Mailing List (not for usage questions) 

Unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=5a5CFTGEvXlDk9pWwNf-JCKgD0TYbElZ8yuQUk8agAA=3D6biqakOTH7JLr3TLKXD_qYy-R0wdUOySEYBwsW8Xw=
 

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=grsR5Fg0eE2KeSRz0GJGD3ynjfBCiSUG8JWqdxVdI4o=lILpFrPj5ir_oBfPpkObf8xbDagrrKcF2ltvuNjQD5k=
 

__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 

Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Loo, Ruby]

Hi Zhenguo,

Thanks for bringing this up. Naming is hard :-(

Maybe this is a dumb question but your phrase "We copied nova's server resource 
concept here, so users may easily to accept the 'baremetal server'" made me 
wonder. I'm not a user of Mogan so I don't know if this would work, but OSC 
already has
openstack server  
openstack flavor  
openstack keypair  

Why can't we use the existing OSC commands, and add an option eg '--bm' to 
indicate that the server is baremetal, not a VM?

Of course, having asked this, how does the user know/distinguish between 
getting a baremetal instance via mogan or via nova... (and should the end user 
actually know that there is a difference...) But I suspect I am digressing.

--ruby

From: Zhenguo Niu 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, May 25, 2017 at 5:38 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same keyword 
'baremetal'?


On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur 
> wrote:
On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
hi all,

Hi!

I'm from the Mogan team, we chose the same keyward 'baremetal' when 
implementing a OSC plugin [1]. As we think the baremetal command is 
representative of a baremetal resource, not a service, so it makes sense for 
different projects to share the top level resource name that OpenStack can 
provide.

We do not "own" the word "baremetal", so nothing prevents you from using it. 
However, in my experience:
1. This does confuse users, as they expect "openstack baremetal" to be a prefix 
belonging to Ironic.
2. Collisions may happen. We had two collisions with TripleO already, one 
resulted in us killing a TripleO command abruptly.

Alternatively, I don't mind to change this to 'bm' or something like that for 
Mogan, but some operators told me that it will confuse users more to have both 
'baremetal' and 'bm' in there CLI.
And as I understand, ironic commands are not used frequently, and it's even 
less if ironic inspector can help to automatically enroll nodes/ports.



The commands we have implemented are listed below, seems there's no collision 
with Ironic presently, and Ironic doesn't manage such resources.

* openstack baremetal server  
* openstack bareemtal flavor  
* openstack baremetal keypair  
* openstack baremetal availability zone  

Ironic does not have any notion of either of these, so it should be fine.

I'm still a bit on a -1 side because of potential users confusion. I wonder how 
can we send a message across that prefixes do not designate a specific project, 
but are rather just part of a "sentence". I'm specifically worried about 
confusing "baremetal server" of Mogan with "baremetal node" of Ironic. For many 
people these can be synonyms.

We copied nova's server resource concept here, so users may easily to accept 
the 'baremetal server'. For 'baremetal node', seems only 
operators/administrators may use such commands, so seems the synonyms is not a 
big problem as they are for different roles.


So, we'd like to ask if our CLI pattern is allowed before we release the client.

Thanks in advance!


[1] https://github.com/openstack/python-moganclient

--
Best Regards,
Zhenguo Niu


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



--
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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] Update re: debian packages?

[Andrew Bogott]

I've just noticed that, as predicted, Mirantis has switched off 
their Openstack package repos (e.g. 
http://liberty-jessie.pkgs.mirantis.com/).  Are there any updates about 
a replacement repo, or a newly-reconstituted packaging team?


I remember being convinced back in February that people were on the 
case, but I was unable to attend the Boston summit, and the lists have 
been dead silent on the subject since the original thread announcing the 
end of Mirantis support.


Thanks!

-Andrew

__
OpenStack Development Mailing 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] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Mark Goddard]

On 25 May 2017 at 11:03, Dmitry Tantsur  wrote:

> On 05/25/2017 11:38 AM, Zhenguo Niu wrote:
>
>>
>> On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur > > wrote:
>>
>> On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
>>
>> hi all,
>>
>>
>> Hi!
>>
>>
>> I'm from the Mogan team, we chose the same keyward 'baremetal'
>> when
>> implementing a OSC plugin [1]. As we think the baremetal command
>> is
>> representative of a baremetal resource, not a service, so it
>> makes sense
>> for different projects to share the top level resource name that
>> OpenStack can provide.
>>
>>
>> We do not "own" the word "baremetal", so nothing prevents you from
>> using it.
>> However, in my experience:
>> 1. This does confuse users, as they expect "openstack baremetal" to
>> be a
>> prefix belonging to Ironic.
>> 2. Collisions may happen. We had two collisions with TripleO already,
>> one
>> resulted in us killing a TripleO command abruptly.
>>
>>
>> Alternatively, I don't mind to change this to 'bm' or something like that
>> for Mogan, but some operators told me that it will confuse users more to
>> have both 'baremetal' and 'bm' in there CLI.
>> And as I understand, ironic commands are not used frequently, and it's
>> even less if ironic inspector can help to automatically enroll nodes/ports.
>>
>
> I don't share this understanding, depends on a situation. A user of a
> purely baremetal cloud, or an installer like TripleO, may use the baremetal
> commands all the time.
>
>
>>
>> The commands we have implemented are listed below, seems there's
>> no
>> collision with Ironic presently, and Ironic doesn't manage such
>> resources.
>>
>> * openstack baremetal server  
>> * openstack bareemtal flavor  
>> * openstack baremetal keypair  
>> * openstack baremetal availability zone  
>>
>>
>> Ironic does not have any notion of either of these, so it should be
>> fine.
>>
>
When using the openstack CLI I'm often in a 'discovery' mode, particularly
if I'm interacting with a service that I don't often interact with. I often
use the tab autocomplete and fuzzy match features of OSC as I explore.
Having command prefix match multiple services could be confusing,
particularly if I have python-moganclient installed but no mogan service
exists.

If there were an additional command prefix for mogan as is used for ironic
inspector (openstack baremetal introspection ...), this would at least
group the mogan commands.

* openstack baremetal foo server  
* openstack baremetal foo flavor  
* openstack baremetal foo keypair  
* openstack baremetal foo availability zone  


>> I'm still a bit on a -1 side because of potential users confusion. I
>> wonder
>> how can we send a message across that prefixes do not designate a
>> specific
>> project, but are rather just part of a "sentence". I'm specifically
>> worried
>> about confusing "baremetal server" of Mogan with "baremetal node" of
>> Ironic.
>> For many people these can be synonyms.
>>
>>
>> We copied nova's server resource concept here, so users may easily to
>> accept the 'baremetal server'. For 'baremetal node', seems only
>> operators/administrators may use such commands, so seems the synonyms is
>> not a big problem as they are for different roles.
>>
>
> It's not obvious from a command name, though. They'll just get 403 when
> trying to use them.
>
>
>>
>> So, we'd like to ask if our CLI pattern is allowed before we
>> release the
>> client.
>>
>> Thanks in advance!
>>
>>
>> [1] https://github.com/openstack/python-moganclient
>> 
>>
>> -- Best Regards,
>> Zhenguo Niu
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > subscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > ck-dev>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>> --
>> Best Regards,
>> Zhenguo Niu
>>
>>
>> 

[openstack-dev] [QA] Proposed changes to the team meeting time

[Andrea Frittoli]

Hello team,

our current QA team meeting schedule alternates between 9:00 UTC and 17:00
UTC.
The 9:00 meetings is a bit towards the end of the day for out contributors
in APAC, so I'm proposing to move the meeting to 8:00 UTC.

Please respond with +1 / -1 and/or comments, I will leave the poll open for
about 10 days to make sure everyone interested gets a chance to comment.

Thank you

andrea
__
OpenStack Development Mailing 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] Onboarding rooms postmortem, what did you do, what worked, lessons learned

[Amrith Kumar]

Kendall,

I would like to be the Trove liaison, and would like to participate in
Upstream University next time around.

With that said, the answers to Sean's original question.

I ran the room for the Trove team, I think it was a welcome addition.

What went well: I think it was a good opportunity for the project to get
new contributors (update: if you are interested in contributing to an
openstack project, trove is looking for new participants).

It would have been nice to have them video taped.

-amrith


-amrith

--
Amrith Kumar
Phone: +1-978-563-9590


On Wed, May 24, 2017 at 6:20 PM, Kendall Nelson 
wrote:

> @Nikhil, we (the organizers of Upstream Institute) sent a few emails
> [1][2] out to the dev mailing list asking for help and representatives from
> various projects to attend and get involved. We are also working on
> building a network of project liaisons to direct newcomers to in each
> project. Would you be interested in being our Glance liaison?
>
> Let me know if you have any other Upstream Institute questions!
>
> - Kendall(diablo_rojo)
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> January/110788.html
> [2]  http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/108084.html
>
> On Wed, May 24, 2017 at 4:03 PM Nikhil Komawar 
> wrote:
>
>> Project:  Glance
>>
>> Attendees: ~15
>>
>> What was done:
>>
>> We started by introducing the core team (or whatever existed then), did a
>> run down of Glance API documentation especially for developers, other
>> references like notes for ops, best practices. We went through the
>> architecture of the project. A few were interested in knowing more details
>> and going in depth so we discussed the design patterns that exist today,
>> scope of improvements and any blackholes therein, auxiliary services and
>> performance tradeoffs etc. A lot of the discussion was free form so people
>> asked questions and session was interactive.
>>
>>
>> What worked:
>>
>> 1. The projector worked!
>>
>> 2. Session was free form, there was good turnout and it was interactive.
>> (all the good things)
>>
>> 3. People were serious about contributing as per their
>> availability/capacity to do upstream and one person showed up asking to do
>> reviews.
>>
>>
>> Lessons:
>>
>> 1. Could have been advertised more at least the session description more
>> customized.
>>
>> 2. A representative from the team could have been officially invited to
>> the upstream institute training.
>>
>> 3. The community building sessions and on-boarding sessions seem to
>> overlap a bit so a representative from the team could be help in those
>> sessions for Q or more interaction. Probably more collaboration/prep
>> before the summit for such things. ($0.02)
>>
>>
>> Cheers
>>
>> On Wed, May 24, 2017 at 1:27 PM, Jay S Bryant 
>> wrote:
>>
>>> Project:  Cinder
>>>
>>> Attendees: Approximately 30
>>>
>>> I was really pleased by the number of people that attended the Cinder
>>> session and the fact that they people in the room seemed engaged with the
>>> presentation and asked good questions showing interest in the project.  I
>>> think having the on-boardings rooms was beneficial and hopefully something
>>> that we can continue.
>>>
>>> Given the number of people in the room we didn't go around and introduce
>>> everyone.  I did have the Sean McGinnis introduce himself as PTL and had
>>> the other Cinder Core members introduce themselves so that the attendees
>>> could put faces with our names.
>>>
>>> From there we kicked off the presentation [1] which covered the
>>> following high level topics:
>>>
>>>- Introduction of Cinder's Repos and components
>>>- Quick overview of Cinder's architecture/organization
>>>- Pointers to the Upstream Institute education (Might have done a
>>>bit of a sales pitch for the next session here ;-))
>>>- Expanded upon the Upstream Institute education to explain how what
>>>was taught there specifically applied to Cinder
>>>- Walked through the main Cinder code tree
>>>- Described how to test changes to Cinder
>>>
>>> My presentation was designed to assume that attendees had been through
>>> Upstream Institute.  I had coverage in the slides in case they had not been
>>> through the education.  Unfortunately most of the class had not been
>>> through the education so I did spend a portion of time re-iterating those
>>> concepts and less time was able to be spent at the end going through real
>>> world examples of working with changes in Cinder.  I got feedback from a
>>> few people that having some real hands on coding examples would have been
>>> helpful.
>>>
>>> One way we could possible handle this is to split the on-boarding to a
>>> introduction section and then a more advanced second session.  The other
>>> option is that we require people who are attending the on-boarding to have
>>> been through Upstream Institute.  Something to 

Re: [openstack-dev] [cyborg]Nominate Rushil Chugh and Justin Kilpatrick as new core reviewers

[Harm Sluiman]

+1
I haven't had time to actively participate these past months but have monitored 
and agree :)

Thanks for your time
Harm Sluiman
harm.slui...@gmail.com


> On May 25, 2017, at 10:24 AM, Zhipeng Huang  wrote:
> 
> Hi Team,
> 
> This is an email for nomination of rushil and justin to the core team. They 
> have been very active in our development and the specs they helped draft have 
> been merged after several rounds of review. The statistics could be found at 
> http://stackalytics.com/?project_type=all=cyborg=person-day .
> 
> Since we are not an official project and i'm the only core reviewer at the 
> moment, I think we should have a simple procedure for the first additional 
> core reviewers to be added. Therefore if there are no outstanding oppositions 
> by the end of the day of next Wed, I will suppose there is a consensus and 
> add these guys to the core team to help accelerating our development.
> 
> Please voice your support or concerns if there are any within the next 7 days 
> :) 
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
> 
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] [ptg] Strawman Queens PTG week slicing

[Amrith Kumar]

Thierry,

Thanks for doing this. Two specific points below.

1. You can schedule Trove for Wednesday and Thursday, skip the Friday.

2. Similar to the idea of splitting the project things from the cross
project/infra things, would it be possible to have projects try and keep
their project specific (non cross project) topics to one of the days and
give a preference to cross project things on another day. This may help
with scheduling cross project participation.

Thanks,

-amrith


-amrith

--
Amrith Kumar
Phone: +1-978-563-9590


On Wed, May 24, 2017 at 10:44 AM, Thierry Carrez 
wrote:

> Doug Hellmann wrote:
> > Two questions about theme-based initiatives:
> >
> > I would like to have a discussion about the work to stop syncing
> > requirements and to see if we can make progress on the implementation
> > while we have the right people together. That seems like a topic
> > for Monday or Tuesday. Would I reserve one of the "last-minute WG"
> > rooms or extra rooms (it doesn't feel very last-minute if I know
> > about it now)?
>
> We have some flexibility there, depending on how much time we need. If
> it's an hour or two, I would go and book one of the "reservable rooms".
> If it's a day or two, I would assign one of the rooms reserved for
> upcoming workgroups/informal teams. "Last-minute" is confusing (just
> changed it on the spreadsheet), those rooms are more to cater for needs
> that are not represented in formal workgroups today.
>
> > I don't see a time on here for the Docs team to work together on
> > the major initiative they have going to change how publishing works.
> > I didn't have the impression that we could anticipate that work
> > being completed this cycle. Is the "helproom" going to be enough,
> > or do we need a separate session for that, too?
>
> Again, we should be pretty flexible on that. We can reuse the doc
> helproom, or we can say that the doc helproom is only on one day and the
> other day is dedicated to making the doc publishing work. And if the doc
> refactoring ends up being a release goal, it could use a release goal
> room instead.
>
> All in all, the idea is to show that on Mon-Tue we have a number of
> rooms set apart to cover for any inter-project need we may have (already
> identified or not). The room allocation is actually much tighter on
> Wed-Thu :)
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] mount ceph block from an instance

[Jean-Philippe Evrard]

I doubt many people have tried this, because 1) cinder/nova/glance probably do 
the job well in a multi-tenant fashion 2) you’re poking holes into your ceph 
cluster security.

Anyway, if you still want it, you would need (I guess) have to create a 
provider network that will be allowed to access your ceph network.

You can either route it from your current public network, or create another 
network. It’s 100% up to you, and not osa specific.

Best regards,
JP

On 24/05/2017, 15:02, "fabrice grelaud"  wrote:

Hi osa team,

i have a multimode openstack-ansible deployed, ocata 15.1.3, with ceph as 
backend for cinder (with our own ceph infra).

After create an instance with root volume, i would like to mount a ceph 
block or cephfs directly to the vm (not a cinder volume). So i want to attach a 
new interface to the vm that is in the ceph vlan.
How can i do that ?

We have our ceph vlan propagated on bond0 interface (bond0.xxx and 
br-storage configured as documented) for openstack infrastructure.

Should i have to propagate this vlan on the bond1 interface where my 
br-vlan is attach ?
Should i have to use the existing br-storage where the ceph vlan is already 
propagated (bond0.xxx) ? And how i create the ceph vlan network in neutron (by 
neutron directly or by horizon) ?

Has anyone ever experienced this ?

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




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing 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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

[zengchen]

Very sorry to foget attaching the link for bp of rewriting Fuxi with go 
language.
https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang




At 2017-05-25 19:46:54, "zengchen"  wrote:

Hi guys:
hongbin had committed a bp of rewriting Fuxi with go language[1]. My 
question is where to commit codes for it.
We have two choice, 1. create a new repository, 2. create a new branch.  IMO, 
the first one is much better. Because
there are many differences in the layer of infrastructure, such as CI.  What's 
your opinion? Thanks very much
 
Best Wishes
zengchen__
OpenStack Development Mailing 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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

[zengchen]

Hi guys:
hongbin had committed a bp of rewriting Fuxi with go language[1]. My 
question is where to commit codes for it.
We have two choice, 1. create a new repository, 2. create a new branch.  IMO, 
the first one is much better. Because
there are many differences in the layer of infrastructure, such as CI.  What's 
your opinion? Thanks very much
 
Best Wishes
zengchen__
OpenStack Development Mailing 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][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

[Lee Yarwood]

On 25-05-17 11:38:44, Duncan Thomas wrote:
> On 25 May 2017 at 11:00, Lee Yarwood  wrote:
> > This has also reminded me that the plain (dm-crypt) format really needs
> > to be deprecated this cycle. I posted to the dev and ops ML [2] last
> > year about this but received no feedback. Assuming there are no last
> > minute objections I'm going to move forward with deprecating this format
> > in os-brick this cycle.
> 
> What is the reasoning for this? There are plenty of people using it, and
> you're going to break them going forward if you remove it.

I didn't receive any feedback indicating that we had any users of plain
when I initially posted to the ML. That said there obviously can be
users out there and my intention isn't to pull support for this format
immediately without any migration path to LUKS etc.

As for the reasoning, the main issue I've seen reported against plain is
that there's always a potential for data loss if an incorrect passphrase
or options are provided when opening the device [1].

There are further reasons for choosing LUKS over plain documented in
various places [2][3][4] that all seem to suggest that it is a better
and safer choice.

Lee

[1] https://bugs.launchpad.net/nova/+bug/1639221
[2] 
https://security.stackexchange.com/questions/90468/why-is-plain-dm-crypt-only-recommended-for-experts
[3] https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
[4] https://wiki.archlinux.org/index.php/Disk_encryption#Block_device_encryption
-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

__
OpenStack Development Mailing 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][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

[Daniel P. Berrange]

On Thu, May 25, 2017 at 11:38:44AM +0100, Duncan Thomas wrote:
> On 25 May 2017 at 11:00, Lee Yarwood  wrote:
> > This has also reminded me that the plain (dm-crypt) format really needs
> > to be deprecated this cycle. I posted to the dev and ops ML [2] last
> > year about this but received no feedback. Assuming there are no last
> > minute objections I'm going to move forward with deprecating this format
> > in os-brick this cycle.
> 
> What is the reasoning for this? There are plenty of people using it, and
> you're going to break them going forward if you remove it.

It has bad security management characteristics because the passphrase is
directly used to create the encryption key. Thus there's no way to update
the passphrase without re-encrypting all data in the device. If your passphrase
is compromised all data is compromised until you can do such re-encryption,
or you have to shred all copies of it, including any backups. If you want
todo the encryption in-place your VMs have to be taken offline too.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

__
OpenStack Development Mailing 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][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

[Duncan Thomas]

On 25 May 2017 at 11:00, Lee Yarwood  wrote:
> This has also reminded me that the plain (dm-crypt) format really needs
> to be deprecated this cycle. I posted to the dev and ops ML [2] last
> year about this but received no feedback. Assuming there are no last
> minute objections I'm going to move forward with deprecating this format
> in os-brick this cycle.

What is the reasoning for this? There are plenty of people using it, and
you're going to break them going forward if you remove it.

-- 
Duncan Thomas

__
OpenStack Development Mailing 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] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Dmitry Tantsur]

On 05/25/2017 11:38 AM, Zhenguo Niu wrote:


On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur > wrote:


On 05/25/2017 10:20 AM, Zhenguo Niu wrote:

hi all,


Hi!


I'm from the Mogan team, we chose the same keyward 'baremetal' when
implementing a OSC plugin [1]. As we think the baremetal command is
representative of a baremetal resource, not a service, so it makes sense
for different projects to share the top level resource name that
OpenStack can provide.


We do not "own" the word "baremetal", so nothing prevents you from using it.
However, in my experience:
1. This does confuse users, as they expect "openstack baremetal" to be a
prefix belonging to Ironic.
2. Collisions may happen. We had two collisions with TripleO already, one
resulted in us killing a TripleO command abruptly.


Alternatively, I don't mind to change this to 'bm' or something like that for 
Mogan, but some operators told me that it will confuse users more to have both 
'baremetal' and 'bm' in there CLI.
And as I understand, ironic commands are not used frequently, and it's even less 
if ironic inspector can help to automatically enroll nodes/ports.


I don't share this understanding, depends on a situation. A user of a purely 
baremetal cloud, or an installer like TripleO, may use the baremetal commands 
all the time.





The commands we have implemented are listed below, seems there's no
collision with Ironic presently, and Ironic doesn't manage such 
resources.

* openstack baremetal server  
* openstack bareemtal flavor  
* openstack baremetal keypair  
* openstack baremetal availability zone  


Ironic does not have any notion of either of these, so it should be fine.

I'm still a bit on a -1 side because of potential users confusion. I wonder
how can we send a message across that prefixes do not designate a specific
project, but are rather just part of a "sentence". I'm specifically worried
about confusing "baremetal server" of Mogan with "baremetal node" of Ironic.
For many people these can be synonyms.


We copied nova's server resource concept here, so users may easily to accept the 
'baremetal server'. For 'baremetal node', seems only operators/administrators 
may use such commands, so seems the synonyms is not a big problem as they are 
for different roles.


It's not obvious from a command name, though. They'll just get 403 when trying 
to use them.





So, we'd like to ask if our CLI pattern is allowed before we release the
client.

Thanks in advance!


[1] https://github.com/openstack/python-moganclient


-- 
Best Regards,

Zhenguo Niu



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





--
Best Regards,
Zhenguo Niu


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




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

[openstack-dev] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

[Lee Yarwood]

Hello all,

I'm currently working on enabling QEMU's native LUKS support within Nova
[1]. While testing this work with Barbican I noticed that Cinder is
creating symmetric keys for use with encrypted volumes :

https://github.com/openstack/cinder/blob/63433278a485b65ae6ed1998e7bc83933ceee167/cinder/volume/flows/api/create_volume.py#L385
https://github.com/openstack/castellan/blob/64207e303529b7fceb3b8b0f0a65f8f49b3f9b26/castellan/key_manager/barbican_key_manager.py#L206

However the only supported disk encryption formats on the front-end at
present are plain (dm-crypt) and LUKS, neither of which use the supplied
key to directly encrypt or decrypt data. Plain derives a fixed length
master key from the provided key / passphrase and LUKS uses PBKDF2 to
derive a key from the key / passphrase that unlocks a separate master
key.

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
- 2.4 What is the difference between "plain" and LUKS format?

I also can't find any evidence of these keys being used directly on the
backend for any direct encryption of volumes within c-vol. Happy to be
corrected here if there are out-of-tree drivers etc that do this.

IMHO for now we are better off storing a secret passphrase in Barbican
for use with these encrypted volumes, would there be any objections to
this? Are there actual plans to use a symmetric key stored in Barbican
to directly encrypt and decrypt volumes?

This has also reminded me that the plain (dm-crypt) format really needs
to be deprecated this cycle. I posted to the dev and ops ML [2] last
year about this but received no feedback. Assuming there are no last
minute objections I'm going to move forward with deprecating this format
in os-brick this cycle.

Thanks in advance,

Lee

[1] 
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/libvirt-qemu-native-luks.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106956.html
-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

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

[openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?

[Jiri Suchomel]

Hi,
it seems to me that the way of adding extra NFS options to the cinder
backend is somewhat confusing.

1. There is  nfs_mount_options in cinder config file [1]

2. Then I can put my options to the nfs_shares_config file - that
it could contain additional options mentiones [2] or the
commit message that adds the feature [3]

Now, when I put my options to both of these places, cinder-volume
actually uses them twice and executes the command like this

mount -t nfs -o nfsvers=3 -o nfsvers=3
192.168.241.10:/srv/nfs/vi7/cinder 
/var/lib/cinder/mnt/f5689da9ea41a66eff2ce0ef89b37bce

BTW, the options coming from nfs_shares_config are called 'flags' by
cinder/volume/drivers/nfs ([4]).

Now, to make it more fun, when I actually want to attach a volume to
running instance, nova uses different way of realizing which NFS options to use:

- It reads them from _nova_ config option of libvirt.nfs_mount_options
[5]
- or it uses those it gets them from cinder when creating cinder
connection [6] But these are only the options defined in
nfs_shares_config file, NOT those nfs_mount_options specified in cinder
config file.


So. If I put my options to both places, nfs_shares_config file and
nfs_mount_options, it actually works how I want it to work, as
current mount does not complain that the option was provided twice. 

But it looks ugly. And I'm wondering - am I doing it wrong, or
is there a problem with either cinder or nova (or both)?


Jiri


[1] https://docs.openstack.org/admin-guide/blockstorage-nfs-backend.html
[2]
https://docs.openstack.org/newton/config-reference/block-storage/drivers/nfs-volume-driver.html
[3]
https://github.com/openstack/cinder/commit/553e0d92c40c73aa1680743c4287f31770131c97
[4]
https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L163
[5]
https://github.com/openstack/nova/blob/stable/newton/nova/virt/libvirt/volume/nfs.py#L87
[6] 
https://github.com/openstack/nova/blob/stable/newton/nova/virt/libvirt/volume/nfs.py#L89

-- 
Jiri Suchomel

SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
18600 Praha 8

__
OpenStack Development Mailing 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] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Zhenguo Niu]

On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur  wrote:

> On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
>
>> hi all,
>>
>
> Hi!
>
>
>> I'm from the Mogan team, we chose the same keyward 'baremetal' when
>> implementing a OSC plugin [1]. As we think the baremetal command is
>> representative of a baremetal resource, not a service, so it makes sense
>> for different projects to share the top level resource name that OpenStack
>> can provide.
>>
>
> We do not "own" the word "baremetal", so nothing prevents you from using
> it. However, in my experience:
> 1. This does confuse users, as they expect "openstack baremetal" to be a
> prefix belonging to Ironic.
> 2. Collisions may happen. We had two collisions with TripleO already, one
> resulted in us killing a TripleO command abruptly.
>
>
Alternatively, I don't mind to change this to 'bm' or something like that
for Mogan, but some operators told me that it will confuse users more to
have both 'baremetal' and 'bm' in there CLI.
And as I understand, ironic commands are not used frequently, and it's even
less if ironic inspector can help to automatically enroll nodes/ports.



>
>> The commands we have implemented are listed below, seems there's no
>> collision with Ironic presently, and Ironic doesn't manage such resources.
>>
>> * openstack baremetal server  
>> * openstack bareemtal flavor  
>> * openstack baremetal keypair  
>> * openstack baremetal availability zone  
>>
>
> Ironic does not have any notion of either of these, so it should be fine.
>
> I'm still a bit on a -1 side because of potential users confusion. I
> wonder how can we send a message across that prefixes do not designate a
> specific project, but are rather just part of a "sentence". I'm
> specifically worried about confusing "baremetal server" of Mogan with
> "baremetal node" of Ironic. For many people these can be synonyms.
>
>
We copied nova's server resource concept here, so users may easily to
accept the 'baremetal server'. For 'baremetal node', seems only
operators/administrators may use such commands, so seems the synonyms is
not a big problem as they are for different roles.


>
>> So, we'd like to ask if our CLI pattern is allowed before we release the
>> client.
>>
>> Thanks in advance!
>>
>>
>> [1] https://github.com/openstack/python-moganclient
>>
>> --
>> Best Regards,
>> Zhenguo Niu
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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,
Zhenguo Niu
__
OpenStack Development Mailing 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] A proposal for hackathon to reduce deploy time of TripleO

[Bogdan Dobrelya]

On 25.05.2017 0:08, Jeremy Stanley wrote:
> On 2017-05-24 16:27:18 -0500 (-0500), Ben Nemec wrote:
> [...]
>> I spent a _lot_ of time tracking down performance issues and
>> optimizing things where I could, and in the end pretty much every
>> gain I made was regressed somewhere else within a few weeks,
>> leaving us where we are now with jobs timing out all over the
>> place.
> [...]
> 
> The uneasy truth (in many places, not just TripleO) is that if
> people only try to improve speed or memory footprint or what have
> you when jobs are constantly hitting those thresholds, then the
> gains will usually only be very temporary. I agree it has to be an
> all-the-time effort to work on minimization across these axes or
> else we'll end up with near constant job failures from them. Under
> development, software will (often rapidly) grow to fill the resource
> constraints placed around it. There's some sort of natural law at
> work there.
> 

Great topic, and a huge effort #deployment-time! Thank you for raising
this. Few more inputs and random thoughts:
[0] - Lightening undercloud MAV to save Mark Watney once again
[1] - There is a strange nerdish joy with (never ending) adjusting of
tests matrix and chaining builds promotion pipelines.

[0] https://bugs.launchpad.net/tripleo/+bug/1693448
[1] https://bugs.launchpad.net/tripleo/+bug/1693435

-- 
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] [ironic] using keystone right - catalog, endpoints, tokens and noauth

[Dmitry Tantsur]

On 05/24/2017 11:46 AM, Pavlo Shchelokovskyy wrote:

Hi all,

There are several problems or inefficiencies in how we are dealing with auth to 
other services. Although it became much better in Newton, some things are still 
to be improved and I like to discuss how to tackle those and my ideas for that.


Keystone endpoints
===

Apparently since February-ish DevStack no longer sets up 'internal' endpoints 
for most of the services in core devstack [0].
Luckily we were not broken by that right away - although when discovering a 
service endpoint from keystone catalog we default to 'internal' endpoint [1], 
for most services our devstack plugin still configures explicit service URL in 
the corresponding config section, and thus the service discovery from keystone 
never takes place (or that code path is not tested by functional/integration 
testing).


AFAIK different endpoint types (internal vs public) are still quite used by 
deployments (and IMO rightfully so), so we have to continue supporting that. I 
propose to take the following actions:


- in our devstack plugin, stop setting up the direct service URLs in config, 
always use keystone catalog for discovery
- in every conf section related to external service add 
'endpoint_type=[internal|public]' option, defaulting to 'internal', with a 
warning in option description (and validated on conductor start) that it will be 
changed to 'public' in the next release
- use those values from CONF wherever we ask for service URL from catalog or 
instantiate client with session.

- populate these options in our devstack plugin to be 'public'


+1 to all this

- in Queens, switch the default to 'public' and use defaults in devstack plugin, 
remove warnings.


-1 here. The semantic of "internal" is much closer to what we want. What we 
actually need is a way to provide a prioritized list of interfaces. So this 
would be ["internal", "public"], which means "take internal if it exists, 
otherwise take public". I'm pretty sure no clients support anything like that.




Unify clients creation


again, in those config sections related to service clients, we have many options 
to instantiate clients from (especially glance section, see my other recent ML 
about our image service code). Many of those seem to be from the time when 
keystone catalog was missing some functionality or not existing at all, and 
keystoneauth lib abstracting identity and client sessions was not there either.


To simplify setup and unify as much code as possible I'd like to propose the 
following:


- in each config section for service client add (if missing) a '_url' 
option that should point to the API of given service and will be used *only in 
noauth mode* when there's no Keystone catalog to discover the service endpoint from


As Monty noticed, we seem to have endpoint_override already.

- in the code creating service clients, always create a keystoneauth session 
from config sections, using appropriate keystoneauth identity plugin - 
'token_endpoint' with fake token _url for noauth mode, 'password' for 
service user client, 'token' when using a token from incoming request. The 
latter will have a benefit to make it possible for the session to reauth itself 
when user token is about to expire, but might require changes in some public 
methods to pass in the full task.context instead of just token
- always create clients from sessions. Although AFAIK all clients ironic uses 
already support this, some in ironic code (e.g. glance) still always create a 
client from token and endpoint directly.


+1000

- deprecate some options explicitly registered by ironic in those sections that 
are becoming redundant - including those that relate to HTTP session settings 
(like timeout, retries, SSL certs and settings) as those will be used from 
options registered by keystoneauth Session, and those multiple options that 
piece together a single service URL.


+1



This will decrease the complexity of service client-related code and will make 
configuring those cleaner.


Of course all of this has to be done minding proper deprecation process, 
although that might complicate things (as usual :/).


Legacy auth
=

Probably not worth specific mention, but we implemented a proper 
keystoneauth-based loading of client auth options back in Newton almost a year 
ago, so the code attempting to load auth for clients in a deprecated way from 
"[keystone_authtoken]" section can be safely removed already.


Yes please. We've already removed it from ironic-inspector.



As always, I'm eager to hear your comments.

[0] https://review.openstack.org/#/c/433272/ 

[1] 
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/keystone.py#n118 



Best regards,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com 

Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Dmitry Tantsur]

On 05/25/2017 10:20 AM, Zhenguo Niu wrote:

hi all,


Hi!



I'm from the Mogan team, we chose the same keyward 'baremetal' when implementing 
a OSC plugin [1]. As we think the baremetal command is representative of a 
baremetal resource, not a service, so it makes sense for different projects to 
share the top level resource name that OpenStack can provide.


We do not "own" the word "baremetal", so nothing prevents you from using it. 
However, in my experience:
1. This does confuse users, as they expect "openstack baremetal" to be a prefix 
belonging to Ironic.
2. Collisions may happen. We had two collisions with TripleO already, one 
resulted in us killing a TripleO command abruptly.




The commands we have implemented are listed below, seems there's no collision 
with Ironic presently, and Ironic doesn't manage such resources.


* openstack baremetal server  
* openstack bareemtal flavor  
* openstack baremetal keypair  
* openstack baremetal availability zone  


Ironic does not have any notion of either of these, so it should be fine.

I'm still a bit on a -1 side because of potential users confusion. I wonder how 
can we send a message across that prefixes do not designate a specific project, 
but are rather just part of a "sentence". I'm specifically worried about 
confusing "baremetal server" of Mogan with "baremetal node" of Ironic. For many 
people these can be synonyms.




So, we'd like to ask if our CLI pattern is allowed before we release the client.

Thanks in advance!


[1] https://github.com/openstack/python-moganclient

--
Best Regards,
Zhenguo Niu


__
OpenStack Development Mailing 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] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Zhenguo Niu]

hi all,

I'm from the Mogan team, we chose the same keyward 'baremetal' when
implementing a OSC plugin [1]. As we think the baremetal command is
representative of a baremetal resource, not a service, so it makes sense
for different projects to share the top level resource name that OpenStack
can provide.

The commands we have implemented are listed below, seems there's no
collision with Ironic presently, and Ironic doesn't manage such resources.

* openstack baremetal server  
* openstack bareemtal flavor  
* openstack baremetal keypair  
* openstack baremetal availability zone  

So, we'd like to ask if our CLI pattern is allowed before we release the
client.

Thanks in advance!


[1] https://github.com/openstack/python-moganclient

-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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] [meteos] Meteos Weekly Meeting

[Hiroyuki]

Hello Meteos Team and All,

Meteos IRC weekly meeting will be held at May.30 Tuesday 13:00-14:00 JST 
(09:30-10:30 IST).




 - Tensorflow implementation
 - Pike release schedule

If you  have other topics to be discussed in the weekly meeting, please 
let me know.

Meteos is very young project,we welcome your question or comment.



http://webchat.freenode.net/?channels=openstack-meteos

Thanks
Hiroyuki

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