date:20150423

 Also, on the Python 3 topic, there's still a big issue with memcached 
 (aka: python-memcache).

Oh, thanks Thomas for the reminder. I just sent a pull request to port 
python-memcached to Python 3:

   https://github.com/linsomniac/python-memcached/pull/67

I don't understand. I saw a lot of Port to Python 3 fixes merged in 2014, and 
these changes are now part of the release 1.54. Problem: running 
python-memcached tests with tox fail on obvious Python 3 errors. Anyway, all 
tests now pass with my pull request. The good news is that python-memcached 
looks to be actively developed.


Julien Danjou ported pymemcache to Python 3, another memcached client. He 
suggests to use this one instead of python-memcached client.


 It's blocking me from adding Python3 support to 
 keystoneclient, and as a consequence, to almost all of OpenStack.

python-keystoneclient announces a full Python 3 support with a voting Python 3 
gate. I just checked locally, tox -e py34 pass.

The problem is that python-memcached miss in test dependencies and so 
middleware tests using memcache are never run!

Victor

__
OpenStack Development Mailing 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] Why no DB index on sort parameters

2015-04-23 Thread Nikhil Komawar

Messing with indices is not a good idea to do iteratively.  Indexing large data 
sets is a really expensive operation and should be done carefully and 
consistently. Changing around indices is only going to make things unstable.

Thanks,
-Nikhil


From: Flavio Percoco fla...@redhat.com
Sent: Thursday, April 23, 2015 7:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Why no DB index on sort parameters

On 21/04/15 14:55 +, Nikhil Komawar wrote:
Rally is great overall however, we need good EXPLAIN examples on real world 
data. Smaller deployments might benefit from a simple sample performance 
analysis however, larger data sets can have impacts on areas that you never 
expect.

A spec means that we document the indices proposed in the code base, based on 
all of the use cases. The way I look at it, a patch is needed anyways and it 
(rally gate job) would get attention from reviewers when the patch is proposed.

Yes, I believe we need both. However, I'd probably just start with
something smaller and see how it behaves before going with big data
sets.

I'm not saying we don't need tests with proper data sets, I'm saying
that I'd probably start with smaller ones. As Mike already mentioned
in his email, there's an impact in writes and we can see that from
Rally tests, AFAICT.

The spec can come later, IMHO.

Cheers,
Flavio



From: Flavio Percoco fla...@redhat.com
Sent: Tuesday, April 21, 2015 10:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Why no DB index on sort parameters

On 21/04/15 14:39 +, Nikhil Komawar wrote:
This is a good idea. We recently removed a unique constraint that may result
into some queries being very slow especially those that involve name
property. I would recommend sketching out a spec that identifies potential 
full
table scans especially for queries that join over image_properties table.


We should discuss there what other use cases look like rather than smaller
feedback on the ML.

More thatn a spec, I'd be interested in seeing the patch with the
change up and the results reported in Rally.

I guess we'll need a spec anyway, although I'd probably be ok with a
good bug report here.

/me *shrugs*
Flavio



Thanks,
-Nikhil
━━━
From: Mike Bayer mba...@redhat.com
Sent: Tuesday, April 21, 2015 9:45 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Why no DB index on sort parameters



On 4/21/15 2:47 AM, Ajaya Agrawal wrote:

Hi All,

I see that glance supports arbitrary sort parameters and the default is
created_at while listing images. Is there any reason why we don't have
index over these fields? If we have an index over these fields then we
would avoid a full table scan to do sorting. IMO at least the created_at
field should have an index on it.

just keep in mind that more indexes will place a performance penalty on INSERT
statements, particularly at larger volumes.  I have no idea if that is
important here but something to keep in mind.






Cheers,
Ajaya



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


--
@flaper87
Flavio Percoco

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

--
@flaper87
Flavio Percoco

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

Re: [openstack-dev] Barbican : Dependency of pyenv configuration in Barbican.sh script

2015-04-23 Thread neetu jain

Thanks John for you answer.
I tried running the  script bin/barbican-api and ran into this issue
(pasted at the end) . Seems like the script does not take care of the
database side.

1) do we need to do something else to setup database? or its being worked
on ?
2) Can we help in the process of removing dependencies in these scripts?
Should that be through the launchpad ?


TASK: [barbican | install barbican]
***
failed: [barbican-04] = {changed: true, cmd: cd /root/barbican/;
python bin/barbican-api, delta: 0:00:00.553279, end: 2015-04-23
14:56:45.773115, rc: 1, start: 2015-04-23 14:56:45.219836,
warnings: []}
stderr: 2015-04-23 14:56:45.736 6984 CRITICAL barbican [-]
BarbicanException: No SQL connection configured
2015-04-23 14:56:45.736 6984 TRACE barbican Traceback (most recent call
last):
2015-04-23 14:56:45.736 6984 TRACE barbican   File bin/barbican-api, line
17, in module
2015-04-23 14:56:45.736 6984 TRACE barbican run()
2015-04-23 14:56:45.736 6984 TRACE barbican   File bin/barbican-api, line
12, in run
2015-04-23 14:56:45.736 6984 TRACE barbican relative_to='.')
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in
loadapp
2015-04-23 14:56:45.736 6984 TRACE barbican return loadobj(APP, uri,
name=name, **kw)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 272, in
loadobj
2015-04-23 14:56:45.736 6984 TRACE barbican return context.create()
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in
create
2015-04-23 14:56:45.736 6984 TRACE barbican return
self.object_type.invoke(self)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 144, in
invoke
2015-04-23 14:56:45.736 6984 TRACE barbican **context.local_conf)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/util.py, line 56, in
fix_call
2015-04-23 14:56:45.736 6984 TRACE barbican val = callable(*args, **kw)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib64/python2.7/site-packages/paste/urlmap.py, line 31, in
urlmap_factory
2015-04-23 14:56:45.736 6984 TRACE barbican app =
loader.get_app(app_name, global_conf=global_conf)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 350, in
get_app
2015-04-23 14:56:45.736 6984 TRACE barbican name=name,
global_conf=global_conf).create()
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in
create
2015-04-23 14:56:45.736 6984 TRACE barbican return
self.object_type.invoke(self)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 203, in
invoke
2015-04-23 14:56:45.736 6984 TRACE barbican app =
context.app_context.create()
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in
create
2015-04-23 14:56:45.736 6984 TRACE barbican return
self.object_type.invoke(self)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 146, in
invoke
2015-04-23 14:56:45.736 6984 TRACE barbican return
fix_call(context.object, context.global_conf, **context.local_conf)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/usr/lib/python2.7/site-packages/paste/deploy/util.py, line 56, in
fix_call
2015-04-23 14:56:45.736 6984 TRACE barbican val = callable(*args, **kw)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/root/barbican/barbican/api/app.py, line 89, in create_main_app
2015-04-23 14:56:45.736 6984 TRACE barbican
repositories.setup_database_engine_and_factory()
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/root/barbican/barbican/model/repositories.py, line 109, in
setup_database_engine_and_factory
2015-04-23 14:56:45.736 6984 TRACE barbican _ENGINE =
_get_engine(_ENGINE)
2015-04-23 14:56:45.736 6984 TRACE barbican   File
/root/barbican/barbican/model/repositories.py, line 170, in _get_engine
2015-04-23 14:56:45.736 6984 TRACE barbican u._('No SQL connection
configured'))
2015-04-23 14:56:45.736 6984 TRACE barbican BarbicanException: No SQL
connection configured
2015-04-23 14:56:45.736 6984 TRACE barbican

FATAL: all hosts have already failed -- aborting


On Wed, Apr 22, 2015 at 11:50 PM, Asha Seshagiri asha.seshag...@gmail.com
wrote:

 Thanks a lot John for your response.
 I appreciate for your time and effort in answering the queries and also
 pointing to the latest changes which you been always doing :)

 Thanks and  Regards,
 Asha Seshagiri

 On Wed, Apr 22, 2015 at 6:09 PM, John Wood john.w...@rackspace.com
 wrote:

  Hello Asha,

  The barbican.sh script was originally

[openstack-dev] [all] Question for the TC candidates

2015-04-23 Thread Chris Dent



This might be a bit presumptuous, but why not give it a try...

This cycle's TC elections didn't come with a set of prepackaged
questions and though the self-nomination messages have included some
very interesting stuff I think it would be useful to get answers
from the candidates on at least one topical but open-ended
question. Maybe other people have additional questions they think
are important but this one is the one that matters to me and also
captures the role that I wish the TC filled more strongly. Here's
the preamble:

There are lots of different ways to categorize the various
stakeholders in the OpenStack community, no list is complete. For
the sake of this question the people I'm concerned with are the
developers, end-users and operators of OpenStack: the individuals
who are actively involved with it on a daily basis. I'm intentionally
leaving out things like the downstream.

There are many different ways to define quality. For the sake of
this question feel free to use whatever definition you like but take
it as given that quality needs to be improved.

Here's the question:

What can and should the TC at large, and you specifically, do to ensure
quality improves for the developers, end-users and operators of
OpenStack as a full system, both as a project being developed and a
product being used?

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

On 04/22/2015 09:55 PM, Anita Kuno wrote:
 On 04/22/2015 09:46 PM, Kyle Mestery wrote:
 On Wed, Apr 22, 2015 at 7:44 PM, Armando M. arma...@gmail.com wrote:



 On 22 April 2015 at 11:19, Russell Bryant rbry...@redhat.com wrote:

 Hello!

 A couple of things I've been working on lately are project governance
 issues as a TC member and also implementation of a new virtual
 networking alternative with a Neutron driver.  So, naturally I started
 thinking about how the Neutron driver code fits in to OpenStack
 governance.

 There are basically two areas with a lot of movement related to this
 issue.

 1) Project governance has moved to a big tent model [1].  The vast
 majority of projects that used to be in Stackforge are being folded in
 to a larger definition of the OpenStack project.  Projects making this
 move meet the following criteria as being one of us:


 Is it sensible to assume that Stackforge is going away entirely at some
 point in the future, and we'll have a single namespace - OpenStack?



 IMHO, I'm not sure what the StackForge designation means anymore now that
 we have the Big Tent. I obviously also don't have the authority to make the
 call on when it goes away however.
 Moving everything from Stackforge into the OpenStack namespace is
 something that Jim Blair has said he would like to see happen. There has
 been no resolution or focused discussion on this exact point that has
 been put before the TC that I have seen.

I think things are moving fast enough.  We need to make sure all of the
repos are properly captured under a team, but it seems momentum is
picking up.  This thread is part of that.

-- 
Russell Bryant

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

Re: [openstack-dev] TC non-candidacy

2015-04-23 Thread Anita Kuno

On 04/23/2015 02:05 AM, Michael Still wrote:
 Hi,
 
 I've served on the TC for a while now and enjoyed it. However, I feel
 I've reached a point where I need to step back and take a break. I
 will therefore not be running this time around. I'm sure I'll return
 just as soon as my righteous anger builds up again.
 
 Cheers,
 Michael
 
Thanks for letting us know your intentions, Michael. You write the best
meeting absentee notes!

Seriously thank you for all your hard work and dedication. I can't
begrudge you a well deserved rest. I look forward to hearing your point
of view on matters when you have the energy to share it again.

My thanks to you,
Anita.

__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

On 04/22/2015 10:33 PM, Armando M. wrote:
 
 Would it make sense to capture these projects as simply
 'affiliated', ie. with a loose relationship to Neutron, because
 they use/integrate with Neutron in some form or another (e.g.
 having 3rd-party, extending-api, integrating-via-plugin-model,
 etc)? Then we could simply consider extending the projects.yaml
 to capture this new concept (for Neutron or any other project)
 once we defined its ontology.
 
 Thoughts?
 
 
 That seems interesting, but given the communities stated goals
 around Big Tent, it seems to me like affiliation or not, adding
 these under the Neutron tent, inside the larger OpenStack Bigger
 Tent, would be a good thing.
 
 Thanks,
 Kyle
  
 
 
 Thanks for clearing some of the questions I raised. I should stress the
 fact that I welcome the idea of finding a more sensible home for these
 projects in light of the big tent developments, but it seems like we're
 still pouring down the foundations. I'd rather get us to a point where
 the landscape is clear, and the dust settled. That would help us make a
 more informed decision compared to the one we can make right now.

Can you be a bit more specific about what's not clear and would help
make you feel more informed?

-- 
Russell Bryant

__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com wrote:

 On 04/22/2015 10:33 PM, Armando M. wrote:
 
  Would it make sense to capture these projects as simply
  'affiliated', ie. with a loose relationship to Neutron, because
  they use/integrate with Neutron in some form or another (e.g.
  having 3rd-party, extending-api, integrating-via-plugin-model,
  etc)? Then we could simply consider extending the projects.yaml
  to capture this new concept (for Neutron or any other project)
  once we defined its ontology.
 
  Thoughts?
 
 
  That seems interesting, but given the communities stated goals
  around Big Tent, it seems to me like affiliation or not, adding
  these under the Neutron tent, inside the larger OpenStack Bigger
  Tent, would be a good thing.
 
  Thanks,
  Kyle
 
 
 
  Thanks for clearing some of the questions I raised. I should stress the
  fact that I welcome the idea of finding a more sensible home for these
  projects in light of the big tent developments, but it seems like we're
  still pouring down the foundations. I'd rather get us to a point where
  the landscape is clear, and the dust settled. That would help us make a
  more informed decision compared to the one we can make right now.

 Can you be a bit more specific about what's not clear and would help
 make you feel more informed?


I am not clear on how we make a decision, as to which project belongs or
doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end up
calling it :)


 --
 Russell Bryant

 __
 OpenStack Development Mailing 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] A big tent home for Neutron backend code

On 23 April 2015 at 01:49, Thierry Carrez thie...@openstack.org wrote:

 Armando M. wrote:
  Is it sensible to assume that Stackforge is going away entirely at some
  point in the future, and we'll have a single namespace - OpenStack?

 The key difference between Stackforge and OpenStack is governance. Any
 project can be in Stackforge. Projects that are considered OpenStack
 projects are special in two ways:

 1- They need to fit the OpenStack requirements as defined by the TC
 2- They need to place themselves under the oversight of the TC

 In return, they get voting rights to elect the TC itself.

 While most projects in Stackforge actually fit (1) and accept (2), not
 all of them do. It's also not a decision that can be made for them (due
 to (2)), so we can't just migrate them.

  It's my understanding that StackForge projects are bound to the same
  governance model, or am I mistaken?

 Of course they aren't. They don't sign up for anything, and our
 governance model has no sort of control over them.


I have always considered StackForge projects (the vast majority anyway)
projects that have the ultimate desire to be an integral part of the
OpenStack ecosystem, and as such would need to follow the same model of the
other openstack projects (at least before the latest governance changes).
This is what I meant 'by bound to the same governance model', ie. besides
the legalities, following the same rules as any other OpenStack project,
but I can see I may have generated confusion with my point.

Thierry, thanks for the clarification.


 --
 Thierry Carrez (ttx)

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

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

Re: [openstack-dev] [Nova][Sahara][Heat] Kilo RC2 available

2015-04-23 Thread YAMAMOTO Takashi

 Hello everyone,
 
 Due to release-critical issues spotted in Nova, Sahara and Heat during
 RC1 testing, new release candidates were created for Kilo. The list of
 RC2 fixes, as well as RC2 tarballs are available at:
 
 https://launchpad.net/nova/kilo/kilo-rc2
 https://launchpad.net/nova/sahara/kilo-rc2
 https://launchpad.net/nova/heat/kilo-rc2

https://launchpad.net/sahara/kilo/kilo-rc2
https://launchpad.net/heat/kilo/kilo-rc2

 
 Unless new release-critical issues are found that warrant a release
 candidate respin, these tarballs will be formally released as the final
 Kilo versions on April 30. You are therefore strongly encouraged to
 test and validate these tarballs !
 
 Alternatively, you can directly test the stable/kilo branches at:
 https://github.com/openstack/nova/tree/stable/kilo
 https://github.com/openstack/sahara/tree/stable/kilo
 https://github.com/openstack/heat/tree/stable/kilo
 
 If you find an issue that could be considered release-critical, please
 file it at:
 
 https://bugs.launchpad.net/nova/+filebug
 https://bugs.launchpad.net/sahara/+filebug
 https://bugs.launchpad.net/heat/+filebug
 
 and tag it *kilo-rc-potential* to bring it to the release crew's attention.
 
 Thanks!
 
 -- 
 Thierry Carrez (ttx)
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

Re: [openstack-dev] [api] API WG Meeting Time

2015-04-23 Thread michael mccune


On 03/31/2015 10:13 PM, Everett Toews wrote:

Ever since daylight savings time it has been increasing difficult for many API 
WG members to make it to the Thursday 00:00 UTC meeting time.

Do we change it so there’s only the Thursday 16:00 UTC meeting time?


this topic was brought up again at today's meeting (April 23, 2015), and 
we are still searching for a good alternate time.


one proposal that came up was for an early morning PST time on thursdays 
for the meeting. i'm guessing this would be around the 12:00-13:00 UTC 
range.


we would still love to hear more thoughts from folks in Australia/Asia 
time zones to see if we can arrive at something that will accommodate 
the most number of interested parties.


regards,
mike


__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com wrote:

 On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
  On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com
  mailto:rbry...@redhat.com wrote:
 
  On 04/22/2015 10:33 PM, Armando M. wrote:
  
   Would it make sense to capture these projects as simply
   'affiliated', ie. with a loose relationship to Neutron,
  because
   they use/integrate with Neutron in some form or another
 (e.g.
   having 3rd-party, extending-api,
 integrating-via-plugin-model,
   etc)? Then we could simply consider extending the
  projects.yaml
   to capture this new concept (for Neutron or any other
 project)
   once we defined its ontology.
  
   Thoughts?
  
  
   That seems interesting, but given the communities stated goals
   around Big Tent, it seems to me like affiliation or not, adding
   these under the Neutron tent, inside the larger OpenStack
 Bigger
   Tent, would be a good thing.
  
   Thanks,
   Kyle
  
  
  
   Thanks for clearing some of the questions I raised. I should
  stress the
   fact that I welcome the idea of finding a more sensible home for
 these
   projects in light of the big tent developments, but it seems like
  we're
   still pouring down the foundations. I'd rather get us to a point
 where
   the landscape is clear, and the dust settled. That would help us
  make a
   more informed decision compared to the one we can make right now.
 
  Can you be a bit more specific about what's not clear and would help
  make you feel more informed?
 
 
  I am not clear on how we make a decision, as to which project belongs or
  doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
  up calling it :)

 OK, that's fine.  Figuring that out is the next step if folks agree with
 Neutron as the home for networking-foo repos.  I'm happy to write up a
 strawman proposal for inclusion criteria and a set of expectations
 around responsibilities and communication.


