[openstack-dev] [Blazar] new instance reservation overview

2017-04-10 Thread Masahito MUROI

Hi Blazar folks,

I drafted overview of new instance reservation [1]. It contains  
motivation and basic idea of the reservation, short-term goal and  
long-term goal.


It's just a draft and entry points for the discussion. We would also  
discuss some reservations things based on the etherpad at Boston Forum.  
So feel free to add your comments.


1. https://etherpad.openstack.org/p/new-instance-reservation

best regards,
Masahito



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


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

2017-04-10 Thread Sean McGinnis
On Mon, Apr 10, 2017 at 03:40:30PM -0500, Matt Riedemann wrote:
> 
> I don't attend many TC meetings, it's usually on accident, but yeah, when I
> do I always note the flurry of cross-talk chatter that just drowns
> everything out. I feel like there are usually at least 3 parallel
> conversations going on during a TC meeting and it's pretty frustrating to
> follow along, or get a thought in the mix. That has to be much worse for a
> non-native English speaker.
> 
> So yeah, slow down folks. :)
> 
 Slowing down is something I never really thought of until I started getting
out and talking to contributors in non-native English speaking areas, and
I'm afraid I still haven't done a good job in the Cinder meetings of slowing
things down. I think this is a good tip for all of us!

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


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

2017-04-10 Thread Sean McGinnis
On Mon, Apr 10, 2017 at 11:16:57AM +0200, Thierry Carrez wrote:
> 
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ?

Starting today, I've moved from a position from where I've spent a lot of time
focused on OpenStack because that's where I've wanted to, to a position where
focusing on OpenStack _is_ my full time focus.

I'm sure the needed time will fluctuate, but I will have the time to dedicate
as needed.

> If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

Communication would be my focus. Both making sure TC initiatives get
communicated out to project teams, as well as trying to open communication
out to communities outside of OpenStack.
> 
> Thanks in advance for your answers !
> 
> -- 
> 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] [tc] [elections] Available time and top priority

2017-04-10 Thread Joshua Hesketh
Howdy,

To answer the original question, if elected, I should be able to commit at
least a few hours per day to the TC (if not more). I can also be quite
elastic in this being able to spend more time some weeks than others as the
role dictates.

My timezone is UTC+10 which makes the meetings at 6am. While not ideal I
can attend these meetings. I do, however, agree with the general discussion
about ensuring the meetings are accessible to all and would support an
alternating meeting time to make it easier for others to participate.

If elected to the TC I would like to help focus on strengthening our
engagement with neighbouring communities. To do this we need to solidify
our vision so that we better understand what role we play in the open cloud
world and how we can both leverage other projects and also give them a
platform to build upon. I want to see the core services continue to become
more stable and consistent to allow other applications, not even
necessarily within the OpenStack ecosystem, to build upon them. I am
excited by the draft version of the vision that has been set forward and I
want to do what I can to help us work towards that.

Cheers,
Josh

On Mon, Apr 10, 2017 at 7:16 PM, Thierry Carrez 
wrote:

> Hi everyone,
>
> New in this TC election round, we have a few days between nominations
> and actual voting to ask questions and get to know the candidates a bit
> better. I'd like to kick off this new "campaigning period" with a basic
> question on available time and top priority.
>
> All the candidates are top community members with a lot of
> responsibilities on their shoulders already. My experience tells me that
> it is easy to overestimate the time we can dedicate to Technical
> Committee matters, and how much we can push and get done in six months
> or one year. At the same time, our most efficient way to make progress
> is always when someone "owns" a particular initiative and pushes it
> through the governance process.
>
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ? If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?
>
> Thanks in advance for your answers !
>
> --
> 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] [tc] [elections] Available time and top priority

2017-04-10 Thread joehuang
> When there are topics with a lot of people clamoring to talk, Thierry usually 
> lets people speak in order of "raising 
> their hand". This reduces cross-talk and lets everyone get their turn to 
> state what's on their mind. 

+1, impressive for the "raising their hand" in TC weekly IRC meeting :), 
especially  during Tricircle's big-tent application discussion.

Best Regards
Chaoyi Huang (joehuang)


From: Ed Leafe [e...@leafe.com]
Sent: 11 April 2017 5:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] [elections] Available time and top priority

On Apr 10, 2017, at 3:40 PM, Matt Riedemann  wrote:
>
> I don't attend many TC meetings, it's usually on accident, but yeah, when I 
> do I always note the flurry of cross-talk chatter that just drowns everything 
> out. I feel like there are usually at least 3 parallel conversations going on 
> during a TC meeting and it's pretty frustrating to follow along, or get a 
> thought in the mix. That has to be much worse for a non-native English 
> speaker.
>
> So yeah, slow down folks. :)

When there are topics with a lot of people clamoring to talk, Thierry usually 
lets people speak in order of "raising their hand". This reduces cross-talk and 
lets everyone get their turn to state what's on their mind. Normally, though, 
it is a bit of an acquired skill to be able to follow along.

-- Ed Leafe






__
OpenStack Development Mailing 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] How to get all detail RPC message and detail context in neutron docs?

2017-04-10 Thread Kevin Benton
I would strongly recommend that you don't build anything based on these
messages. The contents change from release to release since this is an
internal API between the agents and the server.

On Apr 6, 2017 00:48, "Sam"  wrote:

> Thank you, use debug option will also help us to get detail of RPC
> message, good luck~
>
> 2017-04-06 14:20 GMT+08:00 김기석 [Kiseok Kim] :
>
>> Sam,
>>
>>
>>
>> I have no idea whether or not the document exists. (I want to read too)
>>
>>
>>
>> about L3 RPC messages(L3_AGENT topic), its client-side is implemented in
>> l3_router_plugin.[1]
>>
>> There is an oslo_meessaging document.[2] I guess it would help.
>>
>>
>>
>> [1] https://github.com/openstack/neutron/blob/master/neutron/api
>> /rpc/agentnotifiers/l3_rpc_agent_api.py#L37
>>
>> [2] https://docs.openstack.org/developer/oslo.messaging/
>>
>>
>>
>> good luck!
>>
>>
>>
>> *From:* Sam [mailto:batmanu...@gmail.com]
>> *Sent:* Thursday, April 06, 2017 10:56 AM
>> *To:* 김기석 [Kiseok Kim]
>> *Cc:* OpenStack General; OpenStack Development Mailing List (not for
>> usage questions)
>> *Subject:* Re: [Openstack] How to get all detail RPC message and detail
>> context in neutron docs?
>>
>>
>>
>> For example, detail of the messages of topics.L3_AGENT
>>
>>
>>
>> 2017-04-06 9:38 GMT+08:00 Sam :
>>
>> Thank you all.
>>
>>
>>
>> For 'context', I got it.
>>
>> For RPCs, is there some document or blog or some debug method to get its
>> detal contains in neutron L3 Agent?
>>
>>
>>
>> 2017-04-06 9:33 GMT+08:00 김기석 [Kiseok Kim] :
>>
>> Hi Sam,
>>
>>
>>
>> that 'context' is olso_context and neutron use it with addition
>> attributes.
>>
>>
>>
>> oslo.context has to_dict method,
>>
>> so you could add debug log in 'agent_updated' method like:
>>
>>
>>
>>LOG.debug("context in agent_updated: %s", context.to_dict())
>>
>>
>>
>> and you can find out the attributes of context in
>>
>> https://github.com/openstack/neutron-lib/blob/master/neutron
>> _lib/context.py#L83-L92,
>>
>> https://github.com/openstack/oslo.context/blob/master/oslo_c
>> ontext/context.py#L310-L332
>>
>> .
>>
>>
>>
>> *From:* Sam [mailto:batmanu...@gmail.com]
>> *Sent:* Wednesday, April 05, 2017 7:10 PM
>> *To:* OpenStack General; OpenStack Development Mailing List (not for
>> usage questions)
>> *Subject:* [Openstack] How to get all detail RPC message and detail
>> context in neutron docs?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I'm working on neutron L3 Agent and some other Agent. I found that there
>> are lots of RPCs including RPC call and notification and lots of 'context'
>> as bellow. But I don't know its detail context, can I get these from some
>> docs?
>>
>>
>>
>> If there are no docs, could I get these using some debug method? Like
>> '--debug' option or using pdb or something?
>>
>>
>>
>> RPC: like 'agent_updated' in neutron/neutron/agent/l3/agent.py Line759.
>>
>>
>>
>> context: it's param in some function like 'def
>> router_added_to_agent(self, context, payload):' in
>> neutron/neutron/agent/l3/agent.py.
>>
>>
>>
>>
>>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
__
OpenStack Development Mailing 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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

2017-04-10 Thread Kevin Benton
I think 'a' is probably the way to go since we can mainly rely on existing
horizon guides for creating new dashboard repos.

On Apr 10, 2017 08:11, "Akihiro Motoki"  wrote:

> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
>
> I would like to raise this topic again. No dashboard support lands since
> then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>
> Possible approaches
> 
>
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
>
> Which one sounds better?
>
> Pros and Cons
> 
>
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
>
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
>
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium
> inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another
> implementation.
>
>
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a
> repo).
>
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months
> ago.
> As an example, trunk support is being development in the horizon repo.
>
> Thanks,
> Akihiro
>
> __
> OpenStack Development Mailing 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] [stable] What's the plan for mitaka-eol?

2017-04-10 Thread Tony Breeds
On Mon, Apr 10, 2017 at 04:19:00PM -0500, Matt Riedemann wrote:
> There was no stable team meeting today but according to the release schedule
> page [1], Mitaka EOL happens after today. So what's the plan? Same old song
> and dance as always?

Yup.  I'm generating the list of EOL'able repos today.

> Also, while I'm here, should the stable team meeting be cancelled? There
> hasn't been a meeting in a month [2]. Should we cancel the meeting and just
> use the mailing list for any needed communication?

Yeah I think that's fair.  I've been on medical leave for a wheil but not 2 
months.

Yours Tony.


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


Re: [openstack-dev] [stable] What's the plan for mitaka-eol?

2017-04-10 Thread gordon chung


On 10/04/17 05:19 PM, Matt Riedemann wrote:
> There was no stable team meeting today but according to the release
> schedule page [1], Mitaka EOL happens after today. So what's the plan?
> Same old song and dance as always?
>

i abandoned all the stable/mitaka items in Telemetry projects. 
maintaining two stable branches is enough work already. i'll let someone 
else raise complaints on those patches if critical. :)

cheers,

-- 
gord
__
OpenStack Development Mailing 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] [stable] What's the plan for mitaka-eol?

2017-04-10 Thread Ihar Hrachyshka
Yes, please cancel.

I don't even see at this point a need for a separate program for the
effort. It was applicable before when we dealt with stable gates on daily
basis, but it's no longer the case.

Ihar

On Mon, Apr 10, 2017 at 2:19 PM Matt Riedemann  wrote:

> There was no stable team meeting today but according to the release
> schedule page [1], Mitaka EOL happens after today. So what's the plan?
> Same old song and dance as always?
>
> Also, while I'm here, should the stable team meeting be cancelled? There
> hasn't been a meeting in a month [2]. Should we cancel the meeting and
> just use the mailing list for any needed communication?
>
> [1] https://releases.openstack.org/
> [2] http://eavesdrop.openstack.org/meetings/stable/2017/
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2017-04-10 Thread Amrith Kumar


> -Original Message-
> From: Matt Riedemann [mailto:mriede...@gmail.com]
> Sent: Monday, April 10, 2017 4:41 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc] [elections] Available time and top priority
> 
> On 4/10/2017 2:55 PM, Dean Troyer wrote:
> >
> > The TC meetings are held in IRC and that may somewhat mitigate the
> > issue for non-native English speakers, but I've had problems myself
> > keeping up at times with the flurry of comments.  In any case, I think
> > it would be good to include language in the pile of concerns over
> > world-wide participation
> 
> I don't attend many TC meetings, it's usually on accident, but yeah, when I
> do I always note the flurry of cross-talk chatter that just drowns everything
> out. I feel like there are usually at least 3 parallel conversations going on
> during a TC meeting and it's pretty frustrating to follow along, or get a
> thought in the mix. That has to be much worse for a non-native English
> speaker.
> 
> So yeah, slow down folks. :)

[Amrith Kumar] A huge +1000 to that. I have found it very hard to follow the 
conversations of the TC and some months back (may be over a year back) there 
was a meeting where someone had to explicitly ask for people to stop the 
wisecracking. Just unwinding the multiple conversations from last week's 
meeting where I was trying to have parallel conversations with several people 
on a proposal I had before the meeting was very challenging. The challenge this 
must face for people who don't natively think in English is something I can 
hardly imagine.

It may not be a bad idea to have TC meetings be moderated and where people who 
wish to speak must be recognized and the floor yielded to them. It will be 
different, but I think it can work.

> 
> I'm not advocating splitting the meetings though. It's possible to have your
> cake and eat it to if done properly. For example, Alex Xu runs the Nova API
> subteam meeting and we have people from China, India, Japan, UK and USA and
> get through it fine, but it does involve slowing down to get an
> acknowledgement from people that they are OK with any decisions being made.
> 

[Amrith Kumar] I think the answer lies more in having the discussions in mail, 
on the mailing list and reserving the TC meeting for the actual vote. By 
framing the meeting more as a procedural mechanism, one can even allow for 
offline voting and then the time of the meeting becomes less important.

To be truly welcoming of a distributed community, I think this approach would 
be way better.

> This might also tie back in with what cdent was mentioning, and if the flurry
> of conversation during a TC meeting throws people off, maybe the minutes
> should be digested after the meeting in the mailing list. I know the meeting
> is logged, but it can be hard to read through that without one's eyes glazing
> over due to the cross-talk and locker-room towel whipping going on.
> 
> --
> 
> 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

--
Amrith Kumar


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


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

2017-04-10 Thread Ed Leafe
On Apr 10, 2017, at 3:40 PM, Matt Riedemann  wrote:
> 
> I don't attend many TC meetings, it's usually on accident, but yeah, when I 
> do I always note the flurry of cross-talk chatter that just drowns everything 
> out. I feel like there are usually at least 3 parallel conversations going on 
> during a TC meeting and it's pretty frustrating to follow along, or get a 
> thought in the mix. That has to be much worse for a non-native English 
> speaker.
> 
> So yeah, slow down folks. :)

When there are topics with a lot of people clamoring to talk, Thierry usually 
lets people speak in order of "raising their hand". This reduces cross-talk and 
lets everyone get their turn to state what's on their mind. Normally, though, 
it is a bit of an acquired skill to be able to follow along.

-- Ed Leafe







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


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

2017-04-10 Thread Chris Dent

On Mon, 10 Apr 2017, Matt Riedemann wrote:

This might also tie back in with what cdent was mentioning, and if the flurry 
of conversation during a TC meeting throws people off, maybe the minutes 
should be digested after the meeting in the mailing list. I know the meeting 
is logged, but it can be hard to read through that without one's eyes glazing 
over due to the cross-talk and locker-room towel whipping going on.


Aw, you beat me to it. This is part of what I was going to say in
response to your earlier message. I think there are at least three
things to do, all of which you've touched on:

* Alternating the meetings, despite the issues with quorum, probably
  ought to happen. If the issues with quorum are insurmountable that
  may say something important about the TC's choice to be dependent
  on IRC meetings. Is it habit? Doesn't most of the real voting
  happen in gerrit? Can more of the discussion happen in email? I
  think we (by we I mean all of OpenStack) can and should rely on
  email more than we do expressly for the purpose of enabling people
  to include themselves according to their own schedules and their
  own speeds of comprehension.

  Email and writing in general is by no means a panacea. We don't
  want any of email, IRC, voice or expensive international
  gatherings to be the sole mode of interaction.

* People who are participating in the TC meetings can be much more
  considerate, at least during critical parts of the meeting, about
  who has the speaking stick and what the current topic happens to
  be. Sometimes the cross-talk and the towel whipping is exactly
  what needs to be happening, but much of the time it is not and
  makes it all very hard to follow and frustrating. We see a lot of
  behavior in the channel that if we were in person or on the phone
  would be completely unacceptable. Each communication medium
  affords different behaviors, but we still want to manage to
  understand one another. As you say, Alex does a great job of
  making the nova api subteam meeting work so there's probably
  something we can learn from there.

* Digested minutes of the meeting and any pending business
  in gerrit can give an additional way to stay in the loop but they
  are more about providing an invitation or encouragement to
  participate. It shouldn't be a substitute that's there because the
  real grind of participation is inaccessible. Participation needs
  to be more accessible.

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [stable] What's the plan for mitaka-eol?

2017-04-10 Thread Matt Riedemann
There was no stable team meeting today but according to the release 
schedule page [1], Mitaka EOL happens after today. So what's the plan? 
Same old song and dance as always?


Also, while I'm here, should the stable team meeting be cancelled? There 
hasn't been a meeting in a month [2]. Should we cancel the meeting and 
just use the mailing list for any needed communication?


[1] https://releases.openstack.org/
[2] http://eavesdrop.openstack.org/meetings/stable/2017/

--

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] Ocata - Ubuntu 16.04 - OVN does not work with DPDK

2017-04-10 Thread Martinx - ジェームズ
On 8 April 2017 at 00:37, Martinx - ジェームズ  wrote:

