[openstack-dev] [kuryr][magnum]Installing kuryr for mutlinode openstack setup

[Akshay Kumar Sanghai]

Hi,
I have a 4 node openstack setup (1 controller, 1 network, 2 compute nodes).
I want to install kuryr in liberty version. I cannot find a package in
ubuntu repo.
-How do i install kuryr?
- what are the components that need to be installed on the respective
nodes?
- Do i need to install magnum for docker swarm?
- Can i use docker swarm, kubernetes, mesos in openstack without using
kuryr? What will be the disadvantages?

Thanks
Akshay
__
OpenStack Development Mailing 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] support of NSH in networking-SFC

[Elzur, Uri]

Hi Armando

Pls see below [UE]

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

From: Armando M. [mailto:arma...@gmail.com]
Sent: Friday, May 20, 2016 9:08 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 20 May 2016 at 17:37, Elzur, Uri 
> wrote:
Hi Armando, Cathy, All

First I apologize for the delay, returning from a week long international trip. 
(yes, I know,  a lousy excuse on many accounts…)

If I’m attempting to summarize all the responses, it seems like

• A given abstraction in Neutron is allowed (e.g. in support of SFC), 
preferably not specific to a given technology e.g. NSH for SFC

• A stadium project is not held to the same tests (but we do not have a 
“formal” model here, today) and therefore can support even a specific 
technology e.g. NSH (definitely better with abstractions to meet Neutron 
standards for future integration)

A given abstraction is allowed so long as there is enough agreement that it is 
indeed technology agnostic. If the abstraction maps neatly to a given 
technology, the implementation may exist within the context of Neutron or 
elsewhere.
[UE] I think we have agreement SFC is a needed abstraction

Having said that I'd like to clarify a point: you seem to refer to the stadium 
as a golden standard. The stadium is nothing else but a list of software 
repositories that the Neutron team develops and maintain. Given the maturity of 
a specific repo, it may or may not implement an abstraction with integration 
code to non open technologies. This is left at discretion of the group of folks 
who are directly in control of the specific repo, though it has been the 
general direction to strongly encourage and promote openness throughout the 
entire stack that falls under the responsibility of the Neutron team and thus 
the stadium.

[UE] carefully read 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and hope I understand Stadium. All NSH patches that we’d like to support are 
OPEN. I’m still looking for the place where a restriction prevents 
networking-SFC form moving forward on NSH before all other external projects to 
OpenStack has completed their work. Pls see also reply to Tim Rozet

However,

• There still is a chicken and egg phenomenon… how can a technology 
become main stream with OPEN SOURCE support  if we can’t get an OpenStack to 
support the required abstractions before the technology was adopted elsewhere??

o   Especially as Stadium, can we let Neutron to lead the industry, given broad 
enough community interest?

• BTW,  in this particular case, there originally has been a direct ODL 
access as a NSH solution (i.e. NO OpenStack option), then we got Tacker (now an 
Neutron Stadium project, if I get it right) to support SFC and NSH, but we are 
still told that networking-sfc (another Neutron Stadium project ) can’t do the 
same….
I cannot comment for the experience and the conversations you've had so far as 
I have no context. All I know is that if you want to experiment with 
OpenDaylight and its NSH provider and want to use that as a Neutron backend you 
can. However, if that requires new abstractions, these new abstractions must be 
agreed by all interested parties, be technology agnostic, and allow for 
multiple implementation, an open one included. That's the nature of OpenStack.
[UE] thanks for this clarification! I think it means that now that we all agree 
SFC abstraction is needed and that NSH is an emerging standard and 
networking-sfc team agrees to support NSH – there should be no reason to wait. 
As Tim Rozet mentioned an ODL driver with explicit SFC support is WIP, so 
sounds like NSH  support in it should be a go!

• Also regarding the  following comment made on another message in this 
thread, “As to OvS features, I guess the OvS ml is a better place, but wonder 
if the Neutron community wants to hold itself hostage to the pace of other 
projects who are reluctant to adopt a feature”, what I mean is again, that 
chicken and egg situation as above. Personally, I think OpenStack Neutron 
should allow mechanisms that are of interest / value to the networking 
community at large, to “ experiment with the abstraction” as you stated, 
independent of other organizations/projects…
I personally I see no catch-22 if you operate under the premises I stated 
above. If Neutron allowed to experiment with *any* mechanism without taking 
into consideration the importance of abstractions and community consensus, we 
as a community have failed, especially in relation to the aspect of 
interoperability.
[UE] but as stated above and on the ml, in this case where we have agreement on 
the specific SFC abstraction, are we in agreement that we can move without 
being held back by other projects e.g. OvS???

SOOO, is the 

Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances

[Yuiko Takada]

Hi!

Hironori, Lucas, thank you for bringing this topic up!

Yes, as Lucas says,  our latest spec is
https://review.openstack.org/#/c/319505

I and Tien, Hironori, Akira discussed and merged our idea.

And new Nova spec is here:
https://review.openstack.org/#/c/319507

As you guys know, Nova non-priority spec approval freeze is 5/30-6/3,
so that I guess Ironic spec need to be approved until it.


Best Regards,
Yuiko Takada Mori

2016-05-25 1:15 GMT+09:00 Lucas Alvares Gomes :

> Hi,
>
> > I'm working with Tien who is a submitter of one[1] of console specs.
> > I joined the console session in Austin.
> >
> > In the session, we got the following consensus.
> > - focus on serial console in Newton
> > - use nova-serial proxy as is
> >
> > We also got some requirements[2] for this feature in the session.
> > We have started cooperating with Akira and Yuiko who submitted another
> similar spec[3].
> > We're going to unite our specs and add solutions for the requirements
> ASAP.
> >
>
> Great stuff! So do we have an update on this?
>
> I see [3] is now abandoned and a new spec was proposed recently [4].
> Is [4] the result of the union of both specs?
>
> > [1] ironic-ipmiproxy: https://review.openstack.org/#/c/296869/
> > [2] https://etherpad.openstack.org/p/ironic-newton-summit-console
> > [3] ironic-console-server: https://review.openstack.org/#/c/306755/
>
> [4] https://review.openstack.org/#/c/319505
>
> Cheers,
> Lucas
>
> __
> OpenStack Development Mailing 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] support of NSH in networking-SFC

[Elzur, Uri]

Hi Tim

Sorry for the delay due to travel...

This note is very helpful! 

We are in agreement that the team including the individuals cited below are 
supportive. We also agree that SFC belongs in the networking-SFC project (with 
proper API adjustment)

It seems networking-sfc still holds the position that without OvS accepting 
VXLAN-gpe and NSH patches they can't support NSH. I'm trying to get a clear 
read on where is this stated as requirement

Like you, we are closely following the progress of the patches and honestly I 
have hard time seeing OpenStack supporting NSH in production even by the end of 
2017. I think this amounts to slowing down the market...

I think we need to break the logjam. 

I've reviewed 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and found nowhere a guideline suggesting that before a backend has fully 
implemented and merged upstream a technology (i.e. another project outside of 
OepnStack!), OpenStack Neutron can't make any move. ODL is working >2 years to 
support NSH using patches, yet to be accepted into Linux Kernel (almost done) 
and OvS (preliminary) - as you stated. Otherwise we create a serialization, 
that gets worse and worse over time and with additional layers. 

No one suggests the such code needs to be PRODUCTION, but we need a way to roll 
out EXPERIMENTAL functions and later merge them quickly when all layers are 
ready, this creates a nice parallelism and keeps a decent pace of rolling out 
new features broadly supported elsewhere.

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Friday, May 20, 2016 7:01 PM
To: OpenStack Development Mailing List (not for usage questions) 
; Elzur, Uri 
Cc: Cathy Zhang 
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Hi Uri,
I originally wrote the Tacker->ODL SFC NSH piece and have been working with 
Tacker and networking-sfc team to bring it upstream into OpenStack.  Cathy, 
Stephen, Louis and the rest of the networking-sfc team have been very receptive 
to changes specific to NSH around their current API and DB model.  The proper 
place for SFC to live in OpenStack is networking-sfc, while Tacker can do its 
orchestration job by rendering ETSI MANO TOSCA input like VNF Descriptors and 
VNF Forwarding Graph Descriptors.

We currently have a spec in netwoking-odl to migrate my original driver for ODL 
to do IETF NSH.  That driver will be supported in networking-sfc, along with 
some changes to networking-sfc to account for NSH awareness and encap type 
(like VXLAN+GPE or Ethernet).  The OVS work to support NSH is coming along and 
patches are under review.  Yi Yang has built a private OVS version with these 
changes and we can use that for now to test with.

I think it is all coming together and will take a couple more months before all 
of the pieces (Tacker, networking-sfc, networking-odl, ovs) are in place.  I 
don't think networking-sfc is holding up any progress.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Uri Elzur" 
To: "OpenStack Development Mailing List (not for usage questions)" 
, "Cathy Zhang" 
Sent: Friday, May 20, 2016 8:37:26 PM
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



Hi Armando, Cathy, All 



First I apologize for the delay, returning from a week long international trip. 
(yes, I know, a lousy excuse on many accounts…) 



If I’m attempting to summarize all the responses, it seems like 

· A given abstraction in Neutron is allowed (e.g. in support of SFC), 
preferably not specific to a given technology e.g. NSH for SFC 

· A stadium project is not held to the same tests (but we do not have a 
“formal” model here, today) and therefore can support even a specific 
technology e.g. NSH (definitely better with abstractions to meet Neutron 
standards for future integration) 



However, 

· There still is a chicken and egg phenomenon… how can a technology become main 
stream with OPEN SOURCE support if we can’t get an OpenStack to support the 
required abstractions before the technology was adopted elsewhere?? 

o Especially as Stadium, can we let Neutron to lead the industry, given broad 
enough community interest? 

· BTW, in this particular case, there originally has been a direct ODL access 
as a NSH solution (i.e. NO OpenStack option), then we got Tacker (now an 
Neutron Stadium project, if I get it right) to support SFC and NSH, but we are 
still told that networking-sfc (another Neutron Stadium project ) can’t do the 
same…. 

· Also regarding the following comment made on another message in this thread, 
“ As to OvS features, I guess the OvS ml is a better place, but wonder if the 
Neutron community wants to hold itself hostage to the pace of other 

Re: [openstack-dev] [ironic][neutron] bonding?

[Clint Byrum]

Excerpts from Jim Rollenhagen's message of 2016-05-24 07:51:21 -0400:
> Hi,
> 
> There's rumors floating around about Neutron having a bonding model in
> the near future. Are there any solid plans for that?
> 
> For context, as part of the multitenant networking work, ironic has a
> portgroup concept proposed, where operators can configure bonding for
> NICs in a baremetal machine. There are ML2 drivers that support this
> model and will configure a bond.
> 
> Some folks have concerns about landing this code if Neutron is going to
> support bonding as a first-class citizen. So before we delay any
> further, I'd like to find out if there's any truth to this, and what the
> timeline for that might look like.
> 

FYI we've been playing with bonding and Ironic using Bifrost and glean.
There are some patches up for the format we've used: 

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

Just a thought, it would be good if we can get that metadata to be
the same for Neutron, or at least get an early idea of the spec so we
can make sure glean supports it ASAP.

__
OpenStack Development Mailing 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] [docs][install-guide] Install Guide Naming

[Lana Brindley]

Hi everyone,

As part of the massive Install Guide changes the docs team are implementing in 
Newton, we need to come up with a name for what *was* the Install Guide. We 
need to emphasise the fact that it should be used for learning purposes only, 
not for installing a production cloud. So go ahead and tell us what you think!

http://goo.gl/forms/HqyXIU4cjRB4xfN43

Thanks!
Lana

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [Mistral][Zaqar][Ceilometer][Searchlight] Triggering Mistral workflows from Zaqar messages

[Fei Long Wang]

On 25/05/16 07:52, Zane Bitter wrote:
> On 22/05/16 22:38, Lingxian Kong wrote:
>> Hi, Zane, I think you must be interested in this:
>> https://review.openstack.org/#/c/308664/
>
> Oh! Yes that is very interesting. I'm glad that other people are
> thinking about these kinds of problems also.
>
> My blueprint has a different focus, in that it's more about allowing
> the _user_ to configure these actions. Listening to oslo_messaging
> notifications instead of to Zaqar messages limits you to operator use
> cases only. (It's also likely much more efficient - listening to a
> large number of queues simultaneously is not the use case Zaqar is
> optimised for, which is essentially why I changed my mind about
> whether this should be implemented within Mistral.)
>
> At least two projects that I know of (Ceilometer and Searchlight) are
> looking at implementing proxying of oslo_messaging notifications into
> Zaqar queues, and when that is combined with the Zaqar notification
> trigger we'll open up this functionality to everyone - other OpenStack
> services, operators and end-users.
>
> e.g. a user will be able to subscribe (via Ceilometer or Searchlight)
> to a notification about a particular server from Nova in a Zaqar queue
> and have that trigger a Mistral workflow that marks the server
> unhealthy in Heat and triggers a reconvergence of the stack.
>
> Unfortunately, there's always a tension between getting something done
> and in users' hands right now - which is easier to do if you stay
> within the confines of one project - and building flexible,
> orthogonal, user-pluggable abstractions, which are IMHO in the
> long-term best interests of users but generally require the
> co-operation, co-ordination and deployment of multiple projects.
>
Thanks for raising the topic and adding Ceilometer and Searchlight to
this thread. I think a similar topic about user notification was
discussed before. There are a lot of events/notifications in the infra's
message queues and tenant users are really interested in
them so that when there are some resources changed, users can be
notified instead of polling again and again. Based on my investigation
last time, I would like to see a driver at here
https://github.com/openstack/ceilometer/tree/master/ceilometer/publisher
Julien, can you comment this?
> It seems like we, the OpenStack community, are failing not only at
> co-ordinating these kinds of features across projects, but in even
> know what is being planned in other projects. Perhaps we need some
> sort of "Autonomous Applications working group"?
+1 That's a good idea.
>
> cheers,
> Zane.
>
>>
>> Regards!
>> ---
>> Lingxian Kong
>>
>>
>> On Fri, May 20, 2016 at 9:49 AM, Zane Bitter  wrote:
>>> On 19/05/16 04:20, Thomas Herve wrote:

 On Wed, May 18, 2016 at 8:49 PM, Zane Bitter 
 wrote:
>
> I've been lobbying the Mistral developers for $SUBJECT since,
> basically,
> forever.[1][2][3] I like to think after a couple of years I
> succeeded in
> changing their view on it from "crazy" to merely "unrealistic".[4]
> In the
> last few months I've had a couple of realisations though:
>
> 1) The 'pull' model I've been suggesting is the wrong one,
> architecturally
> speaking. It's asking Mistral to do too much to poll Zaqar queues.
> 2) A 'push' model is the correct architecture and it already
> exists in
> the
> form of Zaqar's Notifications, which suddenly makes this goal look
> very
> realistic indeed.
>
> I've posted a Zaqar spec for this here:
>
> https://review.openstack.org/#/c/318202/


 Commented. I certainly need some more time to think about it.
>>>
>>>
>>> Thanks, I updated the spec based on your comments.
>>>
> Not being super familiar with either project myself, I think this
> needs
> close scrutiny from Mistral developers as well as Zaqar developers to
> make
> sure I haven't got any of the details wrong. I'd also welcome any
> volunteers
> interested in implementing this :)
>
>
> One more long-term thing that I did *not* mention in the spec:
> there are
> both Zaqar notifications and Mistral actions for sending email and
> hitting
> webhooks. These are two of the hardest things for a cloud operator to
> secure. It would be highly advantageous if there were only _one_
> place in
> OpenStack where these were implemented. Either project would
> potentially
> work - Zaqar notifications could call a simple, operator defined
> workflow
> behind the scenes for email/webhook notifications; alternatively the
> Mistral
> email/webhook actions could drop a message on a Zaqar queue
> connected to
> a
> notification - although the former sounds easier to me. (And of
> course
> clouds with only one of the services available could fall 

Re: [openstack-dev] [Swift3] improve multi-delete performance

[Kota TSUYUZAKI]

Hello kirubakaran,

Thanks for contributing Swift3, that sounds great. I wonder if you could push 
the diff as a patch to gerrit code review which is the review system for 
openstack and openstack related projects.
The entry point for "how to contribute for openstack" is here, 
https://wiki.openstack.org/wiki/How_To_Contribute and specific git commands 
will be introduced at
http://docs.openstack.org/infra/manual/developers.html.

For your information, a patch[1] from Tim who is working for SwiftStack might 
help you to improve your patch because the patch is for enabling other swift 
middlewares to make concurrent requests, it
is for upstream Swift though :)

Best,
Kota


1: https://review.openstack.org/#/c/311817