What about the other Neutron related ones that didn't strictly follow the
networking- prefix in the name, would the naming convention be one of the
criteria? I look forward to your proposal.

Thanks,
Armando


 --
 Russell Bryant

 __
 OpenStack Development Mailing 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] A big tent home for Neutron backend code

On 04/23/2015 01:19 PM, Armando M. wrote:
 
 
 On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com wrote:
 
 On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
  On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com 
 mailto:rbry...@redhat.com
  mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
  On 04/22/2015 10:33 PM, Armando M. wrote:
  
   Would it make sense to capture these projects as simply
   'affiliated', ie. with a loose relationship to Neutron,
  because
   they use/integrate with Neutron in some form or
 another (e.g.
   having 3rd-party, extending-api,
 integrating-via-plugin-model,
   etc)? Then we could simply consider extending the
  projects.yaml
   to capture this new concept (for Neutron or any
 other project)
   once we defined its ontology.
  
   Thoughts?
  
  
   That seems interesting, but given the communities stated
 goals
   around Big Tent, it seems to me like affiliation or not,
 adding
   these under the Neutron tent, inside the larger
 OpenStack Bigger
   Tent, would be a good thing.
  
   Thanks,
   Kyle
  
  
  
   Thanks for clearing some of the questions I raised. I should
  stress the
   fact that I welcome the idea of finding a more sensible home
 for these
   projects in light of the big tent developments, but it seems
 like
  we're
   still pouring down the foundations. I'd rather get us to a
 point where
   the landscape is clear, and the dust settled. That would help us
  make a
   more informed decision compared to the one we can make right
 now.
 
  Can you be a bit more specific about what's not clear and
 would help
  make you feel more informed?
 
 
  I am not clear on how we make a decision, as to which project
 belongs or
  doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
  up calling it :)
 
 OK, that's fine.  Figuring that out is the next step if folks agree with
 Neutron as the home for networking-foo repos.  I'm happy to write up a
 strawman proposal for inclusion criteria and a set of expectations
 around responsibilities and communication.
 
 
 What about the other Neutron related ones that didn't strictly follow
 the networking- prefix in the name, would the naming convention be one
 of the criteria? I look forward to your proposal.

Good question.  I think consistency is good, especially when there are
so many of them.  It helps make it clear that they're all following some
sort of pattern.  Luckily we do have a way to get repos renamed if needed.

-- 
Russell Bryant

__
OpenStack Development Mailing 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] Question for the TC candidates

2015-04-23 Thread Michael Krotscheck

Hey there Chris!

On Thu, Apr 23, 2015 at 9:17 AM Chris Dent chd...@redhat.com wrote:

 What can and should the TC at large, and you specifically, do to
 ensure quality improves for the developers, end-users and operators
 of OpenStack as a full system, both as a project being developed and
 a product being used?


OpenStack needs to become as boring as possible.

Clouds, to me, are plumbing. They're not themselves interesting, rather
they are the platforms upon which interesting things are built. And they
shouldn't be, either! Use hardware as an analogy: The RJ-45 connector is
ubiquitous for physical network connections. If each manufacturer used
something different, you'd soon be spending all your time soldering
adapters, and the last thing I want our operators, developers, or customers
to do is waste their time doing the cloud-equivalent.

Example: Pep8 is boring. Benefit: We don't waste time arguing about tabs
vs. spaces anymore.

The TC can set policies that encourage being boring. It's the closest we
have to an ISO standards board, and while the TC has no real power to
mobilize resources to build things, it can advise and encourage adoption of
policies and standards. Some examples include: Test Coverage standards,
common middleware, consistent API standards... you get the idea. The more
boring OpenStack becomes, the easier it will be to work on, operate, and
talk about.

As for myself: I'm going to focus on making UI projects as boring as
possible. This includes lots of things, so let me get into specifics:
- Creating, and encouraging the use of, common middleware that encapsulates
existing RFC's and standards which support UI development (CORS, Common
Auth, etc.)
- Researching, Drafting, Proposing, and Shepherding policies for UI
development that involve all stakeholders, including upstream and
downstream engineers, Package Maintainers, and operators.
- Creating the tools that will allow us to publish UI libraries to the
global community (mostly JS, we've got the Python part handled).
- Getting involved in UI tooling projects (Node, Sass, etc) and advocating
a more enterprise-supportive approach to topics like security, package
signing, package structures, audit trails, and distribution.

That about sums it up. Have a nice day!

Michael
__
OpenStack Development Mailing 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] Re: [atomic-devel] Adding kubernetes 0.15 to Fedora 21 Atomic

2015-04-23 Thread Steven Dake (stdake)



On 4/17/15, 10:25 AM, Matthew Miller mat...@mattdm.org wrote:

On Fri, Apr 17, 2015 at 04:29:36PM +, Steven Dake (stdake) wrote:
 Fedora 21 only has kubernetes 0.13 although I see in koji k8s 0.15
 has been built for f23. Is there any possibility of getting
 kubernetes 0.15 in fedora atomic 21 by May 5th? If not, we will have

I noticed this bug https://bugzilla.redhat.com/show_bug.cgi?id=1211266,
which says Tracker used for kubernetes updates. I'm not sure exactly
what that means, though. :)

Matt,

Fedora Atomic wasn¹t moving fast enough for our upstream, and building
Fedora Atomic images is too hard (tm) so I went ahead and built a Fedora
21 Cloud + k8s 0.15 + flannel + docker + etcd.

We are going to switch to using this model in upstream OpenStack Magnum
until Kubernetes development stabilizes, or Fedora Atomic can keep up with
Kubernetes.  Hopefully that will happen prior to the conclusion of the
Liberty development cycle (November 2015).

If folks want to test the f21_k15 image, the image is available here:

https://fedorapeople.org/groups/magnum/


Regards
-steve


-- 
Matthew Millermat...@mattdm.org
http://mattdm.org/
Fedora Project Leader  mat...@fedoraproject.org
http://fedoraproject.org/ 


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

Re: [openstack-dev] [all] Question for the TC candidates

2015-04-23 Thread Anita Kuno

On 04/23/2015 12:14 PM, Chris Dent wrote:
 
 This might be a bit presumptuous, but why not give it a try...
Thank you for asking the question, Chris, my response is below.

Anita.
 
 This cycle's TC elections didn't come with a set of prepackaged
 questions and though the self-nomination messages have included some
 very interesting stuff I think it would be useful to get answers
 from the candidates on at least one topical but open-ended
 question. Maybe other people have additional questions they think
 are important but this one is the one that matters to me and also
 captures the role that I wish the TC filled more strongly. Here's
 the preamble:
 
 There are lots of different ways to categorize the various
 stakeholders in the OpenStack community, no list is complete. For
 the sake of this question the people I'm concerned with are the
 developers, end-users and operators of OpenStack: the individuals
 who are actively involved with it on a daily basis. I'm intentionally
 leaving out things like the downstream.
 
 There are many different ways to define quality. For the sake of
 this question feel free to use whatever definition you like but take
 it as given that quality needs to be improved.
 
 Here's the question:
 
 What can and should the TC at large, and you specifically, do to ensure
 quality improves for the developers, end-users and operators of
 OpenStack as a full system, both as a project being developed and a
 product being used?
 
Question: What can and should the TC at large, and you specifically, do
to ensure quality improves for the developers, end-users and operators
of OpenStack as a full system, both as a project being developed and a
product being used?

Answer: I'll move to my astrological perspective and what I interpret
from OpenStack's birth chart here.

OpenStack has a dynamic energy pattern of three powerful positions, two
of which want to dominate the other and the third which is in the
position to bring balance to the first two. Uranus (the rebel
representing freedom) sits in the position of values with a pioneering
spirit. Saturn representing structure, authority (the tc) and
limitations of physical resources (human limitations and the real
experience of burnout) sits directly opposite, pulling in the other
direction of needing to find common ground, real solutions and to do so
in a careful precise way. These two energies see-saw against each other,
each trying to be the dominate force. Pluto is the balancer here (the
strongly influential recently demoted former planet). It sits in the
exact mid-point between the need for all of us to rebel and the need for
all of us to have structure and be involved in building that structure.
It sits in the position of groups, society and culture. By recognizing
that the TC is one strong force among 3 forces, and ensuring that the TC
play its role, our shared need to rebel and be free will be balanced by
the community norms that come out of that interaction. The TC has a role
to play in that dynamic but it isn't the entire role, nor actually is it
the strongest role, but it is a strong role.

This is my way of saying that the TC and members that serve it need to
recognize the dynamic nature of the relationship it shares with all its
parts. The phrase quality improvement implies for me, a linear
direction, while I feel that the energy dynamic we share is more a
triangular one. If one of the consequences of improvement of quality is
less frustration on any one part of the dynamic it comes from a clearer
appreciation of the other points of view in the dynamic. As a member of
the community (and if the community decides its needs are best served by
me having a voice on the TC) I do my best to look at the situation from
my perspective first (I have to be true to myself here) and then look up
and see what other perspectives are present. I do do my best to make
myself available to hear and interact with other perspectives (chairing
two third party meetings per week, attending infra, tc, neutron, nova as
well as other project meetings as need be) while understanding my
physical limitations at the same time and working to find my own balance.

I realize my invocation of astrology vocabulary might dissuade those who
are uncomfortable with it as a tool. I accept that. I see OpenStack as a
constant dynamic dance we have selected to be a part of and we each have
our role to play.

Thank you for helping me to find mine,
Anita.

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

Re: [openstack-dev] [Horizon] Outreachy call for mentor

2015-04-23 Thread Victoria Martínez de la Cruz

Hi Thai,

Will do, thanks a lot to you too!

2015-04-22 22:21 GMT-03:00 Thai Q Tran tqt...@us.ibm.com:

 Hi Victoria,

 Count me in also. I'll go ahead and subscribe myself to the mailing list
 as well.

 [image: Inactive hide details for Victoria Martínez de la Cruz
 ---04/22/2015 06:10:13 PM---Hi David, Thanks a lot for your quick 
 respon]Victoria
 Martínez de la Cruz ---04/22/2015 06:10:13 PM---Hi David, Thanks a lot for
 your quick response! I'll give you more details about the

 From: Victoria Martínez de la Cruz victo...@vmartinezdelacruz.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 04/22/2015 06:10 PM
 Subject: Re: [openstack-dev] [Horizon] Outreachy call for mentor
 --



 Hi David,

 Thanks a lot for your quick response! I'll give you more details about the
 applicant in a follow up email or in IRC.

 Certainly having separate wikis is not practical sometimes, so Stefano has
 been working on centralize all the information wrt internships and
 mentoring opportunities in OpenStack. There is a new mailing list you can
 subscribe to
 *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-internships*
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-internships
 .

 Again, thanks.

 Victoria

 2015-04-22 21:51 GMT-03:00 David Lyle *dkly...@gmail.com*
 dkly...@gmail.com:

I added my name to an openstack wiki page for this express purpose
some time ago, apparently the wrong one, which I can find no reference to
now.

That said, I am willing to be a mentor for a Horizon focused intern,
if inability to find the correct wiki pages isn't a limiting factor.

David

On Wed, Apr 22, 2015 at 6:31 PM, Victoria Martínez de la Cruz 
*victo...@vmartinezdelacruz.com* victo...@vmartinezdelacruz.com
wrote:
   Hi all,

   Horizon folks, we have a really good Outreachy candidate interested
   in working with you. The internship is from May 25th to August 25th, and
   interns are expected to work full time on their projects. Being a mentor
   should not be time consuming, we expect interns to be able to do their
   tasks independently and to solve the blockers they might find with the 
 help
   of the community. I will be mentoring an applicant this round and, if 
 time
   is a problem, I offer to help with this applicant as well.

   The announcement of accepted participants is soon, so this is a
   real last minute call.

   Outreachy is an internship targeted to anyone who identifies as a
   woman and OpenStack has been participating on it for about two years 
 now.
   We had really good participants and many important features had been 
 added
   as part of this program. For more details on OpenStack participation on
   Outreachy, check out the OpenStack Outreachy wiki page [0] and the
   Outreachy official site [1].

   If you decide you want to mentor, please reach me and I'll guide
   you through the process.

   Please, let me know if you have any doubt or concern.

   Thanks all,

   Victoria

   [0] *https://wiki.openstack.org/wiki/Outreachy*
   https://wiki.openstack.org/wiki/Outreachy
   [1] *https://wiki.gnome.org/Outreachy*
   https://wiki.gnome.org/Outreachy


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

Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

2015-04-23 Thread Clint Byrum

Excerpts from Victor Stinner's message of 2015-04-23 07:24:06 -0700:
  Also, on the Python 3 topic, there's still a big issue with memcached 
  (aka: python-memcache).
 
 Oh, thanks Thomas for the reminder. I just sent a pull request to port 
 python-memcached to Python 3:
 
https://github.com/linsomniac/python-memcached/pull/67
 
 I don't understand. I saw a lot of Port to Python 3 fixes merged in 2014, 
 and these changes are now part of the release 1.54. Problem: running 
 python-memcached tests with tox fail on obvious Python 3 errors. Anyway, all 
 tests now pass with my pull request. The good news is that python-memcached 
 looks to be actively developed.
 
 
 Julien Danjou ported pymemcache to Python 3, another memcached client. He 
 suggests to use this one instead of python-memcached client.
 
  It's blocking me from adding Python3 support to 
  keystoneclient, and as a consequence, to almost all of OpenStack.
 
 python-keystoneclient announces a full Python 3 support with a voting Python 
 3 gate. I just checked locally, tox -e py34 pass.
 
 The problem is that python-memcached miss in test dependencies and so 
 middleware tests using memcache are never run!

This is a bug worth fixing. Those skips should be removed, as memcached
is quite popular as a token store. So I opened this bug to track it:

https://bugs.launchpad.net/python-keystoneclient/+bug/1447731

__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

2015-04-23 Thread Fox, Kevin M

Yeah. In the end, its what git repo the source for a given rpm you install 
comes from. Ops will not care that neutron-openvswitch-agent comes from repo 
foo.git instead of bar.git.

Thanks,
Kevin

From: Armando M. [arma...@gmail.com]
Sent: Thursday, April 23, 2015 9:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

I agree with henry here.
Armando, If we use your analogy with nova that doesn't build and deliver KVM, 
we can say that Neutron doesn't build or deliver OVS. It builds a driver and an 
agent which manage OVS, just like nova which provides a driver to manage 
libvirt/KVM.
Moreover, external SDN controllers are much more complex than Neutron with its 
reference drivers. I feel like forcing the cloud admin to deploy and maintain 
an external SDN controller would be a terrible experience for him if he just 
needs a simple way manage connectivity between VMs.
At the end of the day, it might be detrimental for the neutron project.

I don't think that anyone is saying that cloud admins are going to be forced to 
deploy and maintain an external SDN controller. There are plenty of deployment 
examples where people are just happy with network virtualization the way 
Neutron has been providing for years and we should not regress on that. To me 
it's mostly a matter of responsibilities of who develops what, and what that 
what is :)

The consumption model is totally a different matter.

__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

2015-04-23 Thread Kyle Mestery

On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M kevin@pnnl.gov wrote:

  Yeah. In the end, its what git repo the source for a given rpm you
 install comes from. Ops will not care that neutron-openvswitch-agent comes
 from repo foo.git instead of bar.git.



That's really the tl;dr of the proposed split.

Thanks,
Kyle


 Thanks,
 Kevin
  --
 *From:* Armando M. [arma...@gmail.com]
 *Sent:* Thursday, April 23, 2015 9:10 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron] A big tent home for Neutron
 backend code


   I agree with henry here.
  Armando, If we use your analogy with nova that doesn't build and
 deliver KVM, we can say that Neutron doesn't build or deliver OVS. It
 builds a driver and an agent which manage OVS, just like nova which
 provides a driver to manage libvirt/KVM.
  Moreover, external SDN controllers are much more complex than Neutron
 with its reference drivers. I feel like forcing the cloud admin to deploy
 and maintain an external SDN controller would be a terrible experience for
 him if he just needs a simple way manage connectivity between VMs.
 At the end of the day, it might be detrimental for the neutron project.



  I don't think that anyone is saying that cloud admins are going to be
 forced to deploy and maintain an external SDN controller. There are plenty
 of deployment examples where people are just happy with network
 virtualization the way Neutron has been providing for years and we should
 not regress on that. To me it's mostly a matter of responsibilities of who
 develops what, and what that what is :)

  The consumption model is totally a different matter.


 __
 OpenStack Development Mailing 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] [Trove] Kilo RC2 available

Hello everyone,

Due to release-critical issues spotted in Trove during RC1 testing, a
new release candidate was created for Kilo. The list of RC2 fixes, as
well as the RC2 tarball are available at:

https://launchpad.net/trove/kilo/kilo-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, this tarball will be formally released as the final
Kilo versions on April 30. You are therefore strongly encouraged to
test and validate this tarball !

Alternatively, you can directly test the stable/kilo branch at:
https://github.com/openstack/trove/tree/stable/kilo

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/trove/+filebug

and tag it *kilo-rc-potential* to bring it to the release crew's attention.

Thanks!

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code



 I agree with henry here.
 Armando, If we use your analogy with nova that doesn't build and deliver
 KVM, we can say that Neutron doesn't build or deliver OVS. It builds a
 driver and an agent which manage OVS, just like nova which provides a
 driver to manage libvirt/KVM.
 Moreover, external SDN controllers are much more complex than Neutron with
 its reference drivers. I feel like forcing the cloud admin to deploy and
 maintain an external SDN controller would be a terrible experience for him
 if he just needs a simple way manage connectivity between VMs.
 At the end of the day, it might be detrimental for the neutron project.



I don't think that anyone is saying that cloud admins are going to be
forced to deploy and maintain an external SDN controller. There are plenty
of deployment examples where people are just happy with network
virtualization the way Neutron has been providing for years and we should
not regress on that. To me it's mostly a matter of responsibilities of who
develops what, and what that what is :)