> Guys,
>
>  I manage to deploy Ocata on Ubuntu 16.04 with OVN for the first time
> ever, today!
>
>  It looks very, very good... OVN L3 Router is working, OVN DHCP working...
> bridge mappings "br-ex" on each compute node... All good!
>
>  Then, I've said: time for DPDK!
>
>  I manage to use OVS with DPDK easily on top of Ubuntu (plus Ocata Cloud
> Archive) with plain KVM, no OpenStack, so, I have experience about how to
> setup DPDK, OVS+DPDK, Libvirt vhostuser, KVM and etc...
>
>  After configuring DPDK on a compute node, I tried the following
> instructions:
>
>  https://docs.openstack.org/developer/networking-ovn/dpdk.html
>
>  It looks quite simple!
>
>  To make things even simpler, I have just 1 controller, and 1 compute
> node, to begin with, before enabling DPDK at the compute node and changing
> the "br-int" datapath, I deleted all OVN Routers and all Neutron Networks
> and Subnets, that was previously working with regular OVS (no DPDK).
>
>  Then, after enabling DPDK and updating the "br-int" and the "br-ex"
> interfaces, right after connecting the "OVN L3 Router" into the "ext-net /
> br-ex" network, the following errors appeared on OpenvSwitch logs of the
> related compute node (OpenFlow error):
>
>
>  * After connecting OVN L3 Router against the "ext-net / br-ex" Flat /
> VLAN Network:
>
>  ovs-vswitchd.log:
>
>  http://paste.openstack.org/show/605800/
>
>  ovn-controller.log:
>
>  http://paste.openstack.org/show/605801/
>
>
>  Also, after connecting the OVN L3 Router into the local (GENEVE) network,
> very similar error messages appeared on OpenvSwitch logs...
>
>
>  * After connecting OVN L3 Router on a "local" GENEVE Network:
>
>  ovs-vswitchd.log:
>
>  http://paste.openstack.org/show/605804/
>
>  ovn-controller.log:
>
>  http://paste.openstack.org/show/605805/
>
>
>  * Output of "ovs-vsctl show" at the single compute node, after plugging
> the OVN L3 Router against the two networks (external / GENEVE):
>
>  http://paste.openstack.org/show/605806/
>
>
>  Then, I tried to launch an Instance anyway and, for my surprise, the
> Instance was created! Using vhostuser OVS+DPDK socket!
>
>  Also, the Instance got its IP! Which is great!
>
>  However, the Instance can not ping its OVN L3 Router (its default
> gateway), with or without any kind of security groups applied, no deal...
> :-(
>
>  BTW, the Instance did not received the ARP stuff of the OVN L3 Router, I
> mean, for the instance, the gateway IP on "arp -an" shows "".
>
>
>  * The ovs-vswitchd.log after launching an Instance on top of OVN/OVS+DPDK:
>
>  http://paste.openstack.org/show/605807/
>
>  * The output of "ovs-vsctl show" after launching the above instance:
>
>  http://paste.openstack.org/show/605809/ - Line 33 is the dpdkvhostuser
>
>
>  Just to give another try, I started a second Instance, to see if the
> Instances can ping each other... Also did not worked, the Instances can not
> ping each other.
>
>
>  So, from what I'm seeing, OVN on top of DPDK does not work.
>
>  Any tips?
>
>
>  NOTE:
>
>  I tried to enable "hugepages" on my OpenStack's flavor, just in case...
> Then, I found another bug, it doesn't even boot the Instance:
>
>  https://bugs.launchpad.net/cloud-archive/+bug/1680956
>
>
>  For now, I'll deploy Ocata with regular OVN, no DPDK, but, my goal with
> this cloud is for high performance networks, so, I need DPDK, and I also
> need GENEVE and Provider Networks, everything on top of DPDK.
>
> ---
>  After researching more about this "high perf networks", I found this:
>
>  * DPDK-like performance in Linux kernel with XDP !
>
>  http://openvswitch.org/support/ovscon2016/7/0930-pettit.pdf
>
>  https://www.iovisor.org/technology/xdp
>  https://www.iovisor.org/technology/ebpf
>
>  https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/
>
>  But I have no idea about how to use OpenvSwitch with this thing, however,
> if I can achieve DPDK-Like performance, without DPDK, using just plain
> Linux, I'm a 100% sure that I'll prefer it!
>
>  I'm okay to give OpenvSwitch + DPDK another try, even knowing that it
> [OVS] STILL have serious problems (https://bugs.launchpad.net/
> ubuntu/+source/openvswitch/+bug/1577088)...
> ---
>
>  OpenStack on Ubuntu rocks!   :-D
>
> Thanks!
> Thiago
>

I just realized how cool IO Visor is!

Sorry about mixing subjects, let's keep this one clear for OVN on top of
DPDK.

I found a opened bug on RedHat's Bugzilla, I updated it with the info from
this e-mail:

https://bugzilla.redhat.com/show_bug.cgi?id=1410565

Looks like that, OVN doc say that it is supported on top of any OpenvSwitch
Datapath but, it is not the case... Right?

I would be happy to be able to use GENEVE on top of regular Linux datapath,
and only Provider Networks on top of DPDK but, it also doesn't work. I'll
post more details about this later.

Cheers!
Thiago
__

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

2017-04-10 Thread Matt Riedemann

On 4/10/2017 2:55 PM, Dean Troyer wrote:


The TC meetings are held in IRC and that may somewhat mitigate the
issue for non-native English speakers, but I've had problems myself
keeping up at times with the flurry of comments.  In any case, I think
it would be good to include language in the pile of concerns over
world-wide participation


I don't attend many TC meetings, it's usually on accident, but yeah, 
when I do I always note the flurry of cross-talk chatter that just 
drowns everything out. I feel like there are usually at least 3 parallel 
conversations going on during a TC meeting and it's pretty frustrating 
to follow along, or get a thought in the mix. That has to be much worse 
for a non-native English speaker.


So yeah, slow down folks. :)

I'm not advocating splitting the meetings though. It's possible to have 
your cake and eat it to if done properly. For example, Alex Xu runs the 
Nova API subteam meeting and we have people from China, India, Japan, UK 
and USA and get through it fine, but it does involve slowing down to get 
an acknowledgement from people that they are OK with any decisions being 
made.


This might also tie back in with what cdent was mentioning, and if the 
flurry of conversation during a TC meeting throws people off, maybe the 
minutes should be digested after the meeting in the mailing list. I know 
the meeting is logged, but it can be hard to read through that without 
one's eyes glazing over due to the cross-talk and locker-room towel 
whipping going on.


--

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] [Openstack-operators] FW: [quotas] Unified Limits Conceptual Spec RFC

2017-04-10 Thread Lance Bragstad
Sending out a heads up that the initial spec [0] merged.

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

On Thu, Mar 30, 2017 at 1:44 PM, Tim Bell  wrote:

>
> For those that are interested in nested quotas, there is proposal on how
> to address this forming in openstack-dev (and any comments on the review
> should be made to https://review.openstack.org/#/c/363765).
>
> This proposal has the benefits (if I can summarise) that
>
> - Quota limits will be centrally managed in Keystone so the quota data
> will be close to the project for creation/deletion/admin.
> - The usage data remains within each project avoiding dependencies and
> risks of usage data getting out of sync.
> - With a central store for quotas, there is increased opportunity for
> consistency. Given the complexity of quotas and nested projects, this would
> improve operator and end user understanding. The exact model is still for
> confirmation though.
>
> We’ll have a forum discussion (http://forumtopics.openstack.
> org/cfp/details/9) in Boston too but feel free to give input to
> https://review.openstack.org/#/c/363765 so we can use Boston as the
> opportunity to agree on the approach and next steps.
>
> Tim
>
> On 30.03.17, 19:52, "Sean Dague"  wrote:
>
> The near final draft of the unified limits spec is up now -
> https://review.openstack.org/#/c/440815/
>
> If you have not yet wandered in, now is the time, we're going to make
> the final go / no go the end of this week.
>
> -Sean
>
> On 03/17/2017 06:36 AM, Sean Dague wrote:
> > Background:
> >
> > At the Atlanta PTG there was yet another attempt to get hierarchical
> > quotas more generally addressed in OpenStack. A proposal was put
> forward
> > that considered storing the limit information in Keystone
> > (https://review.openstack.org/#/c/363765/). While there were some
> > concerns on details that emerged out of that spec, the concept of the
> > move to Keystone was actually really well received in that room by a
> > wide range of parties, and it seemed to solve some interesting
> questions
> > around project hierarchy validation. We were perilously close to
> having
> > a path forward for a community request that's had a hard time making
> > progress over the last couple of years.
> >
> > Let's keep that flame alive!
> >
> >
> > Here is the proposal for the Unified Limits in Keystone approach -
> > https://review.openstack.org/#/c/440815/. It is intentionally a high
> > level spec that largely lays out where the conceptual levels of
> control
> > will be. It intentionally does not talk about specific quota models
> > (there is a follow on that is doing some of that, under the
> assumption
> > that the exact model(s) supported will take a while, and that the
> > keystone interfaces are probably not going to substantially change
> based
> > on model).
> >
> > We're shooting for a 2 week comment cycle here to then decide if we
> can
> > merge and move forward during this cycle or not. So please
> > comment/question now (either in the spec or here on the mailing
> list).
> >
> > It is especially important that we get feedback from teams that have
> > limits implementations internally, as well as any that have started
> on
> > hierarchical limits/quotas (which I believe Cinder is the only one).
> >
> > Thanks for your time, and look forward to seeing comments on this.
> >
> >   -Sean
> >
>
>
> --
> Sean Dague
> http://dague.net
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2017-04-10 Thread Monty Taylor

On 04/10/2017 01:52 PM, Matt Riedemann wrote:

On 4/10/2017 1:18 PM, Chris Dent wrote:

On Mon, 10 Apr 2017, Thierry Carrez wrote:


So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ?


I've been regularly reviewing changes in the governance repo and
attending the weekly TC meeting for well over a year now. Increasing
that commitment to include shepherding new initiatives, either ones
I start myself or work on in concert with others, is why I'm running
for the TC and I wouldn't be doing so if I didn't think I had the
time and energy to support that.

Making a specific prediction on how much time that will take is
challenging; some weeks will take more time than others. I intend to
do what's needed to do the job well.


If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?


Just ONE initiative is difficult because from my perspective what
matters is that whatever initiatives happen to be in progress, they
are transparent, inclusive and actually make some kind of
difference. But since ONE is the request:

My hallmark complaint with the TC since I was first aware of it has
been that, often, resolutions or plans can emerge from the TC so
late in their development that engaging them in a way that allows
consideration of completely different options is hard. Hard for a
variety of reasons; one is that it can feel a bit rude to criticize
a complete seeming idea that someone clearly put a lot of effort
into. This means discussion proceeds as an evaluation of the
proposal rather than as analysis of the root causes of the problems
to be solved or the full consequences of the goals being described.

This situation has improved over the years, I think there is at
least increased awareness, and some concrete efforts to allow people
to be involved, but we can do more to make it easier and lighter.

I would prefer that the TC's constituency was more actively made
aware of pending work and ongoing debates prior to the creation of
resolutions (even if WIP) in gerrit or having big sessions at the
Forum.  One way to do this would be to follow the growing trend of
weekly newsletters and updates and do one for the TC. I recall this
was tried (in the form of blog posts, and to some extent in response
to my prompting) a while back, but didn't really take off. I
wonder if that format was too heavyweight?

I'm proud of having played a part in the newsletter trend and I
think the results for the API-WG and the placement project have been
very positive. Doing something similar for the TC -- in a
lightweight, just-the-highlights kind of way -- is something I could
do (I hope with the occasional help of the rest of the TC) and is
something I think would be useful. With luck the newsletter would
operate as a catalyst around which casual discussion and idea
sharing would accrete.

What I hope would happen as a result is that people would feel more
aware of and able to participate in the discussion and processes
working to shape the future of OpenStack.



__

OpenStack Development Mailing 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 Chris. This reminded me of something I wanted to ask about, to
all TC members, or those running for a seat.

Lots of projects have alternating meeting times to accommodate
contributors in different time zones, especially Europe and Asia.

The weekly TC meeting, however, does not.

I have to assume this has come up before and if so, why hasn't the TC
adopted an alternating meeting schedule?

For example, it's 4am in Beijing when the TC meeting happens. It's
already hard to get people from Asia into leadership roles within
projects and especially across the community, in large part because of
the timezone barrier.

How will the TC grow a diverse membership if it's not even held, at
least every other week, in a timezone where the other half of the world
can attend?



I think this is a great question, and one that I believe to be 
fundamentally important.


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


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

2017-04-10 Thread Dean Troyer
On Mon, Apr 10, 2017 at 1:52 PM, Matt Riedemann  wrote:
> How will the TC grow a diverse membership if it's not even held, at least
> every other week, in a timezone where the other half of the world can
> attend?

This is something we do need to sort out. The experiences I have seen
with a number of other meetings that do the alternating time is you
mostly get attendees showing up during their 'local' time slot. This
of course is not how the TC operates, requiring a quorum, and holding
in-meeting votes at times.  I do think that my experience is not
representative of meetings attended by elected members.  Also, we
already ask our close-to-UTC-TZ members to give up evening time
(family time for many) for the meetings.  It might be worthwhile to
look at more than two times for alternation.

There is an additional question around language.  The board has seen
where some members may not be comfortable in a non-native language
meeting and may not speak up like they might otherwise.  The current
board makeup is such that regional meetings (not official board
meetings) in Chinese have become feasible and the feedback is that the
participation is much greater for those in attendance.

The TC meetings are held in IRC and that may somewhat mitigate the
issue for non-native English speakers, but I've had problems myself
keeping up at times with the flurry of comments.  In any case, I think
it would be good to include language in the pile of concerns over
world-wide participation

(I read ahead)  Dims mentions personal conversations with some backing
away from running for the TC due to the meeting time, I wonder how
much language has been a factor for others?

dt

-- 

Dean Troyer
dtro...@gmail.com

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


Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Matt Riedemann

On 4/10/2017 11:14 AM, Monty Taylor wrote:

On 04/10/2017 10:37 AM, Monty Taylor wrote:

On 04/10/2017 09:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki 
wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.


I agree - I think it is not important for horizon to support backward
compat - it's most commonly deployed with a cloud, so one expects it to
support the software in the cloud in question.


However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.


Similarly, shade intends to support nova-net for as long as shade
exists. We have already re-implemented most of nova-net support with
direct calls as part of our current project to delete use of
python-*client.



It turns out there are humans out there who are consuming old clouds -
and end-user client tools should be supporting those humans, even when
the current releases of OpenStack deprecate/remove things.


Quick clarification ...

When I say "shade intends to support nova-net" - I mean a specific thing
that is almost certainly not what you might at first assume.

From the beginning, shade has hidden the nova-net/neutron difference -
but shade is focused on the end-user primarily. This means the
difference is "do you use nova or neutron API to deal with floating IPs
and security groups" We do not expose any nova-net functionality
directly - we expose FIPs and Security Groups, and we hide from the user
what service provides them.

We will continue to do that to the best of our ability - although
functional testing in devstack will have to give way to only
requests-mock based testing once we don't have old stable branches that
can install nova-net.

I may have also given the impression that I'm unhappy about novaclient
dropping support - which is also not the case. I am firmly of the
opinion that python-*client do not have end-users of OpenStack clouds as
primary users in mind. The release model and design just isn't right for
that. They are clearly, to me, designed to aid intra-service
communication. As such, I think it's 100% appropriate for novaclient to
have dropped nova-net support.

I, for one, welcome all things about the removal of nova-net, and I am
quite happy to do the support actions in shade.

__
OpenStack Development Mailing 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 for the clarification and continuing to keep end users in mind.

--

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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Matt Riedemann

On 4/10/2017 1:51 PM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 10:19 AM, Matt Riedemann  wrote:

How long are we expected to be carrying this deprecated bridge code? If you
need these CLIs/API bindings in the client, then don't upgrade to 8.0.0, or
run different versions of novaclient in venvs or containers if you need to
really workaround this.


Oh how I wish this were as easy in practice as it sounds.


I feel like the signaling on all of this was pretty clear back in Newton.
What else are people expecting or that we missed? I don't really see why
python-openstackclient needs to start adding this API binding code back in
locally, that's just extending the lifespan of this busted code that we're
really trying to make uncomfortable for people to be using because like it
or not, nova-network is going away. We did the fallback thing in the CLI in
newton as a way to soften that blow for CLI users, but really at some point
this just needs to be broken and people either stay on old tools or upgrade
to what is supported.


Matt, I am not questioning the signalling nor the actual removal, that
is the right thing for novaclient at some point.  I did miss the early
indications of the timing of 8.0, only seeing it two weeks before the
release, but that is on me.

The fact that this causes us problems is not your problem, but
highlights why OSC and Shade and other things really do not want to
use the project clients because the use cases and assumptions and
other things are different.  I started 3 years ago to start replacing
those things, the SDK came long to replace that work but is still not
at a 1.0 release.  So I'm playing catch-up.

Upgrading old nova-net clouds has been deemed impossible, which is why
we don't do it.  But you might be unhappy about the removal of py27
from distros just yet, as not all of OpenStack is py3 ready.  We
should just upgrade all that code...

dt



Thanks for the clarification Dean. I was obviously a bit defensive and I 
apologize for that.


--

Thanks,

Matt

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


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

2017-04-10 Thread German Eichberger
Agreed but not only for the TC. I also heard privately from some contributors 
that meetings times prevent them from fully engage with a project. This is 
something where we as the TC can lead by example.

German

On 4/10/17, 3:06 PM, "Davanum Srinivas"  wrote:

Matt,

I second this request. At least one person i talked to, pointed this
as a primary reason for not standing for the TC election.

Thanks,
Dims

On Mon, Apr 10, 2017 at 2:52 PM, Matt Riedemann  wrote:
> On 4/10/2017 1:18 PM, Chris Dent wrote:
>>
>> On Mon, 10 Apr 2017, Thierry Carrez wrote:
>>
>>> So my question is the following: if elected, how much time do you think
>>> you'll be able to dedicate to Technical Committee affairs (reviewing
>>> proposed changes and pushing your own) ?
>>
>>
>> I've been regularly reviewing changes in the governance repo and
>> attending the weekly TC meeting for well over a year now. Increasing
>> that commitment to include shepherding new initiatives, either ones
>> I start myself or work on in concert with others, is why I'm running
>> for the TC and I wouldn't be doing so if I didn't think I had the
>> time and energy to support that.
>>
>> Making a specific prediction on how much time that will take is
>> challenging; some weeks will take more time than others. I intend to
>> do what's needed to do the job well.
>>
>>> If there was ONE thing, one
>>> initiative, one change you will actively push in the six months between
>>> this election round and the next, what would it be ?
>>
>>
>> Just ONE initiative is difficult because from my perspective what
>> matters is that whatever initiatives happen to be in progress, they
>> are transparent, inclusive and actually make some kind of
>> difference. But since ONE is the request:
>>
>> My hallmark complaint with the TC since I was first aware of it has
>> been that, often, resolutions or plans can emerge from the TC so
>> late in their development that engaging them in a way that allows
>> consideration of completely different options is hard. Hard for a
>> variety of reasons; one is that it can feel a bit rude to criticize
>> a complete seeming idea that someone clearly put a lot of effort
>> into. This means discussion proceeds as an evaluation of the
>> proposal rather than as analysis of the root causes of the problems
>> to be solved or the full consequences of the goals being described.
>>
>> This situation has improved over the years, I think there is at
>> least increased awareness, and some concrete efforts to allow people
>> to be involved, but we can do more to make it easier and lighter.
>>
>> I would prefer that the TC's constituency was more actively made
>> aware of pending work and ongoing debates prior to the creation of
>> resolutions (even if WIP) in gerrit or having big sessions at the
>> Forum.  One way to do this would be to follow the growing trend of
>> weekly newsletters and updates and do one for the TC. I recall this
>> was tried (in the form of blog posts, and to some extent in response
>> to my prompting) a while back, but didn't really take off. I
>> wonder if that format was too heavyweight?
>>
>> I'm proud of having played a part in the newsletter trend and I
>> think the results for the API-WG and the placement project have been
>> very positive. Doing something similar for the TC -- in a
>> lightweight, just-the-highlights kind of way -- is something I could
>> do (I hope with the occasional help of the rest of the TC) and is
>> something I think would be useful. With luck the newsletter would
>> operate as a catalyst around which casual discussion and idea
>> sharing would accrete.
>>
>> What I hope would happen as a result is that people would feel more
>> aware of and able to participate in the discussion and processes
>> working to shape the future of OpenStack.
>>
>>
>>
>> 
__
>> OpenStack Development Mailing 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 Chris. This reminded me of something I wanted to ask about, to all 
TC
> members, or those running for a seat.
>
> Lots of projects have alternating meeting times to accommodate 
contributors
> in different time zones, especially Europe and Asia.
>
> The weekly TC meeting, however, does not.
>
> I have to assume this has come up before and if so, why hasn't the TC
> adopted an alternating meeting schedule?
>
> For example, it's 4am in Beijing when 

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

2017-04-10 Thread Edward Leafe
On Apr 10, 2017, at 1:52 PM, Matt Riedemann  wrote:
> 
> How will the TC grow a diverse membership if it's not even held, at least 
> every other week, in a timezone where the other half of the world can attend?

+1

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


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

2017-04-10 Thread Davanum Srinivas
Matt,

I second this request. At least one person i talked to, pointed this
as a primary reason for not standing for the TC election.

Thanks,
Dims

On Mon, Apr 10, 2017 at 2:52 PM, Matt Riedemann  wrote:
> On 4/10/2017 1:18 PM, Chris Dent wrote:
>>
>> On Mon, 10 Apr 2017, Thierry Carrez wrote:
>>
>>> So my question is the following: if elected, how much time do you think
>>> you'll be able to dedicate to Technical Committee affairs (reviewing
>>> proposed changes and pushing your own) ?
>>
>>
>> I've been regularly reviewing changes in the governance repo and
>> attending the weekly TC meeting for well over a year now. Increasing
>> that commitment to include shepherding new initiatives, either ones
>> I start myself or work on in concert with others, is why I'm running
>> for the TC and I wouldn't be doing so if I didn't think I had the
>> time and energy to support that.
>>
>> Making a specific prediction on how much time that will take is
>> challenging; some weeks will take more time than others. I intend to
>> do what's needed to do the job well.
>>
>>> If there was ONE thing, one
>>> initiative, one change you will actively push in the six months between
>>> this election round and the next, what would it be ?
>>
>>
>> Just ONE initiative is difficult because from my perspective what
>> matters is that whatever initiatives happen to be in progress, they
>> are transparent, inclusive and actually make some kind of
>> difference. But since ONE is the request:
>>
>> My hallmark complaint with the TC since I was first aware of it has
>> been that, often, resolutions or plans can emerge from the TC so
>> late in their development that engaging them in a way that allows
>> consideration of completely different options is hard. Hard for a
>> variety of reasons; one is that it can feel a bit rude to criticize
>> a complete seeming idea that someone clearly put a lot of effort
>> into. This means discussion proceeds as an evaluation of the
>> proposal rather than as analysis of the root causes of the problems
>> to be solved or the full consequences of the goals being described.
>>
>> This situation has improved over the years, I think there is at
>> least increased awareness, and some concrete efforts to allow people
>> to be involved, but we can do more to make it easier and lighter.
>>
>> I would prefer that the TC's constituency was more actively made
>> aware of pending work and ongoing debates prior to the creation of
>> resolutions (even if WIP) in gerrit or having big sessions at the
>> Forum.  One way to do this would be to follow the growing trend of
>> weekly newsletters and updates and do one for the TC. I recall this
>> was tried (in the form of blog posts, and to some extent in response
>> to my prompting) a while back, but didn't really take off. I
>> wonder if that format was too heavyweight?
>>
>> I'm proud of having played a part in the newsletter trend and I
>> think the results for the API-WG and the placement project have been
>> very positive. Doing something similar for the TC -- in a
>> lightweight, just-the-highlights kind of way -- is something I could
>> do (I hope with the occasional help of the rest of the TC) and is
>> something I think would be useful. With luck the newsletter would
>> operate as a catalyst around which casual discussion and idea
>> sharing would accrete.
>>
>> What I hope would happen as a result is that people would feel more
>> aware of and able to participate in the discussion and processes
>> working to shape the future of OpenStack.
>>
>>
>>
>> __
>> OpenStack Development Mailing 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 Chris. This reminded me of something I wanted to ask about, to all TC
> members, or those running for a seat.
>
> Lots of projects have alternating meeting times to accommodate contributors
> in different time zones, especially Europe and Asia.
>
> The weekly TC meeting, however, does not.
>
> I have to assume this has come up before and if so, why hasn't the TC
> adopted an alternating meeting schedule?
>
> For example, it's 4am in Beijing when the TC meeting happens. It's already
> hard to get people from Asia into leadership roles within projects and
> especially across the community, in large part because of the timezone
> barrier.
>
> How will the TC grow a diverse membership if it's not even held, at least
> every other week, in a timezone where the other half of the world can
> attend?
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [qa][cinder] critical fix for ceph job