(2016/05/24 13:47), Kirubakaran Kaliannan wrote:
> Hi,
> 
> 
> 
> The multi_delete in swift3, perform sequential DELETE.  In my 3
> storage-node configuration to delete a 1000 objects, it took 30 second.
> 
> 
> 
> Following code change to create 100 thread pool to delete 1000 object took
> only 12 second. (This may even reduce if more storage nodes in picture).
> 
> 
> 
> If the following code change look fine, How can we formally
> (propose/review/commit) take this to the swift3 github code base ?
> 
> 
> 
> 
> 
> *Code diff:*
> 
> 
> 
> diff --git a/swift3/swift-plugin-s3/swift3/controllers/multi_delete.py
> b/swift3/swift-plugin-s3/swift3/controllers/multi_delete.py
> 
> index 1bfde1d..5140529 100644
> 
> --- a/swift3/swift-plugin-s3/swift3/controllers/multi_delete.py
> 
> +++ b/swift3/swift-plugin-s3/swift3/controllers/multi_delete.py
> 
> @@ -21,9 +21,9 @@ from swift3.response import HTTPOk, S3NotImplemented,
> NoSuchKey, \
> 
> from swift3.cfg import CONF
> 
> from swift3.utils import LOGGER
> 
> -# Zadara-Begin
> 
> +from eventlet import GreenPool
> 
> +import copy
> 
> MAX_MULTI_DELETE_BODY_SIZE = 262144
> 
> -# Zadara-End
> 
> 
> 
>  class MultiObjectDeleteController(Controller):
> 
> @@ -44,6 +44,24 @@ class MultiObjectDeleteController(Controller):
> 
>  return tostring(elem)
> 
> +def async_delete(self, reqs, key, elem):
> 
> +req = copy.copy(reqs)
> 
> +req.object_name = key
> 
> +try:
> 
> +req.get_response(self.app, method='DELETE')
> 
> +except NoSuchKey:
> 
> +pass
> 
> +except ErrorResponse as e:
> 
> +error = SubElement(elem, 'Error')
> 
> +SubElement(error, 'Key').text = key
> 
> +SubElement(error, 'Code').text = e.__class__.__name__
> 
> +SubElement(error, 'Message').text = e._msg
> 
> +return
> 
> +
> 
> +if not self.quiet:
> 
> +deleted = SubElement(elem, 'Deleted')
> 
> +SubElement(deleted, 'Key').text = key
> 
> +
> 
>  @bucket_operation
> 
>  def POST(self, req):
> 
>  """
> 
> @@ -90,27 +108,17 @@ class MultiObjectDeleteController(Controller):
> 
>  body = self._gen_error_body(error, elem, delete_list)
> 
>  return HTTPOk(body=body)
> 
> +parallel_delete = 100
> 
> +run_pool = GreenPool(size=parallel_delete)
> 
>  for key, version in delete_list:
> 
>  if version is not None:
> 
>  # TODO: delete the specific version of the object
> 
>  raise S3NotImplemented()
> 
> -req.object_name = key
> 
> -
> 
> -try:
> 
> -req.get_response(self.app, method='DELETE')
> 
> -except NoSuchKey:
> 
> -pass
> 
> -except ErrorResponse as e:
> 
> -error = SubElement(elem, 'Error')
> 
> -SubElement(error, 'Key').text = key
> 
> -SubElement(error, 'Code').text = e.__class__.__name__
> 
> -SubElement(error, 'Message').text = e._msg
> 
> -continue
> 
> -
> 
> -if not self.quiet:
> 
> -deleted = SubElement(elem, 'Deleted')
> 
> -SubElement(deleted, 'Key').text = key
> 
> +run_pool.spawn(self.async_delete, req, key, elem)
> 
> +
> 
> +# Wait for all the process to complete
> 
> +run_pool.waitall()
> 
>  body = tostring(elem)
> 
> 
> 
> __
> OpenStack Development Mailing 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] [aodh] Tempest gate not working

[Ryota Mibu]

Hi Tony,


That 'gate_hook.sh' is not good for tempest jobs. DEVSTACK_GATE_TEMPEST is set 
0 in that script, and default one seems better 
(devstack-gate/devstack-vm-gate.sh) .

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


BR,
Ryota

> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Wednesday, May 25, 2016 1:11 PM
> To: openstack-dev@lists.openstack.org; Mibu Ryota(壬生 亮太)
> Subject: Re: [openstack-dev] [aodh] Tempest gate not working
> 
> On Tue, May 24, 2016 at 04:50:21PM +0200, Julien Danjou wrote:
> > Hi,
> >
> > So it turns out we tried (especially Ryota) to add Tempest support via
> > https://review.openstack.org/#/c/303921/ for Aodh's gate, but it does
> > not actually run Tempest.
> 
> Your gate scripts didn't like tempest as an enabled service.
> 
> https://review.openstack.org/#/c/320734/1
> 
> Looks to fix it.
> 
> Yours Tony.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [aodh] Tempest gate not working

[Tony Breeds]

On Tue, May 24, 2016 at 04:50:21PM +0200, Julien Danjou wrote:
> Hi,
> 
> So it turns out we tried (especially Ryota) to add Tempest support via
> https://review.openstack.org/#/c/303921/ for Aodh's gate, but it does
> not actually run Tempest.

Your gate scripts didn't like tempest as an enabled service.

https://review.openstack.org/#/c/320734/1

Looks to fix it.

Yours Tony.


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

[openstack-dev] [Solum] Proposal to change weekly IRC meeting time

[Devdatta Kulkarni]

Hi team,  

In today's IRC meeting [1], we discussed about changing our weekly IRC meeting 
time from current 
time of 1700 UTC to 1400 UTC to allow our team members from Germany, India, and 
China to participate regularly.

I have submitted a WIP patch [2] to make this change. Please provide your votes 
(+1/-1) on the review. 
I will remove WIP once majority of our current contributors have voted on it.

Note that we have to change the day of our weekly meeting as our preferred time 
slot of 1400 UTC 
is not available in any channel on Tuesday.

I am thinking that if majority of our team members agree, we can move to this 
new time starting  June 1 meeting.

Thanks, 
Devdatta

[1] 
http://eavesdrop.openstack.org/meetings/solum_team_meeting/2016/solum_team_meeting.2016-05-24-17.00.log.html

[2] https://review.openstack.org/#/c/320762/1
__
OpenStack Development Mailing 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] [magnum] Need helps to implement the full baremetals support

[Yuanying OTSUKA]

Hi, Hongbin, Spyros.

I’m also interesting this work.
I have workaround patch to support ironic.
(but currently conflict with master.
Is it helpful to upload it for initial step of the implementation?

Thanks
-yuanying

2016年5月25日(水) 6:52 Hongbin Lu :

> Hi all,
>
>
>
> One of the most important feature that Magnum team wants to deliver in
> Newton is the full baremetal support. There is a blueprint [1] created for
> that and the blueprint was marked as “essential” (that is the highest
> priority). Spyros is the owner of the blueprint and he is looking for helps
> from other contributors. For now, we immediately needs help to fix the
> existing Ironic templates [2][3][4] that are used to provision a Kubernetes
> cluster on top of baremetal instances. These templates were used to work,
> but they become outdated right now. We need help to fix those Heat template
> as an initial step of the implementation. Contributors are expected to
> follow the Ironic devstack guide to setup the environment. Then, exercise
> those templates in Heat.
>
>
>
> If you interest to take the work, please contact Spyros or me and we will
> coordinate the efforts.
>
>
>
> [1]
> https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
>
> [2]
> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster-fedora-ironic.yaml
>
> [3]
> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster-fedora-ironic.yaml
>
> [4]
> https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion-fedora-ironic.yaml
>
>
>
> Best regards,
>
> Hongbin
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [higgins] Continued discussion from the last team meeting

[Yanyan Hu]

Hi, Hongbing, thanks a lot for the summary! The following is my thoughts on
those two questions left:

About container composition, it is a really useful and important feature
for enduser. But based on my understanding, user can actually achieve the
same goal by leveraging other high level OpenStack services, e.g. defining
a Heat template with Higgins container resources and app/service
(softwareconfig/softwaredeployment resources) running inside containers. In
future we can implement related functionality inside Higgins to better
support this kind of use cases natively. But in current stage, I suggest we
focus on container primitive and its basic operations.

For container host management, I agree we should expose related API
interfaces to operator(admin). Ideally, Higgins should be able to manage
all container hosts(baremetal and VM) automatically, but manual
intervention could be necessary in many pratical use cases. But I suggest
to hide these API interfaces from endusers since it's not their
responsibility to manage those hosts.

Thanks.

2016-05-25 4:55 GMT+08:00 Hongbin Lu :

> Hi all,
>
>
>
> At the last team meeting, we tried to define the scope of the Higgins
> project. In general, we agreed to focus on the following features as an
> initial start:
>
> · Build a container abstraction and use docker as the first
> implementation.
>
> · Focus on basic container operations (i.e. CRUD), and leave
> advanced operations (i.e. keep container alive, rolling upgrade, etc.) to
> users or other projects/services.
>
> · Start with non-nested container use cases (e.g. containers on
> physical hosts), and revisit nested container use cases (e.g. containers on
> VMs) later.
>
> The items below needs further discussion so I started this ML to discuss
> it.
>
> 1.   Container composition: implement a docker compose like feature
>
> 2.   Container host management: abstract container host
>
> For #1, it seems we broadly agreed that this is a useful feature. The
> argument is where this feature belongs to. Some people think this feature
> belongs to other projects, such as Heat, and others think it belongs to
> Higgins so we should implement it. For #2, we were mainly debating two
> things: where the container hosts come from (provisioned by Nova or
> provided by operators); should we expose host management APIs to end-users?
> Thoughts?
>
>
>
> Best regards,
>
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,

Yanyan
__
OpenStack Development Mailing 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] [aodh] Tempest gate not working

[Ryota Mibu]

Julien,


Thank you for the heads up.

I'll check aodh tempest tests, and also drop tempest full tests in ceilometer 
since the code for ceilometer was removed from tempest.


BR,
Ryota

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Tuesday, May 24, 2016 11:50 PM
> To: openstack-dev@lists.openstack.org
> Cc: Mibu Ryota(壬生 亮太)
> Subject: [aodh] Tempest gate not working
> 
> Hi,
> 
> So it turns out we tried (especially Ryota) to add Tempest support via 
> https://review.openstack.org/#/c/303921/ for Aodh's
> gate, but it does not actually run Tempest.
> 
> Otherwise, we would have notice something wrong in 
> https://review.openstack.org/#/c/318052/. As EmilienM noticed in Puppet
> Aodh module, who actually runs Tempest, Aodh has a test to check the 
> combination alarm that now fails.
> 
> The tempest job log shows that it runs the functional tests, but not Tempest:
> 
> http://logs.openstack.org/52/318052/2/check/gate-aodh-dsvm-tempest-plugin-mongodb/5840d90/console.html.gz#_2016-05-1
> 9_14_01_49_072
>   + ./post_test_hook.sh:main:56  :   sudo -E -H -u stack tox 
> -efunctional
> 
> I've no idea how this exactly work, but if anyone has knowledge on gate and 
> Tempest, it'd be awesome to fix it. Or finish
> it, as the job are still non-voting, I imagine nobody finished Ryota first 
> attempt.
> 
> Cheeres,
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info

__
OpenStack Development Mailing 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] Fwd: keystone federation user story

[Adam Young]

On 05/24/2016 10:30 PM, Adam Young wrote:

On 05/24/2016 01:55 PM, Alexander Makarov wrote:

Colleagues,

here is an actual use case for shadow users assignments, let's 
discuss possible solutions: all suggestions are appreciated.


-- Forwarded message --
From: *Andrey Grebennikov* >

Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov >



Main production usecase:
As a system administrator I need to create assignments for federated 
users into the projects when the user has not authenticated for the 
first time.


Two different approaches.
1. A user has to be assigned directly into the project with the role 
Role1. Since shadow users were implemented, Keystone database has the 
record of the user when the federated user authenticates for the 
first time. When it happens, the user gets unscoped token and 
Keystone registers the user in the database with generated ID (the 
result of hashing the name and the domain). At this point the user 
cannot get scoped token yet since the user has not been assigned to 
any project.
Nonetheless there was a bug 
https://bugs.launchpad.net/keystone/+bug/1313956 which was abandoned, 
and the reporter says that currently it is possible to assign role in 
the project to non-existing user (API only, no CLI). It doesn't help 
much though since it is barely possible to predict the ID of the user 
if it doesn't exist yet.


Potential solution - allow per-user project auto-creation. This will 
allow the user to get scoped token with a pre-defined role (should be 
either mentioned in config or in mapping) and execute operations 
right away.


What we discussed at the summit was the ability for some power user to 
pre=-create the shadow user record by passing in the data that that 
would be mapped:


Kerberos example
{
Realm: YOUNGLOGIC.NET
Principal: ayo...@younglogic.net
REMOTE_GROUPS: ipausers,demo,bookworms
}


Another API will allow for query if a user exists.




Spec is here

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






Disadvantages: less control and order (will potentially end up with 
infinite empty projects).

Benefits: user is authorized right away.

Another potential solution - clearly describe a possibility to assign 
shadow user to a project (client should generate the ID correctly), 
even though the user has not been authenticated for the first time yet.


Disadvantages: high risk of administrator's mistake when typing 
user's ID.
Benefits: user doesn't have to execute first dummy authentication in 
order to be registered.


2. Operate with the groups. It means that the user is a member of the 
remote group and we propose the groups to be assigned to the projects 
instead of the users.
There is no concept of shadow groups yet, so it still has to be 
implemented.


Same problem - in order to be able to assign the group to the project 
currently it has to exist in Keystone database.


It should be either allowed to pre-create the project for a group 
(based on some specific flags in mappings), or it should be allowed 
to assign non-existing groups into the projects.


I'd personally prefer to allow some special attribute to be specified 
in either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend. 
In this case this group is the part of SAML assertions (in case when 
SAML2 is used as the protocol), and Keystone should recognize this 
group through the mapping. When user makes login attempt, Keystone 
should pre-create the project and assign pre-defined role in it. User 
gets access right away.



--
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA



--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.


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




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


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

Re: [openstack-dev] Fwd: keystone federation user story

[Adam Young]

On 05/24/2016 01:55 PM, Alexander Makarov wrote:

Colleagues,

here is an actual use case for shadow users assignments, let's discuss 
possible solutions: all suggestions are appreciated.


-- Forwarded message --
From: *Andrey Grebennikov* >

Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov >



Main production usecase:
As a system administrator I need to create assignments for federated 
users into the projects when the user has not authenticated for the 
first time.


Two different approaches.
1. A user has to be assigned directly into the project with the role 
Role1. Since shadow users were implemented, Keystone database has the 
record of the user when the federated user authenticates for the first 
time. When it happens, the user gets unscoped token and Keystone 
registers the user in the database with generated ID (the result of 
hashing the name and the domain). At this point the user cannot get 
scoped token yet since the user has not been assigned to any project.
Nonetheless there was a bug 
https://bugs.launchpad.net/keystone/+bug/1313956 which was abandoned, 
and the reporter says that currently it is possible to assign role in 
the project to non-existing user (API only, no CLI). It doesn't help 
much though since it is barely possible to predict the ID of the user 
if it doesn't exist yet.


Potential solution - allow per-user project auto-creation. This will 
allow the user to get scoped token with a pre-defined role (should be 
either mentioned in config or in mapping) and execute operations right 
away.


What we discussed at the summit was the ability for some power user to 
pre=-create the shadow user record by passing in the data that that 
would be mapped:


Kerberos example
{
Realm: YOUNGLOGIC.NET
Principal: ayo...@younglogic.net
REMOTE_GROUPS: ipausers,demo,bookworms
}


Another API will allow for query if a user exists.







Disadvantages: less control and order (will potentially end up with 
infinite empty projects).

Benefits: user is authorized right away.

Another potential solution - clearly describe a possibility to assign 
shadow user to a project (client should generate the ID correctly), 
even though the user has not been authenticated for the first time yet.


Disadvantages: high risk of administrator's mistake when typing user's ID.
Benefits: user doesn't have to execute first dummy authentication in 
order to be registered.


2. Operate with the groups. It means that the user is a member of the 
remote group and we propose the groups to be assigned to the projects 
instead of the users.
There is no concept of shadow groups yet, so it still has to be 
implemented.


Same problem - in order to be able to assign the group to the project 
currently it has to exist in Keystone database.


It should be either allowed to pre-create the project for a group 
(based on some specific flags in mappings), or it should be allowed to 
assign non-existing groups into the projects.


I'd personally prefer to allow some special attribute to be specified 
in either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend. In 
this case this group is the part of SAML assertions (in case when 
SAML2 is used as the protocol), and Keystone should recognize this 
group through the mapping. When user makes login attempt, Keystone 
should pre-create the project and assign pre-defined role in it. User 
gets access right away.



--
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA



--
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.


__
OpenStack Development Mailing 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] [aodh] Tempest gate not working

[liusheng]

Hi,

Thanks for this mail, I also noticed that yesterday, and I am trying to 
fix  it by https://review.openstack.org/#/c/320378/


cheers,

Liusheng


在 2016/5/24 22:50, Julien Danjou 写道:

Hi,

So it turns out we tried (especially Ryota) to add Tempest support via
https://review.openstack.org/#/c/303921/ for Aodh's gate, but it does
not actually run Tempest.

Otherwise, we would have notice something wrong in
https://review.openstack.org/#/c/318052/. As EmilienM noticed in Puppet
Aodh module, who actually runs Tempest, Aodh has a test to check the
combination alarm that now fails.

The tempest job log shows that it runs the functional tests, but not Tempest:
   
http://logs.openstack.org/52/318052/2/check/gate-aodh-dsvm-tempest-plugin-mongodb/5840d90/console.html.gz#_2016-05-19_14_01_49_072
   + ./post_test_hook.sh:main:56  :   sudo -E -H -u stack tox 
-efunctional

I've no idea how this exactly work, but if anyone has knowledge on gate
and Tempest, it'd be awesome to fix it. Or finish it, as the job are
still non-voting, I imagine nobody finished Ryota first attempt.

Cheeres,


__
OpenStack Development Mailing 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] [higgins] Continued discussion from the last team meeting

[Qiming Teng]

On Tue, May 24, 2016 at 08:55:28PM +, Hongbin Lu wrote:
> Hi all,
> 
> At the last team meeting, we tried to define the scope of the Higgins 
> project. In general, we agreed to focus on the following features as an 
> initial start:
> 
> * Build a container abstraction and use docker as the first 
> implementation.
> 
> * Focus on basic container operations (i.e. CRUD), and leave advanced 
> operations (i.e. keep container alive, rolling upgrade, etc.) to users or 
> other projects/services.
> 
> * Start with non-nested container use cases (e.g. containers on 
> physical hosts), and revisit nested container use cases (e.g. containers on 
> VMs) later.
> The items below needs further discussion so I started this ML to discuss it.
> 
> 1.   Container composition: implement a docker compose like feature

No doubt this would be very useful a feature for users. However, I still
suggest we keep the initial scope to a bare minimum so folks can focus
on the first two jobs (container abstraction + CRUD) in this cycle and
get things landed soon. We already have a lot details to figure out for
the first two items.

The next step (maybe early next cycle?) would be about a higher level of
APIs that allow users to create some structured, declarative artifacts
as inputs.

> 2.   Container host management: abstract container host

I'm not quite aware of the requirements for end users to see or even to
manage the container "hosts" (bm or vm). Just like that end users are
not supposed to be aware of the compute nodes when they use Nova. For
operators, the story might be quite different. They will need such tools
or APIs for managing the "hosts" used. Such management jobs can be
automated to some extent, but I'm somehow skeptical to full automation.
At the end of the day, we need to provide some knobs for operators to
do things they want because the automation tool is never ever smarter
than the people using it.

Just my 2 cents.

 - Qiming

> For #1, it seems we broadly agreed that this is a useful feature. The 
> argument is where this feature belongs to. Some people think this feature 
> belongs to other projects, such as Heat, and others think it belongs to 
> Higgins so we should implement it. For #2, we were mainly debating two 
> things: where the container hosts come from (provisioned by Nova or provided 
> by operators); should we expose host management APIs to end-users? Thoughts?
> 
> Best regards,
> Hongbin



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

Re: [openstack-dev] [PTLs][all][mentoring] Mentors needed in specific technical areas

[Augustina Ragwitz]

 
>> On 12:54 May 24, Augustina Ragwitz wrote:
>> Hi Emily,
>>
>> I'm the Nova Mentoring Czar and we have a Wiki page with a list of
>> projects that would be good for new contributors:
>> https://wiki.openstack.org/wiki/Nova/Mentoring
>>
>> For Nova, I'd encourage potential contributors to get involved with a
>> specific project so that mentoring can happen organically. Interested
>> folks are more than welcome to reach out to me, preferably by email.
>
> There's an assumption here that all projects have things in place
> to begin
> mentoring people. With the people we've spoken to, sometimes just
> reaching on
> IRC gave no answers. This is actually matching people to
> someone who has
> knowledge and is interested/has time to mentor. Even if a match
> can't be made
> right away, communication is made. First impressions with on
> boarding is key.
>
> --
> Mike Perez
 
I'm a little confused by your response. I wasn't making any assumptions
or intending to criticize this mentorship program. I understood that
Emily had highlighted gaps in certain technical areas, of which Nova is
one. In recognition of the challenges faced by new contributors, the
Nova team had a session at the Newton Design Summit where we discussed
ideas on how to address these challenges within our own team. One
outcome of this session is that I volunteered for the role of Mentoring
Czar. When I saw Emily's original post, I thought this information might
be relevant. My intention is to share our resources for new contributors
and present myself as a contact point so this information could be
provided to participants in the mentorship program that don't have
mentors assigned. In fact, if other projects do have things in place for
new contributors, it would probably be helpful if they also provided
this information to the mentorship program.
 
Again, my intention was not to criticize and I think any effort to
encourage new contributors is a good thing. I apologize if my original
response suggested otherwise.
 
--
Augustina Ragwitz
irc: auggy
Augustina Ragwitz
Sr Systems Software Engineer, HPE Cloud
Hewlett Packard Enterprise
---
irc: auggy
 
 
__
OpenStack Development Mailing 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] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting today. The meeting is being held Wednesday
UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

Thanks
__
OpenStack Development Mailing 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] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Thanks for getting back to me and pointing me in a more OVS like direction. 
What you say makes sense, let me hack something together. I have been a little 
distracted getting some use cases together. The other area is how to better map 
the flow-classifier I have been thinking about it a little, but I will leave it 
till after we get the chains done.

Your load-balancing comment was very interesting - I saw some patches for 
load-balancing a few months ago but nothing since. It would be great if we 
could align with load-balancing as that would make a really powerful solution.

Regards

John

From: Ryan Moats >
Date: Monday, May 23, 2016 at 9:06 PM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, OpenStack 
Development Mailing List 
>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/18/2016 03:55:14 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> >, "OpenStack
> Development Mailing List" 
> >
> Date: 05/18/2016 03:55 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> OK all three repos and now aligned with their masters. I have done
> some simple level system tests and I can steer traffic to a single
> VNF.  Note: some additional changes to networking-sfc to catch-up
> with their changes.
>
> https://github.com/doonhammer/networking-sfc
> https://github.com/doonhammer/networking-ovn
> https://github.com/doonhammer/ovs
>
> The next tasks I see are:
>
> 1. Decouple networking-sfc and networking-ovn. I am thinking that I
> will pass a nested port-chain dictionary holding port-pairs/port-
> pair-groups/flow-classifiers from networking-sfc to networking-ovn.
> 2. Align the interface between networking-ovn and ovs/ovn to match
> the nested dictionary in 1.
> 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain model.
> 4. Add ability to support chain of port-pairs
> 5. Think about flow-classifiers and how best to map them, today I
> just map the logical-port and ignore everything else.
>
> Any other suggestions/feedback?
>
> Regards
>
> John

John-

(Sorry for sending this twice, but I forgot that text/html is not liked
by the mailing lists ...)

My apologies for not answering this sooner - I was giving a two day
training on Tues/Wed last week and came back to my son graduating
from HS the next day, so things have been a bit of a whirlwind here.

Looking at the github repos, I like the idea of passing a dictionary
from networking-sfc to networking-ovn. The flow classifiers should
be relatively straightforward to map to ovs match rules (famous last
words)...

I've probably missed an orbit here, but in the ovn-northd implementation,
I was expecting to find service chains in the egress and router pipelines
in addition to the ingress pipeline (see below for why I think a service
chain stage in the egress pipeline makes sense ...)

Also, in the ovn-northd implementation, I'm a little disturbed to see the
ingress side of the service chain sending packets to output ports - I
think that a more scalable (and more "ovs-like" approach) would be to
match the egress side of a port pair in the chaining stage of the
ingress pipeline, with an action that  set the input port register.
Then the egress pipeline would have a chaining stage where the output
port register would be set based on the ingress port of the next port
pair in the chain and the packet being punted to the proper output port
in the last table.  That should automagically build your function chain
and provide the basis for 

Re: [openstack-dev] [craton] meeting notes

[sean roberts]

I missed that bi-weekly all four meeting slot are taken at 14:30 UTC
Mondays. I am going to move the meeting to 15:00 UTC. Speak up if that
doesn't work for you.

On Mon, May 23, 2016 at 11:45 AM, sean roberts 
wrote:

> Hello project team members. We have one week until M1. We need to discuss
> some details of what should be in the Newton release of Craton. Since no
> one has commented on the project name, I am going to assume we all agree to
> the name Craton. I will push the meeting patch to get it published.
>
>
>
> On Mon, May 16, 2016 at 8:51 AM, sean roberts 
> wrote:
>
>> first team meeting notes here
>> https://etherpad.openstack.org/p/craton-meeting-2016-05-16
>>
>> We have two weeks until M1, which is a good date to finalize what
>> features we will have in the newton release.
>>
>> We proposed the project name Craton to stick. Let's propose an
>> alternative here quickly if anyone wants.
>>
>> We agreed to hold meetbot IRC meetings 07:30 PDT. The
>> #openstack-meeting-4 slot is available.
>>
>> We agreed to move all email to openstack-dev@lists.openstack.org with
>> the subject starting with [craton]
>>
>> The chat.freenode.net IRC channel #craton is up and running, but not
>> logged yet.
>>
>> We want to target getting together face to face around the time of the
>> yet to be scheduled Operators Mid-Cycle. 19 July Watcher mid-cycle in
>> hillsboro, OR may be the area and time.
>>
>> I am happy to patch both the IRC meeting and craton logging patches, as
>> soon as we decide.
>>
>> I would recommend that we decide on these items today or tomorrow, so we
>> can get started on important project work.
>>
>> ~ sean
>>
>
>
>
> --
>
> ~ sean
>



-- 

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

Re: [openstack-dev] [cinder] A friendly reminder about reviews

[Erlon Cruz]

Cinder is definitely lacking reviewing force. I remember 2 years ago
comparing with today and I can tell that patches are taking a lot longer to
get reviewed.

This link is also very useful to triage incoming patches:

https://review.openstack.org/#/dashboard/?foreach=project:^openstack/.*cinder.*
status:open NOT owner:self NOT label:Workflow<=-1 label:Verified>=1 NOT
label:Code-Review<=-1,self NOT label:Code-Review>=1,self=Cinder
Review Inbox Specs=project:openstack/manila-specs
Fixes=topic:^bug/.* Feedback (Changes older than 5 days that have not
been reviewed by anyone)=NOT label:Code-Review<=2 age:5d are a
reviewer, but haven't voted in the current revision=reviewer:self
final +2=label:Code-Review>=2 limit:50
Contributors=reviewer:10068 Jenkins, No Negative Feedback=NOT
label:Code-Review>=2 NOT label:Code-Review<=-1 limit:50 Changes
(Changes with no code review in the last 2days)=NOT label:Code-Review<=2
age:2d

Huge link but the result is beautiful :)


Erlon


On Wed, May 11, 2016 at 11:19 AM, Eric Harney  wrote:

> And for completeness, I'd also like to mention that there is this nice
> dashboard:
>
> http://status.openstack.org/reviews/#cinder
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [new][oslo] taskflow 2.0.0 release (newton)

[no-reply]

We are delighted to announce the release of:

taskflow 2.0.0: Taskflow structured state management library.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/taskflow

With package available at:

https://pypi.python.org/pypi/taskflow

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

For more details, please see below.

Changes in taskflow 1.32.0..2.0.0
-

da30da8 Updated from global requirements
5944ccc Fix documentation related to missing BaseTask class
afbfe77 Remove deprecated things for 2.0 release
3321b22 Always used the library packaged mock

Diffstat (except docs and test files)
-

requirements.txt   |   2 +-
taskflow/conductors/backends/impl_executor.py  |  20 ---
taskflow/conductors/single_threaded.py |  31 -
taskflow/engines/base.py   |  25 
taskflow/engines/helpers.py| 138 +--
taskflow/examples/99_bottles.py|   8 +-
taskflow/examples/delayed_return.py|   2 +-
taskflow/listeners/base.py |  28 
taskflow/listeners/timing.py   |  11 --
taskflow/persistence/backends/impl_memory.py   |  30 +
taskflow/persistence/logbook.py|  37 --
taskflow/persistence/models.py |   2 +-
taskflow/test.py   |  14 +-
.../unit/persistence/test_memory_persistence.py|  39 ++
taskflow/types/fsm.py  |  37 --
taskflow/types/futures.py  |  36 -
taskflow/types/periodic.py |  32 -
taskflow/types/table.py| 147 -
taskflow/utils/deprecation.py  | 147 -
taskflow/utils/misc.py |  12 --
28 files changed, 76 insertions(+), 763 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index f7190e5..7bbf26c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -29 +29 @@ contextlib2>=0.4.0 # PSF License
-stevedore>=1.9.0 # Apache-2.0
+stevedore>=1.10.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.vmware 2.7.0 release (newton)

[no-reply]

We are excited to announce the release of:

oslo.vmware 2.7.0: Oslo VMware library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.vmware

With package available at:

https://pypi.python.org/pypi/oslo.vmware

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.vmware

For more details, please see below.

Changes in oslo.vmware 2.6.0..2.7.0
---

af2bbfe Updated from global requirements
0ae1810 Trivial: ignore openstack/common in flake8 exclude list

Diffstat (except docs and test files)
-

requirements.txt | 2 +-
tox.ini  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index cdae27e..0770ec5 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ pbr>=1.6 # Apache-2.0
-stevedore>=1.9.0 # Apache-2.0
+stevedore>=1.10.0 # Apache-2.0



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

[openstack-dev] [new][oslo] tooz 1.37.0 release (newton)

[no-reply]

We are pleased to announce the release of:

tooz 1.37.0: Coordination library for distributed systems.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/tooz

With package available at:

https://pypi.python.org/pypi/tooz

Please report issues through launchpad:

http://bugs.launchpad.net/python-tooz/

For more details, please see below.

Changes in tooz 1.36.0..1.37.0
--

ad9ce08 Remove unused consul future result
38cd610 Updated from global requirements
f917844 Add a consul based driver

Diffstat (except docs and test files)
-

requirements.txt|   3 +-
setup-consul-env.sh | 108 +++
setup.cfg   |   1 +
tooz/drivers/consul.py  | 186 
tox.ini |   9 +-
6 files changed, 307 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 01de29c..e57d7e0 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@ pbr>=1.6 # Apache-2.0
-stevedore>=1.9.0 # Apache-2.0
+stevedore>=1.10.0 # Apache-2.0
@@ -18,0 +19 @@ requests!=2.9.0,>=2.8.1 # Apache-2.0
+python-consul>=0.4.7 # MIT License



__
OpenStack Development Mailing 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] [new][oslo] stevedore 1.14.0 release (newton)

[no-reply]

We are pleased to announce the release of:

stevedore 1.14.0: Manage dynamic plugins for Python applications

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/stevedore

With package available at:

https://pypi.python.org/pypi/stevedore

Please report issues through launchpad:

https://bugs.launchpad.net/python-stevedore

For more details, please see below.

Changes in stevedore 1.13.0..1.14.0
---

b106ba3 Trivial: ignore openstack/common in flake8 exclude list

Diffstat (except docs and test files)
-

tox.ini | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.log 3.8.0 release (newton)

[no-reply]

We are gleeful to announce the release of:

oslo.log 3.8.0: oslo.log library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.log

With package available at:

https://pypi.python.org/pypi/oslo.log

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.log

For more details, please see below.

3.8.0
^

Bug Fixes

* When removing the "verbose" option, the default logging level was
  set to "WARNING" by mistake. Fixed it back to "INFO".

Changes in oslo.log 3.7.0..3.8.0


ed582b1 Revert "Remove 'verbose' option"
07c3c28 Fix regression causing the default log level to become WARNING
7c671ea Remove 'verbose' option

Diffstat (except docs and test files)
-

releasenotes/notes/info-logging-7b7be9fc7a95aebc.yaml | 4 
2 files changed, 6 insertions(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [new][oslo] oslosphinx 4.4.0 release (newton)

[no-reply]

We are eager to announce the release of:

oslosphinx 4.4.0: OpenStack Sphinx Extensions and Theme

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslosphinx

With package available at:

https://pypi.python.org/pypi/oslosphinx

Please report issues through launchpad:

http://bugs.launchpad.net/oslosphinx

For more details, please see below.

Changes in oslosphinx 4.3.0..4.4.0
--

c327f85 Updated from global requirements
75cfb9f add recent versions links to sidebar

Diffstat (except docs and test files)
-

oslosphinx/__init__.py | 15 +++
oslosphinx/theme/openstack/layout.html | 10 ++
requirements.txt   |  2 +-
3 files changed, 26 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index cb1438c..1c7f46f 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ pbr>=1.6 # Apache-2.0
-requests!=2.9.0,>=2.8.1 # Apache-2.0
+requests>=2.10.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.utils 3.11.0 release (newton)

[no-reply]

We are happy to announce the release of:

oslo.utils 3.11.0: Oslo Utility library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.utils

With package available at:

https://pypi.python.org/pypi/oslo.utils

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.utils

For more details, please see below.

Changes in oslo.utils 3.10.0..3.11.0


12d4936 Trivial: ignore openstack/common in flake8 exclude list
daf4681 Move method split_path into oslo.utils

Diffstat (except docs and test files)
-

oslo_utils/strutils.py| 50 +++
tox.ini   |  2 +-
3 files changed, 90 insertions(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.serialization 2.7.0 release (newton)

[no-reply]

We are amped to announce the release of:

oslo.serialization 2.7.0: Oslo Serialization library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.serialization

With package available at:

https://pypi.python.org/pypi/oslo.serialization

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.serialization

For more details, please see below.

Changes in oslo.serialization 2.6.0..2.7.0
--

0dcd927 Trivial: ignore openstack/common in flake8 exclude list

Diffstat (except docs and test files)
-

tox.ini | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.service 1.11.0 release (newton)

[no-reply]

We are overjoyed to announce the release of:

oslo.service 1.11.0: oslo.service library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.service

With package available at:

https://pypi.python.org/pypi/oslo.service

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.service

For more details, please see below.

Changes in oslo.service 1.10.0..1.11.0
--

43343b4 Trivial: ignore openstack/common in flake8 exclude list

Diffstat (except docs and test files)
-

tox.ini | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [magnum][kuryr] Nested containers networking

[Hongbin Lu]

Hi Gal,

Ton Ngo is the Magnum liaison for Kuryr [1]. Ton will sync up Kuryr liaison in 
weekly basis and provide status update at the Magnum team meeting. Please feel 
free to let Ton or me know if anything we can help. I am looking forward to 
collaborating with Kuryr team to move the implementation forward.

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons

Best regards,
Hongbin

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: May-24-16 4:23 AM
To: OpenStack Development Mailing List (not for usage questions); Fawad Khaliq; 
Antoni Segura Puimedon; Irena Berezovsky; Mohammad Banikazemi
Subject: Re: [openstack-dev] [magnum][kuryr] Nested containers networking

Hi Hongbin,

Thank you for starting this thread.
The person that is going to work on this integration is Fawad (CC'ed) and 
hopefully others will help
him (We have another person from Huawei that showed intrest in working on this).

I think Fawad, given that he is the primary person working on this should be 
Kuryr liaison for this integration
and it could help alot if he has a contact in Magnum that can work with him on 
that closely.
I can also serve as the coordinator between these efforts given that Fawad is 
too busy.

The first task in my view is to start describing the action items for this 
integration, split the work and address
any unknown issues during this process.

I think that design wise things are pretty close (Fawad, please correct me if 
there are any open issues)
and we are just waiting to start the work (and solve any issues as they come)

Thanks
Gal.


On Mon, May 23, 2016 at 6:35 PM, Hongbin Lu 
> wrote:
Hi Kuryr team,

I want to start this ML to sync up the latest status of the nested container 
networking implementation. Could I know who is implementing this feature in 
Kuryr side and how Magnum team could help in this efforts? In addition, I 
wonder if it makes sense to establish cross-project liaisons between Kuryr and 
Magnum. Magnum relies on Kuryr to implement several important features so I 
think it is helpful to setup a communication channel between both teams. 
Thoughts?

Best regards,
Hongbin

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



--
Best Regards ,

The G.
__
OpenStack Development Mailing 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] [new][oslo] oslo.policy 1.8.0 release (newton)

[no-reply]

We are happy to announce the release of:

oslo.policy 1.8.0: Oslo Policy library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.policy

With package available at:

https://pypi.python.org/pypi/oslo.policy

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.policy

For more details, please see below.

Changes in oslo.policy 1.7.0..1.8.0
---

5a8969c Trivial: ignore openstack/common in flake8 exclude list

Diffstat (except docs and test files)
-

tox.ini | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.config 3.10.0 release (newton)

[no-reply]

We are glad to announce the release of:

oslo.config 3.10.0: Oslo Configuration API

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.config

With package available at:

https://pypi.python.org/pypi/oslo.config

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.config

For more details, please see below.

Changes in oslo.config 3.9.0..3.10.0


cd16e52 sphinxconfiggen to generate multiple sample files
9c6bbb1 Fix typo in sphinxconfiggen docs
9930ba4 Updated from global requirements
272a701 fix wrong module name sphinxgenconfig in doc
ed2da1f Update Beta development status from classifiers
6340127 Add 'DEPRECATED: ' prefix for deprecated opts
01ed4fc Avoid duplicate sections in generator output
2799468 Updated from global requirements
bc8f4e7 Updated from global requirements
25926d2 Add * to .coverage in .gitignore
009eb89 Add enfore_type parameter for set_default,
3497a63 Don't set html_last_updated_fmt without git
1d73522 Updated from global requirements
e742fca Updated from global requirements
3f21be7 cfg: do not add --version if not version provided
0d10f6b doc:Log warning when can't get information from git
fa16eb7 Explicitly exclude tests from bandit scan
2531de7 Fix typo error in docstrings of oslo_config.cfg.py
353b7f7 improve documentation about registering entry points for config 
generator
37588d7 Fix isinstance call
5bee7b4 Replace deprecated LOG.warn with LOG.warning
8becbb6 Update reno for stable/mitaka
a1a1c89 Fallback if git is absent
47318f2 Move bandit into pep8
48977b6 Cleanup open file handles in test cases

Diffstat (except docs and test files)
-

.gitignore|   2 +-
oslo_config/cfg.py|  37 +
oslo_config/generator.py  |  57 -
oslo_config/sphinxconfiggen.py|  45 ---
releasenotes/source/index.rst |   1 +
releasenotes/source/mitaka.rst|   6 ++
requirements.txt  |   2 +-
setup.cfg |   2 +-
test-requirements.txt |   6 +-
tox.ini   |   9 ++-
16 files changed, 391 insertions(+), 95 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 029335d..e0a5ef1 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ six>=1.9.0 # MIT
-stevedore>=1.5.0 # Apache-2.0
+stevedore>=1.10.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index fe3d3d1..47f809d 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ discover # BSD
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD
@@ -23 +23 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-reno>=0.1.1 # Apache2
+reno>=1.6.2 # Apache2
@@ -32 +32 @@ mock>=1.2 # BSD
-bandit>=0.17.3 # Apache-2.0
+bandit>=1.0.1 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.reports 1.9.0 release (newton)

[no-reply]

We are psyched to announce the release of:

oslo.reports 1.9.0: oslo.reports library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.reports

With package available at:

https://pypi.python.org/pypi/oslo.reports

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.reports

For more details, please see below.

Changes in oslo.reports 1.8.0..1.9.0


71ce8f5 Trivial: ignore openstack/common in flake8 exclude list

Diffstat (except docs and test files)
-

tox.ini | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.middleware 3.11.0 release (newton)

[no-reply]

We are glad to announce the release of:

oslo.middleware 3.11.0: Oslo Middleware library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.middleware

With package available at:

https://pypi.python.org/pypi/oslo.middleware

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.middleware

For more details, please see below.

Changes in oslo.middleware 3.10.0..3.11.0
-

6f1db02 cors: remove unused import
f5a55c6 Updated from global requirements
315b9a8 Add a simple __main__ to easily show healthcheck output

Diffstat (except docs and test files)
-

oslo_middleware/cors.py   |  1 -
oslo_middleware/healthcheck/__main__.py   | 69 +++
requirements.txt  |  2 +-
4 files changed, 94 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index f03122f..30a44b7 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12 +12 @@ six>=1.9.0 # MIT
-stevedore>=1.9.0 # Apache-2.0
+stevedore>=1.10.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.concurrency 3.9.0 release (newton)

[no-reply]

We are pumped to announce the release of:

oslo.concurrency 3.9.0: Oslo Concurrency library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.concurrency

With package available at:

https://pypi.python.org/pypi/oslo.concurrency

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.concurrency

For more details, please see below.

Changes in oslo.concurrency 3.8.0..3.9.0


7e47d32 Add doc/ to pep8 check
89f890b Remove unused import statement
c876fab Add timeout option to ssh_execute
7279c31 Fix wrong import example in docstring
45cf9f0 Trivial: ignore openstack/common in flake8 exclude list

Diffstat (except docs and test files)
-

oslo_concurrency/lockutils.py|  4 ++--
oslo_concurrency/processutils.py |  5 +++--
tox.ini  |  2 +-
5 files changed, 18 insertions(+), 9 deletions(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.cache 1.8.0 release (newton)

[no-reply]

We are gleeful to announce the release of:

oslo.cache 1.8.0: Cache storage for Openstack projects.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.cache

With package available at:

https://pypi.python.org/pypi/oslo.cache

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.cache

For more details, please see below.

Changes in oslo.cache 1.7.0..1.8.0
--

6251a15 Trivial: ignore openstack/common in flake8 exclude list

Diffstat (except docs and test files)
-

tox.ini | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [new][oslo] oslo.context 2.4.0 release (newton)

[no-reply]

We are stoked to announce the release of:

oslo.context 2.4.0: Oslo Context library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.context

With package available at:

https://pypi.python.org/pypi/oslo.context

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.context

For more details, please see below.

Changes in oslo.context 2.3.0..2.4.0


cf33c02 Trivial: ignore openstack/common in flake8 exclude list
0511e11 Strip roles in from_environ
e192563 Allow deprecated headers in from_environ

Diffstat (except docs and test files)
-

oslo_context/context.py| 36 +++---
tox.ini|  2 +-
3 files changed, 81 insertions(+), 10 deletions(-)




__
OpenStack Development Mailing 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] [magnum] Need helps to implement the full baremetals support

[Hongbin Lu]

Hi all,

One of the most important feature that Magnum team wants to deliver in Newton 
is the full baremetal support. There is a blueprint [1] created for that and 
the blueprint was marked as "essential" (that is the highest priority). Spyros 
is the owner of the blueprint and he is looking for helps from other 
contributors. For now, we immediately needs help to fix the existing Ironic 
templates [2][3][4] that are used to provision a Kubernetes cluster on top of 
baremetal instances. These templates were used to work, but they become 
outdated right now. We need help to fix those Heat template as an initial step 
of the implementation. Contributors are expected to follow the Ironic devstack 
guide to setup the environment. Then, exercise those templates in Heat.

If you interest to take the work, please contact Spyros or me and we will 
coordinate the efforts.

[1] https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
[2] 
https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster-fedora-ironic.yaml
[3] 
https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster-fedora-ironic.yaml
[4] 
https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion-fedora-ironic.yaml

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

Re: [openstack-dev] [PTLs][all][mentoring] Mentors needed in specific technical areas

[Mike Perez]

On 12:54 May 24, Augustina Ragwitz wrote:
> Hi Emily,
> 
> I'm the Nova Mentoring Czar and we have a Wiki page with a list of
> projects that would be good for new contributors:
> https://wiki.openstack.org/wiki/Nova/Mentoring
> 
> For Nova, I'd encourage potential contributors to get involved with a
> specific project so that mentoring can happen organically. Interested
> folks are more than welcome to reach out to me, preferably by email.

There's an assumption here that all projects have things in place to begin
mentoring people. With the people we've spoken to, sometimes just reaching on
IRC gave no answers. This is actually matching people to someone who has
knowledge and is interested/has time to mentor. Even if a match can't be made
right away, communication is made. First impressions with on boarding is key.

-- 
Mike Perez

__
OpenStack Development Mailing 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][neutron][cloud-init] Questions around 'network_data.json'

[Ryan Harper]

On Tue, May 24, 2016 at 4:20 PM, Joshua Harlow 
wrote:

> Hi there all,
>
> I am working through code/refactoring in cloud-init to enable translation
> of the network_data.json file[1] provided by openstack (via nova via
> neutron?) into the equivalent sysconfig files (ubuntu files should already
> *mostly* work and systemd files are underway as well).
>
> Code for this sysconfig (WIP) is @
> https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7
> (requires base branch
> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor
> which did some tweaks to make things easier to work with).
>
> Sadly there has been some questions around certain format conversion and
> what it means when certain formats are given, for example in the following
> example:
>
> {
>   "services": [
> {
>   "type": "dns",
>   "address": "172.19.0.12"
> }
>   ],
>   "networks": [
> {
>   "network_id": "dacd568d-5be6-4786-91fe-750c374b78b4",
>   "type": "ipv4",
>   "netmask": "255.255.252.0",
>   "link": "tap1a81968a-79",
>   "routes": [
> {
>   "netmask": "0.0.0.0",
>   "network": "0.0.0.0",
>   "gateway": "172.19.3.254"
> }
>   ],
>   "ip_address": "172.19.1.34",
>   "id": "network0"
> }
>   ],
>   "links": [
> {
>   "ethernet_mac_address": "fa:16:3e:ed:9a:59",
>   "mtu": null,
>   "type": "bridge",
>   "id": "tap1a81968a-79",
>   "vif_id": "1a81968a-797a-400f-8a80-567f997eb93f"
> }
>   ]
> }
>
> In the cloud-init code what happens is that the links get connected to the
> networks and this gets then internally parsed, but for the bridge type
> listed here it appears information is missing about exactly what to bridge
> to (eth0, ethX? something else)?
>
> Should the 'bridge' type just be ignored and it should just be treated as
> a physical device type (which will cause a different set of logic in
> cloud-init to apply); something else?
>

Thanks Josh,

In particular, I'm hoping to clarify that the spec is meant to describe
guest network configuration (be that a baremetal instance in Ironic or a
VM).  If that holds, then I think
exposing the compute node config (LinuxBridge in this case) into guest
network config is confusing, and instead the network_data.json should have
had type: vif or type: phys.

The same holds true for ovs setup's, we've seen this network_data.json:


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

then ovs setups should emit type: vif  or type: phys to indicate a guest
'physical' interface.

Thanks,
Ryan
__
OpenStack Development Mailing 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][neutron][cloud-init] Questions around 'network_data.json'

[Mathieu Gagné]

I think there is an implementation error.
The spec mentions that link type can be "vif", "phy" or (future) "bond".
Nova passes the "raw" Neutron VIF type instead.
IMO, "bridge" should be "vif" as per spec.
--
Mathieu


On Tue, May 24, 2016 at 5:20 PM, Joshua Harlow  wrote:
> Hi there all,
>
> I am working through code/refactoring in cloud-init to enable translation of
> the network_data.json file[1] provided by openstack (via nova via neutron?)
> into the equivalent sysconfig files (ubuntu files should already *mostly*
> work and systemd files are underway as well).
>
> Code for this sysconfig (WIP) is @
> https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 (requires
> base branch
> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor
> which did some tweaks to make things easier to work with).
>
> Sadly there has been some questions around certain format conversion and
> what it means when certain formats are given, for example in the following
> example:
>
> {
>   "services": [
> {
>   "type": "dns",
>   "address": "172.19.0.12"
> }
>   ],
>   "networks": [
> {
>   "network_id": "dacd568d-5be6-4786-91fe-750c374b78b4",
>   "type": "ipv4",
>   "netmask": "255.255.252.0",
>   "link": "tap1a81968a-79",
>   "routes": [
> {
>   "netmask": "0.0.0.0",
>   "network": "0.0.0.0",
>   "gateway": "172.19.3.254"
> }
>   ],
>   "ip_address": "172.19.1.34",
>   "id": "network0"
> }
>   ],
>   "links": [
> {
>   "ethernet_mac_address": "fa:16:3e:ed:9a:59",
>   "mtu": null,
>   "type": "bridge",
>   "id": "tap1a81968a-79",
>   "vif_id": "1a81968a-797a-400f-8a80-567f997eb93f"
> }
>   ]
> }
>
> In the cloud-init code what happens is that the links get connected to the
> networks and this gets then internally parsed, but for the bridge type
> listed here it appears information is missing about exactly what to bridge
> to (eth0, ethX? something else)?
>
> Should the 'bridge' type just be ignored and it should just be treated as a
> physical device type (which will cause a different set of logic in
> cloud-init to apply); something else?
>
> Thoughts would be appreciated,
>
> [1]
> http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact
>
> -Josh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] Xvisor support

[Michael Still]

On Tue, May 24, 2016 at 11:42 PM, Muneeb Ahmad 
wrote:

> If not, can I add it's support? any ideas how can I do that?
>
> On Sat, May 21, 2016 at 10:23 PM, Muneeb Ahmad 
> wrote:
>
>> Hey guys,
>>
>> Does OpenStack support Xvisor?
>>
>
So, given I'd never heard of xvisor I think we can say that no one has been
thinking about supporting it.

Nova has a pluggable layer for adding hypervisors, and its certainly
possible to do that thing. That said, Nova is pretty hesitant these days to
add new hypervisor drivers, as its a lot of maintenance work for the team,
especially if the original authors of a driver wander off.

A first port of call is probably to work out if you could get support added
to libvirt, and then what exposing that in the libvirt driver for Nova
would look like.

Hope this helps,
Michael

-- 
Rackspace Australia
__
OpenStack Development Mailing 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][neutron][cloud-init] Questions around 'network_data.json'

[Joshua Harlow]

Hi there all,

I am working through code/refactoring in cloud-init to enable 
translation of the network_data.json file[1] provided by openstack (via 
nova via neutron?) into the equivalent sysconfig files (ubuntu files 
should already *mostly* work and systemd files are underway as well).


Code for this sysconfig (WIP) is @ 
https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 
(requires base branch 
https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor 
which did some tweaks to make things easier to work with).


Sadly there has been some questions around certain format conversion and 
what it means when certain formats are given, for example in the 
following example:


{
  "services": [
{
  "type": "dns",
  "address": "172.19.0.12"
}
  ],
  "networks": [
{
  "network_id": "dacd568d-5be6-4786-91fe-750c374b78b4",
  "type": "ipv4",
  "netmask": "255.255.252.0",
  "link": "tap1a81968a-79",
  "routes": [
{
  "netmask": "0.0.0.0",
  "network": "0.0.0.0",
  "gateway": "172.19.3.254"
}
  ],
  "ip_address": "172.19.1.34",
  "id": "network0"
}
  ],
  "links": [
{
  "ethernet_mac_address": "fa:16:3e:ed:9a:59",
  "mtu": null,
  "type": "bridge",
  "id": "tap1a81968a-79",
  "vif_id": "1a81968a-797a-400f-8a80-567f997eb93f"
}
  ]
}

In the cloud-init code what happens is that the links get connected to 
the networks and this gets then internally parsed, but for the bridge 
type listed here it appears information is missing about exactly what to 
bridge to (eth0, ethX? something else)?


Should the 'bridge' type just be ignored and it should just be treated 
as a physical device type (which will cause a different set of logic in 
cloud-init to apply); something else?


Thoughts would be appreciated,

[1] 
http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact


-Josh

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

Re: [openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer

[Mauricio Lima]

Thanks guys, it's a privilege to be part of team. :)

2016-05-24 17:02 GMT-03:00 Steven Dake (stdake) :

> From: Steven Dake 
> Reply-To: "openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, May 17, 2016 at 12:00 PM
> To: "openstack-dev@lists.openstack.org"  >
> Subject: [openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer
>
> Hello core reviewers,
>
> I am proposing Mauricio (mlima on irc) for the core review team.  He has
> done a fantastic job reviewing appearing in the middle of the pack for 90
> days [1] and appearing as #2 in 45 days [2].  His IRC participation is also
> fantastic and does a good job on technical work including implementing
> Manila from zero experience :) as well as code cleanup all over the code
> base and documentation.  Consider my proposal a +1 vote.
>
> I will leave voting open for 1 week until May 24th.  Please vote +1
> (approve), or –2 (veto), or abstain.  I will close voting early if there is
> a veto vote, or a unanimous vote is reached.
>
> Thanks,
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla/90
> [2] http://stackalytics.com/report/contribution/kolla/45
>
>
> Mauricio,
>
> Congratulations, the vote passed with (iirc 10 votes).  A couple people
> are out on vacation, so I wouldn't take offense :)
>
> I've added you to the appropriate group in gerrit.  Ping me when you next
> see me and I'll give you a crash course on the policies for core reviewers.
>
> Regards
> -steve
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [higgins] Continued discussion from the last team meeting

[Hongbin Lu]

Hi all,

At the last team meeting, we tried to define the scope of the Higgins project. 
In general, we agreed to focus on the following features as an initial start:

* Build a container abstraction and use docker as the first 
implementation.

* Focus on basic container operations (i.e. CRUD), and leave advanced 
operations (i.e. keep container alive, rolling upgrade, etc.) to users or other 
projects/services.

* Start with non-nested container use cases (e.g. containers on 
physical hosts), and revisit nested container use cases (e.g. containers on 
VMs) later.
The items below needs further discussion so I started this ML to discuss it.

1.   Container composition: implement a docker compose like feature

2.   Container host management: abstract container host
For #1, it seems we broadly agreed that this is a useful feature. The argument 
is where this feature belongs to. Some people think this feature belongs to 
other projects, such as Heat, and others think it belongs to Higgins so we 
should implement it. For #2, we were mainly debating two things: where the 
container hosts come from (provisioned by Nova or provided by operators); 
should we expose host management APIs to end-users? Thoughts?

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

Re: [openstack-dev] update congress

[Tim Hinrichs]

Hi Yue,

That version of Congress definitely doesn't have the Push driver.  The Push
driver code was implemented only in the latest release (Mitaka).

Here are the upgrade instructions.  They SHOULD work, but let us know if
you run into problems, both so we can help you and so we can correct the
instructions.

https://review.openstack.org/#/c/320652/2/README.rst

Tim

On Tue, May 24, 2016 at 3:40 AM Yue Xin  wrote:

> Hi Tim and all,
>
> May I ask how to update the congress version with the Tokyo Hands on Lab
> environment? cause I use the command ＂openstack congress list version＂ it
> show the congress is 2013's version.
>
> The reason why I want to update it is that I write a demo driver, which I
> want to push data into the datasource table, but when I use 'curl -i -g -X
> PUT ' command , the error is "501 not implemented" , same error comes with
> 'curl -X PUSH', I am not sure whether it comes from the version of congress
> or not(I thought maybe congress is too old so it doesn't support push data).
>
> Thank you very much for your response.
>
> *Regards,*
> *Yue*
>
__
OpenStack Development Mailing 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] [vitrage] Vitrage meeting on May 25 - SKIPPED

[Afek, Ifat (Nokia - IL)]

Hi,

Vitrage weekly meeting on May 25 will be skipped, as many Vitrage developers 
won't be able to attend.
We will meet next week as usual.

Thanks,
Ifat.



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

Re: [openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer

[Steven Dake (stdake)]

From: Steven Dake >
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Tuesday, May 17, 2016 at 12:00 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer

Hello core reviewers,

I am proposing Mauricio (mlima on irc) for the core review team.  He has done a 
fantastic job reviewing appearing in the middle of the pack for 90 days [1] and 
appearing as #2 in 45 days [2].  His IRC participation is also fantastic and 
does a good job on technical work including implementing Manila from zero 
experience :) as well as code cleanup all over the code base and documentation. 
 Consider my proposal a +1 vote.

I will leave voting open for 1 week until May 24th.  Please vote +1 (approve), 
or -2 (veto), or abstain.  I will close voting early if there is a veto vote, 
or a unanimous vote is reached.

Thanks,
-steve

[1] http://stackalytics.com/report/contribution/kolla/90
[2] http://stackalytics.com/report/contribution/kolla/45

Mauricio,

Congratulations, the vote passed with (iirc 10 votes).  A couple people are out 
on vacation, so I wouldn't take offense :)

I've added you to the appropriate group in gerrit.  Ping me when you next see 
me and I'll give you a crash course on the policies for core reviewers.

Regards
-steve

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

Re: [openstack-dev] [all][oslo_config] Improving Config Option Help Texts

[John Garbutt]

On 24 May 2016 at 19:03, Ian Cordasco  wrote:
> -Original Message-
> From: Erno Kuvaja 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: May 24, 2016 at 06:06:14
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject:  [openstack-dev] [all][oslo_config] Improving Config Option Help 
> Texts
>
>> Hi all,
>>
>> Based on the not yet merged spec of categorized config options [0] some
>> project seems to have started improving the config option help texts. This
>> is great but I noticed scary trend on clutter to be added on these
>> sections. Now looking individual changes it does not look that bad at all
>> in the code 20 lines well structured templating. Until you start comparing
>> it to the example config files. Lots of this data is redundant to what is
>> generated to the example configs already and then the maths struck me.
>>
>> In Glance only we have ~120 config options (this does not include
>> glance_store nor any other dependencies we pull in for our configs like
>> Keystone auth. Those +20 lines of templating just became over 2000 lines of
>> clutter in the example configs and if all projects does that we can
>> multiply the issue. I think no-one with good intention can say that it's
>> beneficial for our deployers and admins who are already struggling with the
>> configs.
>>
>> So I beg you when you do these changes to the config option help fields
>> keep them short and compact. We have the Configuration Docs for extended
>> descriptions and cutely formatted repetitive fields, but lets keep those
>> off from the generated (Example) config files. At least I would like to be
>> able to fit more than 3 options on the screen at the time when reading
>> configs.
>>
>> [0] https://review.openstack.org/#/c/295543/
>
> Hey Erno,
>
> So here's where I have to very strongly disagree with you. That spec
> was caused by operator feedback, specifically for projects that
> provide multiple services that may or may not have separated config
> files which and which already have "short and compact" descriptions
> that are not very helpful to oeprators.

+1

The feedback at operator sessions in Manchester and Austin seemed to
back up the need for better descriptions.

More precisely, Operators should not need to read the code to
understand how to use the configuration option.

Now often that means they are longer. But they shouldn't be too long.

> The *example* config files will have a lot more detail in them. Last I
> saw (I've stopped driving that specification) there was going to be a
> way to generate config files without all of the descriptions. That
> means that for operators who don't care about that can ignore it when
> they generate configuration files. Maybe the functionality doesn't
> work right this instant, but I do believe that's a goal and it will be
> implemented.

Different modes of the config generator should help us cater for
multiple use cases.

I am leaving that as a discussion in oslo specs for the moment.

> Beyond that, I don't think example/sample configuration files should
> be treated differently from documentation, nor do I think that our
> documentation team couldn't make use of the improved documentation
> we're adding to each option. In short, I think this effort will
> benefit many different groups of people in and around OpenStack.
> Simply arguing that this is going to make the sample config files have
> more lines of code is not a good argument against this. Please do
> reconsider.

Now I have been discussing a change in Nova's approach to reduce the
size of some of them, but that was really for different reasons:
http://lists.openstack.org/pipermail/openstack-dev/2016-May/095538.html

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] [all][tc] Languages vs. Scope of "OpenStack"

[Adrian Otto]

> On May 24, 2016, at 12:09 PM, Mike Perez  wrote:
> 
> On 12:24 May 24, Thierry Carrez wrote:
>> Morgan Fainberg wrote:
>>> [...]  If we are accepting golang, I want it to be clearly
>>> documented that the expectation is it is used exclusively where there is
>>> a demonstrable case (such as with swift) and not a carte blanche to use
>>> it wherever-you-please.
>>> 
>>> I want this to be a social contract looked at and enforced by the
>>> community, not special permissions that are granted by the TC (I don't
>>> want the TC to need to step in an approve every single use case of
>>> golang, or javascript ...). It's bottlenecking back to the TC for
>>> special permissions or inclusion (see reasons for the dissolution of the
>>> "integrated release").
>>> 
>>> This isn't strictly an all or nothing case, this is a "how would we
>>> enforce this?" type deal. Lean on infra to enforce that only projects
>>> with the golang-is-ok-here tag are allowed to use it? I don't want
>>> people to write their APIs in javascript (and node.js) nor in golang. I
>>> would like to see most of the work continue with python as the primary
>>> language. I just think it's unreasonable to lock tools behind a gate
>>> that is stronger than the social / community contract (and outlined in
>>> the resolution including X language).
>> 
>> +1
>> 
>> I'd prefer if we didn't have to special-case anyone, and we could come up
>> with general rules that every OpenStack project follows. Any other solution
>> is an administrative nightmare and a source of tension between projects (why
>> are they special and not me).
> 
> I'm in agreement that I don't want to see the TC enforcing this. In fact as
> Thierry has said, lets not special case anyone.
> 
> As soon as a special case is accepted, as nortoriously happens people are 
> going
> to go in a corner and rewrite things in Go. They will be upset later for not
> communicating well on their intentions upfront, and the TC or a few strongly
> opinionated folks in the community are going to be made the bad people just
> about every time.
> 
> Community enforcing or not, I predict this to get out of hand and it's going 
> to
> create more community divide regardless.

I remember in 2010, our founding intent was to converge on two languages for 
OpenStack Development: Python and C. We would prefer Python for things like 
control plane API services, and when needed for performance or other reasons, 
we would use C as an alternative. To my knowledge, since then nothing was ever 
written in C. We have a clear trend of high performance alternative solutions 
showing up in Golang. So, I suggest we go back to the original intent that we 
build things in Python as our preference, and allow teams to select a 
designated alternative when they have their own reasons to do that. I see no 
reason why that designated alternative can not be Golang[1].

Programming syles and languages evolve over time. Otherwise we’d all still be 
using FORTRAN from 1954. OpenStack, as a community needs to have a deliberate 
plan for how to track such evolution. Digging our heels in with a Python only 
attitude is not progressive enough. Giving choice of any option under the sun 
is not practical. We will strike a balance. Recognize that evolution requires 
duplication. There must be overlap (wasted effort maintaining common code in 
multiple languages) in order to allow evolution. This overlap is healthy. We 
don’t need our TC to decide when a project should be allowed to use a 
designated alternative. Set rules that allow for innovation, and then let 
projects decide on their own within such guidelines.

My proposal:

"Openstack projects shall use Python as the preferred programming language. 
Golang may be used as an alternative if the project leadership decides it is 
justified."

Additional (non-regulatory) guidance can also be offered by the OpenStack 
community to indicate when individual projects should decide to use an 
alternative language. In the future as we notice evolution around us, we may 
add other alternatives to that list.

Thanks,

Adrian

[1] I categorically reject the previous rhetoric that casts Golang as a 
premature language that we can’t rely on. That’s FUD, plain and simple. Stop it.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTLs][all][mentoring] Mentors needed in specific technical areas

[Augustina Ragwitz]

Hi Emily,

I'm the Nova Mentoring Czar and we have a Wiki page with a list of
projects that would be good for new contributors:
https://wiki.openstack.org/wiki/Nova/Mentoring

For Nova, I'd encourage potential contributors to get involved with a
specific project so that mentoring can happen organically. Interested
folks are more than welcome to reach out to me, preferably by email.

-- 
Augustina Ragwitz
Sr Systems Software Engineer, HPE Cloud
Hewlett Packard Enterprise
---
irc: auggy

__
OpenStack Development Mailing 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][neutron] bonding?

[Sean M. Collins]

The only thing I am remotely aware of that is relevant is:

https://bugs.launchpad.net/bugs/1558626

But that's really just in one agent.
-- 
Sean M. Collins

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

Re: [openstack-dev] [Mistral][Zaqar][Ceilometer][Searchlight] Triggering Mistral workflows from Zaqar messages

[Zane Bitter]

On 22/05/16 22:38, Lingxian Kong wrote:

Hi, Zane, I think you must be interested in this:
https://review.openstack.org/#/c/308664/


Oh! Yes that is very interesting. I'm glad that other people are 
thinking about these kinds of problems also.


My blueprint has a different focus, in that it's more about allowing the 
_user_ to configure these actions. Listening to oslo_messaging 
notifications instead of to Zaqar messages limits you to operator use 
cases only. (It's also likely much more efficient - listening to a large 
number of queues simultaneously is not the use case Zaqar is optimised 
for, which is essentially why I changed my mind about whether this 
should be implemented within Mistral.)


At least two projects that I know of (Ceilometer and Searchlight) are 
looking at implementing proxying of oslo_messaging notifications into 
Zaqar queues, and when that is combined with the Zaqar notification 
trigger we'll open up this functionality to everyone - other OpenStack 
services, operators and end-users.


e.g. a user will be able to subscribe (via Ceilometer or Searchlight) to 
a notification about a particular server from Nova in a Zaqar queue and 
have that trigger a Mistral workflow that marks the server unhealthy in 
Heat and triggers a reconvergence of the stack.


Unfortunately, there's always a tension between getting something done 
and in users' hands right now - which is easier to do if you stay within 
the confines of one project - and building flexible, orthogonal, 
user-pluggable abstractions, which are IMHO in the long-term best 
interests of users but generally require the co-operation, co-ordination 
and deployment of multiple projects.


It seems like we, the OpenStack community, are failing not only at 
co-ordinating these kinds of features across projects, but in even know 
what is being planned in other projects. Perhaps we need some sort of 
"Autonomous Applications working group"?


cheers,
Zane.



Regards!
---
Lingxian Kong


On Fri, May 20, 2016 at 9:49 AM, Zane Bitter  wrote:

On 19/05/16 04:20, Thomas Herve wrote:


On Wed, May 18, 2016 at 8:49 PM, Zane Bitter  wrote:


I've been lobbying the Mistral developers for $SUBJECT since, basically,
forever.[1][2][3] I like to think after a couple of years I succeeded in
changing their view on it from "crazy" to merely "unrealistic".[4] In the
last few months I've had a couple of realisations though:

1) The 'pull' model I've been suggesting is the wrong one,
architecturally
speaking. It's asking Mistral to do too much to poll Zaqar queues.
2) A 'push' model is the correct architecture and it already exists in
the
form of Zaqar's Notifications, which suddenly makes this goal look very
realistic indeed.

I've posted a Zaqar spec for this here:

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



Commented. I certainly need some more time to think about it.



Thanks, I updated the spec based on your comments.


Not being super familiar with either project myself, I think this needs
close scrutiny from Mistral developers as well as Zaqar developers to
make
sure I haven't got any of the details wrong. I'd also welcome any
volunteers
interested in implementing this :)


One more long-term thing that I did *not* mention in the spec: there are
both Zaqar notifications and Mistral actions for sending email and
hitting
webhooks. These are two of the hardest things for a cloud operator to
secure. It would be highly advantageous if there were only _one_ place in
OpenStack where these were implemented. Either project would potentially
work - Zaqar notifications could call a simple, operator defined workflow
behind the scenes for email/webhook notifications; alternatively the
Mistral
email/webhook actions could drop a message on a Zaqar queue connected to
a
notification - although the former sounds easier to me. (And of course
clouds with only one of the services available could fall back to the
current plugins.) Something to think about for the future...



And you're forgetting about Aodh alarm notifications, which are
webhooks as well.



Yeah, those just need to go away :) Aodh can already post the notifications
to Zaqar instead, and hopefully we'll be able to migrate everything to that
method over time.


Unfortunately, I think none of them do a
particularly great job in terms of robustness and security.



Agree. The best you can do is still middling, and we're not there yet.


I
suggested moving away from doing webhook in Zaqar to Flavio in the
past, and I think he responded that he thought it was part of the core
functionality. It's hard to delegate such operations and create a
dependency on another project. Maybe we can start by creating some
library code.



I guess that's a start, but if I were running a large public cloud I'd
probably want to isolate this on its own network surrounded by some pretty
custom firewalls. A library doesn't really help make that 

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Fox, Kevin M]

Frankly, this is one of the major negatives we've felt from the Big Tent idea...

OpenStack use to be more of a product then it is now. When there were common 
problems to be solved, there was pressure applied to solve them in a way 
everyone (OpenStack Project, OpenStack Users, and Openstack Operators) would 
benefit from.

For recent example, there has been a lot of talk about reimplementing features 
from Barbican in Magnum, Keystone, etc, and not wanting to depend on Barbican. 
In the pre-tent days, we'd just fix Barbican to do the things we all need it 
to, and then start depending on it. Then, everyone could start depending on a 
solid secret store being there since everyone would deploy it because they 
would want at least one thing that depends on it. Say, Lbaas, or COE 
orchestration, and then adding more projects that depend on it would be easier 
for the operator. Instead I see a lot of of trying to implement a hack in each 
project to try and not depend on it, solving the problem for one project but 
for no one else.

Its a vicious chicken and the egg cycle we have created. Projects don't want to 
depend on things if its not commonly deployed. Operators don't want to deploy 
it if there's not a direct reason to, or something they do care about depending 
on it. So our projects are encouraged to do bad things now and I think we're 
all suffering for it.

Cross project work became much harder after the big tent because there was less 
reason to play nice with each other. OpenStack projects are already fairly 
insular and this has made it worse. Opening up additional languages makes it 
yet harder to work on the common stuff. I'm not against picking 1 additional 
language for performance critical stuff, but it should be carefully considered, 
and should have to be carefully reasoned about the need for.

Thanks,
Kevin


From: Ian Cordasco [sigmaviru...@gmail.com]
Sent: Tuesday, May 24, 2016 12:12 PM
To: Jay Pipes; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

-Original Message-
From: Jay Pipes 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: May 24, 2016 at 11:35:42
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

> On 05/24/2016 06:19 AM, Thierry Carrez wrote:
> > Chris Dent wrote:
> >> [...]
> >> I don't really know. I'm firmly in the camp that OpenStack needs to
> >> be smaller and more tightly focused if a unitary thing called OpenStack
> >> expects to be any good. So I'm curious about and interested in
> >> strategies for figuring out where the boundaries are.
> >>
> >> So that, of course, leads back to the original question: Is OpenStack
> >> supposed to be a unitary.
> >
> > As a data point, since I heard that question rhetorically asked quite a
> > few times over the past year... There is an old answer to that, since a
> > vote of the PPB (the ancestor of our TC) from June, 2011 which was never
> > overruled or changed afterwards:
> >
> > "OpenStack is a single product made of a lot of independent, but
> > cooperating, components."
> >
> > The log is an interesting read:
> > http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-28-20.06.log.html
>
> Hmm, blast from the past. I'm sad I didn't make it to that meeting.
>
> I would (now at least) have voted for #2: OpenStack is "a collection of
> independent projects that work together for some level of integration
> and releases".
>
> This is how I believe OpenStack should be seen, as I wrote on Twitter
> relatively recently:
>
> https://twitter.com/jaypipes/status/705794815338741761
> https://twitter.com/jaypipes/status/705795095262441472

I'm honestly in the same boat as Chris. And I've constantly heard both. I also 
frankly am not sure I agree with the idea that OpenStack is one product. I 
think more along the lines of the way DefCore specifies OpenStack Compute as a 
Product, etc. I feel like if every project contributed to the OpenStack 
product, we might have a better adoption rate and a better knowledge base for 
how to make new services scale from day 1. Instead, we are definitely a loose 
collection of projects that integrate on some levels and produce what various 
people might combine to create a cloud.

I'm also not entirely that the answer remains true with the different defcore 
programs. It seems like DefCore makes us define a minimum viable OpenStack 
{Compute,Object Storage} and then you can add to that. But those two things are 
"OpenStack" and everything else is a nice additional feature. There's nothing 
that makes Barbican or Magnum or Ceilometer a core part of OpenStack. Yet 
they're projects of varying popularity that different people choose whether or 
not to deploy. 

Re: [openstack-dev] [all][oslo_config] Improving Config Option Help Texts

[Hemanth Makkapati]

+1 to what Ian said.

We had an Ops session at the Austin summit on this and we didn't hear any 
concerns about the clutter from what I can recall.
Some notes from that session are here [0].
May be the clutter is not a problem after all? At least, not yet.

If it does become a problem down the line, we can probably move the 
descriptions around or have ways to not generate them at all like Ian 
suggested. 
But, keeping the help texts themselves short and compact won't solve anything. 
It is, in fact, against what we are trying to solve for here, I think.

-Hemanth

[0] https://etherpad.openstack.org/p/AUS-ops-Config-Options

From: Ian Cordasco 
Sent: Tuesday, May 24, 2016 1:03 PM
To: Erno Kuvaja; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][oslo_config] Improving Config Option Help
Texts

-Original Message-
From: Erno Kuvaja 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: May 24, 2016 at 06:06:14
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [all][oslo_config] Improving Config Option Help Texts

> Hi all,
>
> Based on the not yet merged spec of categorized config options [0] some
> project seems to have started improving the config option help texts. This
> is great but I noticed scary trend on clutter to be added on these
> sections. Now looking individual changes it does not look that bad at all
> in the code 20 lines well structured templating. Until you start comparing
> it to the example config files. Lots of this data is redundant to what is
> generated to the example configs already and then the maths struck me.
>
> In Glance only we have ~120 config options (this does not include
> glance_store nor any other dependencies we pull in for our configs like
> Keystone auth. Those +20 lines of templating just became over 2000 lines of
> clutter in the example configs and if all projects does that we can
> multiply the issue. I think no-one with good intention can say that it's
> beneficial for our deployers and admins who are already struggling with the
> configs.
>
> So I beg you when you do these changes to the config option help fields
> keep them short and compact. We have the Configuration Docs for extended
> descriptions and cutely formatted repetitive fields, but lets keep those
> off from the generated (Example) config files. At least I would like to be
> able to fit more than 3 options on the screen at the time when reading
> configs.
>
> [0] https://review.openstack.org/#/c/295543/

Hey Erno,

So here's where I have to very strongly disagree with you. That spec
was caused by operator feedback, specifically for projects that
provide multiple services that may or may not have separated config
files which and which already have "short and compact" descriptions
that are not very helpful to oeprators.

The *example* config files will have a lot more detail in them. Last I
saw (I've stopped driving that specification) there was going to be a
way to generate config files without all of the descriptions. That
means that for operators who don't care about that can ignore it when
they generate configuration files. Maybe the functionality doesn't
work right this instant, but I do believe that's a goal and it will be
implemented.

Beyond that, I don't think example/sample configuration files should
be treated differently from documentation, nor do I think that our
documentation team couldn't make use of the improved documentation
we're adding to each option. In short, I think this effort will
benefit many different groups of people in and around OpenStack.
Simply arguing that this is going to make the sample config files have
more lines of code is not a good argument against this. Please do
reconsider.

--
Ian Cordasco

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

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

Re: [openstack-dev] [ironic][neutron] bonding?

[Armando M.]

On 24 May 2016 at 04:51, Jim Rollenhagen  wrote:

> Hi,
>
> There's rumors floating around about Neutron having a bonding model in
> the near future. Are there any solid plans for that?
>

Who spreads these rumors :)?

To the best of my knowledge I have not seen any RFE proposed recently along
these lines.


> For context, as part of the multitenant networking work, ironic has a
> portgroup concept proposed, where operators can configure bonding for
> NICs in a baremetal machine. There are ML2 drivers that support this
> model and will configure a bond.
>
> Some folks have concerns about landing this code if Neutron is going to
> support bonding as a first-class citizen. So before we delay any
> further, I'd like to find out if there's any truth to this, and what the
> timeline for that might look like.
>
> Thanks!
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Ian Cordasco]

-Original Message-
From: Jay Pipes 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: May 24, 2016 at 11:35:42
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

> On 05/24/2016 06:19 AM, Thierry Carrez wrote:
> > Chris Dent wrote:
> >> [...]
> >> I don't really know. I'm firmly in the camp that OpenStack needs to
> >> be smaller and more tightly focused if a unitary thing called OpenStack
> >> expects to be any good. So I'm curious about and interested in
> >> strategies for figuring out where the boundaries are.
> >>
> >> So that, of course, leads back to the original question: Is OpenStack
> >> supposed to be a unitary.
> >
> > As a data point, since I heard that question rhetorically asked quite a
> > few times over the past year... There is an old answer to that, since a
> > vote of the PPB (the ancestor of our TC) from June, 2011 which was never
> > overruled or changed afterwards:
> >
> > "OpenStack is a single product made of a lot of independent, but
> > cooperating, components."
> >
> > The log is an interesting read:
> > http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-28-20.06.log.html
> >   
>  
> Hmm, blast from the past. I'm sad I didn't make it to that meeting.
>  
> I would (now at least) have voted for #2: OpenStack is "a collection of
> independent projects that work together for some level of integration
> and releases".
>  
> This is how I believe OpenStack should be seen, as I wrote on Twitter
> relatively recently:
>  
> https://twitter.com/jaypipes/status/705794815338741761
> https://twitter.com/jaypipes/status/705795095262441472

I'm honestly in the same boat as Chris. And I've constantly heard both. I also 
frankly am not sure I agree with the idea that OpenStack is one product. I 
think more along the lines of the way DefCore specifies OpenStack Compute as a 
Product, etc. I feel like if every project contributed to the OpenStack 
product, we might have a better adoption rate and a better knowledge base for 
how to make new services scale from day 1. Instead, we are definitely a loose 
collection of projects that integrate on some levels and produce what various 
people might combine to create a cloud.

I'm also not entirely that the answer remains true with the different defcore 
programs. It seems like DefCore makes us define a minimum viable OpenStack 
{Compute,Object Storage} and then you can add to that. But those two things are 
"OpenStack" and everything else is a nice additional feature. There's nothing 
that makes Barbican or Magnum or Ceilometer a core part of OpenStack. Yet 
they're projects of varying popularity that different people choose whether or 
not to deploy. If OpenStack were a product, I'd think that not deploying 
Ceilometer would be the exception.

--  
Ian Cordasco


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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Mike Perez]

On 12:24 May 24, Thierry Carrez wrote:
> Morgan Fainberg wrote:
> >[...]  If we are accepting golang, I want it to be clearly
> >documented that the expectation is it is used exclusively where there is
> >a demonstrable case (such as with swift) and not a carte blanche to use
> >it wherever-you-please.
> >
> >I want this to be a social contract looked at and enforced by the
> >community, not special permissions that are granted by the TC (I don't
> >want the TC to need to step in an approve every single use case of
> >golang, or javascript ...). It's bottlenecking back to the TC for
> >special permissions or inclusion (see reasons for the dissolution of the
> >"integrated release").
> >
> >This isn't strictly an all or nothing case, this is a "how would we
> >enforce this?" type deal. Lean on infra to enforce that only projects
> >with the golang-is-ok-here tag are allowed to use it? I don't want
> >people to write their APIs in javascript (and node.js) nor in golang. I
> >would like to see most of the work continue with python as the primary
> >language. I just think it's unreasonable to lock tools behind a gate
> >that is stronger than the social / community contract (and outlined in
> >the resolution including X language).
> 
> +1
> 
> I'd prefer if we didn't have to special-case anyone, and we could come up
> with general rules that every OpenStack project follows. Any other solution
> is an administrative nightmare and a source of tension between projects (why
> are they special and not me).

I'm in agreement that I don't want to see the TC enforcing this. In fact as
Thierry has said, lets not special case anyone.

As soon as a special case is accepted, as nortoriously happens people are going
to go in a corner and rewrite things in Go. They will be upset later for not
communicating well on their intentions upfront, and the TC or a few strongly
opinionated folks in the community are going to be made the bad people just
about every time.

Community enforcing or not, I predict this to get out of hand and it's going to
create more community divide regardless.

-- 
Mike Perez

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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Joshua Harlow]

Ok, probably should be chopped out of the oslo lib list then ;)

I'll do that, since it seems to be really not the right name for what it 
is :)


Ian Cordasco wrote:

-Original Message-
From: Joshua Harlow
Reply: OpenStack Development Mailing List (not for usage 
questions)
Date: May 23, 2016 at 15:23:32
To: OpenStack Development Mailing List (not for usage 
questions)
Subject:  Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"


Sean Dague wrote:

On 05/23/2016 03:34 PM, Gregory Haynes wrote:

On Mon, May 23, 2016, at 11:48 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2016-05-23 17:07:36 +0100:

On Mon, 23 May 2016, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2016-05-20 14:16:15 +0100:

I don't think language does (or should) have anything to do with it.

The question is whether or not the tool (whether service or
dependent library) is useful to and usable outside the openstack-stack.
For example gnocchi is useful to openstack but you can use it with other
stuff, therefore _not_ openstack. More controversially: swift can be
usefully used all by its lonesome: _not_ openstack.

Making a tool which is useful outside of the OpenStack context just
seems like good software engineering - it seems odd that we would try
and ensure our tools do not fit this description. Fortunately, many (or
even most) of the tools we create *are* useful outside of the OpenStack
world - pbr, git-review, diskimage-builder, (I hope) many of the oslo
libraries. This is really a question of defining useful interfaces more
than anything else, not a statement of whether a tool is part of our
community.

Only if you are willing to pay the complexity and debt cost of having
optional backends all over the place.


We seem to do this quite well even without building tools/projects that
work outside of openstack ;)

Or are you saying that using such library/project(s) u have to accept
that there will be many optional backends that you will likely not/never
use that exist in said library/project (and thus are akin to dead weight)?


For instance, I think we're well beyond that point that Keystone being
optional should be a thing anywhere (and it is a thing in a number of
places). Keystone should be our auth system, all projects 100% depend on
it, and if you have different site needs, put that into a Keystone backend.

Most of the oslo libraries require other oslo libraries, which is fine.
They aren't trying to solve the general purpose case of logging or
configuration or db access. They are trying to solve a specific set of
patterns that are applicable to OpenStack projects.


I just took a quick stab at annotating which ones (I think are) useable
outside of openstack (without say bringing in the configuration
ideology/pattern that oslo.config adds) and made the following:

automaton (useable)
cliff (useable)
cookiecutter (useable)


I'm catching up on this thread, but cookiecutter most certainly is *NOT* an 
OpenStack project: https://pypi.io/project/cookiecutter/

It was createdy by Audrey Roy Greenfeld.


debtcollector (useable)
futurist (useable)
osprofiler (useable?)
oslo.cache
oslo.concurrency
oslo.context
oslo.config
oslo-cookiecutter
oslo.db
oslo.i18n
oslo.log
oslo.messaging
oslo.middleware
oslo.policy (useable?)
oslo.privsep (useable?)
oslo.reports
oslo.rootwrap
oslo.serialization (useable)
oslo.service
oslosphinx
oslotest (useable)
oslo.utils (useable)
oslo.versionedobjects
oslo.vmware
hacking (useable)
pbr (useable)
pyCADF (useable?)
stevedore (useable)
taskflow (useable)
tooz (useable)

So out of 33 that's about half (~17) that I think are useable outside
without to many patterns/ideologies being forced on non-openstack folks
(if your external project accepts the pattern of oslo.config then the
number increases).


-Sean



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



--
Ian Cordasco



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

Re: [openstack-dev] [oslo] Log spool in the context

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-05-24 14:16:13 -0400:
> On 05/24/2016 01:18 PM, Doug Hellmann wrote:
> > Excerpts from Alexis Lee's message of 2016-05-24 09:34:36 +0100:
> >> Hi,
> >>
> >> I have a spec: https://review.openstack.org/227766
> >> and implementation: https://review.openstack.org/316162
> >> for adding a spooling logger to oslo.log. Neither is merged yet, reviews
> >> welcome.
> >>
> >> Looking at how I'd actually integrate this into Nova, most classes do:
> >>
> >> LOG = logging.getLogger(__name__)
> >>
> >> which is the recommended means of getting a logger. I need to get
> >> certain code paths to use a different logger (if spooling is turned on).
> >> This means I need to pass it around. If I modify method signatures I'm
> >> bound to break back-compat for something.
> >>
> >> Option 1: use a metaclass to register each SpoolManager as a singleton,
> >> IE every call to SpoolManager('api') will return the same manager. I can
> >> then do something like:
> >>
> >> log = LOG
> >> if CONF.spool_api:
> >> log = SpoolManager('api').get_spool(context.request_id)
> >>
> >> in every method.
> >>
> >> Option 2: Put the logger on the context. We're already passing this
> >> everywhere so it'd be awful convenient.
> >>
> >> log = context.log or LOG
> >>
> >> Option 3: ???
> >>
> >> I like option 2, any objections to extending oslo.context like this?
> >>
> >>
> >> Alexis (lxsli)
> > 
> > Do you need more than one? The spec talks about different types of
> > requests having different SpoolManagers (api and scheduler are the 2
> > examples given).
> > 
> > What happens when the context is serialized and sent across an RPC call?
> > Is there some representation of the logger that the messaging code can
> > use on the other side to reconstruct the logger?
> 
> Right, the serialization of the context makes this something I'd rather
> avoid. While in the past I've argued for adding more to context, it is
> sort of useful that it's mostly just a container of attributes for being
> a universal thing. Doug corrected my thinking there, and I thank him for
> it.
> 
> I'd rather have it be more explicit.
> 
> -Sean
> 

Rather than forcing SpoolManager to be a singleton, maybe the thing
to do is build some functions for managing a singleton instance (or
one per type or whatever), and making that API convenient enough
that using the spool logger doesn't require adding a bunch of logic
and import_opt() calls all over the place.  Since it looks like the
convenience function would require looking at a config option owned
by the application, it probably shouldn't live in oslo.log, but
putting it in a utility module in nova might make sense.

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] [all][tc] Languages vs. Scope of "OpenStack"

[Ian Cordasco]

-Original Message-
From: Joshua Harlow 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: May 23, 2016 at 15:23:32
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

> Sean Dague wrote:
> > On 05/23/2016 03:34 PM, Gregory Haynes wrote:
> >> On Mon, May 23, 2016, at 11:48 AM, Doug Hellmann wrote:
> >>> Excerpts from Chris Dent's message of 2016-05-23 17:07:36 +0100:
>  On Mon, 23 May 2016, Doug Hellmann wrote:
> > Excerpts from Chris Dent's message of 2016-05-20 14:16:15 +0100:
> >> I don't think language does (or should) have anything to do with it.
> >>
> >> The question is whether or not the tool (whether service or
> >> dependent library) is useful to and usable outside the openstack-stack.
> >> For example gnocchi is useful to openstack but you can use it with 
> >> other
> >> stuff, therefore _not_ openstack. More controversially: swift can be
> >> usefully used all by its lonesome: _not_ openstack.
> >> Making a tool which is useful outside of the OpenStack context just
> >> seems like good software engineering - it seems odd that we would try
> >> and ensure our tools do not fit this description. Fortunately, many (or
> >> even most) of the tools we create *are* useful outside of the OpenStack
> >> world - pbr, git-review, diskimage-builder, (I hope) many of the oslo
> >> libraries. This is really a question of defining useful interfaces more
> >> than anything else, not a statement of whether a tool is part of our
> >> community.
> >
> > Only if you are willing to pay the complexity and debt cost of having
> > optional backends all over the place.
>  
> We seem to do this quite well even without building tools/projects that
> work outside of openstack ;)
>  
> Or are you saying that using such library/project(s) u have to accept
> that there will be many optional backends that you will likely not/never
> use that exist in said library/project (and thus are akin to dead weight)?
>  
> >
> > For instance, I think we're well beyond that point that Keystone being
> > optional should be a thing anywhere (and it is a thing in a number of
> > places). Keystone should be our auth system, all projects 100% depend on
> > it, and if you have different site needs, put that into a Keystone backend.
> >
> > Most of the oslo libraries require other oslo libraries, which is fine.
> > They aren't trying to solve the general purpose case of logging or
> > configuration or db access. They are trying to solve a specific set of
> > patterns that are applicable to OpenStack projects.
>  
> I just took a quick stab at annotating which ones (I think are) useable
> outside of openstack (without say bringing in the configuration
> ideology/pattern that oslo.config adds) and made the following:
>  
> automaton (useable)
> cliff (useable)
> cookiecutter (useable)

I'm catching up on this thread, but cookiecutter most certainly is *NOT* an 
OpenStack project: https://pypi.io/project/cookiecutter/

It was createdy by Audrey Roy Greenfeld. 

> debtcollector (useable)
> futurist (useable)
> osprofiler (useable?)
> oslo.cache
> oslo.concurrency
> oslo.context
> oslo.config
> oslo-cookiecutter
> oslo.db
> oslo.i18n
> oslo.log
> oslo.messaging
> oslo.middleware
> oslo.policy (useable?)
> oslo.privsep (useable?)
> oslo.reports
> oslo.rootwrap
> oslo.serialization (useable)
> oslo.service
> oslosphinx
> oslotest (useable)
> oslo.utils (useable)
> oslo.versionedobjects
> oslo.vmware
> hacking (useable)
> pbr (useable)
> pyCADF (useable?)
> stevedore (useable)
> taskflow (useable)
> tooz (useable)
>  
> So out of 33 that's about half (~17) that I think are useable outside
> without to many patterns/ideologies being forced on non-openstack folks
> (if your external project accepts the pattern of oslo.config then the
> number increases).
>  
> >
> > -Sean
> >
>  
> __  
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe  
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  

--  
Ian Cordasco


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

[openstack-dev] [keystone] New Core Reviewer (sent on behalf of Steve Martinelli)

[Morgan Fainberg]

I want to welcome Rodrigo Duarte (rodrigods) to the keystone core team.
Rodrigo has been a consistent contributor to keystone and has been
instrumental in the federation implementations. Over the last cycle he has
shown an understanding of the code base and contributed quality reviews.

I am super happy (as proxy for Steve) to welcome Rodrigo to the Keystone
Core team.

Cheers,
--Morgan
__
OpenStack Development Mailing 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] usage of ironic-lib

[Loo, Ruby]

Thanks for the feedback everyone. Lucas has submitted a patch to ironic-lib¹s 
README to clarify this: https://review.openstack.org/#/c/319251/.

--ruby


On 2016-05-20, 8:46 AM, "Jim Rollenhagen"  wrote:

>On Thu, May 19, 2016 at 01:21:35PM -0700, Devananda van der Veen wrote:
>> On 05/16/2016 07:14 AM, Lucas Alvares Gomes wrote:
>> > On Mon, May 16, 2016 at 2:57 PM, Loo, Ruby  wrote:
>> >> Hi,
>> >>
>> >> A patch to ironic-lib made me wonder about what is our supported usage of
>> >> ironic-lib. Or even the intent/scope of it. This patch changes a method,
>> >> Œbootable¹ parameter is removed and Œboot_flag¹ parameter is added [1].
>> >>
>> >> If this library/method is used by some out-of-tree thing (or even some
>> >> in-tree but outside of ironic), this will be a breaking change. If this
>> >> library is meant to be internal to ironic program itself, and to e.g. only
>> >> be used by ironic and IPA, then that is different. I was under the
>> >> impression that it was a library and meant to be used by whatever, no
>> >> restrictions on what that whatever was. It would be WAY easier if we 
>> >> limited
>> >> this for usage by only a few specified projects.
>> >>
>> >> What do people think?
>> >>
>> > 
>> > I still believe that the ironic-lib project was designed to share code
>> > between the Ironic projects _only_. Otherwise, if it the code was
>> > supposed to be shared across multiple projects we should have put it
>> > in oslo instead.
>> 
>> I agree, and don't see a compelling reason, today, for anyone to do the work 
>> to
>> make ironic-lib into a stable library. So...
>> 
>> I think we should keep ironic-lib where it is (in ironic, not oslo) and keep 
>> the
>> scope we intended (only for use within the Ironic project group [1]).
>> 
>> We should more clearly signal that intent within the library (eg, in the 
>> README)
>> and the project description (eg. on PyPI).
>> 
>> [1]
>> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1915
>
>+1, let's not put extra burden on ourselves at this time.
>
>// jim
>
>> 
>> 
>> my 2c,
>> Devananda
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [oslo] Log spool in the context

[Sean Dague]

On 05/24/2016 01:18 PM, Doug Hellmann wrote:
> Excerpts from Alexis Lee's message of 2016-05-24 09:34:36 +0100:
>> Hi,
>>
>> I have a spec: https://review.openstack.org/227766
>> and implementation: https://review.openstack.org/316162
>> for adding a spooling logger to oslo.log. Neither is merged yet, reviews
>> welcome.
>>
>> Looking at how I'd actually integrate this into Nova, most classes do:
>>
>> LOG = logging.getLogger(__name__)
>>
>> which is the recommended means of getting a logger. I need to get
>> certain code paths to use a different logger (if spooling is turned on).
>> This means I need to pass it around. If I modify method signatures I'm
>> bound to break back-compat for something.
>>
>> Option 1: use a metaclass to register each SpoolManager as a singleton,
>> IE every call to SpoolManager('api') will return the same manager. I can
>> then do something like:
>>
>> log = LOG
>> if CONF.spool_api:
>> log = SpoolManager('api').get_spool(context.request_id)
>>
>> in every method.
>>
>> Option 2: Put the logger on the context. We're already passing this
>> everywhere so it'd be awful convenient.
>>
>> log = context.log or LOG
>>
>> Option 3: ???
>>
>> I like option 2, any objections to extending oslo.context like this?
>>
>>
>> Alexis (lxsli)
> 
> Do you need more than one? The spec talks about different types of
> requests having different SpoolManagers (api and scheduler are the 2
> examples given).
> 
> What happens when the context is serialized and sent across an RPC call?
> Is there some representation of the logger that the messaging code can
> use on the other side to reconstruct the logger?

Right, the serialization of the context makes this something I'd rather
avoid. While in the past I've argued for adding more to context, it is
sort of useful that it's mostly just a container of attributes for being
a universal thing. Doug corrected my thinking there, and I thank him for
it.

I'd rather have it be more explicit.

-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-dev] [ironic] weekly sub team status report

[Loo, Ruby]

Hi,

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

Bugs (dtantsur)
===
- Stats (diff with 16 May 2016)
- Ironic: 192 bugs (+2) + 178 wishlist items (+1). 0 new, 138 in progress (+4), 
0 critical, 32 high and 24 incomplete
- Inspector: 8 bugs (-1) + 20 wishlist items. 0 new, 7 in progress (-1), 0 
critical, 1 high (-1) and 0 incomplete (-1)
- Nova bugs with Ironic tag: 17 (+1). 3 new (+2), 0 critical, 1 high (+1)

Upgrade (aka Grenade) testing (jlvillal/mgould):

- Really awesome work this week!! We now have had a passing Grenade job (with 
about 15 unmerged patches).
- vsaienko figured out the networking issue that had been blocking us for over 
a week at the 'resource phase create' stage
- Big thanks to vsaienko and vdrok for all their work
- Now need to finish this up by getting the various patches cleaned up and 
merged into multiple projects.

Network isolation (Neutron/Ironic work) (jroll, TheJulia, devananda)

- patches were split, need review but are in merge conflict :(
- 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:im_full-2016-05-16_04

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
- the old ramdisk jobs no longer run on git master, proceeding with removing 
the old ramdisk support

Node search API (jroll, lintan, rloo)
=
- none - may not be a new priority with new multi-compute spec

Node claims API (jroll, lintan)
===
- none - may not be a new priority with new multi-compute spec
Multiple compute hosts (jroll, devananda)
=
- wrote a new spec: https://review.openstack.org/#/c/320016/

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
- none - spec requires update.

Driver composition (dtantsur)
=
- The spec https://review.openstack.org/188370 progresses well and there are a 
lot of bits requiring your comments already there:
- The high-level change description is there.
- API changes are there (unless I forgot something).
- The upgrade path is there.

Inspector (dtansur)
===
- python-ironic-inspector-client 1.7.0 released for Newton

Bifrost (TheJulia)
==
- TheJulia has been away, please ping if there are needed items asap.  She is 
aware no issues at this time.

.

Until June (no meeting next week),
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard


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

Re: [openstack-dev] [all][oslo_config] Improving Config Option Help Texts

[Ian Cordasco]

-Original Message-
From: Erno Kuvaja 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: May 24, 2016 at 06:06:14
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [all][oslo_config] Improving Config Option Help Texts

> Hi all,
>
> Based on the not yet merged spec of categorized config options [0] some
> project seems to have started improving the config option help texts. This
> is great but I noticed scary trend on clutter to be added on these
> sections. Now looking individual changes it does not look that bad at all
> in the code 20 lines well structured templating. Until you start comparing
> it to the example config files. Lots of this data is redundant to what is
> generated to the example configs already and then the maths struck me.
>
> In Glance only we have ~120 config options (this does not include
> glance_store nor any other dependencies we pull in for our configs like
> Keystone auth. Those +20 lines of templating just became over 2000 lines of
> clutter in the example configs and if all projects does that we can
> multiply the issue. I think no-one with good intention can say that it's
> beneficial for our deployers and admins who are already struggling with the
> configs.
>
> So I beg you when you do these changes to the config option help fields
> keep them short and compact. We have the Configuration Docs for extended
> descriptions and cutely formatted repetitive fields, but lets keep those
> off from the generated (Example) config files. At least I would like to be
> able to fit more than 3 options on the screen at the time when reading
> configs.
>
> [0] https://review.openstack.org/#/c/295543/

Hey Erno,

So here's where I have to very strongly disagree with you. That spec
was caused by operator feedback, specifically for projects that
provide multiple services that may or may not have separated config
files which and which already have "short and compact" descriptions
that are not very helpful to oeprators.

The *example* config files will have a lot more detail in them. Last I
saw (I've stopped driving that specification) there was going to be a
way to generate config files without all of the descriptions. That
means that for operators who don't care about that can ignore it when
they generate configuration files. Maybe the functionality doesn't
work right this instant, but I do believe that's a goal and it will be
implemented.

Beyond that, I don't think example/sample configuration files should
be treated differently from documentation, nor do I think that our
documentation team couldn't make use of the improved documentation
we're adding to each option. In short, I think this effort will
benefit many different groups of people in and around OpenStack.
Simply arguing that this is going to make the sample config files have
more lines of code is not a good argument against this. Please do
reconsider.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [gate] [nova] live migration, libvirt 1.3, and the gate

[Sean Dague]

The team working on live migration testing started with an experimental
job on Ubuntu 16.04 to try to be using the latest and greatest libvirt +
qemu under the assumption that a set of issues we were seeing are
solved. The short answer is, it doesn't look like this is going to work.

We run tests on a bunch of different clouds. Those clouds expose
different cpu flags to us. These are not standard things that map to
"Haswell". It means live migration in the multinode cases can hit cpus
with different flags. So we found the requirement was to come up with a
least common denominator of cpu flags, which we call gate64, and push
that into the libvirt cpu_map.xml in devstack, and set whenever we are
in a multinode scenario.
(https://github.com/openstack-dev/devstack/blob/master/tools/cpu_map_update.py)
 Not ideal, but with libvirt 1.2.2 it works fine.

It turns out it works fine because libvirt *actually* seems to take the
data from cpu_map.xml and do a translation to what it believes qemu will
understand. On these systems apparently this turns into "-cpu
Opteron_G1,-pse36"
(http://logs.openstack.org/29/42529/24/check/gate-tempest-dsvm-multinode-full/5f504c5/logs/libvirt/qemu/instance-000b.txt.gz)

At some point between libvirt 1.2.2 and 1.3.1, this changed. Now libvirt
seems to be passing our cpu_model directly to qemu, and assumes that as
a user you will be responsible for writing all the  stanzas to
add/remove yourself. When libvirt sends 'gate64' to qemu, this explodes,
as qemu has no idea what we are talking about.
http://logs.openstack.org/34/319934/2/experimental/gate-tempest-dsvm-multinode-live-migration/b87d689/logs/screen-n-cpu.txt.gz#_2016-05-24_15_59_12_531

Unlike libvirt, which has a text file (xml) that configures the cpus
that could exist in the world, qemu builds this in statically at compile
time:
http://git.qemu.org/?p=qemu.git;a=blob;f=target-i386/cpu.c;h=895a386d3b7a94e363ca1bb98821d3251e70c0e0;hb=HEAD#l694


So, the existing cpu_map.xml workaround for our testing situation will
no longer work.

So, we have a number of open questions:

* Have our cloud providers standardized enough that we might get away
without this custom cpu model? (Have some of them done it and only use
those for multinode?)
* Is there any way to get this feature back in libvirt to do the cpu
computation?
* Would we have to build a whole nova feature around setting libvirt xml
 to be able to test live migration in our clouds?
* Other options?
* Do we give up and go herd goats?

-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-dev] Fwd: keystone federation user story

[Alexander Makarov]

Colleagues,

here is an actual use case for shadow users assignments, let's discuss
possible solutions: all suggestions are appreciated.

-- Forwarded message --
From: Andrey Grebennikov 
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov 


Main production usecase:
As a system administrator I need to create assignments for federated users
into the projects when the user has not authenticated for the first time.

Two different approaches.
1. A user has to be assigned directly into the project with the role Role1.
Since shadow users were implemented, Keystone database has the record of
the user when the federated user authenticates for the first time. When it
happens, the user gets unscoped token and Keystone registers the user in
the database with generated ID (the result of hashing the name and the
domain). At this point the user cannot get scoped token yet since the user
has not been assigned to any project.
Nonetheless there was a bug https://bugs.launchpad.net/keystone/+bug/1313956
which was abandoned, and the reporter says that currently it is possible to
assign role in the project to non-existing user (API only, no CLI). It
doesn't help much though since it is barely possible to predict the ID of
the user if it doesn't exist yet.

Potential solution - allow per-user project auto-creation. This will allow
the user to get scoped token with a pre-defined role (should be either
mentioned in config or in mapping) and execute operations right away.

Disadvantages: less control and order (will potentially end up with
infinite empty projects).
Benefits: user is authorized right away.

Another potential solution - clearly describe a possibility to assign
shadow user to a project (client should generate the ID correctly), even
though the user has not been authenticated for the first time yet.

Disadvantages: high risk of administrator's mistake when typing user's ID.
Benefits: user doesn't have to execute first dummy authentication in order
to be registered.

2. Operate with the groups. It means that the user is a member of the
remote group and we propose the groups to be assigned to the projects
instead of the users.
There is no concept of shadow groups yet, so it still has to be implemented.

Same problem - in order to be able to assign the group to the project
currently it has to exist in Keystone database.

It should be either allowed to pre-create the project for a group (based on
some specific flags in mappings), or it should be allowed to assign
non-existing groups into the projects.

I'd personally prefer to allow some special attribute to be specified in
either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend. In this
case this group is the part of SAML assertions (in case when SAML2 is used
as the protocol), and Keystone should recognize this group through the
mapping. When user makes login attempt, Keystone should pre-create the
project and assign pre-defined role in it. User gets access right away.


-- 
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA



-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
__
OpenStack Development Mailing 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] Plans to converge on one ldap client?

[Corey Bryant]

On Tue, May 24, 2016 at 1:23 PM, Morgan Fainberg 
wrote:

>
>
> On Tue, May 24, 2016 at 8:55 AM, Corey Bryant 
> wrote:
>
>>
>>
>> On Tue, May 24, 2016 at 11:11 AM, Morgan Fainberg <
>> morgan.fainb...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, May 24, 2016 at 5:53 AM, Corey Bryant <
>>> corey.bry...@canonical.com> wrote:
>>>
 Hi All,

 Are there any plans to converge on one ldap client across projects?
 Some projects have moved to ldap3 and others are using pyldap (both are in
 global requirements).

 The issue we're running into in Ubuntu is that we can only have one
 ldap client in Ubuntu main, while the others will live in universe.

 --
 Regards,
 Corey


>>> Out of curiosity, what drives this requirement? pyldap and ldap3 do not
>>> overlap in namespace and can co-install just fine. This is no different
>>> than previously having python-ldap and ldap3.
>>>
>>> It seems a little arbitrary to say only one of these can be in main, but
>>> this is why i am asking.
>>>
>>>
>> No problem, thanks for asking.  I agree, it's no different than
>> python-ldap and ldap3 and it's not a co-installability issue.  This is just
>> a policy for Ubuntu main.  If we file a Main Inclusion Request (MIR) for a
>> new ldap client then we'll be asked to work on what's needed to get the
>> other client package out of main, which consists of patching use of one
>> client for the other.
>>
>>
> Ah, ok sure; still sounds a little silly imho, but only so much we can do
> on that front ;). So the reality is keystone is
>

Everything in main is fully supported, so limiting those efforts to a
single client makes sense.


> considering ldap3, but there have been concerns about ldap3's interface
> compared to the relatively tried-and-true pyldap (a clean fork+py3 support
> of python-ldap). Long term we may move to ldap3. Short term, we wanted
> python3 support, so the drop in replacement for python-ldap was the clear
> winner (ldap3 is significantly more work to support, and even when/if we
> support it there will be a period where we support both, just in different
> drivers).
>

I like the approach to having different drivers, at least for a transition
period.  That would be very useful from a distro perspective.


>
> Basically, if we add ldap3 to keystone, we will be supporting both for a
> non-insignificant time. For now we're leaning on pyldap for the foreseeable
> future.
>
>
>>
Thanks. Appreciate the information!

-- 
Regards,
Corey
__
OpenStack Development Mailing 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] Fw: [glance] [defcore] [interop] Proposal for a virtual sync dedicated to Import Refactor May 26th

[Catherine Cuong Diep]

+1

- Catheine Diep
- Forwarded by Catherine Cuong Diep/San Jose/IBM on 05/24/2016 10:31 AM
-

From:   Brian Rosmaita 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   05/24/2016 10:30 AM
Subject:Re: [openstack-dev] [glance] [defcore] [interop] Proposal for a
virtual sync dedicated to Import Refactor May 26th



+1

On 5/24/16, 11:11 AM, "Chris Hoge"  wrote:

>+1
>
>> On May 23, 2016, at 8:25 PM, Mike Perez  wrote:
>>
>>> On 18:00 May 20, Nikhil Komawar wrote:
>>> Hello all,
>>>
>>>
>>> I want to propose having a dedicated virtual sync next week Thursday
>>>May
>>> 26th at 1500UTC for one hour on the Import Refactor work [1] ongoing in
>>> Glance. We are making a few updates to the spec; so it would be good to
>>> have everyone on the same page and soon start merging those spec
>>>changes.
>>>
>>>
>>> Also, I would like for this sync to be cross project one so that all
>>>the
>>> different stakeholders are aware of the updates to this work even if
>>>you
>>> just want to listen in.
>>>
>>>
>>> Please vote with +1, 0, -1. Also, if the time doesn't work please
>>> propose 2-3 additional time slots.
>>>
>>>
>>> We can decide later on the tool and I will setup agenda if we have
>>> enough interest.
>>
>> +1
>>
>> --
>> Mike Perez
>>
>>
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


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

Re: [openstack-dev] Plans to converge on one ldap client?

[Morgan Fainberg]

On Tue, May 24, 2016 at 8:55 AM, Corey Bryant 
wrote:

>
>
> On Tue, May 24, 2016 at 11:11 AM, Morgan Fainberg <
> morgan.fainb...@gmail.com> wrote:
>
>>
>>
>> On Tue, May 24, 2016 at 5:53 AM, Corey Bryant > > wrote:
>>
>>> Hi All,
>>>
>>> Are there any plans to converge on one ldap client across projects?
>>> Some projects have moved to ldap3 and others are using pyldap (both are in
>>> global requirements).
>>>
>>> The issue we're running into in Ubuntu is that we can only have one ldap
>>> client in Ubuntu main, while the others will live in universe.
>>>
>>> --
>>> Regards,
>>> Corey
>>>
>>>
>> Out of curiosity, what drives this requirement? pyldap and ldap3 do not
>> overlap in namespace and can co-install just fine. This is no different
>> than previously having python-ldap and ldap3.
>>
>> It seems a little arbitrary to say only one of these can be in main, but
>> this is why i am asking.
>>
>>
> No problem, thanks for asking.  I agree, it's no different than
> python-ldap and ldap3 and it's not a co-installability issue.  This is just
> a policy for Ubuntu main.  If we file a Main Inclusion Request (MIR) for a
> new ldap client then we'll be asked to work on what's needed to get the
> other client package out of main, which consists of patching use of one
> client for the other.
>
>
Ah, ok sure; still sounds a little silly imho, but only so much we can do
on that front ;). So the reality is keystone is considering ldap3, but
there have been concerns about ldap3's interface compared to the relatively
tried-and-true pyldap (a clean fork+py3 support of python-ldap). Long term
we may move to ldap3. Short term, we wanted python3 support, so the drop in
replacement for python-ldap was the clear winner (ldap3 is significantly
more work to support, and even when/if we support it there will be a period
where we support both, just in different drivers).

Basically, if we add ldap3 to keystone, we will be supporting both for a
non-insignificant time. For now we're leaning on pyldap for the foreseeable
future.


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

Re: [openstack-dev] [glance] [defcore] [interop] Proposal for a virtual sync dedicated to Import Refactor May 26th

[Brian Rosmaita]

+1

On 5/24/16, 11:11 AM, "Chris Hoge"  wrote:

>+1
>
>> On May 23, 2016, at 8:25 PM, Mike Perez  wrote:
>> 
>>> On 18:00 May 20, Nikhil Komawar wrote:
>>> Hello all,
>>> 
>>> 
>>> I want to propose having a dedicated virtual sync next week Thursday
>>>May
>>> 26th at 1500UTC for one hour on the Import Refactor work [1] ongoing in
>>> Glance. We are making a few updates to the spec; so it would be good to
>>> have everyone on the same page and soon start merging those spec
>>>changes.
>>> 
>>> 
>>> Also, I would like for this sync to be cross project one so that all
>>>the
>>> different stakeholders are aware of the updates to this work even if
>>>you
>>> just want to listen in.
>>> 
>>> 
>>> Please vote with +1, 0, -1. Also, if the time doesn't work please
>>> propose 2-3 additional time slots.
>>> 
>>> 
>>> We can decide later on the tool and I will setup agenda if we have
>>> enough interest.
>> 
>> +1
>> 
>> -- 
>> Mike Perez
>> 
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] Summit evolution online town halls

[Jonathan Bryce]

Hi everyone,

You might have seen the FAQ we posted last week about the continuing work 
on evolving the format and structure of the Summits: 
http://www.openstack.org/blog/2016/05/faq-evolving-the-openstack-design-summit/


I wanted to send a reminder note out to highlight that Thierry and I will 
be hosting 2 online town halls tomorrow at 1130 and 1900 UTC to talk 
through the current thinking and answer any new questions. Links to the 
webinars are at the top of the blog post. If you have specific questions 
not covered in the FAQ that you'd like us to talk about, feel free to email 
either of us directly beforehand and we will add them to the list.


Jonathan




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

Re: [openstack-dev] [oslo] Log spool in the context

[Doug Hellmann]

Excerpts from Alexis Lee's message of 2016-05-24 09:34:36 +0100:
> Hi,
> 
> I have a spec: https://review.openstack.org/227766
> and implementation: https://review.openstack.org/316162
> for adding a spooling logger to oslo.log. Neither is merged yet, reviews
> welcome.
> 
> Looking at how I'd actually integrate this into Nova, most classes do:
> 
> LOG = logging.getLogger(__name__)
> 
> which is the recommended means of getting a logger. I need to get
> certain code paths to use a different logger (if spooling is turned on).
> This means I need to pass it around. If I modify method signatures I'm
> bound to break back-compat for something.
> 
> Option 1: use a metaclass to register each SpoolManager as a singleton,
> IE every call to SpoolManager('api') will return the same manager. I can
> then do something like:
> 
> log = LOG
> if CONF.spool_api:
> log = SpoolManager('api').get_spool(context.request_id)
> 
> in every method.
> 
> Option 2: Put the logger on the context. We're already passing this
> everywhere so it'd be awful convenient.
> 
> log = context.log or LOG
> 
> Option 3: ???
> 
> I like option 2, any objections to extending oslo.context like this?
> 
> 
> Alexis (lxsli)

Do you need more than one? The spec talks about different types of
requests having different SpoolManagers (api and scheduler are the 2
examples given).

What happens when the context is serialized and sent across an RPC call?
Is there some representation of the logger that the messaging code can
use on the other side to reconstruct the logger?

Doug

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

Re: [openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.

[Doug Hellmann]

Excerpts from Markus Zoeller's message of 2016-05-24 11:00:35 +0200:
> On 24.05.2016 09:34, Duncan Thomas wrote:
> > Cinder bugs list was far more manageable once this had been done.
> > 
> > It is worth sharing the tool for this? I realise it's fairly trivial to
> > write one, but some standardisation on the comment format etc seems
> > valuable, particularly for Q/A folks who work between different projects.
> 
> A first draft (without the actual expiring) is at [1]. I'm going to
> finish it this week. If there is a place in an OpenStack repo, just give
> me a pointer and I'll push a change.
> 
> > On 23 May 2016 at 14:02, Markus Zoeller  wrote:
> > 
> >> TL;DR: Automatic closing of 185 bug reports which are older than 18
> >> months in the week R-13. Skipping specific bug reports is possible. A
> >> bug report comment explains the reasons.
> >> [...]
> 
> References:
> [1]
> https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py
> 

Feel free to submit that to the openstack-infra/release-tools repo. We
have some other tools in that repo for managing launchpad bugs.

Doug

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

Re: [openstack-dev] [nova] [infra] resolving issues with Intel NFV CI

[Znoinski, Waldemar]

The issue is now resolved.

Apparently the job wasn't registered with gearman server as there weren't any 
slaves available in Jenkins to run it at the time of zuul restart (as some old 
nodepool nodes were left over and no new VMs were spawned).



From: Znoinski, Waldemar [mailto:waldemar.znoin...@intel.com]
Sent: Tuesday, May 24, 2016 9:31 AM
To: openstack-in...@lists.openstack.org; OpenStack Development Mailing List 
(not for usage questions) 
Subject: [openstack-dev] [nova] [infra] resolving issues with Intel NFV CI

Hi all,

There is an issue with jobs under Intel NFV CI not being registered.
The issue is currently being investigated. ThirdPartySystems Wiki was updated.

Updates to follow.


Waldemar Znoinski


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Is verification of images in the image cache necessary?

[Sean Dague]

On 05/24/2016 11:54 AM, Dan Smith wrote:
>> I like the idea of checking the md5 matches before each boot, as it
>> mirrors the check we do after downloading from glance. Its possible
>> thats very unlikely to spot anything that shouldn't already be worried
>> about by something else. It may just be my love of symmetry that makes
>> me like that idea?
> 
> IMHO, checking this at boot after we've already checked it on download
> is not very useful. It supposes that the attacker was kind enough to
> visit our system before an instance was booted and not after. If I have
> rooted the system, it's far easier for me to show up after a bunch of
> instances are booted and modify the base images (or even better, the
> instance images themselves which are hard to validate from the host side).
> 
> I would also point out that if I'm going to root a compute node, the
> first thing I'm going to do is disable the feature in nova-compute or in
> some other way cripple it so it can't do its thing.

Right, we're way outside of an attestation chain here.

It does seem that once Nova has validated "once" that it moved the bits
from glance to "local" storage, it's job is done. Are there specific
issues that happened before that made this regular check something that
was needed?

If people are really concerned that things might get accidentally
written out from underneath them, doing a chattr -i after download so
the base images are immutable, and stray processes at least have to try
harder to change the data.

-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] [all][tc] Languages vs. Scope of "OpenStack"

[Jay Pipes]

On 05/24/2016 06:19 AM, Thierry Carrez wrote:

Chris Dent wrote:

[...]
I don't really know. I'm firmly in the camp that OpenStack needs to
be smaller and more tightly focused if a unitary thing called OpenStack
expects to be any good. So I'm curious about and interested in
strategies for figuring out where the boundaries are.

So that, of course, leads back to the original question: Is OpenStack
supposed to be a unitary.


As a data point, since I heard that question rhetorically asked quite a
few times over the past year... There is an old answer to that, since a
vote of the PPB (the ancestor of our TC) from June, 2011 which was never
overruled or changed afterwards:

"OpenStack is a single product made of a lot of independent, but
cooperating, components."

The log is an interesting read:
http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-28-20.06.log.html


Hmm, blast from the past. I'm sad I didn't make it to that meeting.

I would (now at least) have voted for #2: OpenStack is "a collection of 
independent projects that work together for some level of integration 
and releases".


This is how I believe OpenStack should be seen, as I wrote on Twitter 
relatively recently:


https://twitter.com/jaypipes/status/705794815338741761
https://twitter.com/jaypipes/status/705795095262441472

Best,
-jay

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

Re: [openstack-dev] [neutron][stable] proposing Brian Haley for neutron-stable-maint

[Brian Haley]

On 05/24/2016 11:17 AM, Ihar Hrachyshka wrote:



On 17 May 2016, at 13:07, Ihar Hrachyshka  wrote:

Hi stable-maint-core and all,

I would like to propose Brian for neutron specific stable team.

His stats for neutron stable branches are (last 120 days):

mitaka: 19 reviews; liberty: 68 reviews (3rd place in the top); kilo: 16 
reviews.

Brian helped the project with stabilizing liberty neutron/DVR jobs, and with 
other L3 related stable matters. In his stable reviews, he shows attention to 
details.

If Brian is added to the team, I will make sure he is aware of all stable 
policy intricacies.

Side note: recently I added another person to the team (Cedric Brandilly), and 
now I realize that I haven’t followed the usual approval process. That said, 
the person also has decent stable review stats, and is aware of the policy. If 
someone has doubts about that addition to the team, please ping me and we will 
discuss how to proceed.

Ihar


OK, it’s a whole week for the thread, and there are no objections. I added 
Brian to the neutron-stable-maint gerrit group.

Welcome Brian!


Thanks Ihar, and thanks to all for the +1's!

-Brian

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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Fox, Kevin M]

OpenStack is more then the sum of its various pieces. Often features need to 
cross more then one project. Cross project work is already extremely hard 
without having to change languages between. Language change should be done very 
carefully and deliberately.

Thanks,
Kevin


From: Geoff O'Callaghan
Sent: Monday, May 23, 2016 5:59:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

Surely openstack is defined by it’s capabilities and interfaces rather than 
it’s internals.  Given the simplistic view that openstack is a collection of 
micro services connected by well defined api’s does it really matter what code 
is used inside that micro service (or macro service )?   If there is a 
community willing to bring and support code in language ‘x’,  isn’t that better 
than worrying about the off chance of existing developers wishing to move 
projects and not knowing the target language?Is there a fear that we’ll end 
up with a fork of nova (or others) written in rust ?
If we’re not open to evolving then we’ll die.

Just throwing in a different perspective.

Sorry about the top-post but it applies in general to the below discussion
Tks
Geoff

On 24 May 2016, at 9:28 AM, Gregory Haynes 
> wrote:

On Mon, May 23, 2016, at 05:24 PM, Morgan Fainberg wrote:


On Mon, May 23, 2016 at 2:57 PM, Gregory Haynes 
> wrote:
On Fri, May 20, 2016, at 07:48 AM, Thierry Carrez wrote:
> John Dickinson wrote:
> > [...]
> >> So the real question we need to answer is... where does OpenStack
> >> stop, and where does the wider open source community start ? If
> >> OpenStack is purely an "integration engine", glue code for other
> >> lower-level technologies like hypervisors, databases, or distributed
> >> block storage, then the scope is limited, Python should be plenty
> >> enough, and we don't need to fragment our community. If OpenStack is
> >> "whatever it takes to reach our mission", then yes we need to add one
> >> language to cover lower-level/native optimization, because we'll
> >> need that... and we need to accept the community cost as a
> >> consequence of that scope choice. Those are the only two options on
> >> the table.
> >>
> >> I'm actually not sure what is the best answer. But I'm convinced we,
> >> as a community, need to have a clear answer to that. We've been
> >> avoiding that clear answer until now, creating tension between the
> >> advocates of an ASF-like collection of tools and the advocates of a
> >> tighter-integrated "openstack" product. We have created silos and
> >> specialized areas as we got into the business of developing time-
> >> series databases or SDNs. As a result, it's not "one community"
> >> anymore. Should we further encourage that, or should we focus on
> >> what the core of our mission is, what we have in common, this
> >> integration engine that binds all those other open source projects
> >> into one programmable infrastructure solution ?
> >
> > You said the answer in your question. OpenStack isn't defined as an
> > integration engine[3]. The definition of OpenStack is whatever it
> > takes to fulfill our mission[4][5]. I don't mean that as a tautology.
> > I mean that we've already gone to the effort of defining OpenStack. It's
> > our mission statement. We're all about building a cloud platform upon
> > which people can run their apps ("cloud-native" or otherwise), so we
> > write the software needed to do that.
> >
> > So where does OpenStack stop and the wider community start? OpenStack
> > includes the projects needed to fulfill its mission.
>
> I'd totally agree with you if OpenStack was developed in a vacuum. But
> there is a large number of open source projects and libraries that
> OpenStack needs to fulfill its mission that are not in "OpenStack": they
> are external open source projects we depend on. Python, MySQL, libvirt,
> KVM, Ceph, OpenvSwitch, RabbitMQ... We are not asking that those should
> be included in OpenStack, and we are not NIHing replacements for those
> in OpenStack either.
>
> So it is not as clear-cut as you present it, and you can approach this
> dependency question from two directions.
>
> One is community-centric: "anything produced by our community is
> OpenStack". If we are missing a lower-level piece to achieve our mission
> and are developing it ourselves as a result, then it is OpenStack, even
> if it ends up being a message queue or a database.
>
> The other approach is product-centric: "lower-level pieces are OpenStack
> dependencies, rather than OpenStack itself". If we are missing a
> lower-level piece to achieve our mission and are developing it as a
> result, it could be developed on OpenStack infrastructure by members of
> the OpenStack community but it is not "OpenStack the product", it's an
> OpenStack *dependency*. 

[openstack-dev] [kolla][security] Finishing the job on threat analysis for Kolla

[Steven Dake (stdake)]

Rob and Doug,

At Summit we had 4 hours of highly productive work producing a list of "things" 
that can be "threatened".  We have about 4 or 5 common patterns where we follow 
the principle of least privilege.  On Friday of Summit we produced a list of 
all the things (in this case deployed containers).  I'm not sure who, I think 
it was Rob was working on a flow diagram for the least privileged case.  From 
there, the Kolla coresec team can produce the rest of the diagrams for 
increasing privileges.

I'd like to get that done, then move on to next steps.  Not sure what the next 
steps are, but lets cover the flow diagrams first since we know we need those.

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

Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances

[Lucas Alvares Gomes]

Hi,

> I'm working with Tien who is a submitter of one[1] of console specs.
> I joined the console session in Austin.
>
> In the session, we got the following consensus.
> - focus on serial console in Newton
> - use nova-serial proxy as is
>
> We also got some requirements[2] for this feature in the session.
> We have started cooperating with Akira and Yuiko who submitted another 
> similar spec[3].
> We're going to unite our specs and add solutions for the requirements ASAP.
>

Great stuff! So do we have an update on this?

I see [3] is now abandoned and a new spec was proposed recently [4].
Is [4] the result of the union of both specs?

> [1] ironic-ipmiproxy: https://review.openstack.org/#/c/296869/
> [2] https://etherpad.openstack.org/p/ironic-newton-summit-console
> [3] ironic-console-server: https://review.openstack.org/#/c/306755/

[4] https://review.openstack.org/#/c/319505

Cheers,
Lucas

__
OpenStack Development Mailing 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] Plans to converge on one ldap client?

[Corey Bryant]

On Tue, May 24, 2016 at 11:11 AM, Morgan Fainberg  wrote:

>
>
> On Tue, May 24, 2016 at 5:53 AM, Corey Bryant 
> wrote:
>
>> Hi All,
>>
>> Are there any plans to converge on one ldap client across projects?  Some
>> projects have moved to ldap3 and others are using pyldap (both are in
>> global requirements).
>>
>> The issue we're running into in Ubuntu is that we can only have one ldap
>> client in Ubuntu main, while the others will live in universe.
>>
>> --
>> Regards,
>> Corey
>>
>>
> Out of curiosity, what drives this requirement? pyldap and ldap3 do not
> overlap in namespace and can co-install just fine. This is no different
> than previously having python-ldap and ldap3.
>
> It seems a little arbitrary to say only one of these can be in main, but
> this is why i am asking.
>
>
No problem, thanks for asking.  I agree, it's no different than python-ldap
and ldap3 and it's not a co-installability issue.  This is just a policy
for Ubuntu main.  If we file a Main Inclusion Request (MIR) for a new ldap
client then we'll be asked to work on what's needed to get the other client
package out of main, which consists of patching use of one client for the
other.

-- 
Regards,
Corey
__
OpenStack Development Mailing 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] [puppet] weekly meeting #82

[Emilien Macchi]

On Mon, May 23, 2016 at 1:24 PM, Emilien Macchi <emil...@redhat.com> wrote:
> Hi Puppeteers!
>
> We'll have our weekly meeting tomorrow at 3pm UTC on
> #openstack-meeting-4.
>
> Here's a first agenda:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160524
>
> Feel free to add more topics, and any outstanding bug and patch.
>
> See you tomorrow!

Our notes: 
http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-05-24-15.00.html

Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [Openstack-operators] [nova] Is verification of images in the image cache necessary?

[Dan Smith]

> I like the idea of checking the md5 matches before each boot, as it
> mirrors the check we do after downloading from glance. Its possible
> thats very unlikely to spot anything that shouldn't already be worried
> about by something else. It may just be my love of symmetry that makes
> me like that idea?

IMHO, checking this at boot after we've already checked it on download
is not very useful. It supposes that the attacker was kind enough to
visit our system before an instance was booted and not after. If I have
rooted the system, it's far easier for me to show up after a bunch of
instances are booted and modify the base images (or even better, the
instance images themselves which are hard to validate from the host side).

I would also point out that if I'm going to root a compute node, the
first thing I'm going to do is disable the feature in nova-compute or in
some other way cripple it so it can't do its thing.

--Dan

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

Re: [openstack-dev] [fuel] release version numbers: let's use semvers

[Roman Prykhodchenko]

The only thing I would like to mention here is that scripts for making 
automatic releases on PyPi using OpenStack Infra won’t work, if the version is 
not formatted according to semver.

- romcheg

> 24 трав. 2016 р. о 14:34 Igor Kalnitsky  написав(ла):
> 
> Hey Zigo,
> 
> In Python community there's a PEP-440 [1] that defines a versioning scheme. 
> The thing you should know is, the PEP __is not__ compatible with semver, and 
> it's totally fine to have two components version.
> 
> So I don't think we should force version changes from two-components to 
> three-components scheme, since it won't be compatible with semver anyway.
> 
> Thanks,
> Igor
> 
> [1]: https://www.python.org/dev/peps/pep-0440/
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Ben Meyer]

On 05/24/2016 11:13 AM, Dean Troyer wrote:
> On Tue, May 24, 2016 at 8:20 AM, Flavio Percoco  > wrote:
>
> So, just to make sure I'm making myself clear, I believe we should
> go with
> option #2 in Thierry's comment from May 23 11:3 on this[0] review.
> While I'm not
> entirely opposed to #1 I think #2 is better for us at this point
> in time. Here's
> a quote of Thierry's comment:
>
>   "To summarize my view on this, I think our only two options
> here are (1)
>   approve the addition of golang (with caveats on where it
> should be used
>   to try to minimize useless churn), or (2) precise the line
> between
>   'openstack projects' and 'dependencies of openstack
> projects' in a way
>   that makes it obvious that components requiring such
> optimization as to
>   require golang (or any other such language) should be
> developed as
>   dependencies"
>
> My main motivation is that I still believe option #1 will have a
> negative impact
> on the community and, perhaps more importantly, I don't think
> it'll help
> reaching the goal we've been talking about in this thread. Many
> people have been
> asking for focus and I think #2 will do that, whereas #1 will open
> the doors to
> a different set of problems and complexities that won't help with
> keeping the focus.
>
>
> Option #2 without the followup of actually evaluating and removing
> things that do not fit is really Option #3, do nothing. Which is what
> I am afraid will happen.  No renewed focus, no growth, no goal.
>
> On the language front, since we want focus, the exiting decisions re
> languages should also be part of that re-evaluation for focus.  It
> sure feels like JavaScript is in exactly the same boat as folks fear
> Golang will be here (a special case, domain-specific, division of
> community (ask Horizon devs)).  And Bash, well, that isn't even a
> language.

Just $0.02 - if you want to support a language, then it would seem like
having a full SDK for that language would be a first step so that people
inside and outside the community can use the language in a supported
manner. With an SDK, it seems like everyone will just reinvent the
wheel. That would also seem to further the goal of using the language as
the community intends - whether for services, clients, or UI - since the
SDK would be targeted appropriately. If no SDK, then special casing
would seem to the proper place.

Again, $0.02

Ben
__
OpenStack Development Mailing 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][ovo] NeutronDbObject concurrency issues

[John Schwarz]

The incorporation of tooz and Neutron is being discussed as part of
https://bugs.launchpad.net/neutron/+bug/1552680 as an RFE for Newton.
Hopefully I'll have some news to break in on this matter in the
upcoming days (and if I do I'll update on the launchpad to eliminate
duplicity).

On Tue, May 24, 2016 at 8:54 AM, Gary Kotton  wrote:
> Hi,
>
> We have used tooz to enable concurrency. Zookeeper and Redis worked well. I
> think that it is certainly something that we need to consider. The challenge
> becomes a deployment.
>
> Thanks
>
> Gary
>
>
>
> From: Damon Wang 
> Reply-To: OpenStack List 
> Date: Tuesday, May 24, 2016 at 5:58 AM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency
> issues
>
>
>
> Hi,
>
>
>
> I want to add an option which handle by another project Tooz.
>
>
>
> https://github.com/openstack/tooz
>
>
>
> with redis or some other drivers, it seems pretty a good choice.
>
>
>
> Any comments?
>
>
>
> Wei Wang
>
>
>
> 2016-05-17 6:53 GMT+08:00 Ilya Chukhnakov :
>
>
>
> On 16 May 2016, at 20:01, Michał Dulko  wrote:
>
>
> It's not directly related, but this reminds me of tests done by geguileo
> [1] some time ago that were comparing different methods of preventing DB
> race conditions in concurrent environment. Maybe you'll also find them
> useful as you'll probably need to do something like conditional update
> to increment a revision number.
>
> [1] https://github.com/Akrog/test-cinder-atomic-states
>
>
>
> Thanks for the link. The SQLA revisions are similar to the
> 'solutions/update_with_where',
>
> but they use the dedicated column for that [2]. And as long as it is
> properly configured,
>
> it happens 'automagically' (SQLA will take care of adding proper 'where' to
> 'update').
>
>
>
> [2] http://docs.sqlalchemy.org/en/latest/orm/versioning.html
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
John Schwarz,
Red Hat.

__
OpenStack Development Mailing 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][stable] proposing Brian Haley for neutron-stable-maint

[Ihar Hrachyshka]

> On 17 May 2016, at 13:07, Ihar Hrachyshka  wrote:
> 
> Hi stable-maint-core and all,
> 
> I would like to propose Brian for neutron specific stable team.
> 
> His stats for neutron stable branches are (last 120 days):
> 
> mitaka: 19 reviews; liberty: 68 reviews (3rd place in the top); kilo: 16 
> reviews.
> 
> Brian helped the project with stabilizing liberty neutron/DVR jobs, and with 
> other L3 related stable matters. In his stable reviews, he shows attention to 
> details.
> 
> If Brian is added to the team, I will make sure he is aware of all stable 
> policy intricacies.
> 
> Side note: recently I added another person to the team (Cedric Brandilly), 
> and now I realize that I haven’t followed the usual approval process. That 
> said, the person also has decent stable review stats, and is aware of the 
> policy. If someone has doubts about that addition to the team, please ping me 
> and we will discuss how to proceed.
> 
> Ihar

OK, it’s a whole week for the thread, and there are no objections. I added 
Brian to the neutron-stable-maint gerrit group.

Welcome Brian!

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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Dean Troyer]

On Tue, May 24, 2016 at 8:20 AM, Flavio Percoco  wrote:
>
> So, just to make sure I'm making myself clear, I believe we should go with
> option #2 in Thierry's comment from May 23 11:3 on this[0] review. While
> I'm not
> entirely opposed to #1 I think #2 is better for us at this point in time.
> Here's
> a quote of Thierry's comment:
>
>   "To summarize my view on this, I think our only two options here are
> (1)
>   approve the addition of golang (with caveats on where it should be
> used
>   to try to minimize useless churn), or (2) precise the line between
>   'openstack projects' and 'dependencies of openstack projects' in a
> way
>   that makes it obvious that components requiring such optimization as
> to
>   require golang (or any other such language) should be developed as
>   dependencies"
>
> My main motivation is that I still believe option #1 will have a negative
> impact
> on the community and, perhaps more importantly, I don't think it'll help
> reaching the goal we've been talking about in this thread. Many people
> have been
> asking for focus and I think #2 will do that, whereas #1 will open the
> doors to
> a different set of problems and complexities that won't help with keeping
> the focus.
>

Option #2 without the followup of actually evaluating and removing things
that do not fit is really Option #3, do nothing. Which is what I am afraid
will happen.  No renewed focus, no growth, no goal.

On the language front, since we want focus, the exiting decisions re
languages should also be part of that re-evaluation for focus.  It sure
feels like JavaScript is in exactly the same boat as folks fear Golang will
be here (a special case, domain-specific, division of community (ask
Horizon devs)).  And Bash, well, that isn't even a language.

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] Plans to converge on one ldap client?

[Morgan Fainberg]

On Tue, May 24, 2016 at 5:53 AM, Corey Bryant 
wrote:

> Hi All,
>
> Are there any plans to converge on one ldap client across projects?  Some
> projects have moved to ldap3 and others are using pyldap (both are in
> global requirements).
>
> The issue we're running into in Ubuntu is that we can only have one ldap
> client in Ubuntu main, while the others will live in universe.
>
> --
> Regards,
> Corey
>
>
Out of curiosity, what drives this requirement? pyldap and ldap3 do not
overlap in namespace and can co-install just fine. This is no different
than previously having python-ldap and ldap3.

It seems a little arbitrary to say only one of these can be in main, but
this is why i am asking.

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

Re: [openstack-dev] [glance] [defcore] [interop] Proposal for a virtual sync dedicated to Import Refactor May 26th

[Chris Hoge]

+1

> On May 23, 2016, at 8:25 PM, Mike Perez  wrote:
> 
>> On 18:00 May 20, Nikhil Komawar wrote:
>> Hello all,
>> 
>> 
>> I want to propose having a dedicated virtual sync next week Thursday May
>> 26th at 1500UTC for one hour on the Import Refactor work [1] ongoing in
>> Glance. We are making a few updates to the spec; so it would be good to
>> have everyone on the same page and soon start merging those spec changes.
>> 
>> 
>> Also, I would like for this sync to be cross project one so that all the
>> different stakeholders are aware of the updates to this work even if you
>> just want to listen in.
>> 
>> 
>> Please vote with +1, 0, -1. Also, if the time doesn't work please
>> propose 2-3 additional time slots.
>> 
>> 
>> We can decide later on the tool and I will setup agenda if we have
>> enough interest.
> 
> +1
> 
> -- 
> Mike Perez
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [openstack-operators][cinder] max_concurrent_builds in Cinder

[Michał Dulko]

On 05/24/2016 04:38 PM, Gorka Eguileor wrote:
> On 23/05, Ivan Kolodyazhny wrote:
>> Hi developers and operators,
>> I would like to get any feedback from you about my idea before I'll start
>> work on spec.
>>
>> In Nova, we've got max_concurrent_builds option [1] to set 'Maximum number
>> of instance builds to run concurrently' per each compute. There is no
>> equivalent Cinder.
> Hi,
>
> First I want to say that I think this is a good idea because I know this
> message will get diluted once I start with my mumbling.  ;-)
>
> The first thing we should allow to control is the number of workers per
> service, since we currently only allow setting it for the API nodes and
> all other nodes will use a default of 1000.  I posted a patch [1] to
> allow this and it's been sitting there for the last 3 months.  :'-(
>
> As I see it not all mentioned problems are equal, and the main
> distinction is caused by Cinder being not only in the control path but
> also in the data path. Resulting in some of the issues being backend
> specific limitations, that I believe should be address differently in
> the specs.
>
> For operations where Cinder is in the control path we should be
> limiting/queuing operations in the cinder core code (for example the
> manager) whereas when the limitation only applies to some drivers this
> should be addressed by the drivers themselves.  Although the spec should
> provide a clear mechanism/pattern to solve it in the drivers as well so
> all drivers can use a similar pattern which will provide consistency,
> making it easier to review and maintain.
>
> The queuing should preserve the order of arrival of operations, which
> file locks from Oslo concurrency and Tooz don't do.

I would be seriously opposed to queuing done inside Cinder code. It
makes draining a service harder and increases impact of a failure of a
single service. We already have a queue system and it is whatever you're
running under oslo.messaging (RabbitMQ mostly). Making our RPC workers
number configurable for each service sounds like a best shot to me.

>> Why do we need it for Cinder? IMO, it could help us to address following
>> issues:
>>
>>- Creation of N volumes at the same time increases a lot of resource
>>usage by cinder-volume service. Image caching feature [2] could help us a
>>bit in case when we create volume form image. But we still have to upload 
>> N
>>images to the volumes backend at the same time.
> This is an example where we are in the data path.
>
>>- Deletion on N volumes at parallel. Usually, it's not very hard task
>>for Cinder, but if you have to delete 100+ volumes at once, you can fit
>>different issues with DB connections, CPU and memory usages. In case of
>>LVM, it also could use 'dd' command to cleanup volumes.
> This is a case where it is a backend limitation and should be handled by
> the drivers.
>
> I know some people say that deletion and attaching have problems when a
> lot of them are requested to the c-vol nodes and that cinder cannot
> handle the workload properly, but in my experience these cases are
> always due to suboptimal cinder configuration, like a low number of DB
> connections configured in cinder that make operations fight for a DB
> connection creating big delays to complete operations.
>
>>- It will be some kind of load balancing in HA mode: if cinder-volume
>>process is busy with current operations, it will not catch message from
>>RabbitMQ and other cinder-volume service will do it.
> I don't understand what you mean with this.  Do you mean that Cinder
> service will stop listening to the message queue when it reaches a
> certain workload on the "heavy" operations?  Then wouldn't it also stop
> processing "light" operations?
>
>>- From users perspective, it seems that better way is to create/delete N
>>volumes a bit slower than fail after X volumes were created/deleted.
> I agree, it's better not to fail.  :-)
>
> Cheers,
> Gorka.
>
>>
>> [1]
>> https://github.com/openstack/nova/blob/283da2bbb74d0a131a66703516d16698a05817c7/nova/conf/compute.py#L161-L163
>> [2]
>> https://specs.openstack.org/openstack/cinder-specs/specs/liberty/image-volume-cache.html
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Openstack-operators] [nova] Is verification of images in the image cache necessary?

[Matthew Booth]

On Tue, May 24, 2016 at 1:15 PM, Fichter, Dane G. 
wrote:

> Hi John and Matt,
>
> I actually have a spec and patch up for review addressing some of what
> you’re referring to below.
>
> https://review.openstack.org/#/c/314222/
> https://review.openstack.org/#/c/312210/
>
> I think you’re quite right that the existing ImageCacheManager code serves
> little purpose. What I propose here is a cryptographically stronger
> verification meant to protect against both deliberate modification by an
> adversary, as well as accidental sources of disk corruption. If you like, I
> can deprecate the checksum-based verification code in the image cache as a
> part of this change. Feel free me to email me back or ping me on IRC
> (dane-fichter) in order to discuss more.
>

Thanks Dane, reviewed. I don't think the details are right yet, but I do
think this is the way to go. I also think we need to entirely divorce this
functionality from the image cache.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
__
OpenStack Development Mailing 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] Stable disk device instance rescue reviews for libvirt and possible implementation by other virt drivers

[Jay Pipes]

Hi Lee,

I'll try to get to these reviews later this afternoon. Thanks for your 
patience.


Best,
-jay

On 05/24/2016 08:53 AM, Lee Yarwood wrote:

Hello all,

https://review.openstack.org/#/q/topic:bp/virt-rescue-stable-disk-devices

I've been aimlessly pushing my patches around for this spec for a while
now and would really appreciate reviews from the community. Tempest and
devstack patches are also included in the above topic, reviews would
again be really appreciated for these.

I'd also like to ask if any other virt driver maintainers are looking to
implement this spec for their backends in Newton? The spec itself is
pretty straight forward but I'd be happy to help if there are questions
or concerns around getting this implemented outside of libvirt.

Thanks in advance,

Lee



__
OpenStack Development Mailing 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] [aodh] Tempest gate not working

[Julien Danjou]

Hi,

So it turns out we tried (especially Ryota) to add Tempest support via
https://review.openstack.org/#/c/303921/ for Aodh's gate, but it does
not actually run Tempest.

Otherwise, we would have notice something wrong in
https://review.openstack.org/#/c/318052/. As EmilienM noticed in Puppet
Aodh module, who actually runs Tempest, Aodh has a test to check the
combination alarm that now fails.

The tempest job log shows that it runs the functional tests, but not Tempest:
  
http://logs.openstack.org/52/318052/2/check/gate-aodh-dsvm-tempest-plugin-mongodb/5840d90/console.html.gz#_2016-05-19_14_01_49_072
  + ./post_test_hook.sh:main:56  :   sudo -E -H -u stack tox 
-efunctional

I've no idea how this exactly work, but if anyone has knowledge on gate
and Tempest, it'd be awesome to fix it. Or finish it, as the job are
still non-voting, I imagine nobody finished Ryota first attempt.

Cheeres,
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

[Flavio Percoco]

On 23/05/16 21:57 +0100, Chris Dent wrote:

[snip]


So, yet another way to frame the original question (in a loaded way)
may be: Are we trying to come up with a way of defining the community
that lets us carry on doing what we've been doing, haphazardly, or
are we trying to get the process of defining the community to bring
us to a point where we have some useful constraints that allow us to
more effectively reach goal X?

Begging, of course: What's X?

(To me, an unfettered big tent is a great way to keep riding the
great OpenStack enterprise boondoggle, but I'm not sure it's
resulting in a great experience for humans who aren't on that
train.)


The question I believe we're trying to answer is the second one. It seems clear
to me that what we're doing has some problems we need to fix and coming up with
a way to explain what we're doing without fixing those problems won't help us at
all.

I've expressed several times my concerns related to an unfettered big tent. My
belief is that we should focus on the goal and accept that we might need to set
stronger rules (for lack of a better word in my vocabulary) that will help
preserving the tent.

So, just to make sure I'm making myself clear, I believe we should go with
option #2 in Thierry's comment from May 23 11:3 on this[0] review. While I'm not
entirely opposed to #1 I think #2 is better for us at this point in time. Here's
a quote of Thierry's comment:

  "To summarize my view on this, I think our only two options here are (1)
  approve the addition of golang (with caveats on where it should be used
  to try to minimize useless churn), or (2) precise the line between
  'openstack projects' and 'dependencies of openstack projects' in a way
  that makes it obvious that components requiring such optimization as to
  require golang (or any other such language) should be developed as
  dependencies"

My main motivation is that I still believe option #1 will have a negative impact
on the community and, perhaps more importantly, I don't think it'll help
reaching the goal we've been talking about in this thread. Many people have been
asking for focus and I think #2 will do that, whereas #1 will open the doors to
a different set of problems and complexities that won't help with keeping the 
focus.

This is, of course, just my opinion.

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

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