The consumption model is totally a different matter.
__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

2015-04-23 Thread Fox, Kevin M

+1

From: Armando M. [arma...@gmail.com]
Sent: Wednesday, April 22, 2015 7:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

Could you please also pay some attention on Cons of this ultimate
splitting Kyle? I'm afraid it would hurt the user experiences.

On the position of Dev, A naked Neutron without official built-in
reference implementation probably has a more clear architecture. On
the other side, users would be forced to make choice between a long
list of backend implementations, which is very difficult for
non-professionals.

In most of the time, users need a off-the-shelf solution without
paying much extra integration effort, and they have less interest to
study which SDN controller is powerful and is better than others. Can
we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
volume driver [See Deployment Profiles section in 1a] ? Shall we
really decide to make Neutron the only Openstack project which has not
any in tree official implementation?

I think the analogy here is between the agent reference implementation vs KVM 
or Ceph, rather than the plumbing that taps into the underlying technology. 
Nova doesn't build/package KVM as Cinder doesn't build/package Ceph. Neutron 
could rely on other open source solutions (ODL, OpenContrail, OVN, etc), and 
still be similar to the other projects.

I think there's still room for clarifying what the split needs to be, but I 
have always seen Neutron as the exception rather than norm, where, for historic 
reasons, we had to build everything from the ground up for lack of viable open 
source solutions at the time the project was conceived.

[1a] 
http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014

Here is my personal suggestion: decomposition decision needs some
trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2
with OVSLB, based on the survey result of 1a above]. While we are
progressing radically with architecture re-factoring, smooth
experience and easy to adoption should also be cared.

 One thing which is worth bringing up in this context is the potential
 overlap between this implementations. I think having them all under the
 Neutron project would allow me as PTL and the rest of the team work to
 combine things when it makes sense.

 Kyle

 [1] http://www.faqs.org/rfcs/rfc1149.html

 b) Let each interested group define a new project team for their backend
 code.

 To be honest, I don't this is a scalable option. I'm involved with 2 of
 these networking-foo projects, and there is not enough participation so far
 to warrant an entirely new project, PTL and infra around it. This is just my
 opinion, but it's an opinion I've taken after having contributed to
 networking-odl and networking-ovn for the past 5 months.

 So, as an example, the group of people working on Neutron integration
 with OpenDaylight could propose a new project team that would be a
 projects.yaml entry that looks something like:

 Neutron-OpenDaylight:
   ptl: Some Person (ircnick)
   service: OpenDaylight Networking
   mission: 
 To implement Neutron support for the OpenDaylight project.
   url: ...
   projects:
 - repo: openstack/networking-odl

 Pros:
  + There's no additional load on the Neutron project team and PTL.

 Cons:
  - Having all of these efforts organized under a single project team and
 PTL might be better for ensuring some level of collaboration and
 consistency.

 c) A single new project team could be created that is led by a single
 person to coordinate the sub-teams working on each repo.  In this
 scenario, I could see the overall collaboration being around ensuring
 consistent approaches to development process, testing, documentation,
 and releases.

 That would be something like this (note that the project list would be
 limited to those who actually want to be included in the official
 project team and meet some set of inclusion criteria).

 Neutron-Backends:
   ptl: Some Person (ircnick)
   service: Networking Backends
   mission: 
 To implement Neutron backend support for various networking
 technologies.
   url: ...
   projects:
 - openstack/networking-arista
 - openstack/networking-bagpipe-l2
 - openstack/networking-bgpvpn
 - openstack/networking-bigswitch
 - openstack/networking-brocade
 - openstack/networking-cisco
 - openstack/networking-edge-vpn
 - openstack/networking-hyperv
 - openstack/networking-ibm
 - openstack/networking-l2gw
 - openstack/networking-midonet
 - openstack/networking-mlnx
 - openstack/networking-nec
 - openstack/networking-odl
 - openstack/networking-ofagent
 - openstack/networking-ovn
 - openstack/networking-ovs-dpdk
 - openstack/networking-plumgrid
 - openstack/networking-portforwarding
 - openstack/networking-vsphere

 Pros:
  +

Re: [openstack-dev] cirros 0.3.4~pre1 available

2015-04-23 Thread Sean M. Collins

On Thu, Apr 23, 2015 at 09:24:20AM EDT, Scott Moser wrote:
 The changes since 0.3.3 are:
  - Improve tooling for IPv6 and network debugging
adding ping6, traceroute6 and arp.
 
 Thanks to Jens Rosenboom for pushing on getting some ipv6 things going and
 fixing nc -ll.

This is fantastic. Thank you so much for working on this Jens!

-- 
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] [Neutron] A big tent home for Neutron backend code

2015-04-23 Thread Doug Wiegley


 On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com wrote:
 
 On 04/23/2015 01:19 PM, Armando M. wrote:
 
 
 On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com wrote:
 
On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
 On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com 
 mailto:rbry...@redhat.com
 mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
On 04/22/2015 10:33 PM, Armando M. wrote:
 
Would it make sense to capture these projects as simply
'affiliated', ie. with a loose relationship to Neutron,
because
they use/integrate with Neutron in some form or
another (e.g.
having 3rd-party, extending-api,
integrating-via-plugin-model,
etc)? Then we could simply consider extending the
projects.yaml
to capture this new concept (for Neutron or any
other project)
once we defined its ontology.
 
Thoughts?
 
 
That seems interesting, but given the communities stated
goals
around Big Tent, it seems to me like affiliation or not,
adding
these under the Neutron tent, inside the larger
OpenStack Bigger
Tent, would be a good thing.
 
Thanks,
Kyle
 
 
 
 Thanks for clearing some of the questions I raised. I should
stress the
 fact that I welcome the idea of finding a more sensible home
for these
 projects in light of the big tent developments, but it seems
like
we're
 still pouring down the foundations. I'd rather get us to a
point where
 the landscape is clear, and the dust settled. That would help us
make a
 more informed decision compared to the one we can make right
now.
 
Can you be a bit more specific about what's not clear and
would help
make you feel more informed?
 
 
 I am not clear on how we make a decision, as to which project
belongs or
 doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
 up calling it :)
 
OK, that's fine.  Figuring that out is the next step if folks agree with
Neutron as the home for networking-foo repos.  I'm happy to write up a
strawman proposal for inclusion criteria and a set of expectations
around responsibilities and communication.
 
 
 What about the other Neutron related ones that didn't strictly follow
 the networking- prefix in the name, would the naming convention be one
 of the criteria? I look forward to your proposal.
 
 Good question.  I think consistency is good, especially when there are
 so many of them.  It helps make it clear that they're all following some
 sort of pattern.  Luckily we do have a way to get repos renamed if needed.

There is one existing project, stackforge/octavia, which is quite active and 
has used its codename extensively. Suggested naming I’d be ok with, but 
enforced naming seems… confining.

Thanks,
doug


 
 -- 
 Russell Bryant
 
 __
 OpenStack Development Mailing 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] [Fuel] Plugin development docs - currently 404

2015-04-23 Thread Dmitry Borodaenko

Thanks for the correct link, Chris!

Indeed we are aware of this problem, here's the bug where it is tracked:
https://bugs.launchpad.net/fuel/+bug/1447025

On Thu, Apr 23, 2015 at 1:11 PM, Christopher Aedo ca...@mirantis.com wrote:
 On Thu, Apr 23, 2015 at 12:33 PM, Sean M. Collins s...@coreitpro.com wrote:
 The links for the developer documentation are currently broken.

 I would bet the docs team is sorting out the broken link as I type
 this, thanks for pointing it out!  In the mean time it looks like the
 docs on the wiki are up to date (or at least have been modified in the
 last few days, so there's activity)

 https://wiki.openstack.org/wiki/Fuel/Plugins

 -Christopher

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



-- 
Dmitry Borodaenko

__
OpenStack Development Mailing 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] eventlet 0.17.3 is now fully Python 3 compatible

2015-04-23 Thread Joshua Harlow


Victor Stinner wrote:

Also, on the Python 3 topic, there's still a big issue with memcached
(aka: python-memcache).


Oh, thanks Thomas for the reminder. I just sent a pull request to port 
python-memcached to Python 3:

https://github.com/linsomniac/python-memcached/pull/67

I don't understand. I saw a lot of Port to Python 3 fixes merged in 2014, and 
these changes are now part of the release 1.54. Problem: running python-memcached tests 
with tox fail on obvious Python 3 errors. Anyway, all tests now pass with my pull 
request. The good news is that python-memcached looks to be actively developed.


Julien Danjou ported pymemcache to Python 3, another memcached client. He 
suggests to use this one instead of python-memcached client.


Yes please to using pymemcache (I'm also an active contributor[1] there, 
so feel free to ask me questions to...), although what else in openstack 
uses it? From my current understand the nova usage of it is suboptimal 
(may not even be fully working/functional) due to: 
https://review.openstack.org/#/c/138607/ which has exposed some 
interesting details...


[1] https://github.com/pinterest/pymemcache/graphs/contributors





It's blocking me from adding Python3 support to
keystoneclient, and as a consequence, to almost all of OpenStack.


python-keystoneclient announces a full Python 3 support with a voting Python 3 gate. I 
just checked locally, tox -e py34 pass.

The problem is that python-memcached miss in test dependencies and so 
middleware tests using memcache are never run!

Victor

__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

On 04/23/2015 03:23 PM, Kyle Mestery wrote:
 On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley
 doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote:
 
 
  On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com wrote:
 
  On 04/23/2015 01:19 PM, Armando M. wrote:
 
 
  On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com
  mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
 On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
  On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com mailto:rbry...@redhat.com
 mailto:rbry...@redhat.com
  mailto:rbry...@redhat.com mailto:rbry...@redhat.com
 mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
 On 04/22/2015 10:33 PM, Armando M. wrote:
 
 Would it make sense to capture these projects as simply
 'affiliated', ie. with a loose relationship to Neutron,
 because
 they use/integrate with Neutron in some form or
 another (e.g.
 having 3rd-party, extending-api,
 integrating-via-plugin-model,
 etc)? Then we could simply consider extending the
 projects.yaml
 to capture this new concept (for Neutron or any
 other project)
 once we defined its ontology.
 
 Thoughts?
 
 
 That seems interesting, but given the communities stated
 goals
 around Big Tent, it seems to me like affiliation or not,
 adding
 these under the Neutron tent, inside the larger
 OpenStack Bigger
 Tent, would be a good thing.
 
 Thanks,
 Kyle
 
 
 
  Thanks for clearing some of the questions I raised. I should
 stress the
  fact that I welcome the idea of finding a more sensible home
 for these
  projects in light of the big tent developments, but it seems
 like
 we're
  still pouring down the foundations. I'd rather get us to a
 point where
  the landscape is clear, and the dust settled. That would help us
 make a
  more informed decision compared to the one we can make right
 now.
 
 Can you be a bit more specific about what's not clear and
 would help
 make you feel more informed?
 
 
  I am not clear on how we make a decision, as to which project
 belongs or
  doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however
 we end
  up calling it :)
 
 OK, that's fine.  Figuring that out is the next step if folks
 agree with
 Neutron as the home for networking-foo repos.  I'm happy to
 write up a
 strawman proposal for inclusion criteria and a set of expectations
 around responsibilities and communication.
 
 
  What about the other Neutron related ones that didn't strictly follow
  the networking- prefix in the name, would the naming convention
 be one
  of the criteria? I look forward to your proposal.
 
  Good question.  I think consistency is good, especially when there are
  so many of them.  It helps make it clear that they're all
 following some
  sort of pattern.  Luckily we do have a way to get repos renamed if
 needed.
 
 There is one existing project, stackforge/octavia, which is quite
 active and has used its codename extensively. Suggested naming I’d
 be ok with, but enforced naming seems… confining.

To be honest, I really don't care about the names.  All it takes is some
pretty easy docs to help people figure out what things are and where
they live.  Making it a recommendation is fine with me.

 
 If we've reached the point where we're arguing about naming, dos this
 mean we've built consensus on the yes, it makes sense for these to live
 under Neutron argument?

Ha.  I figured I'd give it at least another day before stirring up more
debate with a proposal around criteria / responsibilities / expectations.

-- 
Russell Bryant

__
OpenStack Development Mailing 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] Plugin development docs - currently 404

2015-04-23 Thread Christopher Aedo

On Thu, Apr 23, 2015 at 12:33 PM, Sean M. Collins s...@coreitpro.com wrote:
 The links for the developer documentation are currently broken.

I would bet the docs team is sorting out the broken link as I type
this, thanks for pointing it out!  In the mean time it looks like the
docs on the wiki are up to date (or at least have been modified in the
last few days, so there's activity)

https://wiki.openstack.org/wiki/Fuel/Plugins

-Christopher

__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

2015-04-23 Thread Doug Wiegley


 On Apr 23, 2015, at 1:42 PM, Russell Bryant rbry...@redhat.com wrote:
 
 On 04/23/2015 03:23 PM, Kyle Mestery wrote:
 On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley
 doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote:
 
 
 On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
 
 On 04/23/2015 01:19 PM, Armando M. wrote:
 
 
 On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com
 mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
   On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
 On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com mailto:rbry...@redhat.com
mailto:rbry...@redhat.com
 mailto:rbry...@redhat.com mailto:rbry...@redhat.com
mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
   On 04/22/2015 10:33 PM, Armando M. wrote:
 
   Would it make sense to capture these projects as simply
   'affiliated', ie. with a loose relationship to Neutron,
   because
   they use/integrate with Neutron in some form or
   another (e.g.
   having 3rd-party, extending-api,
   integrating-via-plugin-model,
   etc)? Then we could simply consider extending the
   projects.yaml
   to capture this new concept (for Neutron or any
   other project)
   once we defined its ontology.
 
   Thoughts?
 
 
   That seems interesting, but given the communities stated
   goals
   around Big Tent, it seems to me like affiliation or not,
   adding
   these under the Neutron tent, inside the larger
   OpenStack Bigger
   Tent, would be a good thing.
 
   Thanks,
   Kyle
 
 
 
 Thanks for clearing some of the questions I raised. I should
   stress the
 fact that I welcome the idea of finding a more sensible home
   for these
 projects in light of the big tent developments, but it seems
   like
   we're
 still pouring down the foundations. I'd rather get us to a
   point where
 the landscape is clear, and the dust settled. That would help us
   make a
 more informed decision compared to the one we can make right
   now.
 
   Can you be a bit more specific about what's not clear and
   would help
   make you feel more informed?
 
 
 I am not clear on how we make a decision, as to which project
   belongs or
 doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however
we end
 up calling it :)
 
   OK, that's fine.  Figuring that out is the next step if folks
agree with
   Neutron as the home for networking-foo repos.  I'm happy to
write up a
   strawman proposal for inclusion criteria and a set of expectations
   around responsibilities and communication.
 
 
 What about the other Neutron related ones that didn't strictly follow
 the networking- prefix in the name, would the naming convention
be one
 of the criteria? I look forward to your proposal.
 
 Good question.  I think consistency is good, especially when there are
 so many of them.  It helps make it clear that they're all
following some
 sort of pattern.  Luckily we do have a way to get repos renamed if
needed.
 
There is one existing project, stackforge/octavia, which is quite
active and has used its codename extensively. Suggested naming I’d
be ok with, but enforced naming seems… confining.
 
 To be honest, I really don't care about the names.  All it takes is some
 pretty easy docs to help people figure out what things are and where
 they live.  Making it a recommendation is fine with me.
 
 
 If we've reached the point where we're arguing about naming, dos this
 mean we've built consensus on the yes, it makes sense for these to live
 under Neutron argument?
 
 Ha.  I figured I'd give it at least another day before stirring up more
 debate with a proposal around criteria / responsibilities / expectations.

Quick, someone invoke Godwin’s law, and then let’s ship this thing.

doug


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


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

[openstack-dev] [Ironic] Kilo RC2 available

Hello everyone,

Due to release-critical issues spotted in Ironic during RC1 testing, a
new release candidate was created for Kilo. The list of RC2 fixes, as
well as the RC2 tarball are available at:

https://launchpad.net/ironic/kilo/kilo-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, this tarball will be formally released as the final
Kilo versions on April 30. You are therefore strongly encouraged to
test and validate this tarball !

Alternatively, you can directly test the stable/kilo branch at:
https://github.com/openstack/ironic/tree/stable/kilo

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/ironic/+filebug

and tag it *kilo-rc-potential* to bring it to the release crew's attention.

Thanks!

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

2015-04-23 Thread Salvatore Orlando

Doug, HMS Octavia was a British mine sweeper that served during WW2
figthing German warships and u-boats somewhere in the sea.
I therefore believe if you have anything against this name you are secretly
a nazi.

Does that work for the Godwin's law call?

Salvatore

On 23 April 2015 at 22:09, Doug Wiegley doug...@parksidesoftware.com
wrote:


  On Apr 23, 2015, at 1:42 PM, Russell Bryant rbry...@redhat.com wrote:
 
  On 04/23/2015 03:23 PM, Kyle Mestery wrote:
  On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley
  doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com
 wrote:
 
 
  On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com wrote:
 
  On 04/23/2015 01:19 PM, Armando M. wrote:
 
 
  On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com
  mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
  On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com mailto:rbry...@redhat.com
 mailto:rbry...@redhat.com
  mailto:rbry...@redhat.com mailto:rbry...@redhat.com
 mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
On 04/22/2015 10:33 PM, Armando M. wrote:
 
Would it make sense to capture these projects as simply
'affiliated', ie. with a loose relationship to Neutron,
because
they use/integrate with Neutron in some form or
another (e.g.
having 3rd-party, extending-api,
integrating-via-plugin-model,
etc)? Then we could simply consider extending the
projects.yaml
to capture this new concept (for Neutron or any
other project)
once we defined its ontology.
 
Thoughts?
 
 
That seems interesting, but given the communities stated
goals
around Big Tent, it seems to me like affiliation or not,
adding
these under the Neutron tent, inside the larger
OpenStack Bigger
Tent, would be a good thing.
 
Thanks,
Kyle
 
 
 
  Thanks for clearing some of the questions I raised. I should
stress the
  fact that I welcome the idea of finding a more sensible home
for these
  projects in light of the big tent developments, but it seems