2017-04-10 Thread Jon Bernard
* Matt Riedemann  wrote:
> On 4/7/2017 9:43 AM, Jordan Pittier wrote:
> > 
> > 
> > On Fri, Apr 7, 2017 at 4:15 PM, Ghanshyam Mann  > > wrote:
> > 
> > Thanks. I am not sure these kind of driver specific behavior on APIs
> > side. This bring up question that should not cinder APIs be consistent
> > from usage point. In this case[1], create backup API can accept
> > 'container' param and do/don't create pool as per configured driver?
> > Then have better documentation for that what all driver honor that or
> > not.
> > 
> > Any suggestion ?
> > 
> > ..1 https://review.openstack.org/#/c/454321/3
> > 
> > 
> > 
> > Yeah, I've left a comment on that review. And another comment on
> > https://review.openstack.org/#/c/454722 :
> > 
> > "I'd rather we revert the change completely than to see this merged.
> > 
> > If the Ceph backup driver doesn't support the container argument it
> > should either grow support for it, or ignore that argument, or we change
> > Cinder's API completely so that the container argument is not part of
> > the public API anymore.
> > 
> > Do we expect each and every user to know what each and every drivers
> > support ? I don"t think so, so Tempest shouldn"t either."
> > 
> > 
> > 
> > __
> > OpenStack Development Mailing 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 left a comment in there too. This wasn't the right way to get around this.
> I've tried the same thing before, back when the encrypted volume tests were
> failing for ceph because it simply wasn't supported in nova.
> 
> Jon, as we discussed at the PTG, you need to get a whitelist or blacklist
> file into nova like we have for the cells v1 job and we can use that on the
> ceph job config to control the tests that are run, so we don't need to make
> changes like this in Tempest. Let's work on that and then we can revert this
> workaround to Tempest.

Ok, I understand the logic and I'm happy work towards this.  For
reference, this commit https://review.openstack.org/#/c/345411/ added
support for container names to the ceph backup driver and I think a
discussion within Cinder is needed.  I will first create an analogous
patch for nova's whitelist, and then revert this one.  And if we decide
to change cinder's behaviour then all of it can go away.

-- 
Jon

__
OpenStack Development Mailing 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] UC Meeting 04/10/17 Cancelled

2017-04-10 Thread Melvin Hillsman
Hey everyone,

Apologies for the late notice. We are cancelling the meeting today. We have
moved to a weekly cadence with meetings being subject to new agenda items
having to be proposed/added by the Friday before the meeting. In other
words, for UC meeting scheduled for 04/17/17 agenda items will need to be
proposed/added by this Friday 04/14/17

Thanks very much,

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


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

2017-04-10 Thread Matt Riedemann

On 4/10/2017 1:18 PM, Chris Dent wrote:

On Mon, 10 Apr 2017, Thierry Carrez wrote:


So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ?


I've been regularly reviewing changes in the governance repo and
attending the weekly TC meeting for well over a year now. Increasing
that commitment to include shepherding new initiatives, either ones
I start myself or work on in concert with others, is why I'm running
for the TC and I wouldn't be doing so if I didn't think I had the
time and energy to support that.

Making a specific prediction on how much time that will take is
challenging; some weeks will take more time than others. I intend to
do what's needed to do the job well.


If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?


Just ONE initiative is difficult because from my perspective what
matters is that whatever initiatives happen to be in progress, they
are transparent, inclusive and actually make some kind of
difference. But since ONE is the request:

My hallmark complaint with the TC since I was first aware of it has
been that, often, resolutions or plans can emerge from the TC so
late in their development that engaging them in a way that allows
consideration of completely different options is hard. Hard for a
variety of reasons; one is that it can feel a bit rude to criticize
a complete seeming idea that someone clearly put a lot of effort
into. This means discussion proceeds as an evaluation of the
proposal rather than as analysis of the root causes of the problems
to be solved or the full consequences of the goals being described.

This situation has improved over the years, I think there is at
least increased awareness, and some concrete efforts to allow people
to be involved, but we can do more to make it easier and lighter.

I would prefer that the TC's constituency was more actively made
aware of pending work and ongoing debates prior to the creation of
resolutions (even if WIP) in gerrit or having big sessions at the
Forum.  One way to do this would be to follow the growing trend of
weekly newsletters and updates and do one for the TC. I recall this
was tried (in the form of blog posts, and to some extent in response
to my prompting) a while back, but didn't really take off. I
wonder if that format was too heavyweight?

I'm proud of having played a part in the newsletter trend and I
think the results for the API-WG and the placement project have been
very positive. Doing something similar for the TC -- in a
lightweight, just-the-highlights kind of way -- is something I could
do (I hope with the occasional help of the rest of the TC) and is
something I think would be useful. With luck the newsletter would
operate as a catalyst around which casual discussion and idea
sharing would accrete.

What I hope would happen as a result is that people would feel more
aware of and able to participate in the discussion and processes
working to shape the future of OpenStack.



__
OpenStack Development Mailing 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 Chris. This reminded me of something I wanted to ask about, to 
all TC members, or those running for a seat.


Lots of projects have alternating meeting times to accommodate 
contributors in different time zones, especially Europe and Asia.


The weekly TC meeting, however, does not.

I have to assume this has come up before and if so, why hasn't the TC 
adopted an alternating meeting schedule?


For example, it's 4am in Beijing when the TC meeting happens. It's 
already hard to get people from Asia into leadership roles within 
projects and especially across the community, in large part because of 
the timezone barrier.


How will the TC grow a diverse membership if it's not even held, at 
least every other week, in a timezone where the other half of the world 
can attend?


--

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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Dean Troyer
On Mon, Apr 10, 2017 at 10:19 AM, Matt Riedemann  wrote:
> How long are we expected to be carrying this deprecated bridge code? If you
> need these CLIs/API bindings in the client, then don't upgrade to 8.0.0, or
> run different versions of novaclient in venvs or containers if you need to
> really workaround this.

Oh how I wish this were as easy in practice as it sounds.

> I feel like the signaling on all of this was pretty clear back in Newton.
> What else are people expecting or that we missed? I don't really see why
> python-openstackclient needs to start adding this API binding code back in
> locally, that's just extending the lifespan of this busted code that we're
> really trying to make uncomfortable for people to be using because like it
> or not, nova-network is going away. We did the fallback thing in the CLI in
> newton as a way to soften that blow for CLI users, but really at some point
> this just needs to be broken and people either stay on old tools or upgrade
> to what is supported.

Matt, I am not questioning the signalling nor the actual removal, that
is the right thing for novaclient at some point.  I did miss the early
indications of the timing of 8.0, only seeing it two weeks before the
release, but that is on me.

The fact that this causes us problems is not your problem, but
highlights why OSC and Shade and other things really do not want to
use the project clients because the use cases and assumptions and
other things are different.  I started 3 years ago to start replacing
those things, the SDK came long to replace that work but is still not
at a 1.0 release.  So I'm playing catch-up.

Upgrading old nova-net clouds has been deemed impossible, which is why
we don't do it.  But you might be unhappy about the removal of py27
from distros just yet, as not all of OpenStack is py3 ready.  We
should just upgrade all that code...

dt

-- 

Dean Troyer
dtro...@gmail.com

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


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

2017-04-10 Thread Yeleswarapu, Ramamani
Hi,

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

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

1. rolling upgrades
1.1. make a change to the grenade job to only upgrade conductor
1.2. fix issues in the next patch https://review.openstack.org/#/c/412397/
2. review next BFV patch:
2.1. next: https://review.openstack.org/#/c/453839/
2.2. then: https://review.openstack.org/#/c/366197/
3. update/review next rescue patches:
3.1. https://review.openstack.org/#/c/350831/
3.2. https://review.openstack.org/#/c/353156/
4. review e-tags spec: https://review.openstack.org/#/c/381991/
5. next driver comp client patch: https://review.openstack.org/#/c/419274/


Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 03 Apr 2017 and 10 Apr 2017)
- Ironic: 251 bugs (+10) + 250 wishlist items (+1). 26 new (+11), 202 in 
progress (+1), 0 critical, 27 high (+1) and 28 incomplete (-1)
- Inspector: 15 bugs (-2) + 32 wishlist items (+1). 2 new, 20 in progress (+2), 
0 critical, 1 high (-1) and 4 incomplete
- Nova bugs with Ironic tag: 12. 2 new, 0 critical, 0 high

Essential Priorities


CI refactoring and missing test coverage

- Standalone CI tests (vsaienk0)
- patch to be reviewed: https://review.openstack.org/#/c/437549 MERGED
- next patch to be reviewed: https://review.openstack.org/#/c/429770/
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- blocked by: https://review.openstack.org/#/c/440719/ MERGED

Generic boot-from-volume (TheJulia, dtantsur)
-
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- TheJulia will be unavailable the week of April 10th and the following 
week.
- joanna has volunteered to run the meeting in TheJulia's absence.
- mjturek is working on getting together devstack config updates/script 
changes in order to support this configuration
- hshiina is looking in Nova side changes and is attempting to obtain 
clarity on some of the issues that tenant network separation introduced into 
the deployment workflow.
- Patch/note tracking etherpad: https://etherpad.openstack.org/p/Ironic-BFV
Ironic Patches:
https://review.openstack.org/#/c/355625/  - Merged - Has Follow-up 
that requires reviews https://review.openstack.org/#/c/453839/
https://review.openstack.org/#/c/366197/
https://review.openstack.org/#/c/406290
https://review.openstack.org/#/c/413324
https://review.openstack.org/#/c/454243/ - WIP logic changes for 
deployment process.  Tenant network separation introduced some additional 
complexity, quick conceptual feedback requested.
https://review.openstack.org/#/c/214586/ - Volume Connection 
Information Rest API Change
Additional patches exist, for python-ironicclient and one for nova.  
Links in the patch/note tracking etherpad.

Rolling upgrades and grenade-partial (rloo, jlvillal)
-
- spec approved; code patches: 
https://review.openstack.org/#/q/topic:bug/1526283
- status as of most recent weekly meeting:
- next patch 'Add version column' 
(https://review.openstack.org/#/c/412397/) was updated but seems to have one 
issue still; should be ready tomorrow
- Testing work:
- 27-Mar-2017: Grenade multi-node is non-voting
- need to change it to only upgrade the conductor

Reference architecture guide (jroll)

- no updates

Python 3.5 compatibility (JayF, hurricanerix)
-
- no updates

Deploying with Apache and WSGI in CI (vsaienk0)
---
- seems like we can deploy with WSGI, but it still uses a fixed port, instead 
of sub-path
- next one is https://review.openstack.org/#/c/444337/
- inspector is TODO and depends on https://review.openstack.org/435517

Driver composition (dtantsur, jroll)

* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of most recent weekly meeting:
- TODO as of 10 Apr 2017
- install guide / admin guide docs
- client changes:
- driver commands update: https://review.openstack.org/419274
- node-update update: https://review.openstack.org/#/c/431542/
- new hardware types:
- ilo: https://review.openstack.org/#/c/439404/
- this is blocked by iLO drivers refactoring - see the whole 
patch 

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

2017-04-10 Thread Ed Leafe
On Apr 10, 2017, at 4:16 AM, Thierry Carrez  wrote:

> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ?

Well, as you know I have been active with the TC for years now, even though 
I've never been elected to a position on the TC. Since so many of the issues 
that the TC deals with are important to OpenStack's future, I like to 
contribute to bettering that wherever I can. So if elected to serve on the TC, 
I would be able to focus even more of my time, going from maybe 5-10% now, to 
50% if elected.

> If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

Just one? If I had to choose, I would like to see a clear separation between 
the core services that provide IaaS, and the products that then build on that 
core. They occupy very different places in the OpenStack picture, and should be 
treated differently. The IaaS parts (and yes, I know that just which parts 
these are is a whole debate in itself) should be rock-solid, slow-moving, and, 
well, boring. Reliability is the key for them. But for the services and 
applications that are built on top of this base? I'd like to see allowing them 
a much more open approach: let them develop in whatever language they like, 
release when they feel the timing is right, and define their own CI testing. In 
other words, if you want to develop in a language other than Python, go for it! 
If you want to use a particular NoSQL database, sure thing! However, the price 
of that freedom is that the burden will be on the project to ensure that it is 
adequately tested, instead of laying that responsibility on our infra team. 
Such projects will also have to accept a tag such as 'experimental' or 
'untested' until they can demonstrate otherwise. This can also serve to 
encourage the development of additional testing resources around, say, Golang 
projects, so that the Golang community can all pitch in and develop the sort of 
infrastructure needed to adequately test their products, both alone and in 
conjunction with the IaaS core of OpenStack. The only thing that should be 
absolute is a project's commitment to the Four Opens. There will be winners, 
and there will be losers, and that's not only OK, it's how it should be.


-- Ed Leafe







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


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

2017-04-10 Thread German Eichberger
Hi,

I am well aware that being on the TC is a serious time commitment and that 
there is more to do than a given day has hours. So I read your question more 
about prioritizing and how I would do that. A fair part of how I prioritize 
depends on input from others. That’s why I said listening to operators, 
developers, and end users is key. This will inform where I will try to spend my 
time. As for my big initiative, I want to push my heart is with small or 
underfunded projects and making life easier for them. I don’t think this can be 
done with one big thing but rather small steps like better mentoring, 
documentation,  better visibility by inviting them to say the Forum in Boston, 
but first and foremost helping them to have a voice at the TC.  

Thanks,
German

On 4/10/17, 5:16 AM, "Thierry Carrez"  wrote:

Hi everyone,

New in this TC election round, we have a few days between nominations
and actual voting to ask questions and get to know the candidates a bit
better. I'd like to kick off this new "campaigning period" with a basic
question on available time and top priority.

All the candidates are top community members with a lot of
responsibilities on their shoulders already. My experience tells me that
it is easy to overestimate the time we can dedicate to Technical
Committee matters, and how much we can push and get done in six months
or one year. At the same time, our most efficient way to make progress
is always when someone "owns" a particular initiative and pushes it
through the governance process.

So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ? If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?

Thanks in advance for your answers !

-- 
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] [tc] [elections] Available time and top priority

2017-04-10 Thread Chris Dent

On Mon, 10 Apr 2017, Thierry Carrez wrote:


So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ?


I've been regularly reviewing changes in the governance repo and
attending the weekly TC meeting for well over a year now. Increasing
that commitment to include shepherding new initiatives, either ones
I start myself or work on in concert with others, is why I'm running
for the TC and I wouldn't be doing so if I didn't think I had the
time and energy to support that.

Making a specific prediction on how much time that will take is
challenging; some weeks will take more time than others. I intend to
do what's needed to do the job well.


If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?


Just ONE initiative is difficult because from my perspective what
matters is that whatever initiatives happen to be in progress, they
are transparent, inclusive and actually make some kind of
difference. But since ONE is the request:

My hallmark complaint with the TC since I was first aware of it has
been that, often, resolutions or plans can emerge from the TC so
late in their development that engaging them in a way that allows
consideration of completely different options is hard. Hard for a
variety of reasons; one is that it can feel a bit rude to criticize
a complete seeming idea that someone clearly put a lot of effort
into. This means discussion proceeds as an evaluation of the
proposal rather than as analysis of the root causes of the problems
to be solved or the full consequences of the goals being described.

This situation has improved over the years, I think there is at
least increased awareness, and some concrete efforts to allow people
to be involved, but we can do more to make it easier and lighter.

I would prefer that the TC's constituency was more actively made
aware of pending work and ongoing debates prior to the creation of
resolutions (even if WIP) in gerrit or having big sessions at the
Forum.  One way to do this would be to follow the growing trend of
weekly newsletters and updates and do one for the TC. I recall this
was tried (in the form of blog posts, and to some extent in response
to my prompting) a while back, but didn't really take off. I
wonder if that format was too heavyweight?

I'm proud of having played a part in the newsletter trend and I
think the results for the API-WG and the placement project have been
very positive. Doing something similar for the TC -- in a
lightweight, just-the-highlights kind of way -- is something I could
do (I hope with the occasional help of the rest of the TC) and is
something I think would be useful. With luck the newsletter would
operate as a catalyst around which casual discussion and idea
sharing would accrete.

What I hope would happen as a result is that people would feel more
aware of and able to participate in the discussion and processes
working to shape the future of OpenStack.

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [os-upstream-institute] Meeting Reminder

2017-04-10 Thread Kendall Nelson
Hello!

Just wanted to remind everyone of our meeting today at 20:00 UTC in
#openstack-meeting-3

Please feel free to add items to the agenda:
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

Also, please take a look at the slides so we can focus on improvements
rather than discussing what is already there.

https://docs.openstack.org/upstream-training/

All the Best,

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


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

2017-04-10 Thread Ben Nemec
I'm not really an expert on composable roles so I'll leave that to 
someone else, but see my thoughts inline on the networking aspect.


On 04/10/2017 03:22 AM, Jan Provaznik wrote:

2) define a new VIP (for IP failover) and 2 networks for NfsStorage role:
a) a frontend network between users and ganesha servers (e.g.
NfsNetwork name), used by tenants to mount nfs shares - this network
should be accessible from user instances.


Adding a new network is non-trivial today, so I think we want to avoid 
that if possible.  Is there a reason the Storage network couldn't be 
used for this?  That is already present on compute nodes by default so 
it would be available to user instances, and it seems like the intended 
use of the Storage network matches this use case.  In a Ceph deployment 
today that's the network which exposes data to user instances.



b) a backend network between ganesha servers ans ceph cluster -
this could just map to the existing StorageNetwork I think.


This actually sounds like a better fit for StorageMgmt to me.  It's 
non-user-facing storage communication, which is what StorageMgmt is used 
for in the vanilla Ceph case.



What i'm not sure at all is how network definition should look like.
There are following Overcloud deployment options:
1) no network isolation is used - then both direct ceph mount and
mount through ganesha should work because StorageNetwork and
NfsNetwork are accessible from user instances (there is no restriction
in accessing other networks it seems).


There are no other networks without network-isolation.  Everything runs 
over the provisioning network.  The network-isolation templates should 
mostly handle this for you though.



2) network isolation is used:
a) ceph is used directly - user instances need access to the ceph
public network (which is StorageNetwork in Overcloud) - how should I
enable access to this network? I filled a bug for this deployment
variant here [3]


So does this mean that the current manila implementation is completely 
broken in network-isolation?  If so, that's rather concerning.


If I'm understanding correctly, it sounds like what needs to happen is 
to make the Storage network routable so it's available from user 
instances.  That's not actually something TripleO can do, it's an 
underlying infrastructure thing.  I'm not sure what the security 
implications of it are either.


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


Alternatively I guess you could use ServiceNetMap to move the public 
Ceph traffic to the public network, which has to be routable.  That 
seems like it might have a detrimental effect on the public network's 
capacity, but it might be okay in some instances.



b) ceph is used through ganesha - user instances need access to
ganesha servers (NfsNetwork in previous paragraph) - how should I
enable access to this network?


I think the answer here will be the same as for vanilla Ceph.  You need 
to make the network routable to instances, and you'd have the same 
options as I discussed above.




The ultimate (and future) plan is to deploy ganesha-nfs in VMs (which
will run in Overcloud, probably managed by manila ceph driver), in
this deployment mode a user should have access to ganesha servers and
only ganesha server VMs should have access to ceph public network.
Ganesha VMs would run in a separate tenant so I wonder if it's
possible to manage access to the ceph public network (StorageNetwork
in Overcloud) on per-tenant level?


This would suggest that the bridged Storage network approach is the 
best.  In that case access to the ceph public network is controlled by 
the overcloud Neutron, so you would just need to only give access to it 
to the tenant running the Ganesha VMs.  User VMs would only get access 
to a separate shared network providing access to the public Ganesha API, 
and the Ganesha VMs would straddle both networks.




Any thoughts and hints?

Thanks, Jan

[1] https://github.com/nfs-ganesha/nfs-ganesha/wiki
[2] https://github.com/ceph/ceph-ansible/tree/master/roles/ceph-nfs
[3] https://bugs.launchpad.net/tripleo/+bug/1680749


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


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

2017-04-10 Thread Dean Troyer
On Mon, Apr 10, 2017 at 4:16 AM, Thierry Carrez  wrote:
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ? If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

In the last six months of my abbreviated term on the TC I was able to
increase the amount of time I was able to spend on TC work, and most
of that time went toward the work for additional language supprot, and
specifically golang support with the creation of the Golang Consistent
Testing Interface.

I plan to continue that work whether I am re-elected to the TC or not.
There has been a lot of concern expressed regarding the community
impact of any alternate languages.  Specific experiences with projects
that have already been down that path (eg Horizon with Javascript)
indicate that these concerns can not be ignored.  Part of the
challenge is to not create a situation where the resulting
multi-language environment is totally foreign to any of the
communities involved.  We already have some of that problem in
OpenStack with the broader Python community (I'm looking at you, pbr),
I want to work to minimize that for the new environments and their
existing communities, but also for an OpenStack developer to feel
comfortable and for OpenStack practices to be as consistent as
possible to minimize the pain of moving among our projects.  This is a
tricky proposition but is even trickier without conscious and
intentional coordination.

Some of my other priorities for the TC include refining OpenStack's
identity and focus as we continue to adjust to our current realities.
I was excited to see the TC vision proposal released for general
comment and think this is a great opportunity to come together on
goals and ideals for our future.  Please read it if you have not
already!  https://review.openstack.org/#/c/453262

dt

-- 

Dean Troyer
dtro...@gmail.com

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


[openstack-dev] [horizon] Unknown provider resource-type-registry.service test error

2017-04-10 Thread Beth Elwell
Hi all,

Thanks very much in advance for any help you are able to offer.

I have been working on developing the QoS Policies panel for horizon and have 
the panel working, however I am struggling with the qos.service.spec.js file. 
In advance of going into my findings and issues so far, the related patch is 
located at https://review.openstack.org/#/c/418828/ 
 

The error log is as follows: 

http://paste.openstack.org/show/606058/ 


 From that error log it looks to me 
like the resource-type-registry for neutron is not being defined, and the error 
appears with the link to the network_qos module as per line 19 
https://review.openstack.org/#/c/418828/28/openstack_dashboard/static/app/core/network_qos/qos.service.spec.js
 

 

However the resource-type-registry is definitely defined and I cannot see why 
this should be throwing errors.

It could well be I have just looked at this code for too long and my brain is 
skipping over something, but any help anyone can give on this would be 
massively appreciated.

Many thanks,
Beth
IRC: betherly__
OpenStack Development Mailing 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] [HA] HA Discussion at Boston Forum

2017-04-10 Thread Sam P
Hi All,

 I proposed a session [1] to Boston Forum and it is now at incomplete state.
 This is good opportunity for all of us to get together and discuss
our HA related issues.
 I need your help to reform this session.
 Please put comments on [1] or replay to this with your comments.

[1] http://forumtopics.openstack.org/cfp/details/117

--- Regards,
Sampath

__
OpenStack Development Mailing 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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Monty Taylor

On 04/10/2017 10:23 AM, Akihiro Motoki wrote:

2017-04-10 23:19 GMT+09:00 Dean Troyer :

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.


This topic on novaclient 8.0.0 raised me a question on our python
binding support policy.
I see two points:

- The one is which API version should be supported by a python binding
from a same release.
For example, Pike novaclient supports >2.36 of Nova API while Nova
still supports <=2.35 API.
Python bindings should support a whole set of supported API or a
subset of supported API
(of course including 'latest' version of API).


I think that because we use python-*client for intraservice 
communication, a release of a client needs to support the previous 
release (otherwise rolling upgrades can go poorly) I think given 
structure at this point trying to support more is a thing we should not 
bother doing and we should be clear about that.


- The other is about multi cloud use cases. Different OpenStack clouds
may use different releases
and client libraries need to support

The latter covers broader range of use cases.


If you are a user who wants to use multi-clouds - use shade. As an end 
user, trying to use our python client bindings directly for multi-cloud 
is very painful.


__
OpenStack Development Mailing 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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Monty Taylor

On 04/10/2017 10:24 AM, Sean Dague wrote:

On 04/10/2017 11:19 AM, Matt Riedemann wrote:

On 4/10/2017 9:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki 
wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.

dt



As noted in my reply to Akihiro, the CLIs/APIs were deprecated in
novaclient back in Newton in the 6.0.0 release of python-novaclient. We
left them through Ocata and dropped them here in Pike in 8.0.0.

How long are we expected to be carrying this deprecated bridge code? If
you need these CLIs/API bindings in the client, then don't upgrade to
8.0.0, or run different versions of novaclient in venvs or containers if
you need to really workaround this.

I feel like the signaling on all of this was pretty clear back in
Newton. What else are people expecting or that we missed? I don't really
see why python-openstackclient needs to start adding this API binding
code back in locally, that's just extending the lifespan of this busted
code that we're really trying to make uncomfortable for people to be
using because like it or not, nova-network is going away. We did the
fallback thing in the CLI in newton as a way to soften that blow for CLI
users, but really at some point this just needs to be broken and people
either stay on old tools or upgrade to what is supported.


Right, I guess I'm confused why the operator in that case would just
keep the older version installed. It's not being deleted from pypi.


I think it's, as usual, two different use cases. The operator and the 
end-user are different. I think nova has done an excellent job signaling 
this for operators.


However, one of the places where it may have fallen down is that users 
of python-openstackclient are not necessarily deployers, and they may 
also have accounts on clouds that still force people through the nova 
proxy apis - (and hell no to having a copy of python-openstackclient for 
each cloud, that's crazy)- AND - python-openstackclient depends on 
python-novaclient.


python-openstackclient is fixing this the same way as shade - not using 
python-novaclient but instead using REST calls. I think this is the 
right solution.


But right solution or not right solution, python-*client have 
historically been the thing we've pointed end-users at as a way to 
consume our clouds, and as much as we've been pushing moving the 
services forward, we haven't been as agressive in communicating to our 
end users to NEVER EVER EVER use python-*client for ANY REASON but 
instead to use python-openstackclient for command line and either shade 
or openstacksdk for python programming. A lot of that is inertia - 
people are used to typing "nova boot" - but the time is long past and 
this is a really great example of why it's really REALLY important to 
communicate strongly and clearly that end-users should not use the 
legacy python clients.


Monty

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


Re: [openstack-dev] [infra] is it ok to create extra users with sudo permissions during devstack run

2017-04-10 Thread Pavlo Shchelokovskyy
Clark,

thanks for reply.

On Mon, Apr 10, 2017 at 6:49 PM, Clark Boylan  wrote:

> On Mon, Apr 10, 2017, at 08:31 AM, Pavlo Shchelokovskyy wrote:
> > Hi infra team,
> >
> > on order to test a piece of functionality I am developing, during the
> > devstack plugin run I need to create an extra user with password-less
> > sudo
> > permissions. As I am not sure of intricacies of our infra setup, I'd like
> > to clarify if it is acceptable.
> >
> > TL;DR
> > There is 'openstack/networking-generic-switch' project that mainly aims
> > to
> > provide a Neutron ML2 plugin suitable to manage cheap HW switches that
> > only
> > allow configuration over SSH. The problem with those is that these
> > switches
> > usually have limitations on the number of concurrent SSH sessions open on
> > the switch.
> >
> > In order to overcome this, I am attempting to introduce DLM to
> > networking-generic-switch to globally limit the number of active SSH
> > connections to a given switch across all threads of neutron-service on
> > all
> > hosts [0].
> >
> > To test this locally in my Xenial DevStack VM, I am creating and
> > configuring "ovsmanager" user with password-less sudo permissions (so it
> > is
> > able to manage OVS), limit the number of allowed sessions for that user
> > in
> > /etc/security/limits.d/ and configure networking-generic-switch to access
> > localhost via that user to simulate a switch with limited number
> > of allowed SSH sessions.
> >
> > My questions is is it ok if I replicate this logic in the devstack plugin
> > of networking-generic-switch to set up gate testing for this feature?
> > In the end it seems it boils down to whether infra re-uses VMs it creates
> > to run gate jobs for anything else and if such changes can affect those
> > re-using these VMs, but I might be missing something else.
> >
> > [0] https://review.openstack.org/#/c/452959/
>
> The test instances that run devstack are single use VMs that are not
> reused. Every job running on these instances starts with sudo access,
> but by default we remove sudo access for the stack user which is what
> the OpenStack services run as. We do this to force those services to use
> rootwrap (or its equivalent) and test that the rootwrap rules are
> functional.
>
> As long as you create your new user during the initial devstack run you
> shouldn't have any issues with this.
>
> It wasn't mentioned above, but I would run a separate sshd for this
> rather than modify the existing one as ssh is the control mechanism for
> the test jobs. Better to run a separate independent service that won't
> conflict with job control.
>
> Hope this helps,
> Clark
>
>
I'm not going to control the number of sessions via SSH itself and change
the /etc/ssh/sshd_config, instead I'm going to create a file
/etc/security/limits.d/ovsmanager.conf (this is the place on Ubuntu Xenial)
with

# 
ovsmanager -   maxlogins   2

AFAIU this should not interfere with any other users and the number of
sessions/connections they are allowed (I would even prepend "ngs_" to the
created user name so it is clear what created it).

Cheers,

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

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Monty Taylor

On 04/10/2017 10:37 AM, Monty Taylor wrote:

On 04/10/2017 09:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki 
wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.


I agree - I think it is not important for horizon to support backward
compat - it's most commonly deployed with a cloud, so one expects it to
support the software in the cloud in question.


However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.


Similarly, shade intends to support nova-net for as long as shade
exists. We have already re-implemented most of nova-net support with
direct calls as part of our current project to delete use of
python-*client.



It turns out there are humans out there who are consuming old clouds -
and end-user client tools should be supporting those humans, even when
the current releases of OpenStack deprecate/remove things.


Quick clarification ...

When I say "shade intends to support nova-net" - I mean a specific thing 
that is almost certainly not what you might at first assume.


From the beginning, shade has hidden the nova-net/neutron difference - 
but shade is focused on the end-user primarily. This means the 
difference is "do you use nova or neutron API to deal with floating IPs 
and security groups" We do not expose any nova-net functionality 
directly - we expose FIPs and Security Groups, and we hide from the user 
what service provides them.


We will continue to do that to the best of our ability - although 
functional testing in devstack will have to give way to only 
requests-mock based testing once we don't have old stable branches that 
can install nova-net.


I may have also given the impression that I'm unhappy about novaclient 
dropping support - which is also not the case. I am firmly of the 
opinion that python-*client do not have end-users of OpenStack clouds as 
primary users in mind. The release model and design just isn't right for 
that. They are clearly, to me, designed to aid intra-service 
communication. As such, I think it's 100% appropriate for novaclient to 
have dropped nova-net support.


I, for one, welcome all things about the removal of nova-net, and I am 
quite happy to do the support actions in shade.


__
OpenStack Development Mailing 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] [infra] is it ok to create extra users with sudo permissions during devstack run

2017-04-10 Thread Clark Boylan
On Mon, Apr 10, 2017, at 08:31 AM, Pavlo Shchelokovskyy wrote:
> Hi infra team,
> 
> on order to test a piece of functionality I am developing, during the
> devstack plugin run I need to create an extra user with password-less
> sudo
> permissions. As I am not sure of intricacies of our infra setup, I'd like
> to clarify if it is acceptable.
> 
> TL;DR
> There is 'openstack/networking-generic-switch' project that mainly aims
> to
> provide a Neutron ML2 plugin suitable to manage cheap HW switches that
> only
> allow configuration over SSH. The problem with those is that these
> switches
> usually have limitations on the number of concurrent SSH sessions open on
> the switch.
> 
> In order to overcome this, I am attempting to introduce DLM to
> networking-generic-switch to globally limit the number of active SSH
> connections to a given switch across all threads of neutron-service on
> all
> hosts [0].
> 
> To test this locally in my Xenial DevStack VM, I am creating and
> configuring "ovsmanager" user with password-less sudo permissions (so it
> is
> able to manage OVS), limit the number of allowed sessions for that user
> in
> /etc/security/limits.d/ and configure networking-generic-switch to access
> localhost via that user to simulate a switch with limited number
> of allowed SSH sessions.
> 
> My questions is is it ok if I replicate this logic in the devstack plugin
> of networking-generic-switch to set up gate testing for this feature?
> In the end it seems it boils down to whether infra re-uses VMs it creates
> to run gate jobs for anything else and if such changes can affect those
> re-using these VMs, but I might be missing something else.
> 
> [0] https://review.openstack.org/#/c/452959/

The test instances that run devstack are single use VMs that are not
reused. Every job running on these instances starts with sudo access,
but by default we remove sudo access for the stack user which is what
the OpenStack services run as. We do this to force those services to use
rootwrap (or its equivalent) and test that the rootwrap rules are
functional.

As long as you create your new user during the initial devstack run you
shouldn't have any issues with this.

It wasn't mentioned above, but I would run a separate sshd for this
rather than modify the existing one as ssh is the control mechanism for
the test jobs. Better to run a separate independent service that won't
conflict with job control.

Hope this helps,
Clark

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


[openstack-dev] [puppet] Meeting April 11, 2017 @1500 UTC

2017-04-10 Thread Alex Schultz
Just a reminder, we have a meeting scheduled tomorrow April 11, 2017
@1500UTC[0]. Please add something to the agenda[1] if you have
something you would like to talk about.

Thanks,
-Alex

[0] https://docs.openstack.org/developer/puppet-openstack-guide/meetings.html
[1] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170411

__
OpenStack Development Mailing 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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Monty Taylor

On 04/10/2017 09:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.


I agree - I think it is not important for horizon to support backward 
compat - it's most commonly deployed with a cloud, so one expects it to 
support the software in the cloud in question.



However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.


Similarly, shade intends to support nova-net for as long as shade 
exists. We have already re-implemented most of nova-net support with 
direct calls as part of our current project to delete use of python-*client.