like
we're
  still pouring down the foundations. I'd rather get us to a
point where
  the landscape is clear, and the dust settled. That would help us
make a
  more informed decision compared to the one we can make right
now.
 
Can you be a bit more specific about what's not clear and
would help
make you feel more informed?
 
 
  I am not clear on how we make a decision, as to which project
belongs or
  doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however
 we end
  up calling it :)
 
OK, that's fine.  Figuring that out is the next step if folks
 agree with
Neutron as the home for networking-foo repos.  I'm happy to
 write up a
strawman proposal for inclusion criteria and a set of expectations
around responsibilities and communication.
 
 
  What about the other Neutron related ones that didn't strictly follow
  the networking- prefix in the name, would the naming convention
 be one
  of the criteria? I look forward to your proposal.
 
  Good question.  I think consistency is good, especially when there are
  so many of them.  It helps make it clear that they're all
 following some
  sort of pattern.  Luckily we do have a way to get repos renamed if
 needed.
 
 There is one existing project, stackforge/octavia, which is quite
 active and has used its codename extensively. Suggested naming I’d
 be ok with, but enforced naming seems… confining.
 
  To be honest, I really don't care about the names.  All it takes is some
  pretty easy docs to help people figure out what things are and where
  they live.  Making it a recommendation is fine with me.
 
 
  If we've reached the point where we're arguing about naming, dos this
  mean we've built consensus on the yes, it makes sense for these to live
  under Neutron argument?
 
  Ha.  I figured I'd give it at least another day before stirring up more
  debate with a proposal around criteria / responsibilities / expectations.

 Quick, someone invoke Godwin’s law, and then let’s ship this thing.

 doug


 
  --
  Russell Bryant
 
 
 __
  OpenStack Development Mailing 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] [Neutron][Keystone] Kilo RC2 available

Hello everyone,

Due to release-critical issues spotted in Neutron and Keystone during
RC1 testing, new release candidates were created for Kilo. The list of
RC2 fixes, as well as RC2 tarballs are available at:

https://launchpad.net/neutron/kilo/kilo-rc2
https://launchpad.net/keystone/sahara/kilo-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, these tarballs will be formally released as the final
Kilo versions on April 30. You are therefore strongly encouraged to
test and validate these tarballs !

Alternatively, you can directly test the stable/kilo branches at:
https://github.com/openstack/neutron/tree/stable/kilo
https://github.com/openstack/keystone/tree/stable/kilo

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/neutron/+filebug
https://bugs.launchpad.net/keystone/+filebug

and tag it *kilo-rc-potential* to bring it to the release crew's attention.

Thanks!

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

2015-04-23 Thread Joe Gordon

On Thu, Apr 23, 2015 at 12:10 AM, Victor Stinner vstin...@redhat.com
wrote:

 Hi,

  How invasive would the port to python3 be?

 I squashed all my commits into a single commit of my draft port and I
 pushed it at:

 https://github.com/haypo/nova/commit/bad54bc2b278c7c7cb7fa6cc73d03c70138bd89d


I like how the sha1 starts with 'bad'

Overall that is a pretty small patch.



 As announced, changes are boring, just obvious Python2/Python3 issues:

 - strip L from long integer literals: 123L = 123
 - replace dict.iteritems() with six.iteritems(dict)
 - replace list.sort(cmp_func) with list.sort(key=key_func)
 - replace raise exc_info[0], exc_info[1], exc_info[2] with
 six.reraise(*exc_info)
 - moved functions / modules

   * get http.client, urllib.request and other stdlib modules from
 six.moves since they moved between Python 2 and Python 3
   * get itertools.izip/zip_longest from six.moves
   * replace unichr() with six.unichr()

 - replace filter(func, data) with [item for item in data if func(item)]
 - replace unicode() with six.text_type
 - replace (int, long) with six.integer_types
 - replace file() with open()
 - replace StringIO() with six.StringIO()

 These changes are not enough to port nova to Python 3. But they are
 required to be able to find next Python 3 bugs.

 Reminder: Python 2 compatibility is kept! There is not reason right now to
 drop Python 2 support, it would be a pain to upgrade!


  Would it be easier to have a python3 migration sprint and rip the band
 aid off instead of dragging it out and having partial python3 support for a
 whole cycle?

 Do you mean a physical meeting? Or focus on Python 3 during a short period
 (review/merge all Python 3 patches)?


Focus on Python 3 during a short period.


 A single week may not be enough to fix all Python 3 issues. I prefer to
 submit changes smoothly during the Liberty cycle.



My general concern, is having to manually review new code for python3
compliance.

If this will take more then a week or two to make a big project python3
compat (during a virtual sprint), it would be good to have some tooling in
place to make sure we don't add a lot more burden on reviewers to make sure
new patches are python3 compatible by hand.

 In general what is the least painful way to add python3 support for a
 very large python project?

 Send patches and make incremental changes, as any other change made in
 OpenStack.

 Victor

 __
 OpenStack Development Mailing 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] A big tent home for Neutron backend code

2015-04-23 Thread Kyle Mestery

On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley doug...@parksidesoftware.com
wrote:


  On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com wrote:
 
  On 04/23/2015 01:19 PM, Armando M. wrote:
 
 
  On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com
  mailto:rbry...@redhat.com wrote:
 
 On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
  On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto:
 rbry...@redhat.com
  mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote:
 
 On 04/22/2015 10:33 PM, Armando M. wrote:
 
 Would it make sense to capture these projects as simply
 'affiliated', ie. with a loose relationship to Neutron,
 because
 they use/integrate with Neutron in some form or
 another (e.g.
 having 3rd-party, extending-api,
 integrating-via-plugin-model,
 etc)? Then we could simply consider extending the
 projects.yaml
 to capture this new concept (for Neutron or any
 other project)
 once we defined its ontology.
 
 Thoughts?
 
 
 That seems interesting, but given the communities stated
 goals
 around Big Tent, it seems to me like affiliation or not,
 adding
 these under the Neutron tent, inside the larger
 OpenStack Bigger
 Tent, would be a good thing.
 
 Thanks,
 Kyle
 
 
 
  Thanks for clearing some of the questions I raised. I should
 stress the
  fact that I welcome the idea of finding a more sensible home
 for these
  projects in light of the big tent developments, but it seems
 like
 we're
  still pouring down the foundations. I'd rather get us to a
 point where
  the landscape is clear, and the dust settled. That would help us
 make a
  more informed decision compared to the one we can make right
 now.
 
 Can you be a bit more specific about what's not clear and
 would help
 make you feel more informed?
 
 
  I am not clear on how we make a decision, as to which project
 belongs or
  doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
  up calling it :)
 
 OK, that's fine.  Figuring that out is the next step if folks agree
 with
 Neutron as the home for networking-foo repos.  I'm happy to write up
 a
 strawman proposal for inclusion criteria and a set of expectations
 around responsibilities and communication.
 
 
  What about the other Neutron related ones that didn't strictly follow
  the networking- prefix in the name, would the naming convention be one
  of the criteria? I look forward to your proposal.
 
  Good question.  I think consistency is good, especially when there are
  so many of them.  It helps make it clear that they're all following some
  sort of pattern.  Luckily we do have a way to get repos renamed if
 needed.

 There is one existing project, stackforge/octavia, which is quite active
 and has used its codename extensively. Suggested naming I’d be ok with, but
 enforced naming seems… confining.

 Thanks,
 doug



If we've reached the point where we're arguing about naming, dos this mean
we've built consensus on the yes, it makes sense for these to live under
Neutron argument?

Thanks,
Kyle


 
  --
  Russell Bryant
 
 
 __
  OpenStack Development Mailing 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] [Fuel] Plugin development docs - currently 404

2015-04-23 Thread Sean M. Collins

The links for the developer documentation are currently broken.

https://software.mirantis.com/mirantis-openstack-fuel-plug-in-development/

Links to:

http://docs.mirantis.com/openstack/fuel/fuel-6.0/plugin-dev.html#developing-a-plug-in-for-fuel

Where can I find the documentation?

-- 
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] [Neutron] A big tent home for Neutron backend code

2015-04-23 Thread Joshua Harlow


Russell Bryant wrote:

On 04/23/2015 03:23 PM, Kyle Mestery wrote:

On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com  wrote:


   On Apr 23, 2015, at 11:57 AM, Russell Bryantrbry...@redhat.com
 mailto:rbry...@redhat.com  wrote:
 
   On 04/23/2015 01:19 PM, Armando M. wrote:
 
 
   On 23 April 2015 at 09:58, Russell Bryantrbry...@redhat.com
 mailto:rbry...@redhat.com
   mailto:rbry...@redhat.commailto:rbry...@redhat.com  wrote:
 
  On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
   On 23 April 2015 at 07:32, Russell Bryantrbry...@redhat.com
 mailto:rbry...@redhat.com  mailto:rbry...@redhat.com
 mailto:rbry...@redhat.com
   mailto:rbry...@redhat.commailto:rbry...@redhat.com
 mailto:rbry...@redhat.commailto:rbry...@redhat.com  wrote:
 
  On 04/22/2015 10:33 PM, Armando M. wrote:
 
  Would it make sense to capture these projects as simply
  'affiliated', ie. with a loose relationship to Neutron,
  because
  they use/integrate with Neutron in some form or
  another (e.g.
  having 3rd-party, extending-api,
  integrating-via-plugin-model,
  etc)? Then we could simply consider extending the
  projects.yaml
  to capture this new concept (for Neutron or any
  other project)
  once we defined its ontology.
 
  Thoughts?
 
 
  That seems interesting, but given the communities stated
  goals
  around Big Tent, it seems to me like affiliation or not,
  adding
  these under the Neutron tent, inside the larger
  OpenStack Bigger
  Tent, would be a good thing.
 
  Thanks,
  Kyle
 
 
 
   Thanks for clearing some of the questions I raised. I should
  stress the
   fact that I welcome the idea of finding a more sensible home
  for these
   projects in light of the big tent developments, but it seems
  like
  we're
   still pouring down the foundations. I'd rather get us to a
  point where
   the landscape is clear, and the dust settled. That would help us
  make a
   more informed decision compared to the one we can make right
  now.
 
  Can you be a bit more specific about what's not clear and
  would help
  make you feel more informed?
 
 
   I am not clear on how we make a decision, as to which project
  belongs or
   doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however
 we end
   up calling it :)
 
  OK, that's fine.  Figuring that out is the next step if folks
 agree with
  Neutron as the home for networking-foo repos.  I'm happy to
 write up a
  strawman proposal for inclusion criteria and a set of expectations
  around responsibilities and communication.
 
 
   What about the other Neutron related ones that didn't strictly follow
   the networking- prefix in the name, would the naming convention
 be one
   of the criteria? I look forward to your proposal.
 
   Good question.  I think consistency is good, especially when there are
   so many of them.  It helps make it clear that they're all
 following some
   sort of pattern.  Luckily we do have a way to get repos renamed if
 needed.

 There is one existing project, stackforge/octavia, which is quite
 active and has used its codename extensively. Suggested naming I’d
 be ok with, but enforced naming seems… confining.


To be honest, I really don't care about the names.  All it takes is some
pretty easy docs to help people figure out what things are and where
they live.  Making it a recommendation is fine with me.


Maybe about time we make something like:

http://projects.apache.org/indexes/category.html

And link names to repos there...?




If we've reached the point where we're arguing about naming, dos this
mean we've built consensus on the yes, it makes sense for these to live
under Neutron argument?


Ha.  I figured I'd give it at least another day before stirring up more
debate with a proposal around criteria / responsibilities / expectations.



__
OpenStack Development Mailing 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]Devstack live migration.

2015-04-23 Thread kk bk

I am trying to execute a live migration of a VM from node-1 to node-2. As i
drill thro' the code it ends up calling function migrate_server of
nova/nova/conductor/rpcapi.py

This migrate_server ends up calling

cctxt.call(context, 'migrate_server', **kw)

I am trying to understand, what this call leads up to. Any pointers would
be helpful

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] Barbican : Dependency of pyenv configuration in Barbican.sh script

2015-04-23 Thread Asha Seshagiri

Hi All ,

Would need help!

I tried executing the script present in the link
https://github.com/openstack/barbican/blob/master/bin/barbican-api  to
start the barbican instance but  the use cases of barbican are failing.
Please find the details of the investigations :

Usecase for posting and retrieving the secret.

[root@barbican-keystone2 ~]# curl -X POST -H
'content-type:application/json' -H 'X-Project-Id:12345' -d '{payload:
my-secret-here, payload_content_type: text/plain}'
http://localhost:9311/v1/secrets
{code: 406, description: null, title: Not
Acceptable}[root@barbican-keystone2 ~]#

[root@barbican-keystone2 ~]# curl -H 'Accept: application/json' -H
'X-Project-Id:12345' http://localhost:9311/v1/secrets
{code: 406, description: null, title: Not
Acceptable}[root@barbican-keystone2 ~]#
[root@barbican-keystone2 ~]#

[root@barbican-keystone2 ~]#  curl -X POST -H
'content-type:application/json' -H 'X-Project-Id:12345' -d '{payload:
my-secret-here, payload_content_type: text/plain}'
http://127.0.0.1:9311/v1/secrets
{code: 406, description: null, title: Not
Acceptable}[root@barbican-keystone2 ~]#

The output of the ps command when the barbican instance is stood up using
the python script as pointed in the above link
We do not see the instance of uwsgi in the response:

[root@barbican-keystone2 ~]# ps -ef | grep barbican
avahi 2920 1  0 Apr22 ?00:00:00 avahi-daemon: running
[barbican-keystone2.local]
root 14743 14554  2 14:54 pts/100:00:01 python bin/barbican-api
root 14781 13975  0 14:55 pts/000:00:00 grep --color=auto barbican

The output of the ps command when the barbican instance is stood up using
the barbican.sh script
[root@barbican-keystone2 ~]# ps -ef | grep barbican
avahi 2920 1  0 Apr22 ?00:00:00 avahi-daemon: running
[barbican- keystone2.local]
root 14577 14554  0 14:50 pts/100:00:00 /bin/bash bin/barbican.sh
start





*root 14582 14577  0 14:50 pts/100:00:00 uwsgi --master --emperor
/etc/barbican/vassals root 14583 14582  0 14:50 pts/100:00:00 uwsgi
--master --emperor /etc/barbican/vassals root 14584 14583  0 14:50
pts/100:00:00 /usr/bin/uwsgi --ini barbican-admin.ini root 14585
14583  0 14:50 pts/100:00:00 /usr/bin/uwsgi --ini barbican-api.ini
root 14586 14584 10 14:50 pts/100:00:01 /usr/bin/uwsgi --ini
barbican-admin.ini root 14587 14585 12 14:50 pts/100:00:01
/usr/bin/uwsgi --ini barbican-api.ini*
root 14601 13975  0 14:50 pts/000:00:00 grep --color=auto barbican

The barbican instance needs to be started on top of uswgi server instance
since uwsgi is the webserver which serves the request for barbican
services. The script does not start the uwsgi server

Please correct me if I am wrong.
Any help would be highly appreciated.

Thanks and Regards,
Asha Seshagiri

On Thu, Apr 23, 2015 at 11:27 AM, Asha Seshagiri asha.seshag...@gmail.com
wrote:

 Hi All,

 Thanks Adam for your response.
 I am able to run the barbican-api script without SQLLite installation .I
 guess SQLLite comes configured with barbican installation .Please correct
 me if I am wrong.

 [root@barbican-keystone2 barbican]# bin/barbican-api
 2015-04-23 11:12:31.571 8265 INFO barbican.model.repositories [-] Setting
 up database engine and session factory
 2015-04-23 11:12:31.640 8265 INFO barbican.model.repositories [-] Updating
 schema to latest version
 2015-04-23 11:12:31.640 8265 WARNING barbican.model.migration.commands [-]
 !!! Limited support for migration commands using sqlite databases; This
 operation may not succeed.
 2015-04-23 11:12:31.643 8265 INFO alembic.migration [-] Context impl
 SQLiteImpl.
 2015-04-23 11:12:31.644 8265 INFO alembic.migration [-] Will assume
 non-transactional DDL.
 serving on http://127.0.0.1:9311

 I would like to get confirmation from the team that barbican-api would be
 used only to standup the barbican instance , for installation of barbican
 ,debugging and stoping the barbican instance , we still need to use
 barbican.sh script .

 Any help would highly be appreciated.

 Thanks and Regards,
 Asha Seshagiri


 On Thu, Apr 23, 2015 at 10:28 AM, Adam Harwell adam.harw...@rackspace.com
  wrote:

   Do you have sqlite installed on your system, and do you have config.py
 in the root of your barbican directory? The database is configured there
 (assuming it hasn’t changed since I last ran Barbican locally), and mine
 looks like this:

  config = {
 'sqlalchemy': {
 'url': 'sqlite:tmp/barbican.db',
 'echo': True,
 'echo_pool': False,
 'pool_recycle': 3600,
 'encoding': 'utf-8'
 }
 }

   --Adam

  https://keybase.io/rm_you


   From: neetu jain nut...@gmail.com
 Date: Thursday, April 23, 2015 at 10:07 AM
 To: Asha Seshagiri asha.seshag...@gmail.com
 Cc: John Wood john.w...@rackspace.com, openstack-dev 
 openstack-dev@lists.openstack.org, Reller, Nathan S. 
 nathan.rel...@jhuapl.edu, Douglas Mendizabal

Re: [openstack-dev] [ec2-api] EC2-API release 0.1.0 available

2015-04-23 Thread Michael Still

Excellent, and well done!

I think it would be a good idea to send this announcement to the
openstack-operators list as well, as some ops people might not notice
it here.

Cheers,
Michael

On Thu, Apr 23, 2015 at 10:33 PM, Alexandre Levine
alev...@cloudscaling.com wrote:
 Hello everyone,

 We've decided to cut our first release of the standalone EC2-API project.
 All of the known to us major problems are solved - NovaDB direct access is
 cut off, performance is checked and improved, all of the necessary
 functional, unit and Rally tests are in place.
 One known caveat is that nova API version required is 2.3 (microversion).
 Unfortunately the python-novaclient supporting microversions is not released
 yet. So several instance properties won't be reported if requested with
 version 2.1.

 The 0.1.0 tarball is available for download at:

 https://launchpad.net/ec2-api/trunk/0.1.0

 pip can be used to install PyPI package.

 Installation in devstack is also possible. The following line should be
 added to local.conf or localrc for this:

 enable_plugin ec2-api https://github.com/stackforge/ec2-api

 Current README can be accessed on stackforge:

 https://github.com/stackforge/ec2-api

 Please report bags to launchpad:

 https://bugs.launchpad.net/ec2-api/+filebug

 Best regards,
   Alex Levine


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




-- 
Rackspace 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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

2015-04-23 Thread Jeremy Stanley

On 2015-04-23 12:45:14 -0700 (-0700), Joshua Harlow wrote:
 Maybe about time we make something like:
 
 http://projects.apache.org/indexes/category.html
 
 And link names to repos there...?

http://governance.openstack.org/reference/projects/ is sort of our
analogue there, I think. It's not exact, but each project subpage
lists and links to the various Git repositories it encompasses along
with descriptive tag metadata (and growing richer every week).
-- 
Jeremy Stanley

__
OpenStack Development Mailing 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] eventlet 0.17.3 is now fully Python 3 compatible

2015-04-23 Thread Thomas Goirand




On 04/23/2015 04:24 PM, Victor Stinner wrote:

Also, on the Python 3 topic, there's still a big issue with memcached
(aka: python-memcache).


Oh, thanks Thomas for the reminder. I just sent a pull request to port 
python-memcached to Python 3:

https://github.com/linsomniac/python-memcached/pull/67


Cool! I'll try it, apply the patch to the version 1.54, and upload to 
Debian, if this works well.



I don't understand. I saw a lot of Port to Python 3 fixes merged in 2014, and 
these changes are now part of the release 1.54. Problem: running python-memcached tests 
with tox fail on obvious Python 3 errors. Anyway, all tests now pass with my pull 
request. The good news is that python-memcached looks to be actively developed.


Julien Danjou ported pymemcache to Python 3, another memcached client. He 
suggests to use this one instead of python-memcached client.


pymemcache is much better in many ways, and switching to it shouldn't be 
motivated only because of Python 3 compat.






It's blocking me from adding Python3 support to
keystoneclient, and as a consequence, to almost all of OpenStack.


python-keystoneclient announces a full Python 3 support with a voting Python 3 gate. I 
just checked locally, tox -e py34 pass.

The problem is that python-memcached miss in test dependencies and so 
middleware tests using memcache are never run!

Victor


Yeah, memcached (aka: python-memcache in Debian) is said to be 
optional, but in reality, we really need it for the full Python 3 
compatibility, otherwise that's bullshit (unless we're giving up on 
using memcache completely?).


Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] [oslo] summit session scheduling

2015-04-23 Thread Doug Hellmann

We need to start figuring out the schedule for summit sessions.
Dims has taken a look through the proposed topics and made some
recommendations, and I have expanded on that with a proposed breakdown
of sessions by room type (fishbowl and working).

All of the results are at the bottom of
https://etherpad.openstack.org/p/liberty-oslo-summit-planning

Please give them a look, and leave comments.

Note that the order is not really important at this point, and we'll
need to decide on the actual schedule once we have all of the slots
filled.

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] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

2015-04-23 Thread Brant Knudson

On Thu, Apr 23, 2015 at 4:41 AM, Thomas Goirand z...@debian.org wrote:

On 04/10/2015 09:41 AM, Thierry Carrez wrote:

Victor Stinner wrote:

I fixed 4 issues with monkey-patching in Python 3 (importlib, os.open(),
threading.RLock, threading.Thread). Good news: the just released eventlet
0.17.3 includes these fixes and it is now fully compatible with Python 3!
For example, the Oslo Messaging test suite now pass with this eventlet
version! Currently, eventlet is disabled in Oslo Messaging on Python 3
(eventlet tests are skipped).

Great news ! That makes the port to Python 3 question independent of
the Moving off eventlet question, which should facilitate immediate
progress on the former.

On the latter, do you plan to file a Concurrency models cross-project
session ? That sounds like a good topic to discuss face to face...

See
http://lists.openstack.org/pipermail/openstack-dev/2015-April/061070.html
for
details on how to file there.

Also, on the Python 3 topic, there's still a big issue with memcached
(aka: python-memcache). It's blocking me from adding Python3 support to
keystoneclient, and as a consequence, to almost all of OpenStack.

BTW, the Eventlet module for 0.17.3 is available from here:

http://kilo-jessie.pkgs.mirantis.com/debian/pool/jessie-kilo-backports-nochange/main/p/python-eventlet/

and I will upload this to Experimental as soon as Jessie is released
(that's in 3 days now...).

Cheers,

Thomas Goirand (zigo)

The part of keystoneclient that uses the memcached client was deprecated in
Juno (as it was moved to the keystonemiddleware repo), so I think we can
remove it now. You might want to patch it out of your keystoneclient
package if you know everything's using the auth_token middleware from
keystonemiddleware.

- Brant

__
OpenStack Development Mailing 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] Barbican : Dependency of pyenv configuration in Barbican.sh script

2015-04-23 Thread Asha Seshagiri

Thanks a lot Douglas for your response.
Explanation is great ! I appreciate for your time and efforts.

But Accept header is not required for posting the secret but is required
while geting the secret as per [1]
Accept header was  mentioned while retrieving the secret .

The same curl command works when we standup the barbican instance using
barbican.sh script

Please find the curl command and response below when barbican.sh script is
used to stand up an instance of barbican :

For Storing the secret :

[root@barbican-keystone2 ~]#  curl -X POST -H
'content-type:application/json' -H 'X-Project-Id:12345' -d '{payload:
my-secret-here, payload_content_type: text/plain}'
http://localhost:9311/v1/secrets
{secret_ref: 
http://localhost:9311/v1/secrets/cf1e41ba-a50e-4fda-87aa-05d967e23559
}[root@barbican-keystone2 ~]#

For Retrieving the secret :

[root@barbican-keystone2 ~]# curl -H 'Accept: application/json' -H
'X-Project-Id:12345' http://localhost:9311/v1/secrets
{secrets: [{status: ACTIVE, secret_type: opaque, updated:
2015-04-23T19:53:56.766523, name: null, algorithm: null, created:
2015-04-23T19:53:56.759230, secret_ref: 
http://localhost:9311/v1/secrets/8e373140-8388-4d44-a4ee-4093b9c5f477;,
content_types: {default: text/plain}, creator_id: null, mode:
null, bit_length: null, expiration: null}, {status: ACTIVE,
secret_type: opaque, updated: 2015-04-23T22:34:53.642004, name:
null, algorithm: null, created: 2015-04-23T22:34:53.635745,
secret_ref: 
http://localhost:9311/v1/secrets/cf1e41ba-a50e-4fda-87aa-05d967e23559;,
content_types: {default: text/plain}, creator_id: null, mode:
null, bit_length: null, expiration: null}], total:
2}[root@barbican-keystone2 ~]#

[1] :https://github.com/cloudkeep/barbican/wiki/Barbican-Quick-Start-Guide

It would be great if you could please elaborate the syntax.
Looking forward for your response.

Thanks and Regards,
Asha Seshagiri

On Thu, Apr 23, 2015 at 4:42 PM, Douglas Mendizabal 
douglas.mendiza...@rackspace.com wrote:

  Hi Asha,

  I hope I can clear up some of your confusion about the Barbican server.
 Barbican is a standard WSGI application. [1]  The WSGI application object
 is created by the create_main_app function in barbican.api.app [2].  WSGI
 should not be confused with uWSGI [3], which is a web server that can serve
 WSGI applications.

  There are many ways to deploy a WSGI application.  You could use apache
 with mod_wsgi [4],  or you could use gunicorn [5], or you could use
 paste.httpserver [6] as the barbican-api script does, or you could use
 uWSGI as the barbican.sh script does.  Whatever your choice of web server
 will not affect how Barbican works.

  The barbican-api script that runs Barbican using paste.httpserver is a
 very lightweight script to get Barbican running quickly in development
 environments without any additional requirements.  The barbican.sh script
 is a very opinionated script for setting up a development environment.
 Note that uwsgi and pyenv are not required by Barbican itself, only for the
 barbican.sh script.  Neither script is intended to be used for production
 deployments.

  The Barbican team currently defers all deployment decisions to the
 operator, so you will have to figure out which WSGI host is right for your
 deployment, and create your own deployment scripts.

  The reason you’re seeing 406 errors with your curl commands is because
 you’re not specifying an “Accept” header with your requests.  You should
 retry the curl commands with –H “Accept: application/json” and you should
 see the correct responses.

  Thanks,
 - Douglas Mendizabal

  [1] https://www.python.org/dev/peps/pep-/
 [2]
 http://git.openstack.org/cgit/openstack/barbican/tree/barbican/api/app.py#n74
 [3] http://uwsgi-docs.readthedocs.org/en/latest/
 [4] https://code.google.com/p/modwsgi/
 [5] http://gunicorn.org/
 [6] http://pythonpaste.org/modules/httpserver.html

   From: Asha Seshagiri asha.seshag...@gmail.com
 Date: Thursday, April 23, 2015 at 4:17 PM
 To: Adam Harwell adam.harw...@rackspace.com
 Cc: neetu jain nut...@gmail.com, John Wood john.w...@rackspace.com,
 openstack-dev openstack-dev@lists.openstack.org, Reller, Nathan S. 
 nathan.rel...@jhuapl.edu, Douglas Mendizábal 
 douglas.mendiza...@rackspace.com, Paul Kehrer paul.keh...@rackspace.com,
 Alexis Lee alex...@hp.com

 Subject: Re: Barbican : Dependency of pyenv configuration in Barbican.sh
 script

   Hi All ,

  Would need help!

 I tried executing the script present in the link
 https://github.com/openstack/barbican/blob/master/bin/barbican-api  to
 start the barbican instance but  the use cases of barbican are failing.
 Please find the details of the investigations :

 Usecase for posting and retrieving the secret.

 [root@barbican-keystone2 ~]# curl -X POST -H
 'content-type:application/json' -H 'X-Project-Id:12345' -d '{payload:
 my-secret-here, payload_content_type: text/plain}'
 http://localhost:9311/v1/secrets
 {code: 406, description: null, title: Not

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

2015-04-23 Thread Fei Long Wang



On 24/04/15 06:02, Richard Raseley wrote:
 Flavio Percoco wrote:
 I think getting operators to adopt it is key to getting other openstack
 projects to also adopt it. There is something of a chicken and the egg
 problem
 with the integration. Some of the projects you will want to integrate
 the most
 with are already considered pretty stable and may not want to rewrite
 working
 bits to target a service thats hard for ops to deploy. It makes their
 service
 hard to deploy too.

 Getting into RDO and Ubuntu will go a long way there. Getting into
 Packstack
 and other deployment tools even further.

 I don't fully agree with the above. The problem on waiting for
 operators to adopt it is that they might actually not have a reason to
 do it, which doesn't mean the project is useless. Each operator will
 decide what services they want to provide.

 The needs of operators are a reflection of the needs of their users.

 I don't want to use the word 'useless', because it has a clear
 negative connotation - and I don't think Zaqar is 'useless'. Let's
 instead discuss 'utility'.

 The utility of any solution or product is completely subjective, and
 solely based upon the underlying requirements. If real operators with
 real requirements do not view a particular solution as having utility
 for them - then it doesn't.

 You are correct in that there is a bit of a bootstrapping problem, but
 I strongly feel like the answer to that is continuing to listen to,
 and test against, the market (the architects and operators).

 Build a minimally viable product that (a) has clear messaging and use
 cases (b) is easy to deploy and configure and (c) doesn't demand deep
 integration into an existing cloud and operators will start deploying,
 testing, and providing feedback. This will create the right feedback
 cycle and help in validating (or completely demolishing) assumptions
 on what users actually need.

 With regard to '(b)' above, it doesn't appear that there any any
 Puppet modules to assist with the installation and configuration of
 Zaqar. If you're interested, let's chat in Vancouver to see if I can
 help in get a basic set out there.

Awesome, thank you for the support. I believe the puppet work is one of
our goals in Liberty, so please pop in #openstack-zaqar and let's have a
talk.
 Regards,

 Richard Raseley

 SysOps Engineer
 Puppet Labs

 __

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

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


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

Re: [openstack-dev] Barbican : Dependency of pyenv configuration in Barbican.sh script

2015-04-23 Thread Douglas Mendizabal

Hi Asha,

I hope I can clear up some of your confusion about the Barbican server.  
Barbican is a standard WSGI application. [1]  The WSGI application object is 
created by the create_main_app function in barbican.api.app [2].  WSGI should 
not be confused with uWSGI [3], which is a web server that can serve WSGI 
applications.

There are many ways to deploy a WSGI application.  You could use apache with 
mod_wsgi [4],  or you could use gunicorn [5], or you could use paste.httpserver 
[6] as the barbican-api script does, or you could use uWSGI as the barbican.sh 
script does.  Whatever your choice of web server will not affect how Barbican 
works.

The barbican-api script that runs Barbican using paste.httpserver is a very 
lightweight script to get Barbican running quickly in development environments 
without any additional requirements.  The barbican.sh script is a very 
opinionated script for setting up a development environment.  Note that uwsgi 
and pyenv are not required by Barbican itself, only for the barbican.sh script. 
 Neither script is intended to be used for production deployments.

The Barbican team currently defers all deployment decisions to the operator, so 
you will have to figure out which WSGI host is right for your deployment, and 
create your own deployment scripts.

The reason you’re seeing 406 errors with your curl commands is because you’re 
not specifying an “Accept” header with your requests.  You should retry the 
curl commands with –H “Accept: application/json” and you should see the correct 
responses.

Thanks,
- Douglas Mendizabal

[1] https://www.python.org/dev/peps/pep-/
[2] 
http://git.openstack.org/cgit/openstack/barbican/tree/barbican/api/app.py#n74
[3] http://uwsgi-docs.readthedocs.org/en/latest/
[4] https://code.google.com/p/modwsgi/
[5] http://gunicorn.org/
[6] http://pythonpaste.org/modules/httpserver.html

From: Asha Seshagiri asha.seshag...@gmail.commailto:asha.seshag...@gmail.com
Date: Thursday, April 23, 2015 at 4:17 PM
To: Adam Harwell adam.harw...@rackspace.commailto:adam.harw...@rackspace.com
Cc: neetu jain nut...@gmail.commailto:nut...@gmail.com, John Wood 
john.w...@rackspace.commailto:john.w...@rackspace.com, openstack-dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Reller, Nathan S. 
nathan.rel...@jhuapl.edumailto:nathan.rel...@jhuapl.edu, Douglas Mendizábal 
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com, 
Paul Kehrer paul.keh...@rackspace.commailto:paul.keh...@rackspace.com, 
Alexis Lee alex...@hp.commailto:alex...@hp.com
Subject: Re: Barbican : Dependency of pyenv configuration in Barbican.sh script

Hi All ,

Would need help!

I tried executing the script present in the link 
https://github.com/openstack/barbican/blob/master/bin/barbican-api  to  start 
the barbican instance but  the use cases of barbican are failing.
Please find the details of the investigations :

Usecase for posting and retrieving the secret.

[root@barbican-keystone2 ~]# curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id:12345' -d '{payload: my-secret-here, payload_content_type: 
text/plain}' http://localhost:9311/v1/secrets
{code: 406, description: null, title: Not 
Acceptable}[root@barbican-keystone2 ~]#

[root@barbican-keystone2 ~]# curl -H 'Accept: application/json' -H 
'X-Project-Id:12345' http://localhost:9311/v1/secrets
{code: 406, description: null, title: Not 
Acceptable}[root@barbican-keystone2 ~]#
[root@barbican-keystone2 ~]#

[root@barbican-keystone2 ~]#  curl -X POST -H 'content-type:application/json' 
-H 'X-Project-Id:12345' -d '{payload: my-secret-here, 
payload_content_type: text/plain}' http://127.0.0.1:9311/v1/secrets
{code: 406, description: null, title: Not 
Acceptable}[root@barbican-keystone2 ~]#

The output of the ps command when the barbican instance is stood up using the 
python script as pointed in the above link
We do not see the instance of uwsgi in the response:

[root@barbican-keystone2 ~]# ps -ef | grep barbican
avahi 2920 1  0 Apr22 ?00:00:00 avahi-daemon: running 
[barbican-keystone2.local]
root 14743 14554  2 14:54 pts/100:00:01 python bin/barbican-api
root 14781 13975  0 14:55 pts/000:00:00 grep --color=auto barbican

The output of the ps command when the barbican instance is stood up using the 
barbican.sh script
[root@barbican-keystone2 ~]# ps -ef | grep barbican
avahi 2920 1  0 Apr22 ?00:00:00 avahi-daemon: running 
[barbican- keystone2.local]
root 14577 14554  0 14:50 pts/100:00:00 /bin/bash bin/barbican.sh start
root 14582 14577  0 14:50 pts/100:00:00 uwsgi --master --emperor 
/etc/barbican/vassals
root 14583 14582  0 14:50 pts/100:00:00 uwsgi --master --emperor 
/etc/barbican/vassals
root 14584 14583  0 14:50 pts/100:00:00 /usr/bin/uwsgi --ini 
barbican-admin.ini
root 14585 14583  0 14:50 pts/100:00:00 /usr/bin/uwsgi --ini 
barbican-api.ini
root 14586 14584

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On 04/23/2015 12:14 PM, Armando M. wrote:
 
 
 On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com
 mailto:rbry...@redhat.com wrote:
 
 On 04/22/2015 10:33 PM, Armando M. wrote:
 
  Would it make sense to capture these projects as simply
  'affiliated', ie. with a loose relationship to Neutron,
 because
  they use/integrate with Neutron in some form or another (e.g.
  having 3rd-party, extending-api, integrating-via-plugin-model,
  etc)? Then we could simply consider extending the
 projects.yaml
  to capture this new concept (for Neutron or any other project)
  once we defined its ontology.
 
  Thoughts?
 
 
  That seems interesting, but given the communities stated goals
  around Big Tent, it seems to me like affiliation or not, adding
  these under the Neutron tent, inside the larger OpenStack Bigger
  Tent, would be a good thing.
 
  Thanks,
  Kyle
 
 
 
  Thanks for clearing some of the questions I raised. I should
 stress the
  fact that I welcome the idea of finding a more sensible home for these
  projects in light of the big tent developments, but it seems like
 we're
  still pouring down the foundations. I'd rather get us to a point where
  the landscape is clear, and the dust settled. That would help us
 make a
  more informed decision compared to the one we can make right now.
 
 Can you be a bit more specific about what's not clear and would help
 make you feel more informed?
 
 
 I am not clear on how we make a decision, as to which project belongs or
 doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
 up calling it :)