It turns out there are humans out there who are consuming old clouds - 
and end-user client tools should be supporting those humans, even when 
the current releases of OpenStack deprecate/remove things.


__
OpenStack Development Mailing 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] [infra] is it ok to create extra users with sudo permissions during devstack run

2017-04-10 Thread Pavlo Shchelokovskyy
Hi infra team,

on order to test a piece of functionality I am developing, during the
devstack plugin run I need to create an extra user with password-less sudo
permissions. As I am not sure of intricacies of our infra setup, I'd like
to clarify if it is acceptable.

TL;DR
There is 'openstack/networking-generic-switch' project that mainly aims to
provide a Neutron ML2 plugin suitable to manage cheap HW switches that only
allow configuration over SSH. The problem with those is that these switches
usually have limitations on the number of concurrent SSH sessions open on
the switch.

In order to overcome this, I am attempting to introduce DLM to
networking-generic-switch to globally limit the number of active SSH
connections to a given switch across all threads of neutron-service on all
hosts [0].

To test this locally in my Xenial DevStack VM, I am creating and
configuring "ovsmanager" user with password-less sudo permissions (so it is
able to manage OVS), limit the number of allowed sessions for that user in
/etc/security/limits.d/ and configure networking-generic-switch to access
localhost via that user to simulate a switch with limited number
of allowed SSH sessions.

My questions is is it ok if I replicate this logic in the devstack plugin
of networking-generic-switch to set up gate testing for this feature?
In the end it seems it boils down to whether infra re-uses VMs it creates
to run gate jobs for anything else and if such changes can affect those
re-using these VMs, but I might be missing something else.

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

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Boston Forum Schedule

2017-04-10 Thread Thiago da Silva
Looks like " Swift cluster level metrics and analytics" is also scheduled
twice.

Thiago

>
On Mon, Apr 10, 2017 at 11:03 AM, Tom Fifield  wrote:

> On 10/04/17 22:19, Emilien Macchi wrote:
>
>> On Mon, Apr 10, 2017 at 7:31 AM, Flavio Percoco 
>> wrote:
>>
>>> On 10/04/17 17:35 +0800, Tom Fifield wrote:
>>>

 Hi everyone,

 Thank you for the many excellent topics submitted for our first Forum.
 We
 have updated the topic submission site with the status of each - please
 check yours.

 Please also find attached in PDF the proposed schedule for the Forum in
 Boston.


 Let us know if you see major issues with it. As Thierry said in design
 summits past; "It's difficult to make too many changes at this stage as
 they
 quickly cascade into breaking all sorts of constraints, but we may
 still be
 able to accommodate some." :)

 Eagle-eyed readers will see that there are a number of slots in gray (on
 Thursday afternoon). These are being deliberately kept aside for the
 usual
 few critical topics that come up in the next few weeks and also for the
 discoveries we make in the first 3 days of the summit.

 We'll soon publish the Forum sessions on the main schedule, using the
 title, abstracts and moderators you submitted, but look forward to your
 feedback in the mean-time!

 Thank you all very much for making our first Forum a success.



>>> Hey Folks,
>>>
>>> Thanks for working on this.
>>>
>>> The topic "Future of configuration management tools" seems to have been
>>> scheduled twice. Is that expected or a mistake? In the schedule it's not
>>> explicit whether it's a 2 parts topic or not.
>>>
>>
>> Good point. I think 1 session to keep is enough and I checked both
>> slots, we can pick one of those, I don't see much conflict that would
>> prevent folks to have to make an hard choice.
>>
>> Tom, any chance to remove the second slot please?
>>
>>
> Yup, this was a mistake, sorry!


>
>
> __
> OpenStack Development Mailing 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] Boston Forum Schedule

2017-04-10 Thread Matt Riedemann

On 4/10/2017 4:35 AM, Tom Fifield wrote:

Hi everyone,

Thank you for the many excellent topics submitted for our first Forum.
We have updated the topic submission site with the status of each -
please check yours.

Please also find attached in PDF the proposed schedule for the Forum in
Boston.


Let us know if you see major issues with it. As Thierry said in design
summits past; "It's difficult to make too many changes at this stage as
they quickly cascade into breaking all sorts of constraints, but we may
still be able to accommodate some." :)

Eagle-eyed readers will see that there are a number of slots in gray (on
Thursday afternoon). These are being deliberately kept aside for the
usual few critical topics that come up in the next few weeks and also
for the discoveries we make in the first 3 days of the summit.

We'll soon publish the Forum sessions on the main schedule, using the
title, abstracts and moderators you submitted, but look forward to your
feedback in the mean-time!

Thank you all very much for making our first Forum a success.


Regards,

Doug, Emilien, Melvin, Mike, Shamail & Tom
Forum Scheduling Committee


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



There are some forum topic sessions still marked as Incomplete, like in 
some cases asking for a rewrite of the abstract. Assuming people 
addressed the comments associated with the Incomplete status, when is 
the next round of reviews on those proposed sessions to see if they are 
going to be accepted now?


--

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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Sean Dague
On 04/10/2017 11:19 AM, Matt Riedemann wrote:
> On 4/10/2017 9:19 AM, Dean Troyer wrote:
>> On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki 
>> wrote:
>>> (question not directly related to this topic)
>>> I am not sure there is a case where users still use API 2.36 for
>>> network management
>>> and newer API versions for other compute operation.
>>
>> This is probably true for Horizon, where the app install likely
>> matches the cloud it is configured to use.  However, many other use
>> cases for the Python libraries are meant to talk to multiple versions
>> of clouds and the 8.0 release of novaclient causes problems there.
>>
>> Even after nova-net support is EOL officially OSC plans to support the
>> use of nova-net for some time.  We are re-implementing the removed
>> functionality locally.  And anticipating some of the questions why,
>> consider an operator working on the long migration/upgrade from a
>> deployed nova-net cloud to a Neutron cloud, and needing to keep at
>> least one foot in both worlds.  There are other similar uses.
>>
>> dt
>>
> 
> As noted in my reply to Akihiro, the CLIs/APIs were deprecated in
> novaclient back in Newton in the 6.0.0 release of python-novaclient. We
> left them through Ocata and dropped them here in Pike in 8.0.0.
> 
> How long are we expected to be carrying this deprecated bridge code? If
> you need these CLIs/API bindings in the client, then don't upgrade to
> 8.0.0, or run different versions of novaclient in venvs or containers if
> you need to really workaround this.
> 
> I feel like the signaling on all of this was pretty clear back in
> Newton. What else are people expecting or that we missed? I don't really
> see why python-openstackclient needs to start adding this API binding
> code back in locally, that's just extending the lifespan of this busted
> code that we're really trying to make uncomfortable for people to be
> using because like it or not, nova-network is going away. We did the
> fallback thing in the CLI in newton as a way to soften that blow for CLI
> users, but really at some point this just needs to be broken and people
> either stay on old tools or upgrade to what is supported.

Right, I guess I'm confused why the operator in that case would just
keep the older version installed. It's not being deleted from pypi.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Akihiro Motoki
2017-04-10 23:19 GMT+09:00 Dean Troyer :
> On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:
>> (question not directly related to this topic)
>> I am not sure there is a case where users still use API 2.36 for
>> network management
>> and newer API versions for other compute operation.
>
> This is probably true for Horizon, where the app install likely
> matches the cloud it is configured to use.  However, many other use
> cases for the Python libraries are meant to talk to multiple versions
> of clouds and the 8.0 release of novaclient causes problems there.
>
> Even after nova-net support is EOL officially OSC plans to support the
> use of nova-net for some time.  We are re-implementing the removed
> functionality locally.  And anticipating some of the questions why,
> consider an operator working on the long migration/upgrade from a
> deployed nova-net cloud to a Neutron cloud, and needing to keep at
> least one foot in both worlds.  There are other similar uses.

This topic on novaclient 8.0.0 raised me a question on our python
binding support policy.
I see two points:

- The one is which API version should be supported by a python binding
from a same release.
For example, Pike novaclient supports >2.36 of Nova API while Nova
still supports <=2.35 API.
Python bindings should support a whole set of supported API or a
subset of supported API
(of course including 'latest' version of API).

- The other is about multi cloud use cases. Different OpenStack clouds
may use different releases
and client libraries need to support

The latter covers broader range of use cases.

Akihiro

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

__
OpenStack Development Mailing 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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

2017-04-10 Thread Doug Hellmann
Excerpts from Akihiro Motoki's message of 2017-04-11 00:09:10 +0900:
> Hi neutrinos (and horizoners),
> 
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
> 
> I would like to raise this topic again. No dashboard support lands since then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
> 
> Possible approaches
> 
> 
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
> 
> Which one sounds better?
> 
> Pros and Cons
> 
> 
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
> 
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
> 
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another 
> implementation.
> 
> 
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).
> 
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months ago.
> As an example, trunk support is being development in the horizon repo.
> 
> Thanks,
> Akihiro
> 

From the release team's perspective, we would prefer (a), because
having one deliverable per package simplifies packaging and makes
more sense for deployments (no one would end up with dashboard
panels for features not supported by the backend).

Doug

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


Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Matt Riedemann

On 4/10/2017 9:19 AM, Dean Troyer wrote:

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.


This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.

dt



As noted in my reply to Akihiro, the CLIs/APIs were deprecated in 
novaclient back in Newton in the 6.0.0 release of python-novaclient. We 
left them through Ocata and dropped them here in Pike in 8.0.0.


How long are we expected to be carrying this deprecated bridge code? If 
you need these CLIs/API bindings in the client, then don't upgrade to 
8.0.0, or run different versions of novaclient in venvs or containers if 
you need to really workaround this.


I feel like the signaling on all of this was pretty clear back in 
Newton. What else are people expecting or that we missed? I don't really 
see why python-openstackclient needs to start adding this API binding 
code back in locally, that's just extending the lifespan of this busted 
code that we're really trying to make uncomfortable for people to be 
using because like it or not, nova-network is going away. We did the 
fallback thing in the CLI in newton as a way to soften that blow for CLI 
users, but really at some point this just needs to be broken and people 
either stay on old tools or upgrade to what is supported.


--

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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Matt Riedemann

On 4/10/2017 8:58 AM, Akihiro Motoki wrote:


Is there any deprecation policy in novaclient python binding?
I was not aware of deprecation warnings.
If novaclient follows nova deprecation, it sounds reasonable to me.


Yes we deprecated the CLIs in this change in Newton:

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

That would emit a deprecation warning if you're using the CLIs. If you 
were using the latest microversion on those CLIs and it wasn't 
supported, we softened the blow by falling back to 2.35 so things would 
still work. That was dropped in the novaclient 8.0.0 release in Pike. 
There was also a pretty massive release note with that change.


The change to deprecate the API bindings came after it, but also in Newton:

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

I guess we weren't emitting a DeprecationWarning using the warnings.warn 
method on those, maybe we should have. That's what Horizon would have 
seen though, and probably why Horizon never noticed. The APIs were 
capped at 2.35 though, and a client specifically opting into >2.35 on 
those APIs would fail. Since Horizon hasn't been using nova 
microversions with the novaclient API bindings until now, again that is 
probably why no one in Horizon noticed.


--

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] [tripleo][ui] another i18n proposal for heat templates 'description' help strings

2017-04-10 Thread Julie Pichon
Hi Peng,

I added some thoughts in-line, let me know what you think.

On 10 April 2017 at 08:10, Peng Wu  wrote:
> Hi,
>
>   In TripleO UI project users requested translation of the web UI. But
> some web UI strings are displayed from heat template files in tripleo-
> heat-templates project.
>
>   In order to get translated templates displayed in tripleo-ui, we
> propose another solution as follows, which needs to change code in
> tripleo-heat-templates and tripleo-ui projects.
>
>   I18n proposal for Heat templates 'description' help strings
>
>   1. Update tripleo-heat-templates to generate the javascript files to
> include all translation strings, like "tripleo-heat-templates.js"
>
>  a. Need to write python script to extract "title" and
> "description" field from yaml files and generate "tripleo-heat-
> templates.js" for react-intl usage in tripleo-ui

I think extracting the strings directly into js/json format may be not
be a viable option, because it isn't a format supported by
Zanata [1].

For tripleo-ui itself we use react-intl which expects json, and work
with scripts to convert to/from pot and po (see [2]) which are fully
supported by Zanata.

Or is the idea that we'd also generate pot/po as intermediary steps and
only store json in the repo?

>  b. Use default message as message id or consider nodejs-i18n for
> tripleo-ui

I'm wary of considering a library change considering the amount of
churn it would cause in the code base for all the existing strings,
plus that would then make backports more difficult. It really needs to
be considered carefully.

>
>   2. Update tripleo-ui to use "tripleo-heat-templates.js"
>
>  a. Write some script to sync "tripleo-heat-templates.js" from
> tripleo-heat-templates
>
>  b. Call formatMessage function for "title" and "description" field
> with message id (use default message) and default message or consider
> nodejs-i18n for tripleo-ui
>
>   Refer URL for message id: https://github.com/yahoo/react-intl/issues/
> 912

Could you explain a bit more the issue with the ids? I see us defining
an id in every message [3] and this is how they are referenced in the
locale json [4] (the mapping is not done by message, but by ID).

When it comes to the THT message, I think they all have a hierarchy
that perhaps could be used as a key to map between the original string
and the translation? Something along the lines of
OS::TripleO::Services::Apache::ApacheMaxRequestWorkers::description,
whichever form the API gives us at the moment.

>   Please evaluate it, thanks!

Thank you!

Julie

[1] 
http://docs.zanata.org/en/release/user-guide/projects/project-types/#supported-types
[2] 
https://github.com/openstack/tripleo-ui/blob/master/docs/translation.rst#extracting-messages-from-components
[3] 
https://github.com/openstack/tripleo-ui/blob/master/src/js/components/nodes/Nodes.js#L17
[4] https://github.com/openstack/tripleo-ui/blob/master/i18n/locales/es.json#L3

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


[openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

2017-04-10 Thread Akihiro Motoki
Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for
neutron stadium projects?
There are several projects under neutron stadium and they are trying
to add dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard
(VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can
provide its dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a
single repository
 for testing and translation supports. Each project needs to
explore the way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and
possible makes things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository
are implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

__
OpenStack Development Mailing 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] Boston Forum Schedule

2017-04-10 Thread Tom Fifield

On 10/04/17 22:19, Emilien Macchi wrote:

On Mon, Apr 10, 2017 at 7:31 AM, Flavio Percoco  wrote:

On 10/04/17 17:35 +0800, Tom Fifield wrote:


Hi everyone,

Thank you for the many excellent topics submitted for our first Forum. We
have updated the topic submission site with the status of each - please
check yours.

Please also find attached in PDF the proposed schedule for the Forum in
Boston.


Let us know if you see major issues with it. As Thierry said in design
summits past; "It's difficult to make too many changes at this stage as they
quickly cascade into breaking all sorts of constraints, but we may still be
able to accommodate some." :)

Eagle-eyed readers will see that there are a number of slots in gray (on
Thursday afternoon). These are being deliberately kept aside for the usual
few critical topics that come up in the next few weeks and also for the
discoveries we make in the first 3 days of the summit.

We'll soon publish the Forum sessions on the main schedule, using the
title, abstracts and moderators you submitted, but look forward to your
feedback in the mean-time!

Thank you all very much for making our first Forum a success.




Hey Folks,

Thanks for working on this.

The topic "Future of configuration management tools" seems to have been
scheduled twice. Is that expected or a mistake? In the schedule it's not
explicit whether it's a 2 parts topic or not.


Good point. I think 1 session to keep is enough and I checked both
slots, we can pick one of those, I don't see much conflict that would
prevent folks to have to make an hard choice.

Tom, any chance to remove the second slot please?



Yup, this was a mistake, sorry!


__
OpenStack Development Mailing 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][Token expiration]

2017-04-10 Thread lương hữu tuấn
Thanks Dolph,

I now have a pretty clear picture about it.

Br,

Tuan/Nokia

On Mon, Apr 10, 2017 at 2:58 PM, Dolph Mathews 
wrote:

> The token itself is still expired, regardless of where it's persisted, if
> at all. Expired tokens are only considered valid when presented as an
> X-Auth-Token to keystonemiddleware.auth_token along with a valid
> X-Service-Token, or when validating an X-Subject-Token against keystone
> directly using either:
>
>   HEAD /v3/auth/token?allow_expired
>   GET /v3/auth/token?allow_expired
>
> No configuration is required in keystone.conf to enable the feature.
>
> More documentation is available in the release notes [1][2] and in the
> sample configuration file [3] (see [token] allow_expired_window).
>
> [1] https://docs.openstack.org/releasenotes/keystone/ocata.
> html#new-features
> [2] https://docs.openstack.org/releasenotes/keystone/ocata.
> html#upgrade-notes
> [3] https://docs.openstack.org/ocata/config-reference/
> identity/samples/keystone.conf.html
>
> On Mon, Apr 3, 2017 at 7:58 AM lương hữu tuấn 
> wrote:
>
>> Hi Dolph,
>>
>> Thanks for reply, it means that from the db point of view, token is
>> expired but it is still passed to other service users in request (token
>> stored in memory?) and keystone allows this expired token? And to make this
>> feature working, we should apply the header of "X-Service-Token" and change
>> of "allow_expired" in keystone.conf.
>>
>> Br,
>>
>> Tuan/Nokia
>>
>> On Mon, Apr 3, 2017 at 2:36 PM, Dolph Mathews 
>> wrote:
>>
>> > does it mean that the token now will live forever
>>
>> No; it behaves as described in the document you linked. If you have any
>> specific security concerns, please raise them appropriately (such as a
>> security bug, if necessary).
>>
>> On Mon, Apr 3, 2017 at 5:27 AM lương hữu tuấn 
>> wrote:
>>
>> Hi keystone folks,
>>
>> I have had a chance to take a look to this below patch for allowing the
>> expired token and it was merged in Octaka:
>>
>> https://specs.openstack.org/openstack/keystone-specs/
>> specs/keystone/ocata/allow-expired.html
>>
>> In our project, we also have problem with token expiration when running
>> mistral workflow. I have a concern that if this patch works as it does,
>> does it mean that the token now will live forever ("forever" seems so
>> sloppy, but it seems like the token is no longer expired). In this case, it
>> seems not good for security purpose.
>>
>> Br,
>>
>> Tuan/Nokia
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>> -Dolph
>>
>> 
>> __
>> OpenStack Development Mailing 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
>>
> --
> -Dolph
>
> __
> OpenStack Development Mailing 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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Dean Troyer
On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki  wrote:
> (question not directly related to this topic)
> I am not sure there is a case where users still use API 2.36 for
> network management
> and newer API versions for other compute operation.

This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least one foot in both worlds.  There are other similar uses.

dt

-- 

Dean Troyer
dtro...@gmail.com

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


Re: [openstack-dev] Boston Forum Schedule