OK, that's fine.  Figuring that out is the next step if folks agree with
Neutron as the home for networking-foo repos.  I'm happy to write up a
strawman proposal for inclusion criteria and a set of expectations
around responsibilities and communication.

-- 
Russell Bryant

__
OpenStack Development Mailing 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] [Zaqar] Call for adoption (or exclusion?)

2015-04-23 Thread Richard Raseley


Flavio Percoco wrote:

I think getting operators to adopt it is key to getting other openstack
projects to also adopt it. There is something of a chicken and the egg
problem
with the integration. Some of the projects you will want to integrate
the most
with are already considered pretty stable and may not want to rewrite
working
bits to target a service thats hard for ops to deploy. It makes their
service
hard to deploy too.

Getting into RDO and Ubuntu will go a long way there. Getting into
Packstack
and other deployment tools even further.


I don't fully agree with the above. The problem on waiting for
operators to adopt it is that they might actually not have a reason to
do it, which doesn't mean the project is useless. Each operator will
decide what services they want to provide.


The needs of operators are a reflection of the needs of their users.

I don't want to use the word 'useless', because it has a clear negative 
connotation - and I don't think Zaqar is 'useless'. Let's instead 
discuss 'utility'.


The utility of any solution or product is completely subjective, and 
solely based upon the underlying requirements. If real operators with 
real requirements do not view a particular solution as having utility 
for them - then it doesn't.


You are correct in that there is a bit of a bootstrapping problem, but I 
strongly feel like the answer to that is continuing to listen to, and 
test against, the market (the architects and operators).


Build a minimally viable product that (a) has clear messaging and use 
cases (b) is easy to deploy and configure and (c) doesn't demand deep 
integration into an existing cloud and operators will start deploying, 
testing, and providing feedback. This will create the right feedback 
cycle and help in validating (or completely demolishing) assumptions on 
what users actually need.


With regard to '(b)' above, it doesn't appear that there any any Puppet 
modules to assist with the installation and configuration of Zaqar. If 
you're interested, let's chat in Vancouver to see if I can help in get a 
basic set out there.


Regards,

Richard Raseley

SysOps Engineer
Puppet Labs

__
OpenStack Development Mailing 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] [api] API WG Meeting Time

2015-04-23 Thread Ryan Brown

On 04/23/2015 01:12 PM, michael mccune wrote:
 On 03/31/2015 10:13 PM, Everett Toews wrote:
 Ever since daylight savings time it has been increasing difficult for
 many API WG members to make it to the Thursday 00:00 UTC meeting time.

 Do we change it so there’s only the Thursday 16:00 UTC meeting time?
 
 this topic was brought up again at today's meeting (April 23, 2015), and
 we are still searching for a good alternate time.
 
 one proposal that came up was for an early morning PST time on thursdays
 for the meeting. i'm guessing this would be around the 12:00-13:00 UTC
 range.
 
 we would still love to hear more thoughts from folks in Australia/Asia
 time zones to see if we can arrive at something that will accommodate
 the most number of interested parties.
 
 regards,
 mike

I'd be more than happy with a 1200UTC-1300UTC meeting (I'm US-based).

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, 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] [nova][python-novaclient] microversion implementation on client side

2015-04-23 Thread Alex Xu

Thanks Andrey for hard work on the microverison client support.

Wrote down some my thought:

I also agreed we will have only one endpoint 'compute'. Hope we can switch
v2.1 export as '/v2' in the api-paste.conf as default very soon~

let's say what expected after we only have v2.1 in the world first:

There are two cases for use nova client.
1. user use nova client command line. I think command line should support
version discover. Provide most convenient way let the user try nova.
2. user use nova client as library. user should call the client code to
discover the version and decided what version he want to use by himself.

For the command line, the behavior can be:

When user execute cmd without --os-compute-version. The nova client should
discover the nova server supported version. Then cmd choice the latest
version supported both by client and server. This is good for us to
introduce the new feature to the user.

Also user can specified a version he want to by --os-compute-version.

'--os-compute-version=None' can be supported, that means will return the
min version of server supported.

The supported version can be discovered by version API (Thanks to Ken'ichi
fix this):
GET '/'
https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25

But reality is the v2 and v2.1 will existed at same time.

So the v2 or v2.1 code both can run under the endpoint 'compute' with url
'/v2'. It depend on the admin's deployment.

So I think the cmd also can discover whether the api supported microversion
under the 'compute' endpoint.

This can be discovered by version api also.

GET '/v2/' will return the endpoint version info. Then we can check the
version and min_version properties to know whether the api support
microversion or not.

The behavior can be:
1. If the microversion supported, the cmd behavior is same as the
description at the top of this mail
2. If the microversion non-supported, user call cmd without
--os-compute-version, we use the min version.
3. if the microversion non-supported, but user call cmd with
--os-compute-version, this should return failed.

Hope those thoughts are helpful.

Looks like this need some change in current patchset also :( I know Andrey
already pay lot of on this. But if we like this way, I also can give some
help on the coding :)

Thanks
Alex


2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com:

 Hi all!
 I working on implementation of support microversions in novaclient.
 Patches are ready for review, but there is one opened question: what we
 should do with v2.1 endpoint(computev21 service type)?

 compute is a default value of service type and keystone returns v2 api
 endpoint for it(at least in devstack), so version header will be ignored on
 API side.

 On the one hand, each deployment can have it's own configuration of
 service catalog and endpoints, so default value of service type should be
 strict and support as much deployments as we can. On the other hand,
 dependency of service type for microversion feature is not good and
 end-users should not take care about choice of correct service type when
 they want to execute simple command.

 Possible solutions:

1. leave everything as is: use --service-type computev21 for each
microversioned command
2. move default value of service type to environment variables(default
value is hardcoded in novaclient code now)
3. add additional option --compute-api-type. Proposed etherpad by
Christopher Yeoh
https://etherpad.openstack.org/p/novaclient_microversions_design .
Implementation is already finished -
https://review.openstack.org/#/c/167577/ . This proposal still
requires addition cli option, but compute-api-type looks more user-friendly


 Current implementation uses compute as default value for service type.
 Patches are pass all gates, except stable branches and ready for review:

- https://review.openstack.org/#/c/169378/  - deprecate v1.1 and
remove references to v3 in code
- https://review.openstack.org/#/c/152569/  - Implements
'microversions' api type - Part 1 (usage of
nova.api.openstack.api_version_request:APIVersionRequest class with
https://review.openstack.org/#/c/169292/ )
- https://review.openstack.org/#/c/167408/  - Implements
'microversions' api type - Part 2 (adds new decorators and substitution
mechanism using nova.api.openstack.versioned_method )
- https://review.openstack.org/#/c/136458/  - Implementation of 2.2
microversion


 --
 Best regards,
 Andrey Kurilin.

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


__
OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [all] Question for the TC candidates

2015-04-23 Thread Angus Salkeld

On Fri, Apr 24, 2015 at 2:14 AM, Chris Dent chd...@redhat.com wrote:


 This might be a bit presumptuous, but why not give it a try...

 This cycle's TC elections didn't come with a set of prepackaged
 questions and though the self-nomination messages have included some
 very interesting stuff I think it would be useful to get answers
 from the candidates on at least one topical but open-ended
 question. Maybe other people have additional questions they think
 are important but this one is the one that matters to me and also
 captures the role that I wish the TC filled more strongly. Here's
 the preamble:

 There are lots of different ways to categorize the various
 stakeholders in the OpenStack community, no list is complete. For
 the sake of this question the people I'm concerned with are the
 developers, end-users and operators of OpenStack: the individuals
 who are actively involved with it on a daily basis. I'm intentionally
 leaving out things like the downstream.

 There are many different ways to define quality. For the sake of
 this question feel free to use whatever definition you like but take
 it as given that quality needs to be improved.

 Here's the question:

 What can and should the TC at large, and you specifically, do to ensure
 quality improves for the developers, end-users and operators of
 OpenStack as a full system, both as a project being developed and a
 product being used?


I think this can be broader still - How can the TC herd cats :-O

Jokes aside, OpenStack is an opensource project and it's not easy for
TC members or PTL's to make developers do their bidding.

I'd like to think we at least need a better feedback loop from the user
survey
(or consumers of OpenStack in general) to what development actually
happens.
At the moment we have user feedback, but that doesn't always result in
developers doing exactly that. I think we need a number of tools for
PTLs and the TC be able to set priorities for particular themes OpenStack
wide.

1. I think the TC and PTLs need a place to say what the priorities are
(that is visible to everyone).
2. Then follow up with assigning blueprints and bug priorities accordingly
3. Be open to saying no to work that is not within these themes if it is
creating
a distraction.
4. recognition of work in these themes, perhaps on stackalytics (or else
where).

With some version of the above, we can hopefully get better at turning
user requests into solutions. (or better quality).

Regards
Angus




 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

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

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

[openstack-dev] [Fuel][Plugins] Fuel Plugin Guide is replaced with the wiki page

2015-04-23 Thread Irina Povolotskaya

Hi to everyone,

Please, be informed that Fuel Plugin Guide has been removed
and split into more specific sections at the wiki page [1].

The Plugins wiki page covers the following issues:
- basic development issues (Fuel Plugin Builder, package types)
- detailed plugin files description
- repo creation recommendations
- common CI recommendations
- tutorials about debugging UI and deployment
- FAQ

It is constantly updated and provides the latest information on
how to develop and deliver Fuel Plugins.

Feel free to have a look and ask questions.

Thank you!


[1] https://wiki.openstack.org/wiki/Fuel/Plugins


-- 
Best regards,

Irina

PI Team Technical Writer
__
OpenStack Development Mailing 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] Question for the TC candidates

2015-04-23 Thread Zane Bitter


On 23/04/15 12:14, Chris Dent wrote:


This might be a bit presumptuous, but why not give it a try...


Not at all, we should *strongly* encourage people to ask questions of 
the candidates.


In fact, I think we should encourage everyone to contribute to the 
discussion, not just the candidates.



This cycle's TC elections didn't come with a set of prepackaged
questions and though the self-nomination messages have included some
very interesting stuff I think it would be useful to get answers
from the candidates on at least one topical but open-ended
question. Maybe other people have additional questions they think
are important but this one is the one that matters to me and also
captures the role that I wish the TC filled more strongly. Here's
the preamble:

There are lots of different ways to categorize the various
stakeholders in the OpenStack community, no list is complete. For
the sake of this question the people I'm concerned with are the
developers, end-users and operators of OpenStack: the individuals
who are actively involved with it on a daily basis. I'm intentionally
leaving out things like the downstream.

There are many different ways to define quality. For the sake of
this question feel free to use whatever definition you like but take
it as given that quality needs to be improved.

Here's the question:

What can and should the TC at large, and you specifically, do to ensure
quality improves for the developers, end-users and operators of
OpenStack as a full system, both as a project being developed and a
product being used?


As you've identified, that is an extremely broad question and therefore 
it can only be correctly answered with an extremely vague response ;)


The only known way to improve 'quality' for all definitions of 'quality' 
is to make feedback loops shorter.



As for what the Technical Committee can do specifically, in the short 
term I think the most important thing is to make sure that projects have 
the flexibility to respond to their own individual challenges. I think 
we've made some progress in this direction - for example, the 
reorganisation that Neutron has been/is going through would probably 
have been easier had it begun in a big-tent world (it's much easier to 
split repos up than to punt parts of your project to stackforge), and 
that's the kind of change that could potentially allow projects to bring 
in more (but more specialised) core reviewers to reduce average 
time-to-review, thus shortening an important feedback loop. So I think 
the TC needs to be vigilant to make sure it's not making those kinds of 
changes difficult.


And of course we should try to identify ideas that work and introduce 
them to other projects who might benefit from them. But I don't think 
that needs to be the TC's responsibility alone - anyone in the community 
should feel able to do that. When I was a PTL I regarded my most 
important responsibility to be making sure that everyone on the team saw 
themselves as leaders of the project. I think the same applies to the TC.


[Warning: hand-waving ahead]

In the much longer term, I think the biggest improvement in quality 
would come from finding a way to not solve the same problems multiple 
times. I'll give an example: RabbitMQ doesn't scale. I hope that's not a 
controversial example, I think it's generally agreed that it just 
doesn't. Nova has developed Cells to enable itself to scale to very 
large deployments despite that limitation (and others). As a result of 
Cells being developed, every other project that uses RabbitMQ is... 
exactly where it was before. That seems suboptimal.


Right now we have a lot of back-end interfaces where the semantics are 
unclear to OpenStack developers, since they're deployer-defined in many 
cases and no one project really owns them. (Example: even if 
oslo-messaging didn't explicitly rule out durability by acknowledging 
messages *before* they're delivered to the application, there's still no 
way we could rely on it because who knows in what configuration RabbitMQ 
is deployed?) Even worse, the interfaces don't support the invariants we 
care about - like being able to scale to both extremely large and 
extremely small deployments - so that every project must find a way to 
reinvent those itself (or not), on top of the aforementioned unclear 
semantics. I can't say how much impact this has on quality. I would 
guess that it is both substantial and negative.


More co-operation between the various different deployment projects 
might help a little, and in any event would be a Good Thing, and we 
could start encouraging that right away.


Solving the problem entirely will be much harder, to put it mildly. I 
don't know if we'll ever get there (though I don't think it's 
impossible). I do believe that the first step is to have a conversation 
about what our vision is for the OpenStack project as a whole, and I 
think it will be much harder to have that conversation and follow 
through on it

[openstack-dev] [puppet] CI status proposal for puppet-syntax-future jobs

2015-04-23 Thread Emilien Macchi

Hi,

I dressed a spreadsheet with the current status of our CI [1].
You can see that we need to work on Puppet 4.0 [2] and beaker [3].

Otherwise, gate-puppet-*-puppet-syntax-future is green everywhere and I
don't see any reason why they should not vote in our CI process.

Also, once we have Puppet 4.0 jobs green everywhere, it makes sense they
will also vote.

Please raise your hand if you're against this idea, otherwise I'll
submit the patch in project-config.

Thanks,

[1]
https://docs.google.com/spreadsheets/d/1i2z5QyvukHCWU_JjkWrTpn-PexPBnt3bWPlQfiDGsj8/edit#gid=0
[2] https://bugs.launchpad.net/puppet-nova/+bug/1447620
[3] https://bugs.launchpad.net/puppet-nova/+bug/1444736
-- 
Emilien Macchi



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

[openstack-dev] [magnum] New fedora 21 Atomic images available for testing

2015-04-23 Thread Steven Dake (stdake)

Hi folks,

I have spent the last couple of days trying to bring some sanity to the image 
building process for Magnum.

I have found a tool which the Atomic upstream produces which allows a simple 
repeatable building process for Fedora Atomic images using any upstream repos 
of our choosing.

I put in a kubernetes 0.15 COPR repo in this build.  Please test and get back 
to me either on irc or the ML.

The image is available for download from here:
https://fedorapeople.org/groups/magnum/fedora-21-atomic-3.qcow2.xzhttps://fedorapeople.org/groups/magnum/

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] [puppet] CI status proposal for puppet-syntax-future jobs

2015-04-23 Thread Richard Raseley


Emilien Macchi wrote:

I dressed a spreadsheet with the current status of our CI [1].
You can see that we need to work on Puppet4.0  [2] and beaker [3].

Otherwise, gate-puppet-*-puppet-syntax-future is green everywhere and I
don't see any reason why they should not vote in our CI process.

Also, once we have Puppet4.0  jobs green everywhere, it makes sense they
will also vote.

Please raise your hand if you're against this idea, otherwise I'll
submit the patch in project-config.


Emilien,

+1 on both points, thank you.

Regards,

Richard

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

[openstack-dev] [puppet] Openstack Cluster Management

2015-04-23 Thread Guo, Ruijing

Apache Ambari(https://ambari.apache.org/) is to manage Hadoop cluster. Is it 
possible to port ambari framework to manage Openstack cluster.
__
OpenStack Development Mailing 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-dev Digest, Vol 36, Issue 67

2015-04-23 Thread INADA Naoki



  I recommend to use mysqlclient instead of MySQL-python even on
  Python 2.
 
  https://pypi.python.org/pypi/mysqlclient
  https://github.com/PyMySQL/mysqlclient-python

  Is it packaged in popular distributions? RHEL? Fedora? SuSe? Ubuntu?
  Debian? Gentoo?

 If this library solves real bugs and provides Python 3 compatibility, I
 think it's worth to replace MySQL-python with this new library. Linux
 distro can package it, they can probably copy the packaging of MySQL-Python
 since it's a fork.

 Note: mysqlclient-python conflicts with MySQL-Python, both libraries use
 the same MySQLdb Python module. The good news is that mysqlclient-python
 is a drop-in library for MySQL-Python: no need to change any line of code,
 only modify requirements.

 @Naoki: Did you try to contact MySQL-Python authors to take over their
 project instead of forking?

 Victor




First of all, I've sent pull request to MySQL-python. It wasn't merged for
a long time while
I needed it. So I've forked.

https://github.com/farcepest/MySQLdb1/pull/61
https://github.com/farcepest/MySQLdb1/pull/62


After that, Django supports Python 3 officially.
So we've discussed about which driver Django recommend for Python:
mysql-connector/Python,
PyMySQL and mysqlclient.

https://groups.google.com/forum/#!searchin/django-developers/mysql-python/django-developers/n-TI8mBcegE/BpGKEE08-g0J


While the discussion, it was reported on Debian.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768096

It's experimental package for now.
https://packages.debian.org/experimental/python3-mysqldb
http://metadata.ftp-master.debian.org/changelogs//main/p/python-mysqldb/python-mysqldb_1.3.4-1_changelog

I don't know about RHEL. As far as I googling, they are using original.
__
OpenStack Development Mailing 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] A big tent home for Neutron backend code

2015-04-23 Thread Mathieu Rohon