2017-04-10 Thread Emilien Macchi
On Mon, Apr 10, 2017 at 7:31 AM, Flavio Percoco  wrote:
> On 10/04/17 17:35 +0800, Tom Fifield wrote:
>>
>> Hi everyone,
>>
>> Thank you for the many excellent topics submitted for our first Forum. We
>> have updated the topic submission site with the status of each - please
>> check yours.
>>
>> Please also find attached in PDF the proposed schedule for the Forum in
>> Boston.
>>
>>
>> Let us know if you see major issues with it. As Thierry said in design
>> summits past; "It's difficult to make too many changes at this stage as they
>> quickly cascade into breaking all sorts of constraints, but we may still be
>> able to accommodate some." :)
>>
>> Eagle-eyed readers will see that there are a number of slots in gray (on
>> Thursday afternoon). These are being deliberately kept aside for the usual
>> few critical topics that come up in the next few weeks and also for the
>> discoveries we make in the first 3 days of the summit.
>>
>> We'll soon publish the Forum sessions on the main schedule, using the
>> title, abstracts and moderators you submitted, but look forward to your
>> feedback in the mean-time!
>>
>> Thank you all very much for making our first Forum a success.
>>
>>
>
> Hey Folks,
>
> Thanks for working on this.
>
> The topic "Future of configuration management tools" seems to have been
> scheduled twice. Is that expected or a mistake? In the schedule it's not
> explicit whether it's a 2 parts topic or not.

Good point. I think 1 session to keep is enough and I checked both
slots, we can pick one of those, I don't see much conflict that would
prevent folks to have to make an hard choice.

Tom, any chance to remove the second slot please?

Thanks!

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



-- 
Emilien Macchi

__
OpenStack Development Mailing 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] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Akihiro Motoki
I am okay to drop nova-network feature in Pike.

More generally, can we horizon team say the following?

 A feature deprecated in a back-end project is automatically
deprecated in Horizon
 and a feature in horizon will be dropped if a corresponding support
is dropped in
 a back-end project and/or its support library (like python bindings)
 even though horizon may provide an extended supports.

Akihiro

2017-03-29 7:02 GMT+09:00 Rob Cresswell :
> Frankly, it sounds like we can pretty comfortably drop support for nova-net
> in Pike. I'm fine with that, from a Horizon point of view.
>
> Rob
>
> On 28 March 2017 at 21:06, Matt Riedemann  wrote:
>>
>> On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
>> > Hi,
>> >
>> > I would like to raise a topic when horizon nova-network support can be
>> > dropped.
>> > I added [tc] tag as it is related to
>> > "assert:follows-standard-deprecation" tag in the governance.
>> >
>> > Can horizon drop nova-network support based on the deprecation of
>> > nova-network
>> > from the nova team?
>> > or does horizon need to deprecate nova-network support in horizon
>> > explicitly?
>> >
>> > Let me summarize the current situation:
>> > - nova team deprecated nova-network in Newton release. [1]
>> > - horizon team has not deprecated it so far (just forgot to do it).
>> > - nova-network security group and floating IP support has been dropped
>> > from novaclient few days ago [2].
>> > - When a new release of novaclient comes, horizon security group
>> > support will be broken (if neutron is not used)
>> > - Nova microversion also allows to use nova-network but old version of
>> > novaclient is required for horizon to
>> >   support it and it is not realistic.
>>
>> This is the tricky part. You can specify a microversion to use
>> novaclient with the nova-network behavior. If you're using the python
>> API bindings in novaclient, which I think Horizon is, then you have to
>> specify a microversion anyway. The nova-network API bindings in
>> novaclient will work up until 2.35.
>>
>> The messy part about this is when we release novaclient 8.0 then that
>> code is gone and microversions don't matter. So you'd have to use an
>> older version, 7.1.0 at this point. To do that, we have to essentially
>> cap novaclient to 7.1.0 in upper-constraints in the requirements repo
>> for the rest of Pike since Horizon won't work with 8.0.
>>
>> I don't want to cap novaclient in upper-constraints for the rest of
>> Pike, but at the same time, it's not great to just drop features out of
>> a UI without first telling users they are deprecated first. However,
>> having said that, isn't Horizon really the portal for the tenant user? I
>> know admins use it also, but the admin/operator should already know
>> about the nova-network deprecation. If they are just finding out about
>> this because their Horizon features all of a sudden don't work in Pike,
>> that's pretty bad on their part, in my opinion anyway. In this
>> perspective, I think it might be OK to drop nova-network support without
>> a deprecation period in Horizon for the things we've removed from
>> novaclient.
>>
>> >
>> > It would be nice that horizon team is allowed to drop some feature
>> > aligning with feature deprecation
>> > and drop in backend project(s) (without explicit deprecation notices
>> > in horizon side).
>> >
>> > It is not easy that horizon team is aware of all feature deprecations
>> > in other projects
>> > and the horizon team tends to be aware of them when the deprecated
>> > features are
>> > actually dropped.
>> >
>> > Thought?
>> >
>> > There may be things and solutions I am not aware of. Any feedback
>> > would be appreciated.
>>
>> Me too. :)
>>
>> >
>> > Best Regards,
>> > Akihiro
>> >
>> > [1]
>> > https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
>> > [2] https://review.openstack.org/#/c/447707/
>> >
>> >
>> > __
>> > OpenStack Development Mailing 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,
>>
>> Matt
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Akihiro Motoki
2017-03-29 5:06 GMT+09:00 Matt Riedemann :
> On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
>>
>> Hi,
>>
>> I would like to raise a topic when horizon nova-network support can be
>> dropped.
>> I added [tc] tag as it is related to
>> "assert:follows-standard-deprecation" tag in the governance.
>>
>> Can horizon drop nova-network support based on the deprecation of
>> nova-network
>> from the nova team?
>> or does horizon need to deprecate nova-network support in horizon
>> explicitly?
>>
>> Let me summarize the current situation:
>> - nova team deprecated nova-network in Newton release. [1]
>> - horizon team has not deprecated it so far (just forgot to do it).
>> - nova-network security group and floating IP support has been dropped
>> from novaclient few days ago [2].
>> - When a new release of novaclient comes, horizon security group
>> support will be broken (if neutron is not used)
>> - Nova microversion also allows to use nova-network but old version of
>> novaclient is required for horizon to
>>   support it and it is not realistic.
>
>
> This is the tricky part. You can specify a microversion to use novaclient
> with the nova-network behavior. If you're using the python API bindings in
> novaclient, which I think Horizon is, then you have to specify a
> microversion anyway. The nova-network API bindings in novaclient will work
> up until 2.35.

Sorry for my late.

Yes, nova supports nova-network API in API version up to 2.35.
Horizon now consumes python bindings from novaclient with version 2
(not latest API version) unless we need to use more recent version.
Horizon just started micro versioning support in Pile and most work is
under development.

> The messy part about this is when we release novaclient 8.0 then that code
> is gone and microversions don't matter. So you'd have to use an older
> version, 7.1.0 at this point. To do that, we have to essentially cap
> novaclient to 7.1.0 in upper-constraints in the requirements repo for the
> rest of Pike since Horizon won't work with 8.0.

Yeah, this is the most tricky part.

Is there any deprecation policy in novaclient python binding?
I was not aware of deprecation warnings.
If novaclient follows nova deprecation, it sounds reasonable to me.

> I don't want to cap novaclient in upper-constraints for the rest of Pike,
> but at the same time, it's not great to just drop features out of a UI
> without first telling users they are deprecated first. However, having said
> that, isn't Horizon really the portal for the tenant user? I know admins use
> it also, but the admin/operator should already know about the nova-network
> deprecation. If they are just finding out about this because their Horizon
> features all of a sudden don't work in Pike, that's pretty bad on their
> part, in my opinion anyway. In this perspective, I think it might be OK to
> drop nova-network support without a deprecation period in Horizon for the
> things we've removed from novaclient.

Horizon is both for tenant users and admin/operators.
In my understanding, operators need to know deprecation notices of various
projects and decide which version they should provide.
This applies to horizon too. If they want to provide nova-network
support in horizon,
they can choose a way not to upgrade horizon to Pike.
Nova already deprecated nova-network after Nova API 2.36 and this means
users cannot use newer features anymore as if a newer API version is used
nova-network is not take into account. What is the merit of upgrading
nova and horizon?

Considering the above, it looks okay to me to drop nova-network support
from horizon in Pike based on nova-team deprecation of nova-network in Newton.

(question not directly related to this topic)
I am not sure there is a case where users still use API 2.36 for
network management
and newer API versions for other compute operation.

Akihiro

>
>>
>> It would be nice that horizon team is allowed to drop some feature
>> aligning with feature deprecation
>> and drop in backend project(s) (without explicit deprecation notices
>> in horizon side).
>>
>> It is not easy that horizon team is aware of all feature deprecations
>> in other projects
>> and the horizon team tends to be aware of them when the deprecated
>> features are
>> actually dropped.
>>
>> Thought?
>>
>> There may be things and solutions I am not aware of. Any feedback
>> would be appreciated.
>
>
> Me too. :)
>
>>
>> Best Regards,
>> Akihiro
>>
>> [1]
>> https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
>> [2] https://review.openstack.org/#/c/447707/
>>
>> __
>> OpenStack Development Mailing 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,
>
> Matt
>
> 

Re: [openstack-dev] Boston Forum Schedule

2017-04-10 Thread Thierry Carrez
David Medberry wrote:
> Are the three rooms roughly the same size?

102 and 103 are slightly larger than 104.
Cheers,

-- 
Thierry Carrez (ttx)

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


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

2017-04-10 Thread Amrith Kumar
> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Monday, April 10, 2017 5:17 AM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [tc] [elections] Available time and top priority
> 
> Hi everyone,
> 
> New in this TC election round, we have a few days between nominations and
> actual voting to ask questions and get to know the candidates a bit better.
> I'd like to kick off this new "campaigning period" with a basic question on
> available time and top priority.
> 
> All the candidates are top community members with a lot of responsibilities
> on their shoulders already. My experience tells me that it is easy to
> overestimate the time we can dedicate to Technical Committee matters, and how
> much we can push and get done in six months or one year. At the same time,
> our most efficient way to make progress is always when someone "owns" a
> particular initiative and pushes it through the governance process.
> 
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing proposed
> changes and pushing your own) ? If there was ONE thing, one initiative, one
> change you will actively push in the six months between this election round
> and the next, what would it be ?
> 

[Amrith Kumar] I have the (somewhat) luxury of being able to devote a 
significant portion of my time to activities of OpenStack and the technical 
committee in the new role that I will be entering into. I will therefore be 
able to devote at least 20% of my time to activities related to the technical 
committee.

The one initiative that I would drive would be to build community for projects 
that (like Trove) face a declining participation, and are facing the same 
kind(s) of challenges when it comes to the mechanics of reviewing changes, 
keeping up with the rest of OpenStack, and continuing to make forward progress 
on their own deliverables.

It will be part of my new role to establish a core group of OpenStack talent 
who will participate in a number of projects (including, of course Trove). This 
initiative is not something new for me, I've been doing this for some time now. 
I gratefully acknowledge the help I've received in this area from many in the 
community, and most of all from dims (also candidate for election to the TC 
this cycle, please also vote for him) and want to build a larger group of 
motivated contributors who are willing to take time out of their schedules and 
participate in the effort of growing the community and the leadership. I've 
been participating in the activities of the SWG (since its inception) and I see 
this not so much as an 'election campaign' but rather a continuation of what 
I've been espousing for some time now.

The success of OpenStack in its mission to be the ubiquitous cloud computing 
platform depends in large part on the vibrant community in all of the projects 
that form part of OpenStack, not just the high profile ones. For this mission 
to be fulfilled, it will be essential that this community which has been 
weakened by recent corporate redirections be rebuilt through the introduction 
of new participants and participating companies.

> Thanks in advance for your answers !
> 

[Amrith Kumar] Thanks for the question.

> --
> 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] Boston Forum Schedule

2017-04-10 Thread David Medberry
Are the three rooms roughly the same size?

On Mon, Apr 10, 2017 at 3:35 AM, Tom Fifield  wrote:

> Hi everyone,
>
> Thank you for the many excellent topics submitted for our first Forum. We
> have updated the topic submission site with the status of each - please
> check yours.
>
> Please also find attached in PDF the proposed schedule for the Forum in
> Boston.
>
>
> Let us know if you see major issues with it. As Thierry said in design
> summits past; "It's difficult to make too many changes at this stage as
> they quickly cascade into breaking all sorts of constraints, but we may
> still be able to accommodate some." :)
>
> Eagle-eyed readers will see that there are a number of slots in gray (on
> Thursday afternoon). These are being deliberately kept aside for the usual
> few critical topics that come up in the next few weeks and also for the
> discoveries we make in the first 3 days of the summit.
>
> We'll soon publish the Forum sessions on the main schedule, using the
> title, abstracts and moderators you submitted, but look forward to your
> feedback in the mean-time!
>
> Thank you all very much for making our first Forum a success.
>
>
> Regards,
>
> Doug, Emilien, Melvin, Mike, Shamail & Tom
> Forum Scheduling Committee
>
> __
> OpenStack Development Mailing 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] [tripleo][kolla] extended start and hostpath persistent dirs

2017-04-10 Thread Jiří Stránský
Responses inline :) I started snipping parts out because the quotations 
are getting long.





tl;dr use kolla images and bootsrap OR upstream images with
direct
commands:

.. code-block:: yaml
kolla_config:
/var/lib/kolla/config_files/foo.json
  command: /usr/bin/foo


We insist on using kolla extended start, if only it can't function
w/o Kolla extended start using Kolla images (like Mysql and Rabbitmq
have some extra initialization)



I don't think we need to insist on this, in fact i'd even prefer not 
using kolla_start in cases where it doesn't provide significant value.


In addition to the Kolla flavor that Dan mentioned earlier, using these 
entrypoints also increases chance of TripleO being broken by a commit to 
Kolla, because Kolla commits aren't gated on deploying TripleO.


If the only thing we need is the file permissions setup, we don't even 
need to use kolla_start for that, we can use kolla_set_configs [4] 
directly in an init container. (But again, i don't think we need to 
force this as a rule.)






vs

.. code-block:: yaml
foo:
image: upstream/foo:latest
command: /usr/bin/foo


We accept direct commands as well, if it works w/o "user: root" for
Kolla containers omitting extended start OR if it just works as is with
upstream containers (non Kolla), like etcd [2] and perhaps redis


I think using direct commands is fine.

However, i think we should avoid targeting any images that we can't 
build ourselves easily. One of the benefits of using Kolla images is a 
uniform way how to build them.





* Custom entrypoints for containers adds complexity and head ache.


Good point. But the entry points Kolla uses for many containers don't
match what our systemd services already use on baremetal. As we are
striving for update path that does not break end users upgrading from
baremetal to containers we have to have a mechanism that gives us
configuration parity across the implementions. Controlling the entry
point either by injecting it into the container (via something like
Kolla's template overrides mechanism) or via tripleo-heat-templates
direction (much more hackable) is where we ended up.


Yea i'd very much prefer using entrypoints that are easily amendable by 
TripleO developers, and are gated on deploying TripleO.


As for having them in-image or externally passed from t-h-t, that could 
almost be a thread on its own :) The benefit of t-h-t approach is 
hackability. The benefit of in-image approach is being sure that the 
image version is compatible with its entrypoint (for rollbacks and such) 
and generally the image being more self contained (being able to use it 
easier manually, without Heat/t-h-t, should the need arise).


I think we may still be forming our opinion on this matter as we hit 
issues with one or the other approach, maybe we'll even continue using 
different approaches for different use cases.




In general we like Kolla images at the moment for what they provide.
But there are some cases where we need to control things that have too
much of a "kolla flavor" and would potentially break upgrades/features
if we used them directly.



We accept custom entry points for some tricky cases as well.

Having that said, I'd really like to see a final call for that topic.
Otherwise it's really hard to do a code review and perhaps to maintain
changes to t-h-t for future releases as well.




Cheers

Jirka

[4] 
https://github.com/openstack/kolla/blob/77903c70cd651ad97a6a918f6889e5120d85b8d1/docker/base/start.sh#L14


__
OpenStack Development Mailing 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][Token expiration]

2017-04-10 Thread Dolph Mathews
The token itself is still expired, regardless of where it's persisted, if
at all. Expired tokens are only considered valid when presented as an
X-Auth-Token to keystonemiddleware.auth_token along with a valid
X-Service-Token, or when validating an X-Subject-Token against keystone
directly using either:

  HEAD /v3/auth/token?allow_expired
  GET /v3/auth/token?allow_expired

No configuration is required in keystone.conf to enable the feature.

More documentation is available in the release notes [1][2] and in the
sample configuration file [3] (see [token] allow_expired_window).

[1] https://docs.openstack.org/releasenotes/keystone/ocata.html#new-features
[2]
https://docs.openstack.org/releasenotes/keystone/ocata.html#upgrade-notes
[3]
https://docs.openstack.org/ocata/config-reference/identity/samples/keystone.conf.html

On Mon, Apr 3, 2017 at 7:58 AM lương hữu tuấn  wrote:

> Hi Dolph,
>
> Thanks for reply, it means that from the db point of view, token is
> expired but it is still passed to other service users in request (token
> stored in memory?) and keystone allows this expired token? And to make this
> feature working, we should apply the header of "X-Service-Token" and change
> of "allow_expired" in keystone.conf.
>
> Br,
>
> Tuan/Nokia
>
> On Mon, Apr 3, 2017 at 2:36 PM, Dolph Mathews 
> wrote:
>
> > does it mean that the token now will live forever
>
> No; it behaves as described in the document you linked. If you have any
> specific security concerns, please raise them appropriately (such as a
> security bug, if necessary).
>
> On Mon, Apr 3, 2017 at 5:27 AM lương hữu tuấn 
> wrote:
>
> Hi keystone folks,
>
> I have had a chance to take a look to this below patch for allowing the
> expired token and it was merged in Octaka:
>
>
> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/allow-expired.html
>
> In our project, we also have problem with token expiration when running
> mistral workflow. I have a concern that if this patch works as it does,
> does it mean that the token now will live forever ("forever" seems so
> sloppy, but it seems like the token is no longer expired). In this case, it
> seems not good for security purpose.
>
> Br,
>
> Tuan/Nokia
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> -Dolph
>
> __
> OpenStack Development Mailing 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
>
-- 
-Dolph
__
OpenStack Development Mailing 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] allow_instance_snapshots config option is not used consistently

2017-04-10 Thread Matt Riedemann

On 4/10/2017 5:20 AM, sfinu...@redhat.com wrote:

On Mon, 2017-04-10 at 10:24 +0100, John Garbutt wrote:

On 10 April 2017 at 01:56, Matt Riedemann 
wrote:

I found a fun little legacy nugget of compute API non-
interoperability joy
tonight.

The "allow_instance_snapshots" config option disables the
createImage server
action API. Completely config driven and therefore not
discoverable.

What intrigues me is that this isn't applied to the createBackup or
shelve
APIs, which also create a snapshot of the instance. Is this by
design? I'm
guessing probably not. In fact, this predates the use of Gerrit [1]
so this
was probably just something hacked in so long ago it makes zero
sense now.
The way to disable any of these APIs now is via policy.

Unless anyone has an issue with this, I'm going to deprecate it for
removal.