On Thu, Apr 23, 2015 at 10:28 AM, henry hly henry4...@gmail.com wrote:

 On Thu, Apr 23, 2015 at 10:44 AM, Armando M. arma...@gmail.com wrote:
 
  Could you please also pay some attention on Cons of this ultimate
  splitting Kyle? I'm afraid it would hurt the user experiences.
 
  On the position of Dev, A naked Neutron without official built-in
  reference implementation probably has a more clear architecture. On
  the other side, users would be forced to make choice between a long
  list of backend implementations, which is very difficult for
  non-professionals.
 
  In most of the time, users need a off-the-shelf solution without
  paying much extra integration effort, and they have less interest to
  study which SDN controller is powerful and is better than others. Can
  we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
  volume driver [See Deployment Profiles section in 1a] ? Shall we
  really decide to make Neutron the only Openstack project which has not
  any in tree official implementation?
 
 
  I think the analogy here is between the agent reference implementation vs
  KVM or Ceph, rather than the plumbing that taps into the underlying
  technology. Nova doesn't build/package KVM as Cinder doesn't
 build/package
  Ceph. Neutron could rely on other open source solutions (ODL,
 OpenContrail,
  OVN, etc), and still be similar to the other projects.
 
  I think there's still room for clarifying what the split needs to be,
 but I
  have always seen Neutron as the exception rather than norm, where, for
  historic reasons, we had to build everything from the ground up for lack
 of
  viable open source solutions at the time the project was conceived.
 

 Thanks for bring in this interesting topic, maybe it should not be
 scoped only inside Neutron, also I found a similar discuss from John
 griffith on Cinder vs SDS controller :-)


 https://griffithscorner.wordpress.com/2014/05/16/the-problem-with-sds-under-cinder/

 It's clear that an typical Cloud deployment is composed of two
 distinct part: workload engine vs. supervisor. The engine part
 obviously do not belong to Openstack project, which include open
 sourced like KVM, Ceph, OVS/Linuxstack/haproxy/openswan, and vendor's
 like Vcenter/ESXi, SAN disk arrays, and all kinds of networking
 hardware gears or virtualized service VMs.

 However for the supervisor part, there is some blurring for debates:
 Should Openstack provide complete in-house implementation of
 controlling functions which could directly drive backend workload
 engine (via backend driver), or just thin API/DB layer which need to
 integrate some 3rd external controller projects to finish those works:
 scheduling, pooling and service logic abstraction? For networking, how
 should we regard the functions of plugin/agent and SDN controller, are
 they classified in the same layer of real backends working engine
 like Switchs/Routers/Firewalls?

 For Nova  Cinder, it seems former is adopted: a single unified
 central framework including API, scheduling, abstraction service
 logic, rpc  message queue, and a common agent side framework of
 compute/volume manager, then with a bunch of virt/volume drivers
 plugged to abstract the all kinds of backends. There are standalone
 backends like KVM and LVM, and aggregated clustering backends like
 vcenter and ceph.

 The Neutron was just like a developing game of continuously
 re-factoring: plugin, meta plugin, ML2, and now the platform. Next
 ML2 plugin suddenly became just a reference for concept proving, and
 no plugin/agent would be maintained in-tree officially anymore, while
 the reason is confusingly not to compete with other 3rd SDN
 controllers :-P


I agree with henry here.
Armando, If we use your analogy with nova that doesn't build and deliver
KVM, we can say that Neutron doesn't build or deliver OVS. It builds a
driver and an agent which manage OVS, just like nova which provides a
driver to manage libvirt/KVM.
Moreover, external SDN controllers are much more complex than Neutron with
its reference drivers. I feel like forcing the cloud admin to deploy and
maintain an external SDN controller would be a terrible experience for him
if he just needs a simple way manage connectivity between VMs.
At the end of the day, it might be detrimental for the neutron project.


 
 
 
  [1a]
 
 http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014
 
  Here is my personal suggestion: decomposition decision needs some
  trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2
  with OVSLB, based on the survey result of 1a above]. While we are
  progressing radically with architecture re-factoring, smooth
  experience and easy to adoption should also be cared.
 
  
   One thing which is worth bringing up in this context is the potential
   overlap between this implementations. I think having them all under
 the
   Neutron project would allow me as PTL and the rest of the team work to

Re: [openstack-dev] [Nova][Neutron] Cross-project coordination

2015-04-23 Thread Daniel Comnea

Good luck Sean!! Hopefully you can sort out the DNS and the Qoutas.

Thanks again !

On Wed, Apr 22, 2015 at 11:41 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 04/22/2015 04:33 PM, Kyle Mestery wrote:

 On Wed, Apr 22, 2015 at 3:28 PM, Sean M. Collins s...@coreitpro.com
 mailto:s...@coreitpro.com wrote:

 Hi,

 Kyle Mestery has asked me to serve as a cross-project liaison between
 Neutron and Nova. So, I'd like to say hello, and
 direct everyone towards an etherpad that I have created.

 https://etherpad.openstack.org/p/nova-neutron

 The etherpad can serve as a way to collect items that should be
 discussed between the projects.

 I will be attending the Nova main meetings to field Neutron
 questions, or at least provide who on the Neutron side would know the
 answer to a question.

 This is a big job, and I'd like to see if there is a volunteer on the
 Nova side who would be interested in also helping this effort, who
 could
 do the reverse (Sit in on Neutron meetings, field Nova questions).

 Thank you, and I look forward to working with everyone!

 Sean, thank you so much for volunteering to take on this incredibly
 important job. I'm hoping we can get someone from the nova side to work
 hand-in-hand with you and ensure we continue to drive issues related to
 both nova and neutron to conclusion in a way which benefits are mutual
 users!


 Agreed. I'm hoping that someone in the Nova community -- note, this does
 not need to be a Nova core contributor -- can step up to the plate and
 serve in this critical role.

 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

__
OpenStack Development Mailing 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] eventlet 0.17.3 is now fully Python 3 compatible

Hi,

 How invasive would the port to python3 be?

I squashed all my commits into a single commit of my draft port and I pushed it 
at:
https://github.com/haypo/nova/commit/bad54bc2b278c7c7cb7fa6cc73d03c70138bd89d

As announced, changes are boring, just obvious Python2/Python3 issues:

- strip L from long integer literals: 123L = 123
- replace dict.iteritems() with six.iteritems(dict)
- replace list.sort(cmp_func) with list.sort(key=key_func)
- replace raise exc_info[0], exc_info[1], exc_info[2] with 
six.reraise(*exc_info)
- moved functions / modules

  * get http.client, urllib.request and other stdlib modules from six.moves 
since they moved between Python 2 and Python 3
  * get itertools.izip/zip_longest from six.moves
  * replace unichr() with six.unichr()

- replace filter(func, data) with [item for item in data if func(item)]
- replace unicode() with six.text_type
- replace (int, long) with six.integer_types
- replace file() with open()
- replace StringIO() with six.StringIO()

These changes are not enough to port nova to Python 3. But they are required to 
be able to find next Python 3 bugs.

Reminder: Python 2 compatibility is kept! There is not reason right now to drop 
Python 2 support, it would be a pain to upgrade!


 Would it be easier to have a python3 migration sprint and rip the band aid 
 off instead of dragging it out and having partial python3 support for a whole 
 cycle? 

Do you mean a physical meeting? Or focus on Python 3 during a short period 
(review/merge all Python 3 patches)?

A single week may not be enough to fix all Python 3 issues. I prefer to submit 
changes smoothly during the Liberty cycle.


 In general what is the least painful way to add python3 support for a very 
 large python project? 

Send patches and make incremental changes, as any other change made in 
OpenStack.

Victor

__
OpenStack Development Mailing 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] Policy rules are killed by the context admin check

2015-04-23 Thread Sylvain Bauza

Le 23 avr. 2015 04:49, Alex Xu sou...@gmail.com a écrit :



 2015-04-23 6:55 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com:



 On 4/22/2015 8:32 AM, Sylvain Bauza wrote:

 Hi,

 By discussing on a specific bug [1], I just discovered that the admin
 context check which was done at the DB level has been moved to the API
 level thanks to the api-policy-v3 blueprint [2]

 That behaviour still leads to a bug if the operator wants to change an
 endpoint policy by leaving it end-user but still continues to be denied
 because of that, as it will forbid any non-admin user to call the
 methods (even if authorize() grants the request)

 I consequently opened a bug [3] for this but I'm also concerned about
 the backportability of that and why it shouldn't fixed in v2.0 too.

 Releasing the check by removing it sounds an acceptable change, as it
 fixes a bug without changing the expected behaviour [4]. The impact of
 the change sounds also minimal with a very precise scope (ie. leave the
 policy rules work as they are expected) [5]

 Folks, thoughts ?

 -Sylvain

 [1] https://bugs.launchpad.net/nova/+bug/1447084
 [2]

https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z

 [3] https://bugs.launchpad.net/nova/+bug/1447164
 [4]

https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK
 Fixing a bug so that a request which resulted in an error response
 before is now successful
 [5] https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy


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


 I don't disagree, see bug 1168488 from way back in grizzly.

 The only thing would be we'd have to make sure the default rule is admin
for any v2 extensions which are enforcing an admin context today.


 Agree, if we want to fix those for v2, we need make sure the default rule
is admin.

 And do you mean [3] want to fix this for v2 both in Kilo and Liberty?

 For liberty, we can do that, but I think we will switch to v2.1 very
soon. Not sure it is still worth to do that.

 For kilo, some of api is pretty easy to fix by just removing
'require_admin_context()'. But there still have many of policy patches
didn't merged into the master yet. like:

https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z

https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z

https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_qutoa_hardcode_permission,n,z

https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_quotaclass_hardcode_permission,n,z

 Should we back-port them all?

Wrt all the necessary backports, I'm eventually rather in favor of an
opportunistic approach and only backport what has been reported as a bug,
ie. [1]

That has also the benefit of not proposing a stable patch which was not
cherry-picked (like providing an elevated context), which I disapprove.

-Sylvain




 --

 Thanks,

 Matt Riedemann




__
 OpenStack Development Mailing 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] TC non-candidacy

2015-04-23 Thread Michael Still

Hi,

I've served on the TC for a while now and enjoyed it. However, I feel
I've reached a point where I need to step back and take a break. I
will therefore not be running this time around. I'm sure I'll return
just as soon as my righteous anger builds up again.

Cheers,
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

Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

 I recommend to use mysqlclient instead of MySQL-python even on
 Python 2.
 
 https://pypi.python.org/pypi/mysqlclient 
 https://github.com/PyMySQL/mysqlclient-python

 Is it packaged in popular distributions? RHEL? Fedora? SuSe? Ubuntu?
 Debian? Gentoo?

If this library solves real bugs and provides Python 3 compatibility, I think 
it's worth to replace MySQL-python with this new library. Linux distro can 
package it, they can probably copy the packaging of MySQL-Python since it's a 
fork.

Note: mysqlclient-python conflicts with MySQL-Python, both libraries use the 
same MySQLdb Python module. The good news is that mysqlclient-python is a 
drop-in library for MySQL-Python: no need to change any line of code, only 
modify requirements.

@Naoki: Did you try to contact MySQL-Python authors to take over their project 
instead of forking?

Victor

__
OpenStack Development Mailing 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] Break_on in Retry policy

2015-04-23 Thread Renat Akhmerov


 On 22 Apr 2015, at 20:46, Dmitri Zimine dzim...@stackstorm.com wrote:
 
 1) if break-on expression contains the reference to task result, like 
 break-on: % $.my_task.foo.bar = true % 
 but action returns ERROR and task payload is None (desired behavior: don’t 
 puke, evaluate to false and don’t break)

I’m a little confused now. I remember we discussed it with you already but I’m 
just trying to see in what cases we may get action result (= task result) but 
have action in ERROR state. The only case that I see is when we use 
“with-items” and part of actions completed successfully by the time that some 
action (iteration of “with-items”) failed. Then in $.my_task we would be able 
to provide a partial (incomplete) result consisting of those successful action 
results. It’s not how it’s supposed to work now though. If at least one action 
fails then all successful iterations get invalidated too.

 2) if break-on contains the value from (e.g. published variable, updated by 
 other branch of workflow) - desired behavior - evaluate my_global_flag on 
 every iteration: 
 break-on %  $.my_global_flag = true %

Yes, that would be cool to do. The implementation I think is not going to be 
easy though..

 3) a combination of the two
 break-on %  $.my_global_counter  $.my_task.counter  %

Yes. We need to clarify 1)

 On Apr 22, 2015, at 6:55 AM, Nikolay Makhotkin nmakhot...@mirantis.com 
 mailto:nmakhot...@mirantis.com wrote:
 
 So, in this case I guess 'break-on' will work correctly now: 
 https://github.com/stackforge/mistral/blob/master/mistral/engine/policies.py#L295-L296
  
 https://github.com/stackforge/mistral/blob/master/mistral/engine/policies.py#L295-L296
Yes, you’re right. It seems like it works now as I described.


Renat Akhmerov
@ 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] [Neutron] A big tent home for Neutron backend code

2015-04-23 Thread henry hly

On Thu, Apr 23, 2015 at 10:44 AM, Armando M. arma...@gmail.com wrote:

 Could you please also pay some attention on Cons of this ultimate
 splitting Kyle? I'm afraid it would hurt the user experiences.

 On the position of Dev, A naked Neutron without official built-in
 reference implementation probably has a more clear architecture. On
 the other side, users would be forced to make choice between a long
 list of backend implementations, which is very difficult for
 non-professionals.

 In most of the time, users need a off-the-shelf solution without
 paying much extra integration effort, and they have less interest to
 study which SDN controller is powerful and is better than others. Can
 we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
 volume driver [See Deployment Profiles section in 1a] ? Shall we
 really decide to make Neutron the only Openstack project which has not
 any in tree official implementation?


 I think the analogy here is between the agent reference implementation vs
 KVM or Ceph, rather than the plumbing that taps into the underlying
 technology. Nova doesn't build/package KVM as Cinder doesn't build/package
 Ceph. Neutron could rely on other open source solutions (ODL, OpenContrail,
 OVN, etc), and still be similar to the other projects.

 I think there's still room for clarifying what the split needs to be, but I
 have always seen Neutron as the exception rather than norm, where, for
 historic reasons, we had to build everything from the ground up for lack of
 viable open source solutions at the time the project was conceived.


Thanks for bring in this interesting topic, maybe it should not be
scoped only inside Neutron, also I found a similar discuss from John
griffith on Cinder vs SDS controller :-)

https://griffithscorner.wordpress.com/2014/05/16/the-problem-with-sds-under-cinder/

It's clear that an typical Cloud deployment is composed of two
distinct part: workload engine vs. supervisor. The engine part
obviously do not belong to Openstack project, which include open
sourced like KVM, Ceph, OVS/Linuxstack/haproxy/openswan, and vendor's
like Vcenter/ESXi, SAN disk arrays, and all kinds of networking
hardware gears or virtualized service VMs.

However for the supervisor part, there is some blurring for debates:
Should Openstack provide complete in-house implementation of
controlling functions which could directly drive backend workload
engine (via backend driver), or just thin API/DB layer which need to
integrate some 3rd external controller projects to finish those works:
scheduling, pooling and service logic abstraction? For networking, how
should we regard the functions of plugin/agent and SDN controller, are
they classified in the same layer of real backends working engine
like Switchs/Routers/Firewalls?

For Nova  Cinder, it seems former is adopted: a single unified
central framework including API, scheduling, abstraction service
logic, rpc  message queue, and a common agent side framework of
compute/volume manager, then with a bunch of virt/volume drivers
plugged to abstract the all kinds of backends. There are standalone
backends like KVM and LVM, and aggregated clustering backends like
vcenter and ceph.

The Neutron was just like a developing game of continuously
re-factoring: plugin, meta plugin, ML2, and now the platform. Next
ML2 plugin suddenly became just a reference for concept proving, and
no plugin/agent would be maintained in-tree officially anymore, while
the reason is confusingly not to compete with other 3rd SDN
controllers :-P




 [1a]
 http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014

 Here is my personal suggestion: decomposition decision needs some
 trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2
 with OVSLB, based on the survey result of 1a above]. While we are
 progressing radically with architecture re-factoring, smooth
 experience and easy to adoption should also be cared.

 
  One thing which is worth bringing up in this context is the potential
  overlap between this implementations. I think having them all under the
  Neutron project would allow me as PTL and the rest of the team work to
  combine things when it makes sense.
 
  Kyle
 
  [1] http://www.faqs.org/rfcs/rfc1149.html
 
 
  b) Let each interested group define a new project team for their
  backend
  code.
 
  To be honest, I don't this is a scalable option. I'm involved with 2 of
  these networking-foo projects, and there is not enough participation so
  far
  to warrant an entirely new project, PTL and infra around it. This is
  just my
  opinion, but it's an opinion I've taken after having contributed to
  networking-odl and networking-ovn for the past 5 months.
 
 
  So, as an example, the group of people working on Neutron integration
  with OpenDaylight could propose a new project team that would be a
  projects.yaml entry that looks something like:
 
  Neutron-OpenDaylight:
ptl: Some Person

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

Armando M. wrote:
 Is it sensible to assume that Stackforge is going away entirely at some
 point in the future, and we'll have a single namespace - OpenStack?

The key difference between Stackforge and OpenStack is governance. Any
project can be in Stackforge. Projects that are considered OpenStack
projects are special in two ways:

1- They need to fit the OpenStack requirements as defined by the TC
2- They need to place themselves under the oversight of the TC

In return, they get voting rights to elect the TC itself.

While most projects in Stackforge actually fit (1) and accept (2), not
all of them do. It's also not a decision that can be made for them (due
to (2)), so we can't just migrate them.

 It's my understanding that StackForge projects are bound to the same
 governance model, or am I mistaken? 

Of course they aren't. They don't sign up for anything, and our
governance model has no sort of control over them.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

2015-04-23 Thread Salvatore Orlando

On 23 April 2015 at 01:30, Armando M. arma...@gmail.com wrote:

On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo mangel...@redhat.com
wrote:

Hi everybody,

In the latest QoS meeting, one of the topics was a discussion about
how to implement
QoS [1] either as in core, or as a service plugin, in, or out-tree.

It is really promising that after only two meetings the team is already
split! I cannot wait for the API discussion to start ;)

My apologies if I was unable to join, the meeting clashed with another one
I was supposed to attend.

It’s my feeling, and Mathieu’s that it looks more like a core feature,
as we’re talking of
port properties that we define at high level, and most plugins (QoS
capable) may want
to implement at dataplane/controlplane level, and also that it’s
something requiring a good
amount of review.

Core is a term which is recently being abused in Neutron... However, I
think you mean that it is a feature fairly entangled with the L2 mechanisms
that deserves being integrated in what is today the core plugin and in
the OVS/LB agents. To this aim I think it's good to make a distinction
between the management plane and the control plane implementation.

At the management plane you have a few choices:
- yet another mixin, so that any plugin can add it and quickly support the
API extension at the mgmt layer. I believe we're fairly certain everybody
understands mixins are not sustainable anymore and I'm hopeful you are not
considering this route.
- a service plugin - as suggested by some proposers. The service plugin is
fairly easy to implement, and now Armando has provided you with a mechanism
to register for callbacks for events in other plugins. This should make the
implementation fairly straightforward. This also enables other plugins to
implement QoS support.
- a ML2 mechanism driver + a ML2 extension driver. From an architectural
perspective this would be the preferred solution for a ML2 implementation,
but at the same time will not provide management level support for non-ML2
plugins.

In the other hand Irena and Sean were more concerned about having a
good separation
of concerns (I agree actually with that part), and being able to do
quicker iterations on a
separate stackforge repo.

Perhaps we're trying to address the issue at the wrong time. Once a
reasonable agreement has been reached on the data model, and the API,
whether we're going with a service plugin or core etc should be an
implementation detail. I think the crux of the matter is the data plane
integration. From a management and control standpoint it should be fairly
trivial to expose/implement the API and business logic via a service plugin
and, and some of you suggested, integrate with the core via callbacks.

However, I am pretty sure there will be preliminary work necessary to
integrate the server with the agent fabric (when there is one) so that is
no longer a pain. Extending what the agent can do the way we did so far
(e.g. by adding extra payloads/messages, mixin etc) is not sustainable, and
incredibly brittle.

In my opinion the interesting part for an architectural decision here is
the control plane support for the reference implementation.
Adding more stuff to the OVS/LB agents might lead to an increase in
technical debt. On the other hand, adding a new QoS agent might lead to
further complexity - another loose bit to keep in sync with the rest, and
operators usually are not happy about having to manage the lifecycle of
another independent component. And as Armando say, you also need to
consider what changes you need to the RPC interface.

Without that information it is hard to make a call, and therefore I agree
with Armando that there are not yet enough elements to make a decision -
let's wait at least for a high level view of system architecture.

Since we didn’t seem to find an agreement, and I’m probably missing
some details,
I’d like to loop in our core developers and PTL to provide an opinion on
this.

Core developers and the PTL do not necessarily have a better opinion...
instead in many cases they have a worse one!
By the way, if you go the stackforge route, then you can apply for becoming
an openstack project and one of you can become PTL! Isn't that wonderful?
Who doesn't want to be PTL these days?

[1]
http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-04-21-14.03.log.html#l-192

Thanks for your patience,
Miguel Angel Ajo

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

2015-04-23 Thread Angus Lees

On Thu, 23 Apr 2015 at 17:11 Victor Stinner vstin...@redhat.com wrote:

 As announced, changes are boring, just obvious Python2/Python3 issues:

 - strip L from long integer literals: 123L = 123
 - replace dict.iteritems() with six.iteritems(dict)
 - replace list.sort(cmp_func) with list.sort(key=key_func)
 - replace raise exc_info[0], exc_info[1], exc_info[2] with
 six.reraise(*exc_info)
 - moved functions / modules

   * get http.client, urllib.request and other stdlib modules from
 six.moves since they moved between Python 2 and Python 3
   * get itertools.izip/zip_longest from six.moves
   * replace unichr() with six.unichr()

 - replace filter(func, data) with [item for item in data if func(item)]
 - replace unicode() with six.text_type
 - replace (int, long) with six.integer_types
 - replace file() with open()
 - replace StringIO() with six.StringIO()

 These changes are not enough to port nova to Python 3. But they are
 required to be able to find next Python 3 bugs.


Is there already a static analysis tool that helps find these things?
 (Would a pylint check for the above be useful?  Some of them would be hard
to find reliably, but a bunch of the above would be trivial)

 - Gus
__
OpenStack Development Mailing 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] eventlet 0.17.3 is now fully Python 3 compatible

Hi,

 These changes are not enough to port nova to Python 3. But they are required 
 to be able to find next Python 3 bugs.

 Is there already a static analysis tool that helps find these things? (Would 
 a pylint check for the above be useful? Some of them would be hard to find 
 reliably, but a bunch of the above would be trivial) 

I read that hacking has some checks. It's quite easy to run 2to3 to see 
modified lines.

Personally, I prefer to just run tests and fix issues one by one. It's faster 
to fix failing tests without having the modify the whole project at one.

Sometimes, I'm also using regular expressions (in vim or grep). For example, I 
used [0-9]+L to find 123L. You can also use regex to modify code inplace.

2to3 tool drops Python 2 compatibility, so it's not great. But it helps to find 
code that needs to be modified.

I now prefer 2to6 which uses six and so keeps Python 2 compatibility. I 
modified it a little bit to reduce changes:
https://github.com/haypo/2to6/

Victor

__
OpenStack Development Mailing 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] Sahara HA discussion

2015-04-23 Thread Sergey Reshetnyak

Hi Lu

I'm going to start working on HA support for Sahara  for HDP and CDH
plugins. Now I didn't create specs or blueprints about HA. Also I don't
have code for HA support.
When are you going to start implement HA for CDH?

Thanks
Sergey

2015-04-20 4:06 GMT+03:00 Lu, Huichun huichun...@intel.com:

  Hi Sergey

 Last IRC meeting, I heard that you are currently working on the HA on CDH
 and HDP, by chance that we just raise a bp about HA, so do you have any bp
 or spec about this topic? I think it’s interesting about this topic, we can
 have some discussion.

 https://blueprints.launchpad.net/sahara/+spec/cdh-ha-support





 thx Sergey ^^

__
OpenStack Development Mailing 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] [Manila] Two nominations for Manila Core Reviewer Team

2015-04-23 Thread Valeriy Ponomaryov

+1

On Wed, Apr 22, 2015 at 11:48 PM, yang, xing xing.y...@emc.com wrote:

  +1 to both.



 *From:* Ben Swartzlander [mailto:b...@swartzlander.org]
 *Sent:* Wednesday, April 22, 2015 2:23 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* [openstack-dev] [Manila] Two nominations for Manila Core
 Reviewer Team



 I would like to nominate Thomas Bechtold to join the Manila core reviewer
 team. Thomas has been contributing to Manila for close to 6 months and has
 provided a good number of quality code reviews in addition to a substantial
 amount of contributions. Thomas brings both Oslo experience as well as a
 packager/distro perspective which is especially helpful as Manila starts to
 get used in more production scenarios.

 I would also like to nominate Mark Sturdevant. He has also been active in
 the community for about 6 months and has a similar history of code reviews.
 Mark is the maintainer of the HP driver and would add vendor diversity to
 the core team.

 -Ben Swartzlander
 Manila PTL


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




-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Manila] Two nominations for Manila Core Reviewer Team

2015-04-23 Thread Igor Malinovskiy

+1

On Wed, Apr 22, 2015 at 9:23 PM, Ben Swartzlander b...@swartzlander.org
wrote:

  I would like to nominate Thomas Bechtold to join the Manila core
 reviewer team. Thomas has been contributing to Manila for close to 6 months
 and has provided a good number of quality code reviews in addition to a
 substantial amount of contributions. Thomas brings both Oslo experience as
 well as a packager/distro perspective which is especially helpful as Manila
 starts to get used in more production scenarios.

 I would also like to nominate Mark Sturdevant. He has also been active in
 the community for about 6 months and has a similar history of code reviews.
 Mark is the maintainer of the HP driver and would add vendor diversity to
 the core team.

 -Ben Swartzlander
 Manila PTL


 __
 OpenStack Development Mailing 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] eventlet 0.17.3 is now fully Python 3 compatible

2015-04-23 Thread Chmouel Boudjnah

Victor Stinner vstin...@redhat.com writes:

 Is there already a static analysis tool that helps find these things? (Would 
 a
 pylint check for the above be useful? Some of them would be hard to find
 reliably, but a bunch of the above would be trivial)

 I read that hacking has some checks. It's quite easy to run 2to3 to see 
 modified lines.

In Swift, Alex has installed this tox.ini target to detect those :

https://github.com/openstack/swift/blob/master/tox.ini#L38

may be a good idea to generalize.

Cheers,
Chmouel

__
OpenStack Development Mailing 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] eventlet 0.17.3 is now fully Python 3 compatible

2015-04-23 Thread Thomas Goirand

On 04/10/2015 09:41 AM, Thierry Carrez wrote:

Victor Stinner wrote:

I fixed 4 issues with monkey-patching in Python 3 (importlib, os.open(),
threading.RLock, threading.Thread). Good news: the just released eventlet
0.17.3 includes these fixes and it is now fully compatible with Python 3! For
example, the Oslo Messaging test suite now pass with this eventlet version!
Currently, eventlet is disabled in Oslo Messaging on Python 3 (eventlet tests
are skipped).

Great news ! That makes the port to Python 3 question independent of
the Moving off eventlet question, which should facilitate immediate
progress on the former.

On the latter, do you plan to file a Concurrency models cross-project
session ? That sounds like a good topic to discuss face to face...

See
http://lists.openstack.org/pipermail/openstack-dev/2015-April/061070.html for
details on how to file there.

BTW, the Eventlet module for 0.17.3 is available from here:
http://kilo-jessie.pkgs.mirantis.com/debian/pool/jessie-kilo-backports-nochange/main/p/python-eventlet/

and I will upload this to Experimental as soon as Jessie is released
(that's in 3 days now...).

Cheers,

Thomas Goirand (zigo)

Re: [openstack-dev] [neutron-lbaas] [third-party] trying to set up 3rd party CI, neutron-lbaas tox fails to import some neutron

2015-04-23 Thread Shane McGough

Thanks guys that was it! Did a git pull on the egg that tox cloned and it works 
now.


Pretty strange that it clones an out of date neutron though. This was all a 
fresh environment.


Cheers


Shane McGough
Junior Software Developer
KEMP Technologies
National Technology Park, Limerick, Ireland.

kemptechnologies.comhttps://kemptechnologies.com/ | 
@KEMPtechhttps://twitter.com/KEMPtech | 
LinkedInhttps://www.linkedin.com/company/kemp-technologies



From: Salvatore Orlando sorla...@nicira.com
Sent: Wednesday, April 22, 2015 6:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron-lbaas] [third-party] trying to set up 3rd 
party CI, neutron-lbaas tox fails to import some neutron

At first glance it seems like you're trying to run these tests with a neutron 
repo which is not up to date.
Recently Neutron unit tests were reorganized [1]. Have you tried pulling again 
from git the neutron repo?

Salvatore

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

On 22 April 2015 at 19:38, Lenny Verkhovsky 
len...@mellanox.commailto:len...@mellanox.com wrote:
Hi,
We had some issues with tox lately,
The fix was removing ~/.pip  and some other packages from this folder that were 
used as cache for pip
And reinstalling devstack.


Lenny Verkhovsky

From: Shane McGough 
[mailto:smcgo...@kemptechnologies.commailto:smcgo...@kemptechnologies.com]
Sent: Wednesday, April 22, 2015 1:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron-lbaas] [third-party] trying to set up 3rd 
party CI, neutron-lbaas tox fails to import some neutron


Hi all



I am having trouble running tox tests on neutron-lbaas on a default clone. I 
can see from the tox logs that it downloads the neutron egg just fine, however, 
when running some of the tests it gets import errors when trying to import from 
the neutron side of things.



I checked the neutron repo and it does indeed seem like the files its trying to 
import do not exist within the neutron repo tox downloads. Some neutron files 
do successfully import apparently but majority are referencing files that do 
not exist in the location its referencing.



Am I missing something fundamental here?



I included some of the errors below just to give an idea of what fails.



Any help would be appreciated



I am using Ubuntu Server 14.04.2 LTS



Thanks

Shane





py27 runtests: PYTHONHASHSEED='0'
py27 runtests: commands[0] | sh tools/pretty_tox.sh
running testr
Non-zero exit code (2) from test listing.
error: testr failed (3)
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} 
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} 
${PYTHON:-python} -m subunit.run discover -t ./ 
${OS_TEST_PATH:-./neutron_lbaas/tests/unit} --list
--- import errors ---
Failed to import test module: neutron_lbaas.tests.unit.agent.test_agent
Traceback (most recent call last):
  File 
/home/shane/work/neutron-lbaas/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
 line 445, in _find_test_path
module = self._get_module_from_name(name)
  File 
/home/shane/work/neutron-lbaas/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
 line 384, in _get_module_from_name
__import__(name)
  File neutron_lbaas/tests/unit/agent/test_agent.py, line 21, in module
from neutron_lbaas.tests import base
  File neutron_lbaas/tests/base.py, line 18, in module
from neutron.tests.unit.db import test_db_base_plugin_v2
ImportError: cannot import name test_db_base_plugin_v2

Failed to import test module: neutron_lbaas.tests.unit.agent.test_agent_api
Traceback (most recent call last):
  File 
/home/shane/work/neutron-lbaas/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
 line 445, in _find_test_path
module = self._get_module_from_name(name)
  File 
/home/shane/work/neutron-lbaas/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
 line 384, in _get_module_from_name
__import__(name)
  File neutron_lbaas/tests/unit/agent/test_agent_api.py, line 21, in module
from neutron_lbaas.tests import base
  File neutron_lbaas/tests/base.py, line 18, in module
from neutron.tests.unit.db import test_db_base_plugin_v2
ImportError: cannot import name test_db_base_plugin_v2

Failed to import test module: neutron_lbaas.tests.unit.agent.test_agent_manager
Traceback (most recent call last):
  File 
/home/shane/work/neutron-lbaas/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
 line 445, in _find_test_path
module = self._get_module_from_name(name)
  File 
/home/shane/work/neutron-lbaas/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
 line 384, in _get_module_from_name
__import__(name)
  File neutron_lbaas/tests/unit/agent/test_agent_manager.py, line 24, in 
module
from neutron_lbaas.tests import base
  File neutron_lbaas/tests/base.py, line 18, in module
from neutron.tests.unit.db import

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

2015-04-23 Thread Flavio Percoco


On 21/04/15 14:08 +, Fox, Kevin M wrote:

I think getting operators to adopt it is key to getting other openstack
projects to also adopt it. There is something of a chicken and the egg problem
with the integration. Some of the projects you will want to integrate the most
with are already considered pretty stable and may not want to rewrite working
bits to target a service thats hard for ops to deploy. It makes their service
hard to deploy too.

Getting into RDO and Ubuntu will go a long way there. Getting into Packstack
and other deployment tools even further.


I don't fully agree with the above. The problem on waiting for
operators to adopt it is that they might actually not have a reason to
do it, which doesn't mean the project is useless. Each operator will
decide what services they want to provide.

Integrating with other projects will give a good reason for
operators to install it. It's actually kind of forcing them if the
projects end up depending on each other but I don't think that's wrong
if the integration is made for good reasons instead of simple
promotion.

These thread is mostly to ask those projects that we know have use
cases where zaqar would be a good fit to help us working on this
integration.


One of the places that would be interesting to start trying and get integrated
is Sahara to Sahara VM hooks. In my opinion, it currently has the wrong model
of trying to contact the vm from the controller rather then have the vm contact
a queue. This requires all sahara vms to be public (less secure, wastes ips) or
only have one controller/network node to tunnel with(nonscalable). This would
fix a problem ops are having with it, benifiting all parties.

I mentioned oslo.messaging earlier since trove I think uses it for its
controller/vm communication. If a very simple messaging driver could be
written, it also could help you prove out your api with real use and trove
could see why closer integration would be good? It wouldnt need all the
messaging features. Just the features that make point to point controller to vm
work?


Oslo.messaging has a different target that I currently don't think
Zaqar is good for. Therefore, the integration with services like
Trove, Sahara, etc. will have to be done manually. That is, using the
zaqarclient directly.

Cheers,
Flavio



Thanks,
Kevin

━━━
From: Flavio Percoco
Sent: Tuesday, April 21, 2015 12:56:27 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 20/04/15 13:39 -0700, Vipul Sabhaya wrote:



On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M kevin@pnnl.gov wrote:

   Another parallel is Manilla vs Swift. Both provides something like a share
   for users to store files.

   The former is a multitenant api to provision non multitenant file shares.
   The latter is a multitenant api to provide file sharing.

   Cue is a multitenant api to provision non multitenant queues.
   Zaqar is an api for a multitenant queueing system.

   They are complimentary services.



Agreed, it’s not an either/or, there is room for both.  While Cue could
provision Zaqar, it doesn’t make sense, since it is already multi-tenant.  As
has been said, Cue’s goal is to bring non-multi-tenant message brokers to the
cloud.

On the question of adoption, what confuses me is why the measurement of

success
of a project is whether other OpenStack services are integrating or not. 

Zaqar

exposes an API that seems best fit for application workloads running on an
OpenStack cloud.  The question should be raised to operators as to what’s
preventing them from running Zaqar in their public cloud, distro, or whatever.

Looking at other services that we consider to be successful, such as Trove, we
did not attempt to integrate with other OpenStack projects.  Rather, we solved
the concerns that operators had.


FWIW, the team is not messuring the success of the project on whether
it's integrated with other services or not. The adoption in all
possible areas play key parts in every project's life. While it's
amazing that RDO - and I believe Ubuntu is packaging too, Zigo,
correct me, pls - has support for it, I don't think that's enough for
the project to go anywhere.

The use cases of this project, from a *provider* point of view are
very specific - you either want to sell/use queues or you don't - and
similar to SQS's. The fact that many folks miss is that SQS itself is
being used *internally* in AWS for other things that I'm not going to
get into. This is true not just for SQS, SNS but also for several
other services they provide. Thankfully enough, we've folloed the same
lead of using the things we've created. For instance, Trove uses nova
for vms, Nova uses Cinder for block devices, etc, etc, etc.

This needs to happen for Zaqar too. This will help the project mature
with feedback from the real world. This will give

[openstack-dev] [Nova][Sahara][Heat] Kilo RC2 available