[1]
https://github.com/openstack/nova/commit/9633e9877c7836c18c30b51c84
94abfb025e64ca


+1 for deprecate it.

That looks like something we did before we had policy.
Not that policy is that discoverable yet either, but it seems better.

Thanks,
john


I concur. Policy seems a far better way of configuring this.

Stephen

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



The question about deprecation was really just rhetorical. :)

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

--

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] [Cinder] Tags for volumes

2017-04-10 Thread Duncan Thomas
You can deploy Searchlight
(https://wiki.openstack.org/wiki/Searchlight) and it can handle this
and more complex metadata querying (it is backed by elastic search and
supports all of the expressive power of elastic search queries).
There's a limit to how much query functionality can go into a basic
API service before DoS becomes a serious issue, or you start to
require serious database restructuring.

As an extreme example, I've repeated resisted attempts to add regexp
matching into the cinder API since nobody has come up with any way to
deal with the DoS issues - I suspect the regexp processing in nova is
vulnerable though I've never spent the time to prove it.

On 10 April 2017 at 10:58, 王玺源  wrote:
> We have an user demand that volumes should be filtered by some operation
> with metadata(or tag):
> 1. key1=value1
> 2. key1=value1 and key2=value2
> 3. key1=value1 or key1=value2
> 4. key1=value1 or key2=value2
> 5. not key1=value1
> 6. not key1=value1 and not key1=value2
> 7. not key1=value1 and not key2=value2
> 8. not key1=value1 and key2=value2
>
> But AFAIK Cinder now use metadata as a filter when list volumes, so it only
> support the 1 and 2.
>
> Is there any suggestion that how Cinder can support them?
>
>
> Thanks
> Wangxiyuan
>
> 2017-04-08 8:49 GMT+08:00 Matt Riedemann :
>>
>> On 3/27/2017 9:59 AM, Duncan Thomas wrote:
>>>
>>> On 27 March 2017 at 14:20, 王玺源 >> > wrote:
>>>
>>> I think the reason is quite simple:
>>> 1. Some users don't want to use key/value pairs to tag volums. They
>>> just need some simple strings.
>>>
>>>
>>> ...and some do. We can hide this in the client and just save tags under
>>> a metadata item called 'tags', with no API changes needed on the cinder
>>> side and backwards compatability on the client.
>>>
>>>
>>> 2. Metadata must be shorter than 255. If users don't need keys, use
>>> tag here can save some spaces.
>>>
>>>
>>> How many / long tags are you considering supporting?
>>>
>>>
>>> 3. Easy for quick searching or filter. Users don't need to know
>>> what' the key related to the value.
>>>
>>>
>>> The client can hide all this, so it is not really a justification
>>>
>>>
>>> 4. For Web App, it should be a basic function[1]
>>>
>>>
>>> Web standards are not really standards. You can find a million things
>>> that apps 'should' do. They're usually contradictory.
>>>
>>>
>>>
>>>
>>> [1]https://en.m.wikipedia.org/wiki/Tag_(metadata)
>>> 
>>>
>>>
>>> 2017-03-27 19:49 GMT+08:00 Sean McGinnis :
>>>
>>> On Mon, Mar 27, 2017 at 03:13:59PM +0800, 王玺源 wrote:
>>> > Hi cinder team:
>>> >
>>> > I want to know what's your thought about adding tags for
>>> volumes.
>>> >
>>> > Now Many resources, like Nova instances, Glance images,
>>> Neutron
>>> > networks and so on, all support tagging. And some of our cloud
>>> customers
>>> > want this feature in Cinder as well. It's useful for auditing,
>>> billing for
>>> > could admin, it can let admin and users filter resources by
>>> tag, it can let
>>> > users categorize resources for different usage or just remarks
>>> something.
>>> >
>>> > Actually there is a related spec in Cinder 2 years ago, but
>>> > unfortunately it was not accepted and was abandoned :
>>> > https://review.openstack.org/#/c/99305/
>>> 
>>> >
>>> > Can we bring it up and revisit it a second time now? What's
>>> cinder
>>> > team's idea?  Can you give me some advice that if we can do it
>>> or not?
>>>
>>> Can you give any reason why the existing metadata mechanism does
>>> not or will
>>> not work for them? There was some discussion in that spec
>>> explaining why it
>>> was rejected at the time. I don't think anything has changed
>>> since then that
>>> would change what was said there.
>>>
>>> >
>>> >
>>> > Thanks!
>>> >
>>> > Wangxiyuan
>>>
>>> >
>>>
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>
>>> 
>>> >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> 

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

2017-04-10 Thread Flavio Percoco

On 10/04/17 11:16 +0200, Thierry Carrez wrote:

Hi everyone,

New in this TC election round, we have a few days between nominations
and actual voting to ask questions and get to know the candidates a bit
better. I'd like to kick off this new "campaigning period" with a basic
question on available time and top priority.

All the candidates are top community members with a lot of
responsibilities on their shoulders already. My experience tells me that
it is easy to overestimate the time we can dedicate to Technical
Committee matters, and how much we can push and get done in six months
or one year. At the same time, our most efficient way to make progress
is always when someone "owns" a particular initiative and pushes it
through the governance process.

So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ?


I consider my role in the TC to be half of my work in the community. The other
half is covered by my other technical contributions. My reviews and proposed
changes on the Technical Committee tasks are as "important" (if not more,
sometimes) as my contributions to other tasks.


If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?


One thing I'd love to see happening more is to have more bridges built between
the OpenStack community and other cloud communities like CNCF. I truly believe
there's lots we can learn from each other and share. However, for us to be able
to create stable, solid, bridges, we need to think of ourselves as a single
community composed by multiple bricks. These bricks can be used as a group or
individually but they definitely cooperate between them. Make OpenStack more
"programmable/flexible".

So, to answer your question directly, I'd choose to focus on improving the
OpenStack community by taking the time to check where we are, what we are, where
we are headed, how we can there. Documenting this process, the OpenStack culture
and making sure the community is in a healthy state team/project wise. I think
this would make our existing interactions with other communities better and
it'll also help creating new ones.

Flavio

--
@flaper87
Flavio Percoco


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


Re: [openstack-dev] Boston Forum Schedule

2017-04-10 Thread Flavio Percoco

On 10/04/17 17:35 +0800, Tom Fifield wrote:

Hi everyone,

Thank you for the many excellent topics submitted for our first Forum. 
We have updated the topic submission site with the status of each - 
please check yours.


Please also find attached in PDF the proposed schedule for the Forum 
in Boston.



Let us know if you see major issues with it. As Thierry said in design 
summits past; "It's difficult to make too many changes at this stage 
as they quickly cascade into breaking all sorts of constraints, but we 
may still be able to accommodate some." :)


Eagle-eyed readers will see that there are a number of slots in gray 
(on Thursday afternoon). These are being deliberately kept aside for 
the usual few critical topics that come up in the next few weeks and 
also for the discoveries we make in the first 3 days of the summit.


We'll soon publish the Forum sessions on the main schedule, using the 
title, abstracts and moderators you submitted, but look forward to 
your feedback in the mean-time!


Thank you all very much for making our first Forum a success.




Hey Folks,

Thanks for working on this.

The topic "Future of configuration management tools" seems to have been
scheduled twice. Is that expected or a mistake? In the schedule it's not
explicit whether it's a 2 parts topic or not.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


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


[openstack-dev] Reminder User Committee Meeting

2017-04-10 Thread Melvin Hillsman
Hey everyone,

User Committee will meet today in #openstack-meeting @ 1900UTC. If you have
any requests for agenda items you can reply to this email or message any of
the UC members via email as well as IRC - #openstack-uc

-- 
Kind regards,

OpenStack UC
__
OpenStack Development Mailing 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][nova] Suggestion required on pci_device inventory addition to ironic and its subsequent changes in nova

2017-04-10 Thread John Garbutt
On 10 April 2017 at 11:31,   wrote:
> On Mon, 2017-04-10 at 11:50 +0530, Nisha Agarwal wrote:
>> Hi team,
>>
>> Please could you pour in your suggestions on the mail?
>>
>> I raised a blueprint in Nova for this https://blueprints.launchpad.ne
>> t/nova/+spec/pci-passthorugh-for-ironic and two RFEs at ironic side h
>> ttps://bugs.launchpad.net/ironic/+bug/1680780 and https://bugs.launch
>> pad.net/ironic/+bug/1681320 for the discussion topic.
>
> If I understand you correctly, you want to be able to filter ironic
> hosts by available PCI device, correct? Barring any possibility that
> resource providers could do this for you yet, extending the nova ironic
> driver to use the PCI passthrough filter sounds like the way to go.

With ironic I thought everything is "passed through" by default,
because there is no virtualization in the way. (I am possibly
incorrectly assuming no BIOS tricks to turn off or re-assign PCI
devices dynamically.)

So I am assuming this is purely a scheduling concern. If so, why are
the new custom resource classes not good enough? "ironic_blue" could
mean two GPUs and two 10Gb nics, "ironic_yellow" could mean one GPU
and one 1Gb nic, etc.

Or is there something else that needs addressing here? Trying to
describe what you get with each flavor to end users? Are you needing
to aggregating similar hardware in a different way to the above
resource class approach?

Thanks,
johnthetubaguy

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


Re: [openstack-dev] [tripleo][kolla] extended start and hostpath persistent dirs

2017-04-10 Thread Bogdan Dobrelya
Dan, Martin, Jiri, and all folks, how could we make a final call for
this please?
The decision impacts code review for new patches, like redis [0] or etcd [1]

[0] https://review.openstack.org/#/c/442151/
[1] https://review.openstack.org/#/c/447627/

As I see (suggest) it:

On 04.04.2017 22:53, Dan Prince wrote:
> On Tue, 2017-04-04 at 18:03 +0200, Bogdan Dobrelya wrote:
>> On 03.04.2017 21:01, Dan Prince wrote:
>>> On Mon, 2017-04-03 at 16:15 +0200, Bogdan Dobrelya wrote:
 Let's please re-evaluate configuration of containerized non-
 openstack,
 like database, message queue, key value, web, services for
 tripleo
 heat
 templates and Kolla. Here is an example containerized etcd patch
 [0].

 tl;dr use kolla images and bootsrap OR upstream images with
 direct
 commands:

 .. code-block:: yaml
 kolla_config:
 /var/lib/kolla/config_files/foo.json
   command: /usr/bin/foo

We insist on using kolla extended start, if only it can't function
w/o Kolla extended start using Kolla images (like Mysql and Rabbitmq
have some extra initialization)



 vs

 .. code-block:: yaml
 foo:
 image: upstream/foo:latest
 command: /usr/bin/foo

We accept direct commands as well, if it works w/o "user: root" for
Kolla containers omitting extended start OR if it just works as is with
upstream containers (non Kolla), like etcd [2] and perhaps redis

[2] https://quay.io/repository/coreos/etcd

>> [tl;dr] kolla_config is a bad fit for logs, let's run containers'
>> steps
>> as 'user: root' in a user namespace remapped [1] for a
>> tripleocontainers

If a container wants its main entry point to be run as a root, like the
example upstream etcd image expects, we shall accept that if only tht
root is remapped [3] to some system (e.g. tripleocontainers) user
namespace done for docker

[3] https://goo.gl/HtDQYk

>> * Custom entrypoints for containers adds complexity and head ache.
> 
> Good point. But the entry points Kolla uses for many containers don't
> match what our systemd services already use on baremetal. As we are
> striving for update path that does not break end users upgrading from
> baremetal to containers we have to have a mechanism that gives us
> configuration parity across the implementions. Controlling the entry
> point either by injecting it into the container (via something like
> Kolla's template overrides mechanism) or via tripleo-heat-templates
> direction (much more hackable) is where we ended up.
> 
> In general we like Kolla images at the moment for what they provide.
> But there are some cases where we need to control things that have too
> much of a "kolla flavor" and would potentially break upgrades/features
> if we used them directly.
> 

We accept custom entry points for some tricky cases as well.

Having that said, I'd really like to see a final call for that topic.
Otherwise it's really hard to do a code review and perhaps to maintain
changes to t-h-t for future releases as well.


-- 
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] [tc] [elections] Available time and top priority

2017-04-10 Thread Davanum Srinivas
Thierry, Team,

On Mon, Apr 10, 2017 at 5:16 AM, Thierry Carrez  wrote:
> Hi everyone,
>
> New in this TC election round, we have a few days between nominations
> and actual voting to ask questions and get to know the candidates a bit
> better. I'd like to kick off this new "campaigning period" with a basic
> question on available time and top priority.
>
> All the candidates are top community members with a lot of
> responsibilities on their shoulders already. My experience tells me that
> it is easy to overestimate the time we can dedicate to Technical
> Committee matters, and how much we can push and get done in six months
> or one year. At the same time, our most efficient way to make progress
> is always when someone "owns" a particular initiative and pushes it
> through the governance process.
>
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ? If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

We need to work better with other adjacent communities. We need to
find/make a place in the new/larger eco systems that are beginning to
shape up. I'd like to focus on intersections, boundaries to improve
what's possible and put our best foot (play to our strengths) forward.
This includes Kubernetes, Golang, Containers in general. Hopefully i
can get more people interested and excited in this initiative
irrespective of whether i am on the TC or not.

Thanks,
Dims

> Thanks in advance for your answers !
>
> --
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing 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][nova] Suggestion required on pci_device inventory addition to ironic and its subsequent changes in nova

2017-04-10 Thread sfinucan
On Mon, 2017-04-10 at 11:50 +0530, Nisha Agarwal wrote:
> Hi team,
> 
> Please could you pour in your suggestions on the mail?
> 
> I raised a blueprint in Nova for this https://blueprints.launchpad.ne
> t/nova/+spec/pci-passthorugh-for-ironic and two RFEs at ironic side h
> ttps://bugs.launchpad.net/ironic/+bug/1680780 and https://bugs.launch
> pad.net/ironic/+bug/1681320 for the discussion topic.

If I understand you correctly, you want to be able to filter ironic
hosts by available PCI device, correct? Barring any possibility that
resource providers could do this for you yet, extending the nova ironic
driver to use the PCI passthrough filter sounds like the way to go.

Stephen

> Regards
> Nisha
> 
> On Wed, Apr 5, 2017 at 11:03 PM, Nisha Agarwal  l.com> wrote:
> > Hi,
> > 
> > I suggested to add few pci devices related attributes to ironic
> > inspection(out-of-band as well inband). https://review.openstack.or
> > g/#/c/338138.
> > 
> > I got the suggestion to convert them to standard pci device format
> > which nova understands. For example( as given in Nova code):
> > [{"count": 5, "vendor_id": "8086", "product_id": "1520",
> >  "extra_info":'{}'}],
> > 
> > For above to be supported for ironic scheduling, we will require
> > changes at two places: 
> > 1. nova - This should require a small code changes as
> > pci_passthrough filter already exists in nova. The ironic virt
> > driver should be able to consume the pci_device structure from
> > ironic node/database and pass it on to scheduler for scheduling and
> > it should add pci_passthrough filter in ironic nodes filter list.
> > 2. ironic - this definitely needs a spec which will suggest to add
> > the pci_device data structure to ironic node.
> > 
> > 
> > The ironic side work may take some time but Nova side looks to be a
> > small change. IMO we can have the nova side changes and ironic
> > database changes (to add pci_device field) parallely. 
> > Inspection can populate that new pci_device field for the node to
> > get scheduled.
> > 
> > AFAIK, ironic-inspector already has the plugin to discover pci
> > devices in the format nova has it today. If we get the scheduling
> > enabled based on pci_devices for ironic nodes, then inspector can
> > write this data to ironic node object by default.
> > 
> > What do you people think on this idea? Does it make sense? If its
> > worth to do this way i can own up this work.
> > 
> > Regards
> > Nisha
> > 
> > -- 
> > The Secret Of Success is learning how to use pain and pleasure,
> > instead
> > of having pain and pleasure use you. If You do that you are in
> > control
> > of your life. If you don't life controls you.
> > 
> 
> 
> 
> -- 
> The Secret Of Success is learning how to use pain and pleasure,
> instead
> of having pain and pleasure use you. If You do that you are in
> control
> of your life. If you don't life controls you.
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


[openstack-dev] [nova] notification update week 14

2017-04-10 Thread Balazs Gibizer

Hi,

Here is the status update / focus setting mail about notification work
for week 14.

Bugs

[Medium] https://bugs.launchpad.net/nova/+bug/1657428 The instance
notifications are sent with inconsistent timestamp format. Fix seems
abandoned by the original author so I will update it soon to
fix the review comments on https://review.openstack.org/#/c/421981



Versioned notification transformation
-
The volume_attach and detach notifications are still in focus to support
Searchlight switching to the versioned notifications:
* https://review.openstack.org/#/c/401992/ Transform
instance.volume_attach notification. It is ready for core review.
* https://review.openstack.org/#/c/408676/ Transform
instance.volume_detach notification. It needs some update to make
Jenkins happy.


Searchlight integration
---
changing Searchlight to use versioned notifications
~~~
https://blueprints.launchpad.net/searchlight/+spec/nova-versioned-notifications
bp is a hard dependency for the integration work.

There is a WIP path on searchlight side to follow 
https://review.openstack.org/#/c/453352/



bp additional-notification-fields-for-searchlight
~
Besides volume_attach and volume_detach we need the following patches to
help Searchlight integration:
https://review.openstack.org/#/q/status:open+topic:bp/additional-notification-fields-for-searchlight
Some of them only missing a second +2.
There seems to be a debate about adding the tags field as it is a lazy 
loaded field. Tags can only have new value in instance.create and 
instance.update notifications so we might be able to limit the db load 
by only add tags there. This is a change in the original direction 
where we made the tags field loaded by default to avoid this 
complication.


The https://review.openstack.org/#/c/448779/ (Add BDM to 
InstancePayload) is now updated with the agreed bdms_in_notifications 
config option to allow limiting the db load.



Other items
---
soft_delete and force_delete

During solving a regression about sending delete notifications for 
unscheduled instances some of the soft_delete cases are removed. The 
patch continuing the transformation of instance.delete notifications 
hit a wall of soft_ and force_delete in 
https://review.openstack.org/#/c/443764/ use context mgr in 
instance.delete. This need some discussion how to move forward.


Inheritance in notification payload types
~
During the implementation of https://review.openstack.org/#/c/453667 
(Add snapshot id to the snapshot notifications) we realized that the 
inheritance used in the notification payload classes has some 
drawbacks. When we need to introduce new leaf classes the content of 
the nova.obj_name field will change in the emited payload. This should 
be avoided if possible or at least we have to keep the version number 
increasing all the time. See the 
https://review.openstack.org/#/c/453667/ (explain payload inheritance 
in notification devref) for more info.


Remove notification sample duplications
~~
Every notification has its own sample file in nova tree for functional 
testing and for doc generation. Many notifications use the same payload 
structure and therefore these sample files are quite similar to each 
other. If a new field is added to the payload a lot of sample file 
needs to be updated. The following patch series show a way to remove 
such duplications https://review.openstack.org/#/c/452818/ (Factor out 
duplicated notification sample data)



Small improvements
~~
https://review.openstack.org/#/c/418489/ (Remove **kwargs passing in 
payload __init__)
https://review.openstack.org/#/c/428199/ (Improve assertJsonEqual error 
reporting)
https://review.openstack.org/#/c/443686/ (Using max api version in 
notification sample test)

https://review.openstack.org/#/c/450787/ (remove ugly local import)
https://review.openstack.org/#/c/443677/ (Add json style checking for 
sample notifications)



Weekly meeting
--
The notification subteam holds it's weekly meeting on Tuesday 17:00 UTC
on openstack-meeting-4 so the next meeting will be held on 11th of
April.
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170411T17

Cheers,
gibi




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


Re: [openstack-dev] [nova] allow_instance_snapshots config option is not used consistently

2017-04-10 Thread sfinucan
On Mon, 2017-04-10 at 10:24 +0100, John Garbutt wrote:
> On 10 April 2017 at 01:56, Matt Riedemann 
> wrote:
> > I found a fun little legacy nugget of compute API non-
> > interoperability joy
> > tonight.
> > 
> > The "allow_instance_snapshots" config option disables the
> > createImage server
> > action API. Completely config driven and therefore not
> > discoverable.
> > 
> > What intrigues me is that this isn't applied to the createBackup or
> > shelve
> > APIs, which also create a snapshot of the instance. Is this by
> > design? I'm
> > guessing probably not. In fact, this predates the use of Gerrit [1]
> > so this
> > was probably just something hacked in so long ago it makes zero
> > sense now.
> > The way to disable any of these APIs now is via policy.
> > 
> > Unless anyone has an issue with this, I'm going to deprecate it for
> > removal.
> > 
> > [1]
> > https://github.com/openstack/nova/commit/9633e9877c7836c18c30b51c84
> > 94abfb025e64ca
> 
> +1 for deprecate it.
> 
> That looks like something we did before we had policy.
> Not that policy is that discoverable yet either, but it seems better.
> 
> Thanks,
> john

I concur. Policy seems a far better way of configuring this.

Stephen

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


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

2017-04-10 Thread John Garbutt
On 10 April 2017 at 10:16, Thierry Carrez  wrote:
> All the candidates are top community members with a lot of
> responsibilities on their shoulders already. My experience tells me that
> it is easy to overestimate the time we can dedicate to Technical
> Committee matters, and how much we can push and get done in six months
> or one year. At the same time, our most efficient way to make progress
> is always when someone "owns" a particular initiative and pushes it
> through the governance process.

I am not productive during the TC meeting, its too late for me to
think properly. Similarly much of the travel I have had to skip
(partly due to the personal cost, more recently due to budget
constraints) feels like it has limited my involvement with the TC over
the past year. I want to help make us a more globally welcoming group.

I have found it very hard to pick TC related efforts, work out what
others are doing, what is urgent vs important. I believe the TC vision
will help with that massively.

My recent focus has been around the TC vision, and SWG efforts. More
generally, I have been looking at Nova reaching out to related
projects, like Keystone, Cinder and Neutron, and helping to break down
the silos a little. That has lead me to look at creating the VM and
Baremetal working group, getting groups of projects to get feedback
together. If it works, it might be a pattern other constellations of
projects could copy. While that is just "Nova" work, I hope to share
success and failures to help other collaboration efforts.

> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ?

I hope to spend a minimum of 10% of my work time on TC related
efforts, regardless of being elected or not.

If elected, I hope to increase that to at least 20%.

> If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

The TC vision.

Lets reach out to get feedback to help refine and revise the vision.
Then lets get it agreed, and start the work to make it reality.

After we have that agreed, I think my focus will turn to the feedback
loops in our community. By that I mean helping breaking down the silos
between the different groups of developers in our community, between
developers vs users, and so on. The VM & Baremetal group is my latest
push in that general direction. The long term aim being improving the
user experience for all the different users of all the various
constellations in OpenStack.

Thanks,
johnthetubaguy

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


Re: [openstack-dev] [Cinder] Tags for volumes

2017-04-10 Thread 王玺源
We have an user demand that volumes should be filtered by some operation
with metadata(or tag):
1. key1=value1
2. key1=value1 and key2=value2
3. key1=value1 or key1=value2
4. key1=value1 or key2=value2
5. not key1=value1
6. not key1=value1 and not key1=value2
7. not key1=value1 and not key2=value2
8. not key1=value1 and key2=value2

But AFAIK Cinder now use metadata as a filter when list volumes, so it only
support the 1 and 2.

Is there any suggestion that how Cinder can support them?


Thanks
Wangxiyuan

2017-04-08 8:49 GMT+08:00 Matt Riedemann :

> On 3/27/2017 9:59 AM, Duncan Thomas wrote:
>
>> On 27 March 2017 at 14:20, 王玺源 > > wrote:
>>
>> I think the reason is quite simple:
>> 1. Some users don't want to use key/value pairs to tag volums. They
>> just need some simple strings.
>>
>>
>> ...and some do. We can hide this in the client and just save tags under
>> a metadata item called 'tags', with no API changes needed on the cinder
>> side and backwards compatability on the client.
>>
>>
>> 2. Metadata must be shorter than 255. If users don't need keys, use
>> tag here can save some spaces.
>>
>>
>> How many / long tags are you considering supporting?
>>
>>
>> 3. Easy for quick searching or filter. Users don't need to know
>> what' the key related to the value.
>>
>>
>> The client can hide all this, so it is not really a justification
>>
>>
>> 4. For Web App, it should be a basic function[1]
>>
>>
>> Web standards are not really standards. You can find a million things
>> that apps 'should' do. They're usually contradictory.
>>
>>
>>
>>
>> [1]https://en.m.wikipedia.org/wiki/Tag_(metadata)
>> 
>>
>>
>> 2017-03-27 19:49 GMT+08:00 Sean McGinnis :
>>
>> On Mon, Mar 27, 2017 at 03:13:59PM +0800, 王玺源 wrote:
>> > Hi cinder team:
>> >
>> > I want to know what's your thought about adding tags for
>> volumes.
>> >
>> > Now Many resources, like Nova instances, Glance images,
>> Neutron
>> > networks and so on, all support tagging. And some of our cloud
>> customers
>> > want this feature in Cinder as well. It's useful for auditing,
>> billing for
>> > could admin, it can let admin and users filter resources by
>> tag, it can let
>> > users categorize resources for different usage or just remarks
>> something.
>> >
>> > Actually there is a related spec in Cinder 2 years ago, but
>> > unfortunately it was not accepted and was abandoned :
>> > https://review.openstack.org/#/c/99305/
>> 
>> >
>> > Can we bring it up and revisit it a second time now? What's
>> cinder
>> > team's idea?  Can you give me some advice that if we can do it
>> or not?
>>
>> Can you give any reason why the existing metadata mechanism does
>> not or will
>> not work for them? There was some discussion in that spec
>> explaining why it
>> was rejected at the time. I don't think anything has changed
>> since then that
>> would change what was said there.
>>
>> >
>> >
>> > Thanks!
>> >
>> > Wangxiyuan
>>
>> >
>> 
>> __
>> > 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
>> 
>>
>>
>> 
>> __
>> 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
>> 
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>> --
>> --
>> Duncan Thomas
>>
>>
>> 

Re: [openstack-dev] [infra][docker] registry-1.docker.io to reverse proxy cache

2017-04-10 Thread Flavio Percoco

On 08/04/17 10:44 -0400, Paul Belanger wrote:

On Fri, Apr 07, 2017 at 12:15:49PM -0400, Paul Belanger wrote:

Greetings,

In an effort to help projects depending on docker infrastructure, we've setup a
reverse proxy cache for http://registry-1.docker.io. Please see the
instructions in 453811[1] on how to configure dockerd to use them.  While
testing, I did run into an issue with docker 17.04 so suggest you use a lower
version for now.

Please reply to the thread when you have a patches propose to use the proxy
cache. We working to update our configure_mirror.sh[2] so jobs get the URL
easier, hope to land this today. We'd like to monitor the proxy cache for a few
jobs first, before opening the flood gates.

If you have questions, feel free to drop by #openstack-infra or reply.

[1] https://review.openstack.org/#/c/453811/
[2] https://review.openstack.org/#/c/454334/


Our configure_mirror.sh script is now live, so you can find your regional
registry by doing the following:

 $ source /etc/ci/mirror_info.sh
 $ echo $NODEPOOL_DOCKER_REGISTRY_PROXY
 http://mirror.iad.rax.openstack.org:8081/registry-1.docker

on any of our zuul workers.


Thanks a bunch for setting this up,
Flavio

--
@flaper87
Flavio Percoco


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


[openstack-dev] Boston Forum Schedule

2017-04-10 Thread Tom Fifield

Hi everyone,

Thank you for the many excellent topics submitted for our first Forum. 
We have updated the topic submission site with the status of each - 
please check yours.


Please also find attached in PDF the proposed schedule for the Forum in 
Boston.



Let us know if you see major issues with it. As Thierry said in design 
summits past; "It's difficult to make too many changes at this stage as 
they quickly cascade into breaking all sorts of constraints, but we may 
still be able to accommodate some." :)


Eagle-eyed readers will see that there are a number of slots in gray (on 
Thursday afternoon). These are being deliberately kept aside for the 
usual few critical topics that come up in the next few weeks and also 
for the discoveries we make in the first 3 days of the summit.


We'll soon publish the Forum sessions on the main schedule, using the 
title, abstracts and moderators you submitted, but look forward to your 
feedback in the mean-time!


Thank you all very much for making our first Forum a success.


Regards,

Doug, Emilien, Melvin, Mike, Shamail & Tom
Forum Scheduling Committee


BOS-forum.pdf
Description: Adobe PDF document
__
OpenStack Development Mailing 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] allow_instance_snapshots config option is not used consistently

2017-04-10 Thread John Garbutt
On 10 April 2017 at 01:56, Matt Riedemann  wrote:
> I found a fun little legacy nugget of compute API non-interoperability joy
> tonight.
>
> The "allow_instance_snapshots" config option disables the createImage server
> action API. Completely config driven and therefore not discoverable.
>
> What intrigues me is that this isn't applied to the createBackup or shelve
> APIs, which also create a snapshot of the instance. Is this by design? I'm
> guessing probably not. In fact, this predates the use of Gerrit [1] so this
> was probably just something hacked in so long ago it makes zero sense now.
> The way to disable any of these APIs now is via policy.
>
> Unless anyone has an issue with this, I'm going to deprecate it for removal.
>
> [1]
> https://github.com/openstack/nova/commit/9633e9877c7836c18c30b51c8494abfb025e64ca

+1 for deprecate it.

That looks like something we did before we had policy.
Not that policy is that discoverable yet either, but it seems better.

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


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

2017-04-10 Thread Thierry Carrez
Hi everyone,

New in this TC election round, we have a few days between nominations
and actual voting to ask questions and get to know the candidates a bit
better. I'd like to kick off this new "campaigning period" with a basic
question on available time and top priority.

All the candidates are top community members with a lot of
responsibilities on their shoulders already. My experience tells me that
it is easy to overestimate the time we can dedicate to Technical
Committee matters, and how much we can push and get done in six months
or one year. At the same time, our most efficient way to make progress
is always when someone "owns" a particular initiative and pushes it
through the governance process.

So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ? If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?

Thanks in advance for your answers !

-- 
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-dev] [mistral] Team meeting - 04/10/2017

2017-04-10 Thread Ренат Ахмеров
Hi,

I’d like to invite Mistral team members to our weekly team meeting today at 
#openstack-meeting-3 at 15.00 UTC.

Agenda:

• Review action items
• Current status (progress, issues, roadblocks, further plans)
• Sync on Pike 1 progress
• Setting up project goals for 2017
• Open discussion


Generally we stopped sending out reminders regularly but I decided that I’d be 
doing it once in a while if some of the topics may potentially be interesting 
not only for core/active members.

[1] https://wiki.openstack.org/wiki/Meetings/MistralAgenda

Thanks

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


[openstack-dev] [kuryr] Weekly IRC meeting today April 10th is cancelled

2017-04-10 Thread Antoni Segura Puimedon
Hi Kuryrs,

I'm on PTO on the mountains with limited connectivity, hence I won't
be able to make it to the weekly IRC meeting.

Regards and sorry for the short notice,

Toni

__
OpenStack Development Mailing 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] [tripleo][manila] Ganesha deployment

2017-04-10 Thread Jan Provaznik
Hi,
TripleO currently supports deploying CephFS and it can be used as a
backend for Manila service, so user can mount ceph shares by using
either ceph kernel driver or ceph-fuse on his side.

There is an ongoing ganesha-nfs project [1] which can be used as a
proxy when accessing CephFS. The benefit is that user then interacts
only with ganesha server and mounts shares from this server using NFS
protocol.

And Manila will soon support both variants of ceph backend :
1) ceph is used directly (what we support now)
user instance <-- ceph protocol --> ceph cluster

2) ceph is used through ganesha server (what we don't support yet but
we would like)
user instance <-- NFS protocol --> ganesha server <-- ceph protocol
--> ceph cluster

We would like to enable both deployment options in TripleO and I
wonder how ganesha deployment should look like.

Prerequisities are:
- use of ganesha servers will be optional - operators can still choose
to use ceph directly, ideally it should be possible to deploy Manila
both with direct ceph and ganesha backends
- ganesha servers should not run on controller nodes (e.g. collocated
with manila-share service) because of data traffic, ideally ganesha
servers should be dedicated  (which is probably not a probablem with
composable services)
- ganesha servers will probably use active/passive HA model and will
be managed by pacemaker+corosync - AFAIK detailed HA architecture is
not specified yet and is still in progress by ganesha folks.

I imagine that (extremely simplified) setup would look
something like this from TripleO point of view:
1) define a new role (e.g. NfsStorage) which represents ganesha servers
2) define a new VIP (for IP failover) and 2 networks for NfsStorage role:
a) a frontend network between users and ganesha servers (e.g.
NfsNetwork name), used by tenants to mount nfs shares - this network
should be accessible from user instances.
b) a backend network between ganesha servers ans ceph cluster -
this could just map to the existing StorageNetwork I think.
3) pacemaker and ganesha setup magic happens - I wonder if the
existing puppet pacemaker modules could be used for setting up another
pacemaker cluster on dedicated ganesha nodes? It seems the long term
plan is to switch to ceph-ansible for ceph setup in TripleO. So should
be the whole HA setup of ganesha server delegated to the ceph ansible
isntead?

What i'm not sure at all is how network definition should look like.
There are following Overcloud deployment options:
1) no network isolation is used - then both direct ceph mount and
mount through ganesha should work because StorageNetwork and
NfsNetwork are accessible from user instances (there is no restriction
in accessing other networks it seems).
2) network isolation is used:
a) ceph is used directly - user instances need access to the ceph
public network (which is StorageNetwork in Overcloud) - how should I
enable access to this network? I filled a bug for this deployment
variant here [3]
b) ceph is used through ganesha - user instances need access to
ganesha servers (NfsNetwork in previous paragraph) - how should I
enable access to this network?

The ultimate (and future) plan is to deploy ganesha-nfs in VMs (which
will run in Overcloud, probably managed by manila ceph driver), in
this deployment mode a user should have access to ganesha servers and
only ganesha server VMs should have access to ceph public network.
Ganesha VMs would run in a separate tenant so I wonder if it's
possible to manage access to the ceph public network (StorageNetwork
in Overcloud) on per-tenant level?

Any thoughts and hints?

Thanks, Jan

[1] https://github.com/nfs-ganesha/nfs-ganesha/wiki
[2] https://github.com/ceph/ceph-ansible/tree/master/roles/ceph-nfs
[3] https://bugs.launchpad.net/tripleo/+bug/1680749

__
OpenStack Development Mailing 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] [tripleo][ui] another i18n proposal for heat templates 'description' help strings

2017-04-10 Thread Peng Wu
Hi,

  In TripleO UI project users requested translation of the web UI. But
some web UI strings are displayed from heat template files in tripleo-
heat-templates project.

  In order to get translated templates displayed in tripleo-ui, we
propose another solution as follows, which needs to change code in
tripleo-heat-templates and tripleo-ui projects.

  I18n proposal for Heat templates 'description' help strings

  1. Update tripleo-heat-templates to generate the javascript files to
include all translation strings, like "tripleo-heat-templates.js"

 a. Need to write python script to extract "title" and
"description" field from yaml files and generate "tripleo-heat-
templates.js" for react-intl usage in tripleo-ui

 b. Use default message as message id or consider nodejs-i18n for
tripleo-ui

  2. Update tripleo-ui to use "tripleo-heat-templates.js"

 a. Write some script to sync "tripleo-heat-templates.js" from
tripleo-heat-templates

 b. Call formatMessage function for "title" and "description" field
with message id (use default message) and default message or consider
nodejs-i18n for tripleo-ui

  Refer URL for message id: https://github.com/yahoo/react-intl/issues/
912

  Please evaluate it, thanks!

Regards,
  Peng


__
OpenStack Development Mailing 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][nova] Suggestion required on pci_device inventory addition to ironic and its subsequent changes in nova

2017-04-10 Thread Nisha Agarwal
Hi team,

Please could you pour in your suggestions on the mail?

I raised a blueprint in Nova for this
https://blueprints.launchpad.net/nova/+spec/pci-passthorugh-for-ironic and
two RFEs at ironic side https://bugs.launchpad.net/ironic/+bug/1680780 and
https://bugs.launchpad.net/ironic/+bug/1681320 for the discussion topic.

Regards
Nisha

On Wed, Apr 5, 2017 at 11:03 PM, Nisha Agarwal 
wrote:

> Hi,
>
> I suggested to add few pci devices related attributes to ironic
> inspection(out-of-band as well inband). https://review.
> openstack.org/#/c/338138.
>
> I got the suggestion to convert them to standard pci device format which
> nova understands. For example( as given in Nova code):
> [{"count": 5, "vendor_id": "8086", "product_id": "1520",
>  "extra_info":'{}'}],
>
> For above to be supported for ironic scheduling, we will require changes
> at two places:
> 1. nova - This should require a small code changes as pci_passthrough
> filter already exists in nova. The ironic virt driver should be able to
> consume the pci_device structure from ironic node/database and pass it on
> to scheduler for scheduling and it should add pci_passthrough filter in
> ironic nodes filter list.
> 2. ironic - this definitely needs a spec which will suggest to add the
> pci_device data structure to ironic node.
>
>
> The ironic side work may take some time but Nova side looks to be a small
> change. IMO we can have the nova side changes and ironic database changes
> (to add pci_device field) parallely.
> Inspection can populate that new pci_device field for the node to get
> scheduled.
>
> AFAIK, ironic-inspector already has the plugin to discover pci devices in
> the format nova has it today. If we get the scheduling enabled based on
> pci_devices for ironic nodes, then inspector can write this data to ironic
> node object by default.
>
> What do you people think on this idea? Does it make sense? If its worth to
> do this way i can own up this work.
>
> Regards
> Nisha
>
> --
> The Secret Of Success is learning how to use pain and pleasure, instead
> of having pain and pleasure use you. If You do that you are in control
> of your life. If you don't life controls you.
>



-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev