date:20150610

On 10 June 2015 at 20:12, Matthias Runge mru...@redhat.com wrote:

 Since our software is to be consumed by packages, shouldn't the packages
 project consider itself to be responsible for global requirements? I.e.
 checking, if requirements are packageable, if versions fit, etc.

I think we welcome input from distribution maintainers on
global-requirements; especially for new packages.

But, the responsibility is ultimately a team effort: all the
components of openstack have to meet the operator/distributor
co-installability requirement. If one project has a minimum version of
X, its not possible for other projects to have a max version of  X
otherwise we're not coinstallable. This works both ways of course.

 In some distros, there are multiple versions of the same package allowed, in
 others, it's forbidden.

Thats true, but its also a per-distro thing. Within a distro you need
to be consistent. There's no need for RHEL to match RDO for instance,
and trying to make that happen across a dozen redistributors in the
OpenStack context makes no sense at all. We're moving to making our
ranges as wide as we can to make life easier for anyone that wants to
pick slightly different versions: we can't assert that it will work,
but unless we know it doesnt', we won't preclude you trying :)

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [packaging] Adding packaging as an OpenStack project

2015-06-10 Thread Dirk Müller

Hi Derek,

 I selected these 80 to move all of what RDO is currently maintaining on
 gerrithub to review.openstack.org, this was perhaps too big a set and in RDO
 we instead may need to go hybrid.

Yeah, In my opinion we ahve lots of repeated divergence between the
different python modules, so getting them sorted out in a small set of
packages and then extending it to all python-* modules (and then as a
3rd step to all openstack-* modules) would be a better approach in my
opinion (small steps).

 1. pull what I've proposed (or a subset of it) into a rpm namespace and from
 there work in package to get them to a point where all rpm interested
 parties can use them.

+1

 3. Same as 2 but start with Suse packaging

well, imho we should have a look at which starting point makes more
sense for both of us. I see goods and bads in the spec files on both
sides (of course my view is a bit biased on that :-) ).

 For this specific example I think differences of opinion are ok, we should
 provide the tools for each party interest in the packaging can hook in their
 own patches (I'm not sure what this would look like yet), I'm assuming here
 that we would also have deployer's out there interested who would have their
 own custom patches and bug fixes that they are interested in.

Right, that might be a good solution (use pristine upstream packaging
and provide tools for downstream to modify/add patches easily).
For most of the python-* dependencies we have zero patches so its not
a big issue for the initial step, it gets more complex as we get
closer to the python*clients and openstack* packages, as we tend to
have a need for patches in there that have not yet been merged
upstream (for whatever reason).

 +1, maybe we should schedule something in a few days where we could go
 though the differences of a specific package and how things could take
 shape.

Good idea. Whats a good time and date? I'm mostly available
tomorrow-Sunday in the CEST time zone.

Greetings,
Dirk

__
OpenStack Development Mailing 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] [murano] shellcheck all .sh scripts in murano-deployment

2015-06-10 Thread Filip Blaha

+1, nice idea. Shell script are not easy to review - large files, not 
covered by unit tests. Any automatic tool could be beneficial.


Regards
Filip

On 06/09/2015 09:58 PM, Kirill Zaitsev wrote:
Folks, I’ve got another proposal, mainly to the guys, who deal with CI 
and test jobs daily.


What would you say about adding a job to murano-deployment, that would 
launch shellcheck http://www.shellcheck.net/about.html against all .sh 
files?


I use it, when reviewing .sh scripts (well, actually my vim does it 
for me =P) and although It has some excessive checks I find it quite 
useful.


We could also add a similar job to murano-apps, since they use shell 
scripts quite often.


Any objections to this idea?


--
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc


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


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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 10 June 2015 at 11:07, Robert Collins robe...@robertcollins.net wrote:
 On 10 June 2015 at 20:12, Matthias Runge mru...@redhat.com wrote:

 Since our software is to be consumed by packages, shouldn't the packages
 project consider itself to be responsible for global requirements? I.e.
 checking, if requirements are packageable, if versions fit, etc.

 I think we welcome input from distribution maintainers on
 global-requirements; especially for new packages.

 But, the responsibility is ultimately a team effort: all the
 components of openstack have to meet the operator/distributor
 co-installability requirement. If one project has a minimum version of
 X, its not possible for other projects to have a max version of  X
 otherwise we're not coinstallable. This works both ways of course.

 In some distros, there are multiple versions of the same package allowed, in
 others, it's forbidden.

 Thats true, but its also a per-distro thing. Within a distro you need
 to be consistent. There's no need for RHEL to match RDO for instance,
 and trying to make that happen across a dozen redistributors in the
 OpenStack context makes no sense at all. We're moving to making our
 ranges as wide as we can to make life easier for anyone that wants to
 pick slightly different versions: we can't assert that it will work,
 but unless we know it doesnt', we won't preclude you trying :)

 -Rob


Just to add some history here, this was *precisely* the problems that
vendors were having - but worse, each openstack project had
conflicting version requirements making it really quite hard for
distro's to centralise package this..

This is why the project, openstack/requirements was created to
centralise the management of this to avoid conflicting version
requirements AND get input back from distro's and vendors.  The
initial core reviewers was seeded by representatives of distro's and
vendors to get their input on viability in distro's.

Vendors and distro's didn't engage as much as they could have (myself
included), which means that they had less input.  It is pretty easy to
get that input back, you just need to review the incoming changes:
https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master,n,z

I did start working on a jenkins job to check distro's to see what
version of package was already in releases, but it wasn't really
reliable enough, so I dropped it on the floor.  If you wanted to work
on a jenkins job to provide advise on proposed changesets, I am sure
the infra' team would be supportive.

--
Kind Regards,
Dave Walker

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

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

2015-06-10 Thread Boris Pavlovic

Dmitry,

We introduced recently dsvm rally ironic job:
https://review.openstack.org/#/c/187997/

Now we are working on Rally tests for Ironic:
https://review.openstack.org/#/c/186064/

Don't hesitate to join us=)

Best regards,
Boris Pavlovic

On Wed, Jun 10, 2015 at 1:23 PM, Dmitry Tantsur dtant...@redhat.com wrote:

 On 06/10/2015 11:57 AM, Boris Pavlovic wrote:

 Dmitry,

 If you chose to use Rally framework for testing there are 3 opportunities:

   - Keep Rally plugins (tests) in separated tree
   - Keep Rally plugins (tests) in your project tree
   - Keep Rally plugins (tests) in Rally repo

 Rally plugins can be used for all kinds of testing: (perf, scalability,
 load...)
 so you are killing two birds with one stone.

 P.S. I would imho prefer to keep all high quality plugins inside Rally
 repo to simplify operators life..


 Hi, that sounds interesting, I'll have a look.

 Note, however, that Inspector integration testing highly depends on Ironic
 one, so unless Ironic adapts/agrees to adapt Rally, it will be hard to
 Inspector to do it.



 Best regards,
 Boris Pavlovic

 On Wed, Jun 10, 2015 at 11:57 AM, Ken'ichi Ohmichi
 ken1ohmi...@gmail.com mailto:ken1ohmi...@gmail.com wrote:

 2015-06-10 16:48 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
 mailto:dtant...@redhat.com:

  On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote:
  To solve it, we have decided the scope of Tempest as the etherpad
  mentioned.
 
  Are there any hints now on where we can start with our
 integration tests?
 
 
  For the other projects, we are migrating the test framework of
 Tempest
  to tempest-lib which is a library.
  So each project can implement their own tests in each repository by
  using the test framework of tempest-lib.
 
 
  So in my case we can start with putting test code to
 ironic-inspector tree
  using tempest-lib, right?

 Yeah, right.
 Neutron is already doing that.
 maybe neutron/tests/api/ of Neutron repository will be a hint for it.

  Will it be possible to run tests on Ironic as well using plugin from
  ironic-inspector?

 Yeah, it will be possible.
 but I'm guessing ironic-inspector is optional and Ironic should not
 depend on the gate test result of ironic-inspector.
 So maybe you just need to run Ironic tests on ironic-inspector gate
 tests, right?

  After a quick look at devstack-gate I got an impression that it's
  expecting
  tests as part of tempest:
 
 
 https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L600
 
  Our final goal is to have devstack gate test for Ironic and
 Inspector
  projects working together.
 
 
  We have discussed external interfaces of Tempest on the summit, so
  that Tempest gathers tests from each project repository and runs
 them
  at the same time.
  There is a qa-spec forhttps://review.openstack.org/#/c/184992/

 
 
  Cool, thanks! Does it mean that devstack-gate will also be updated
 to allow
  something like DEVSTACK_GATE_TEMPEST_PLUGINS=https://github.com/..
 .?

 Yeah, will be.
 The idea of this external interface is based on DevStack's one.
 I think we will be able to use it on the gate like that.

 Thanks
 Ken'ichi Ohmichi

 ---

   On 06/10/2015 08:07 AM, Yuiko Takada wrote:
  
  
   Hi, Dmitry,
  
I guess the whole idea of new release models is NOT to
 tie projects
to each other any more except for The Big Release twice a
 year :)
   So
I think no, we don't need to. We still can do it, if we
 have
something to release by the time Ironic releases, but I
 suggest
deciding it on case-by-case basis.
  
   OK, I see.
  
   One more concern, about Tempest integration test which I will
 implement
   in V2.1.0,
   it seems like that we cannot add Ironic-inspector's tests into
 Tempest
   even if integration tests.
   Please see:
   https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent
  
  
  
   Good catch. I guess the answer depends on where Ironic
 integration tests
   are
   going to live - we're going to live with them. Let me retarget
 this
   thread
   to a wider audience.
  
  
   But I heard from you that Devananda thinks we need this in
 tempest
   itself. [3]
   Do you know something like current situation?
  
  
   Best Regards,
   Yuiko Takada
  
   2015-06-09 15:59 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
 mailto:dtant...@redhat.com
   mailto:dtant...@redhat.com mailto:dtant...@redhat.com:

  
On 06/09/2015 03:49 AM, Yuiko Takada wrote:
  
Hi, Dmitry,
  
Thank you for notifying.
  
 I've updated our summit etherpad

[openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

2015-06-10 Thread Dmitry Tantsur


Hi, QA folks!

As ironic-inspector is joining the openstack/* crows, we're faces with 
integration testing question. At the summit we discussed with Devananda 
that it makes sense for inspector + ironic integration test to live in 
tempest with other bare metal tests.


However, judging by 
https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent even Ironic 
integration tests will no longer be welcome in Tempest itself, to say 
nothing about pretty new Inspector.


Are there any hints now on where we can start with our integration 
tests? After a quick look at devstack-gate I got an impression that it's 
expecting tests as part of tempest:

https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L600

Our final goal is to have devstack gate test for Ironic and Inspector 
projects working together.


Cheers,
Dmitry

On 06/10/2015 08:07 AM, Yuiko Takada wrote:

Hi, Dmitry,

I guess the whole idea of new release models is NOT to tie projects
to each other any more except for The Big Release twice a year :) So
I think no, we don't need to. We still can do it, if we have
something to release by the time Ironic releases, but I suggest
deciding it on case-by-case basis.

OK, I see.

One more concern, about Tempest integration test which I will implement
in V2.1.0,
it seems like that we cannot add Ironic-inspector's tests into Tempest
even if integration tests.
Please see:
https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent


Good catch. I guess the answer depends on where Ironic integration tests 
are going to live - we're going to live with them. Let me retarget this 
thread to a wider audience.




But I heard from you that Devananda thinks we need this in tempest
itself. [3]
Do you know something like current situation?


Best Regards,
Yuiko Takada

2015-06-09 15:59 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com:

On 06/09/2015 03:49 AM, Yuiko Takada wrote:

Hi, Dmitry,

Thank you for notifying.

 I've updated our summit etherpad [3] with whatever priorities I
 remembered, please have a look. I've also untargeted a few
things in
 launchpad [4] (and will probably untarget more later on).
Please
 assign yourself, if you want something done in this release
time frame.

I've assigned one item to myself in [3], and also I added one BP
to [4],
so please take a look.
https://blueprints.launchpad.net/ironic-inspector/+spec/delete-db-api


Looks good, though I don't think it's a big priority for 2.0.0.
Definitely worth doing for 2.1.0.

Thanks for assigning for tempest work, that's definitely a priority
right now.


BTW, how do you think about Ironic-inspector's release model?
You wrote Version released with Ironic Liberty as
Ironic-inspector Version 2.1.0 in etherpad [3],
but as you know, Ironic's release model has changed to feature
releases.(right?)
Should we make our release model same as Ironic?


I guess the whole idea of new release models is NOT to tie projects
to each other any more except for The Big Release twice a year :) So
I think no, we don't need to. We still can do it, if we have
something to release by the time Ironic releases, but I suggest
deciding it on case-by-case basis.



Best Regards,
Yuiko Takada(Inspector team member)

2015-06-08 20:38 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com
mailto:dtant...@redhat.com mailto:dtant...@redhat.com:


 Hello, Inspector team!

 The renaming process is going pretty well, the last thing
we need to
 do is to get Infra approval and actual rename [1][2].

 I'd like to allow people (e.g. myself) to start packaging
inspector
 under it's new name, so I'd like to make 2.0.0 release as
soon as
 possible (as opposed to scheduling it to particular date). All
 breaking changes should land by this release - I don't
expect 3.0.0
 soon :)

 I've updated our summit etherpad [3] with whatever priorities I
 remembered, please have a look. I've also untargeted a few
things in
 launchpad [4] (and will probably untarget more later on).
Please
 assign yourself, if you want something done in this release
time frame.

 I would like 2.1.0 to be released with Ironic Liberty and be
 properly supported.

 Let me know what you think.

 Cheers,
 Dmitry

 [1] https://review.openstack.org/#/c/188030/
 [2] https://review.openstack.org/#/c/188798/
 [3] https://etherpad.openstack.org/p/liberty-ironic-discoverd
 [4]

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

2015-06-10 Thread Dmitry Tantsur


On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote:

Hi Dmitry,

2015-06-10 16:11 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:

Hi, QA folks!

As ironic-inspector is joining the openstack/* crows, we're faces with
integration testing question. At the summit we discussed with Devananda that
it makes sense for inspector + ironic integration test to live in tempest
with other bare metal tests.

However, judging by https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent
even Ironic integration tests will no longer be welcome in Tempest itself,
to say nothing about pretty new Inspector.


Yeah, right.
On big-tent trend, it is difficult to cover/review test of all
projects by a single Tempest-team.
It is easy to imagine Tempest-team will be bottleneck of developments
if continuing current way.


+1


To solve it, we have decided the scope of Tempest as the etherpad mentioned.


Are there any hints now on where we can start with our integration tests?


For the other projects, we are migrating the test framework of Tempest
to tempest-lib which is a library.
So each project can implement their own tests in each repository by
using the test framework of tempest-lib.


So in my case we can start with putting test code to ironic-inspector 
tree using tempest-lib, right?


Will it be possible to run tests on Ironic as well using plugin from 
ironic-inspector?





After a quick look at devstack-gate I got an impression that it's expecting
tests as part of tempest:
https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L600

Our final goal is to have devstack gate test for Ironic and Inspector
projects working together.


We have discussed external interfaces of Tempest on the summit, so
that Tempest gathers tests from each project repository and runs them
at the same time.
There is a qa-spec for https://review.openstack.org/#/c/184992/


Cool, thanks! Does it mean that devstack-gate will also be updated to 
allow something like DEVSTACK_GATE_TEMPEST_PLUGINS=https://github.com/...;?




Thanks
Ken'ichi Ohmichi




On 06/10/2015 08:07 AM, Yuiko Takada wrote:


Hi, Dmitry,

 I guess the whole idea of new release models is NOT to tie projects
 to each other any more except for The Big Release twice a year :) So
 I think no, we don't need to. We still can do it, if we have
 something to release by the time Ironic releases, but I suggest
 deciding it on case-by-case basis.

OK, I see.

One more concern, about Tempest integration test which I will implement
in V2.1.0,
it seems like that we cannot add Ironic-inspector's tests into Tempest
even if integration tests.
Please see:
https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent



Good catch. I guess the answer depends on where Ironic integration tests are
going to live - we're going to live with them. Let me retarget this thread
to a wider audience.



But I heard from you that Devananda thinks we need this in tempest
itself. [3]
Do you know something like current situation?


Best Regards,
Yuiko Takada

2015-06-09 15:59 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com:

 On 06/09/2015 03:49 AM, Yuiko Takada wrote:

 Hi, Dmitry,

 Thank you for notifying.

  I've updated our summit etherpad [3] with whatever priorities
I
  remembered, please have a look. I've also untargeted a few
 things in
  launchpad [4] (and will probably untarget more later on).
 Please
  assign yourself, if you want something done in this release
 time frame.

 I've assigned one item to myself in [3], and also I added one BP
 to [4],
 so please take a look.

https://blueprints.launchpad.net/ironic-inspector/+spec/delete-db-api


 Looks good, though I don't think it's a big priority for 2.0.0.
 Definitely worth doing for 2.1.0.

 Thanks for assigning for tempest work, that's definitely a priority
 right now.


 BTW, how do you think about Ironic-inspector's release model?
 You wrote Version released with Ironic Liberty as
 Ironic-inspector Version 2.1.0 in etherpad [3],
 but as you know, Ironic's release model has changed to feature
 releases.(right?)
 Should we make our release model same as Ironic?


 I guess the whole idea of new release models is NOT to tie projects
 to each other any more except for The Big Release twice a year :) So
 I think no, we don't need to. We still can do it, if we have
 something to release by the time Ironic releases, but I suggest
 deciding it on case-by-case basis.



 Best Regards,
 Yuiko Takada(Inspector team member)

 2015-06-08 20:38 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
 mailto:dtant...@redhat.com
 mailto:dtant...@redhat.com mailto:dtant...@redhat.com:


  Hello, Inspector team!

  The renaming process is going pretty well,

Re: [openstack-dev] [Nova] Liberty Priorties for Nova

2015-06-10 Thread Daniel P. Berrange

On Wed, Jun 10, 2015 at 08:48:36AM +0200, Andreas Scheuring wrote:
 Daniel, 
 if I got it right, the vif script blueprint only is about plug/unplug
 operations and not about generating new xml representations for vif
 types. What if for a new vif type it's sufficient to have the
 get_config_* method updated? In this case plug/unplug would be handled
 by libvirt (like with many other existing vif types). The plug/unplug
 methods would just contain a pass.
 
 Would you tend to be supportive in such cases?

Probably, but it depends if there is any overlap with existing VIF
drivers in terms of libvirt config generated.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] doubt about static routes and host routes

2015-06-10 Thread Kevin Benton

Yes, static routes can be added to the router:
https://ask.openstack.org/en/question/42529/how-to-add-extra-static-route-in-neutron-havana/

host_routes are routes advertised to the clients via DHCP, they don't apply
to the router.

I also would like to know use case of static routes of router and
--host_routes of subnet ?

Static routes can be used to get to a subnet reachable via one of your
instances that acts as a router. That's just one use case.

host_routes can achieve something similar so the instances don't have to go
through the router if they are on the same subnet as the next hop.

On Wed, Jun 10, 2015 at 2:12 AM, Saju M sajup...@gmail.com wrote:

 Hi,

 Can we add static routes to the router which created by #neutron
 router-create command ?

 What is the defference static routes of router and --host_routes of subnet
 ?

 I also would like to know use case of static routes of router and
 --host_routes of subnet ?

 Regards
 Saju Madhavan
 +91 09535134654

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




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

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

2015-06-10 Thread Ken'ichi Ohmichi

2015-06-10 16:48 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:
 On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote:
 To solve it, we have decided the scope of Tempest as the etherpad
 mentioned.

 Are there any hints now on where we can start with our integration tests?


 For the other projects, we are migrating the test framework of Tempest
 to tempest-lib which is a library.
 So each project can implement their own tests in each repository by
 using the test framework of tempest-lib.


 So in my case we can start with putting test code to ironic-inspector tree
 using tempest-lib, right?

Yeah, right.
Neutron is already doing that.
maybe neutron/tests/api/ of Neutron repository will be a hint for it.

 Will it be possible to run tests on Ironic as well using plugin from
 ironic-inspector?

Yeah, it will be possible.
but I'm guessing ironic-inspector is optional and Ironic should not
depend on the gate test result of ironic-inspector.
So maybe you just need to run Ironic tests on ironic-inspector gate
tests, right?

 After a quick look at devstack-gate I got an impression that it's
 expecting
 tests as part of tempest:

 https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L600

 Our final goal is to have devstack gate test for Ironic and Inspector
 projects working together.


 We have discussed external interfaces of Tempest on the summit, so
 that Tempest gathers tests from each project repository and runs them
 at the same time.
 There is a qa-spec for https://review.openstack.org/#/c/184992/


 Cool, thanks! Does it mean that devstack-gate will also be updated to allow
 something like DEVSTACK_GATE_TEMPEST_PLUGINS=https://github.com/...;?

Yeah, will be.
The idea of this external interface is based on DevStack's one.
I think we will be able to use it on the gate like that.

Thanks
Ken'ichi Ohmichi

---

 On 06/10/2015 08:07 AM, Yuiko Takada wrote:


 Hi, Dmitry,

  I guess the whole idea of new release models is NOT to tie projects
  to each other any more except for The Big Release twice a year :)
 So
  I think no, we don't need to. We still can do it, if we have
  something to release by the time Ironic releases, but I suggest
  deciding it on case-by-case basis.

 OK, I see.

 One more concern, about Tempest integration test which I will implement
 in V2.1.0,
 it seems like that we cannot add Ironic-inspector's tests into Tempest
 even if integration tests.
 Please see:
 https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent



 Good catch. I guess the answer depends on where Ironic integration tests
 are
 going to live - we're going to live with them. Let me retarget this
 thread
 to a wider audience.


 But I heard from you that Devananda thinks we need this in tempest
 itself. [3]
 Do you know something like current situation?


 Best Regards,
 Yuiko Takada

 2015-06-09 15:59 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
 mailto:dtant...@redhat.com:

  On 06/09/2015 03:49 AM, Yuiko Takada wrote:

  Hi, Dmitry,

  Thank you for notifying.

   I've updated our summit etherpad [3] with whatever
 priorities
 I
   remembered, please have a look. I've also untargeted a few
  things in
   launchpad [4] (and will probably untarget more later on).
  Please
   assign yourself, if you want something done in this
 release
  time frame.

  I've assigned one item to myself in [3], and also I added one
 BP
  to [4],
  so please take a look.

 https://blueprints.launchpad.net/ironic-inspector/+spec/delete-db-api


  Looks good, though I don't think it's a big priority for 2.0.0.
  Definitely worth doing for 2.1.0.

  Thanks for assigning for tempest work, that's definitely a priority
  right now.


  BTW, how do you think about Ironic-inspector's release model?
  You wrote Version released with Ironic Liberty as
  Ironic-inspector Version 2.1.0 in etherpad [3],
  but as you know, Ironic's release model has changed to feature
  releases.(right?)
  Should we make our release model same as Ironic?


  I guess the whole idea of new release models is NOT to tie projects
  to each other any more except for The Big Release twice a year :)
 So
  I think no, we don't need to. We still can do it, if we have
  something to release by the time Ironic releases, but I suggest
  deciding it on case-by-case basis.



  Best Regards,
  Yuiko Takada(Inspector team member)

  2015-06-08 20:38 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
  mailto:dtant...@redhat.com
  mailto:dtant...@redhat.com mailto:dtant...@redhat.com:


   Hello, Inspector team!

   The renaming process is going pretty well, the last thing
  we need to
   do is to get Infra approval and actual rename [1][2].

   I'd like to

Re: [openstack-dev] [release][oslo] oslotest release 1.7.0 (liberty)

2015-06-10 Thread Victor Sergeyev

Hi All,

this oslotest release break oslo.messaging gate - unittest fails
with ImportError, on import mox from six.moves - [0].
It caused by commit [1], which removed adding mox to six moves.

There is a fix for oslo.messaging - [2] - please, help to merge it.

[0] - http://paste.openstack.org/show/281091/
[1] -
https://github.com/openstack/oslotest/commit/9e0c8ad2c251274128499a7fcfb591c488d27d2b
[2] - https://review.openstack.org/190136

Thanks,
Victor

On Tue, Jun 9, 2015 at 6:14 PM, d...@doughellmann.com wrote:

 We are content to announce the release of:

 oslotest 1.7.0: Oslo test framework

 This release is part of the liberty release series.

 With source available at:

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

 For more details, please see the git log history below and:

 http://launchpad.net/oslotest/+milestone/1.7.0

 Please report issues through launchpad:

 http://bugs.launchpad.net/oslotest

 Changes in oslotest 1.6.0..1.7.0
 

 5bd9b31 Updated from global requirements
 ff9b38e Fix argument handling in oslo_run_cross_tests
 960e444 Add class to deal with clouds.yaml support
 1c0863f Remove unneeded runtime pbr dep
 5f2e635 Updated from global requirements
 f8a5a3c Advertise support for Python3.4 / Remove support for Python 3.3
 a063f25 Do not sync run_cross_tests.sh
 0782ab7 Remove unused discover dependency
 9e0c8ad Remove six.moves call

 Diffstat (except docs and test files)
 -

 openstack-common.conf  |  7 --
 oslotest/__init__.py   |  1 -
 oslotest/functional.py | 59
 ++
 oslotest/moxstubout.py |  2 +-
 requirements.txt   |  3 +--
 setup.cfg  |  6 +
 tox.ini|  3 +--
 8 files changed, 83 insertions(+), 30 deletions(-)


 Requirements updates
 

 diff --git a/requirements.txt b/requirements.txt
 index 674130c..1486ede 100644
 --- a/requirements.txt
 +++ b/requirements.txt
 @@ -5,2 +4,0 @@
 -pbr=0.6,!=0.7,1.0
 -discover
 @@ -14,0 +13 @@ mox3=0.7.0
 +os-client-config=1.2.0



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

__
OpenStack Development Mailing 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] [packaging] Adding packaging as an OpenStack project

2015-06-10 Thread Doug Hellmann

Excerpts from Matthias Runge's message of 2015-06-10 12:29:45 +0200:
 On 10/06/15 12:07, Robert Collins wrote:
  On 10 June 2015 at 20:12, Matthias Runge mru...@redhat.com wrote:
 
  Since our software is to be consumed by packages, shouldn't the packages
  project consider itself to be responsible for global requirements? I.e.
  checking, if requirements are packageable, if versions fit, etc.
 
  I think we welcome input from distribution maintainers on
  global-requirements; especially for new packages.
 
  But, the responsibility is ultimately a team effort: all the
  components of openstack have to meet the operator/distributor
  co-installability requirement. If one project has a minimum version of
  X, its not possible for other projects to have a max version of  X
  otherwise we're not coinstallable. This works both ways of course.
 
 My wording was not that good here.
 
 I know, some distro packagers are already looking at changes, but maybe 
 this could be improved, i.e. intensified? It was more about: giving this 
 more basic openstack effort a home in a project.

Given the history of lack of interest, I would want to see a significant
increase in reviews from that team before giving them control of the
repository.

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] [Barbican] Multiple KMIP servers on a single barbican

2015-06-10 Thread Nathan Reller

You would need to update the KMIPSecretStore or create a new
SecretStore to handle this. The logic should be behind the SecretStore
abstraction because Barbican only allows one active secret store.

I would think that the configuration file would have a listing of
available KMIP server URLs.

The URL as to where each key is stored would not be in the DTO but
rather in the metadata associated with a secret. The return calls for
the generate and store methods would return this metadata. Then all of
the other calls would need to parse the metadata to determine where
the secret is stored, so it would contact the correct KMIP server.

That's how I am envisioning it, but perhaps you have a better design
in which case I would vote for that one :)

-Nate

__
OpenStack Development Mailing 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] ThirdPartyCI: Tempest job fails with Unexpected termination of the channel

2015-06-10 Thread Lenny Verkhovsky

Can you check dmesg –T to see at least if the messages are not too old?
Are you using port2 as a connection to VM?



Lenny Verkhovsky

From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
Sent: Wednesday, June 10, 2015 10:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] ThirdPartyCI: Tempest job fails with Unexpected 
termination of the channel

Short story:
- all runs of the tempest job are failing after ~ 1,5 - 2 hrs with  FATAL: 
java.io.IOException: Unexpected termination of the channel and jenkins logs 
SEVERE: I/O error in channel d-p-c-local_01-1655 java.io.IOException: 
Unexpected termination of the channel

Long story:
- Host is 4 core Intel Xeon, 32GB RAM, 3x1TB HDD
-- devstack is 2015.1.1, networking is done via n-net
- Jenkins master is a VM, 2 core, 8 GB RAM, 500 GB disk
-- not managed through devstack, but using virsh, networking done manually via 
iptables
- test slaves are VMs, m1.large (4 VCPU, 8 GB RAM, trusty), managed by nodepool

Load on master is usually around 6-7, memory usage around 90%, little swapping.

I tried increasing ClientAliveInterval/ServerAliveInterval and 
ClientAliveCountMax/ServerAliveCountMax on both the Jenkins VM and on the test 
vm (using the job to configure), but it still fails with the above mentioned 
error.

On the host, dmesg is full of: (not sure if directly related to this)
[1037245.231196] br100: port 2(vnet1) entered disabled state
followed by
[1037259.147672] br100: port 2(vnet1) entered forwarding state

I think it might be something related to networking on the host itself but i 
couldn't figure it yet.

Any suggestion on what to try next?

Thanks,
Eduard

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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 06/09/2015 04:54 PM, Jeremy Stanley wrote:
 On 2015-06-09 10:55:55 +0200 (+0200), Thomas Goirand wrote:
 [...]
 That's far from being in place. Also, while we are removing point
 releases, and support for Icehouse, we still don't have a common private
 Gerrit for security, which we've been told about 2 years ago.

 Removing collaboration tools before new ones are in place is
 definitively not the way to go.
 [...]
 
 In the stable branch management session at the Liberty summit, the
 Infrastructure Team position was confirmed that we can't maintain
 non-supported branches in a second Gerrit any more than we can in
 the primary one. The idea that there might be some branch of an
 OpenStack project which we just give up on testing but keep
 available for new changes is distasteful from a quality perspective.
 If there is sufficient interest from distro representatives in
 collaborating upstream on backports to, for example, stable/icehouse
 then that interest needs to include the resources necessary to
 maintain sufficient testing upstream (as defined by the upstream
 community).

Jeremy,

I have made a round table in Paris, and I have names of interested
people who would work on this. But without a collaboration tool (and at
least a common Git repository to work on), it is going to be harder to
work on together.

 So, I'm sorry, but don't look to an OpenStack-maintained non-public
 code review system as a workaround for continuing to collaborate in
 private on branches unsupported upstream in public. Most of the time
 it ends up being non-distro upstream developers (quality assurance,
 release management, infrastructure, vulnerability management,
 individual projects) who bear the majority of the responsibility for
 keeping testing working on those branches and we're clearly at our
 breaking point now trying to maintain three besides our master
 branch.

I understand, and I haven't asked the VMT or anyone upstream to work on
this.

 If the interested distributions come back with teams of people to
 dedicate to this work, which means getting deeply embedded in the
 groups who currently maintain the existing testing and release
 management for stable branches and are currently understaffed for
 that effort, then we can certainly revisit the number of branches
 we're able to maintain in both the public and (future) embargoed
 security review systems.

As we discussed, the goal isn't to maintain upstream CI, but to have a
place to share our work between distributions. We would do the testing
downstream, not using OpenStack infra.

Please get this security gerrit up, so that we can work on a patch
during the embargo period.

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] doubt about static routes and host routes

2015-06-10 Thread Saju M

Hi,

Can we add static routes to the router which created by #neutron
router-create command ?

What is the defference static routes of router and --host_routes of subnet
?

I also would like to know use case of static routes of router and
--host_routes of subnet ?

Regards
Saju Madhavan
+91 09535134654
__
OpenStack Development Mailing 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] [rabbitmq] ANN New ops-oriented guides on rabbitmq.com

2015-06-10 Thread Michael Klishin

First of all, apologies if this belongs strictly to openstack-docs,
based on multiple discussions in Vancouver I'd like more people to be aware of 
this.

As announced in April and at the summit in May, RabbitMQ
team at Pivotal  would like to help with OpenStack documentation and operations
experience around RabbitMQ.
It was later decided that most of the docs improvements should go to 
rabbitmq.com.

I'm happy to announced that we recently have shipped two new ops-oriented
guides:

 * Networking: http://www.rabbitmq.com/networking.html 
 * Production Checklist: http://www.rabbitmq.com/production-checklist.html 

The former covers multiple subjects related to networking, in particular 
tuning for two common scenarios: maximum throughput and highest possible number 
of concurrent connections. 
The latter is aimed at users looking to move into production or validate their 
existing deployment.

Nothing not OpenStack-specific so far but should be relevant to OpenStack 
operators.
Expansions to the above guides and more OpenStack-focused docs are coming
as time permits.

Cheers.
--  
MK  

Staff Software Engineer, Pivotal/RabbitMQ  



__
OpenStack Development Mailing 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][python3] use of six.iteritems()

On 10 June 2015 at 21:30, Ihar Hrachyshka ihrac...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 06/10/2015 02:15 AM, Robert Collins wrote:
 I'm very glad folk are working on Python3 ports.

 I'd like to call attention to one little wart in that process: I
 get the feeling that folk are applying a massive regex to find
 things like d.iteritems() and convert that to six.iteritems(d).

 I'd very much prefer that such a regex approach move things to
 d.items(), which is much easier to read.

 Here's why. Firstly, very very very few of our dict iterations are
 going to be performance sensitive in the way that iteritems()
 matters. Secondly, no really - unless you're doing HUGE dicts, it
 doesn't matter. Thirdly. Really, it doesn't.


 Does it hurt though? ;)

Yes.

Its: harder to read. Its going to have to be removed eventually anyway
(when we stop supporting 2.7). Its marginally slower on 3.x (it has a
function and an iterator wrapping the actual thing). Its unidiomatic,
and we get lots of programmers that are new to Python; we should be
giving them as beautiful code as we can to help them learn.

 At 1 million items the overhead is 54ms[1]. If we're doing inner
 loops on million item dictionaries anywhere in OpenStack today, we
 have a problem. We might want to in e.g. the scheduler... if it
 held in-memory state on a million hypervisors at once, because I
 don't really to to imagine it pulling a million rows from a DB on
 every action. But then, we'd be looking at a whole 54ms. I think we
 could survive, if we did that (which we don't).

 So - please, no six.iteritems().


 The reason why in e.g. neutron we merged the patch using six.iteritems
 is that we don't want to go too deep into determining whether the
 original usage of iteritems() was justified.

Its not.

 The goal of the patch is
 to get python3 support, not to apply subjective style guidelines, so
 if someone wants to eliminate .iteritems(), he should create another
 patch just for that and struggle with reviewing it. While folks
 interested python3 can proceed with their work.

 We should not be afraid of multiple patches.

We shouldn't be indeed. All I'm asking is that we don't do poor
intermediate patches.

I've written code where performance tuning like that around iteritems
mattered. That code also needed to optimise tuple unpacking to avoid
performance hits and was aiming to manipulate million item data sets
from interpreter startup in subsecond times. It was some of the worst,
most impenetrable Python code I've ever seen, and while our code has
lots of issues, it neither has the same performance context that that
did, nor (thankfully) is it such impenetrable code.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 10 June 2015 at 09:53, Thomas Goirand z...@debian.org wrote:
 On 06/05/2015 02:46 PM, Thierry Carrez wrote:
 So.. summarizing the various options again:

 Plan A
 Just drop stable point releases.
 (-) No more release notes
 (-) Lack of reference points to compare installations

 Plan B
 Push date-based tags across supported projects from time to time.
 (-) Encourages to continue using same version across the board
 (-) Almost as much work as making proper releases

 Plan C
 Let projects randomly tag point releases whenever
 (-) Still a bit costly in terms of herding cats

 Plan D
 Drop stable point releases, publish per-commit tarballs
 (-) Requires some infra changes, takes some storage space

 Plans B, C and D also require some release note / changelog generation
 from data maintained *within* the repository.

 Personally I think the objections raised against plan A are valid. I
 like plan D, since it's more like releasing every commit than not
 releasing anymore. I think it's the most honest trade-off. I could go
 with plan C, but I think it's added work for no additional value to the
 user.

 What would be your preferred option ?

 I see no point of doing D. I already don't use tarballs, and those who
 do could as well switch to generating them (how hard is it to run
 python setup.py sdist or git archive?).

 What counts is having a schedule date, where all distros are releasing a
 point release, so we have a common reference point. If that is a fully
 automated process, then great, less work for everyone, and it wont
 change anything from what we had in the past (we can even collectively
 decide for point release dates...).

 Cheers,

 Thomas Goirand (zigo)

This is really one of the things I think we want to get away from...
If *every* stable commit is treated with the seriousness of it
creating a release, lets make every commit a release.

This means that Debian may be using a (micro)patch release newer or
older than a different distro, but the key is that it empowers the
vendors and/or users to select a release cadence that best fits them,
rather than being tied to an arbitrary upstream community wide date.

Yes, this might mean that your cadence might be more or less regular
than an alternative vendor / distribution, but the key is that it
empowers the vendor to meet the needs of their users/customers.

For example, you could select a cadence of rebasing to a release every
6 months - where as another consumer could choose to do one every 6
weeks.  The difference is how much of a jump, at which intervals..
Alternatively, a vendor might choose just to go with stock release +
their own select cherry picked patches from stable/*, which is also a
model that works.

The issue around producing tarballs, is really about having forwards
and backwards verification by means of sha/md5 sums, which is hard to
do when generating your own orig tarball.  Debian, Ubuntu and I
believe Arch have made varying use of 'pristine-tar' - which was an
effort to re-producible tarballs using xdelta to make the sum match.
However, Maintainers seem to be moving away from this now.

When I perform source NEW reviews for Ubuntu Archive, I always check
that getting the source orig tarball can be done with either
get-orig-source (inspecting the generation method) or uscan and then
diff the tarballs with the one included on the upload and the one
generated.  Timestamps (or even shasums) haven't been an important
issue for me, but the actual content and verifiable source is what has
mattered more.

--
Kind Regards,
Dave Walker

__
OpenStack Development Mailing 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] ThirdPartyCI: Tempest job fails with Unexpected termination of the channel

2015-06-10 Thread Eduard Matei

Short story:
- all runs of the tempest job are failing after ~ 1,5 - 2 hrs with  FATAL:
java.io.IOException: Unexpected termination of the channel and jenkins
logs SEVERE: I/O error in channel d-p-c-local_01-1655 java.io.IOException:
Unexpected termination of the channel

Long story:
- Host is 4 core Intel Xeon, 32GB RAM, 3x1TB HDD
-- devstack is 2015.1.1, networking is done via n-net
- Jenkins master is a VM, 2 core, 8 GB RAM, 500 GB disk
-- not managed through devstack, but using virsh, networking done manually
via iptables
- test slaves are VMs, m1.large (4 VCPU, 8 GB RAM, trusty), managed by
nodepool

Load on master is usually around 6-7, memory usage around 90%, little
swapping.

I tried increasing ClientAliveInterval/ServerAliveInterval and
ClientAliveCountMax/ServerAliveCountMax on both the Jenkins VM and on the
test vm (using the job to configure), but it still fails with the above
mentioned error.

On the host, dmesg is full of: (not sure if directly related to this)
[1037245.231196] br100: port 2(vnet1) entered disabled state
followed by
[1037259.147672] br100: port 2(vnet1) entered forwarding state

I think it might be something related to networking on the host itself but
i couldn't figure it yet.

Any suggestion on what to try next?

Thanks,
Eduard
__
OpenStack Development Mailing 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][api] 1 new guideline entering freeze period

michael mccune wrote:
 The API working group has one new guidelines that is entering the freeze
 period. We would like to ask all PTLs and CPLs, and other interested
 parties, to take a look at these reviews. We will use lazy consensus at
 the end of the freeze to merge them if there are no objections.
 
 The guideline up for review is:
 
 * Clarification on the return code when a server has a hard coded length
 limit
 https://review.openstack.org/#/c/181784/

Added this to next week cross-project meeting agenda so that it gets
more visibility.

Cheers,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

2015-06-10 Thread Li, Chen

Hello Manila,

There is a HDFS driver in Manila summited by our team in Kilo, so I guess we do 
own this driver in Manila for current situation.

But, CI systems are really new to us, and we heard from other teams that they 
took almost one year to implement a CI for going through all the company 
processes and building all related staff for it.
And , the biggest issue we have is there is not enough resource to actually 
implement and maintain the CI as that is not allowed by the team's strategy.

We strongly believe the HDFS driver will be really useful in Manila/Openstack, 
and might be used by other Openstack projects such as Sahara/Cognitive which 
are big data related projects in the near future, thus we don't want to see the 
driver to be remove.

Do we have a volunteer to take over the CI for HDFS driver as it is an open 
source distributed storage system which actually has no vendor dependency ?

Looking forward to your reply.

Thanks.
-chen


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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 06/05/2015 02:46 PM, Thierry Carrez wrote:
 So.. summarizing the various options again:
 
 Plan A
 Just drop stable point releases.
 (-) No more release notes
 (-) Lack of reference points to compare installations
 
 Plan B
 Push date-based tags across supported projects from time to time.
 (-) Encourages to continue using same version across the board
 (-) Almost as much work as making proper releases
 
 Plan C
 Let projects randomly tag point releases whenever
 (-) Still a bit costly in terms of herding cats
 
 Plan D
 Drop stable point releases, publish per-commit tarballs
 (-) Requires some infra changes, takes some storage space
 
 Plans B, C and D also require some release note / changelog generation
 from data maintained *within* the repository.
 
 Personally I think the objections raised against plan A are valid. I
 like plan D, since it's more like releasing every commit than not
 releasing anymore. I think it's the most honest trade-off. I could go
 with plan C, but I think it's added work for no additional value to the
 user.
 
 What would be your preferred option ?

I see no point of doing D. I already don't use tarballs, and those who
do could as well switch to generating them (how hard is it to run
python setup.py sdist or git archive?).

What counts is having a schedule date, where all distros are releasing a
point release, so we have a common reference point. If that is a fully
automated process, then great, less work for everyone, and it wont
change anything from what we had in the past (we can even collectively
decide for point release dates...).

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

Re: [openstack-dev] [all][python3] use of six.iteritems()

2015-06-10 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/10/2015 02:15 AM, Robert Collins wrote:
 I'm very glad folk are working on Python3 ports.
 
 I'd like to call attention to one little wart in that process: I
 get the feeling that folk are applying a massive regex to find
 things like d.iteritems() and convert that to six.iteritems(d).
 
 I'd very much prefer that such a regex approach move things to 
 d.items(), which is much easier to read.
 
 Here's why. Firstly, very very very few of our dict iterations are 
 going to be performance sensitive in the way that iteritems()
 matters. Secondly, no really - unless you're doing HUGE dicts, it
 doesn't matter. Thirdly. Really, it doesn't.
 

Does it hurt though? ;)

 At 1 million items the overhead is 54ms[1]. If we're doing inner
 loops on million item dictionaries anywhere in OpenStack today, we
 have a problem. We might want to in e.g. the scheduler... if it
 held in-memory state on a million hypervisors at once, because I
 don't really to to imagine it pulling a million rows from a DB on
 every action. But then, we'd be looking at a whole 54ms. I think we
 could survive, if we did that (which we don't).
 
 So - please, no six.iteritems().
 

The reason why in e.g. neutron we merged the patch using six.iteritems
is that we don't want to go too deep into determining whether the
original usage of iteritems() was justified. The goal of the patch is
to get python3 support, not to apply subjective style guidelines, so
if someone wants to eliminate .iteritems(), he should create another
patch just for that and struggle with reviewing it. While folks
interested python3 can proceed with their work.

We should not be afraid of multiple patches.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVeAO+AAoJEC5aWaUY1u57/XwH/0AsOQHa1IDWOauginSHAbi+
ZNwAUDRSKEI+ydwf9u/DxRkZP2MsiJwAbrlPeGyjr8aqNpqoTLcS5CxYaS7IqSOn
khrVGkczv6yNwKrB6j3jAFJtXz+Z2i475eTLJqRgdUeI4gJinhc0ghXJzF+4HpUN
2DewJlOqrD3OWJcUu0Gvmp4aEkr8JK0Iu2crCRoFJ2N5fvv7rt8FfcZ3oGkixJXd
n0+xD5Aszl8M/jAv3xt7ZxqFSL7QUiEhAVVgJEHm0D8mAR+2J9bpCKVvjkJ5T7Tw
fkHYXetzUipe0MMpXPl3jfSKBitpFOOOEBaqOSXvvgtxAo8U6nkNgPe6n+vuduc=
=lUY4
-END PGP SIGNATURE-

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

Re: [openstack-dev] OpenStack Diversity Working Group

2015-06-10 Thread Victoria Martínez de la Cruz

Hi all,

Thanks for starting this! I'd like to join you for the kick off meeting. In
which timezone are the times in the Doodle?

Cheers,

Victoria

2015-06-09 17:28 GMT-03:00 Sousou, Imad imad.sou...@intel.com:

  Stackers – We’re happy to announce the creation of a Diversity Working
 Group. The genesis for this work group was a discussion at the May meeting
 of the OpenStack Board of Directors ahead of the Vancouver Summit.



 The Board is committed to fostering an inclusive and welcoming place for
 all people to collaborate to drive innovation and design cutting-edge data
 center capabilities, while finding the best answers to our most pressing
 challenges. To achieve this, the Board formed this Work Group to determine
 what actions are required to fulfill this commitment. Three Board members
 volunteered to work with community members in this Work Group and bring
 updates/requests to the Board for discussion and action on a regular basis,
 starting with the July meeting.



 If you’re interested in joining this effort, please:

 · Join the Foundation mail list to participate in discussions and
 shape the direction: click here
 http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

 · Visit the wiki page for this work group to learn more about the
 charter: click here https://wiki.openstack.org/wiki/Diversity

 · Plan to join the kick-off IRC meeting and let us know what
 day/times work for you by accessing the Doodle here: click here
 http://doodle.com/z85c23dtexx8qzq7



 We will send out the results of the Doodle to the mail list and look
 forward to working with you to foster a strong and diverse community.



 Thanks

 Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)















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


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

Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x

Hi Mike,

Thanks a lot for your quick reply which is very useful to me.

On 06/09/2015 07:08 PM, Mike Bayer wrote:
 On 6/9/15 9:26 AM, Thomas Goirand wrote:
 Hi,

 The python-sqlalchemy package has been uploaded to Debian Experimental,
 and is about to be uploaded to Debian Unstable. So I wonder what's the
 state of the project regarding upgrading SQLA.

 Maybe Mike can tell what kind of issue we may run into? How much work
 will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be
 compatible with both 9.x and 1.x (which would be the best way forward)?
 
 The short answer is that there are no supported use cases that have been
 intentionally changed in any backwards incompatible way in 1.0 and all
 Openstack code should be able to accommodate from 0.9.x - 1.0.x without
 any change.

Ah, super cool!

I saw that this passed all tests:
https://review.openstack.org/#/c/189847/

Could we get it approved?

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] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

2015-06-10 Thread Ken'ichi Ohmichi

Hi Dmitry,

2015-06-10 16:11 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:
 Hi, QA folks!

 As ironic-inspector is joining the openstack/* crows, we're faces with
 integration testing question. At the summit we discussed with Devananda that
 it makes sense for inspector + ironic integration test to live in tempest
 with other bare metal tests.

 However, judging by https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent
 even Ironic integration tests will no longer be welcome in Tempest itself,
 to say nothing about pretty new Inspector.

Yeah, right.
On big-tent trend, it is difficult to cover/review test of all
projects by a single Tempest-team.
It is easy to imagine Tempest-team will be bottleneck of developments
if continuing current way.
To solve it, we have decided the scope of Tempest as the etherpad mentioned.

 Are there any hints now on where we can start with our integration tests?

For the other projects, we are migrating the test framework of Tempest
to tempest-lib which is a library.
So each project can implement their own tests in each repository by
using the test framework of tempest-lib.

 After a quick look at devstack-gate I got an impression that it's expecting
 tests as part of tempest:
 https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L600

 Our final goal is to have devstack gate test for Ironic and Inspector
 projects working together.

We have discussed external interfaces of Tempest on the summit, so
that Tempest gathers tests from each project repository and runs them
at the same time.
There is a qa-spec for https://review.openstack.org/#/c/184992/

Thanks
Ken'ichi Ohmichi



 On 06/10/2015 08:07 AM, Yuiko Takada wrote:

 Hi, Dmitry,

 I guess the whole idea of new release models is NOT to tie projects
 to each other any more except for The Big Release twice a year :) So
 I think no, we don't need to. We still can do it, if we have
 something to release by the time Ironic releases, but I suggest
 deciding it on case-by-case basis.

 OK, I see.

 One more concern, about Tempest integration test which I will implement
 in V2.1.0,
 it seems like that we cannot add Ironic-inspector's tests into Tempest
 even if integration tests.
 Please see:
 https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent


 Good catch. I guess the answer depends on where Ironic integration tests are
 going to live - we're going to live with them. Let me retarget this thread
 to a wider audience.


 But I heard from you that Devananda thinks we need this in tempest
 itself. [3]
 Do you know something like current situation?


 Best Regards,
 Yuiko Takada

 2015-06-09 15:59 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
 mailto:dtant...@redhat.com:

 On 06/09/2015 03:49 AM, Yuiko Takada wrote:

 Hi, Dmitry,

 Thank you for notifying.

  I've updated our summit etherpad [3] with whatever priorities
 I
  remembered, please have a look. I've also untargeted a few
 things in
  launchpad [4] (and will probably untarget more later on).
 Please
  assign yourself, if you want something done in this release
 time frame.

 I've assigned one item to myself in [3], and also I added one BP
 to [4],
 so please take a look.

 https://blueprints.launchpad.net/ironic-inspector/+spec/delete-db-api


 Looks good, though I don't think it's a big priority for 2.0.0.
 Definitely worth doing for 2.1.0.

 Thanks for assigning for tempest work, that's definitely a priority
 right now.


 BTW, how do you think about Ironic-inspector's release model?
 You wrote Version released with Ironic Liberty as
 Ironic-inspector Version 2.1.0 in etherpad [3],
 but as you know, Ironic's release model has changed to feature
 releases.(right?)
 Should we make our release model same as Ironic?


 I guess the whole idea of new release models is NOT to tie projects
 to each other any more except for The Big Release twice a year :) So
 I think no, we don't need to. We still can do it, if we have
 something to release by the time Ironic releases, but I suggest
 deciding it on case-by-case basis.



 Best Regards,
 Yuiko Takada(Inspector team member)

 2015-06-08 20:38 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
 mailto:dtant...@redhat.com
 mailto:dtant...@redhat.com mailto:dtant...@redhat.com:


  Hello, Inspector team!

  The renaming process is going pretty well, the last thing
 we need to
  do is to get Infra approval and actual rename [1][2].

  I'd like to allow people (e.g. myself) to start packaging
 inspector
  under it's new name, so I'd like to make 2.0.0 release as
 soon as
  possible (as opposed to scheduling it to particular date).
 All

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

2015-06-10 Thread Matthias Runge


On 27/05/15 10:14, Thomas Goirand wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

tl;dr:
- - We'd like to push distribution packaging of OpenStack on upstream
gerrit with reviews.
- - The intention is to better share the workload, and improve the overall
QA for packaging *and* upstream.
- - The goal is *not* to publish packages upstream
- - There's an ongoing discussion about using stackforge or openstack.
This isn't, IMO, that important, what's important is to get started.
- - There's an ongoing discussion about using a distribution specific
namespace, my own opinion here is that using /openstack-pkg-{deb,rpm} or
/stackforge-pkg-{deb,rpm} would be the most convenient because of a
number of technical reasons like the amount of Git repository.
- - Finally, let's not discuss for too long and let's do it!!! :)



Since our software is to be consumed by packages, shouldn't the packages 
project consider itself to be responsible for global requirements? I.e. 
checking, if requirements are packageable, if versions fit, etc.


In some distros, there are multiple versions of the same package 
allowed, in others, it's forbidden.


Matthias

__
OpenStack Development Mailing 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] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

2015-06-10 Thread Salvatore Orlando

As a further data point, Neutron has been trying to introduce
microversioning for a while, without success so far.

Given the sheer amount of backends the management layer integrates with,
and the constant need for the various subteams to experiment with the
API, the proposal [1] has probably some differences with the proposed
guideline.

Since the proposal is not yet approved nor implemented, perhaps it would be
worth looking at those differences, and get your advice on whether it might
be better if neutron adheres to the current guideline proposal or whether
it might be the case to include Neutron's requirements in the current
guideline proposal.

Salvatore

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

On 10 June 2015 at 06:28, Xu, Hejie hejie...@intel.com wrote:

  I updated the Microversion specification in API-WG
 https://review.openstack.org/187112



 The new patchset adds min/max version headers as Ironic used:

 X-Openstack-[PROJECT]-API-Minimum-Version

 X-Openstack-[PROJECT]-API-Maximum-Version



 And new response body for invalid version request.



   {

 versionFault: {

   max_version: 5.2,

   min_version: 2.1,

   description: Version 5.3 is not supported by the API. \

   Minimum is 2.1 and maximum is 5.2.

 }

   }



 Which for backward compatible can add the existed fields in the response
 also. For example, the nova response is



   {

 versionFault: {

   max_version: 5.2,

   min_version: 2.1,

   description: Version 5.3 is not supported by the API. \

   Minimum is 2.1 and maximum is 5.2.

 },

 computeFault: {

   message: Version 5.3 is not supported by the API. \

   Minimum is 2.1 and maximum is 5.2.,

   code: 406

 }

   }



 The “computeFault” fields is included by current implementation, we can
 still add here, hope deprecated in the future.



 And the “experimental” flag in the X-OpenStack-Nova-API-Version header was
 deleted. It mentioned in the nova-spec but

 It didn’t implement. And I didn’t saw the same thing in the ironic. For
 current all the things satisfied all the cases. If we

 “experimental” flag still usefull, we can propose separately.



 Thanks

 Alex



 *From:* Devananda van der Veen [mailto:devananda@gmail.com]
 *Sent:* Monday, June 8, 2015 1:59 AM
 *To:* OpenStack Development Mailing List
 *Subject:* Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum]
 Microversion guideline in API-WG




 On Jun 5, 2015 4:36 AM, Sean Dague s...@dague.net wrote:
 
  On 06/05/2015 01:28 AM, Adrian Otto wrote:
  
   On Jun 4, 2015, at 11:03 AM, Devananda van der Veen
   devananda@gmail.com mailto:devananda@gmail.com wrote:
  
  
   On Jun 4, 2015 12:00 AM, Xu, Hejie hejie...@intel.com
   mailto:hejie...@intel.com wrote:
   
Hi, guys,
   
I’m working on adding Microversion into the API-WG’s guideline which
   make sure we have consistent Microversion behavior in the API for
 user.
The Nova and Ironic already have Microversion implementation, and as
   I know Magnum https://review.openstack.org/#/c/184975/ is going to
   implement Microversion also.
   
Hope all the projects which support( or plan to) Microversion can
   join the review of guideline.
   
The Mircoversion specification(this almost copy from nova-specs):
   https://review.openstack.org/#/c/187112
And another guideline for when we should bump Mircoversion
   https://review.openstack.org/#/c/187896/
   
As I know, there already have a little different between Nova and
   Ironic’s implementation. Ironic return min/max version when the
 requested
version doesn’t support in server by http-headers. There isn’t such
   thing in nova. But that is something for version negotiation we need
   for nova also.
Sean have pointed out we should use response body instead of http
   headers, the body can includes error message. Really hope ironic team
   can take a
look at if you guys have compelling reason for using http headers.
   
And if we think return body instead of http headers, we probably
   need think about back-compatible also. Because Microversion itself
   isn’t versioned.
So I think we should keep those header for a while, does make sense?
   
Hope we have good guideline for Microversion, because we only can
   change Mircoversion itself by back-compatible way.
  
   Ironic returns the min/max/current API version in the http headers for
   every request.
  
   Why would it return this information in a header on success and in the
   body on failure? (How would this inconsistency benefit users?)
  
   To be clear, I'm not opposed to *also* having a useful error message
   in the body, but while writing the client side of api versioning,
   parsing the range consistently from the response header is, IMO,
   better than requiring a conditional.
  
   +1. I fully agree with Devananda on this point. Use the headers
   consistently, and add helpful errors into the body

Re: [openstack-dev] [all][python3] use of six.iteritems()

On 10 June 2015 at 17:22, gordon chung g...@live.ca wrote:
 maybe the suggestion should be don't blindly apply six.iteritems or items 
 rather than don't apply iteritems at all. admittedly, it's a massive eyesore, 
 but it's a very real use case that some projects deal with large data results 
 and to enforce the latter policy can have negative effects[1].  one million 
 item dictionary might be negligible but in a multi-user, multi-* environment 
 that can have a significant impact on the amount memory required to store 
 everything.

 [1] disclaimer: i have no real world results but i assume memory management 
 was the reason for the switch in logic from py2 to py3

I wouldn't make that assumption.

And no, memory isn't an issue. If you have a million item dict,
ignoring the internal overheads, the dict needs 1 million object
pointers. The size of a list with those pointers in it is 1M (pointer
size in bytes). E.g. 4M or 8M. Nothing to worry about given the
footprint of such a program :)

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] oslo releasing is noisy...

Victor Stinner wrote:
 Le 09/06/2015 18:31, Thierry Carrez a écrit :
 We are currently exploring the option to repurpose the
 openstack-announce ML to be the extensive record of release
 announcements. It's part of a larger plan to streamline library
 releases, about which Doug should start a discussion pretty soon now.
 
 In the Python community, there are Special Interest Groups (SIG) which
 have their mailing lists: distutils-sig, import-sig, mobile-sig, etc.
 
 https://www.python.org/community/sigs/
 
 Maybe we can move some traffic to new mailing lists, like a new
 openstack-oslo@ list, instead of using tags in the subject?
 
 Anyone would be able to choose to subscribe or not to openstack-oslo.

We've been considering that in the past, but figured that would result
in further fragmentation of our community and loss of even more common
culture. The goal is that we form a single community, beyond each
specific project team, and openstack-dev (and #openstack-meeting,
and...) has been a tool we've been using to keep that.

You can search the list for past threads, which contain good advice on
how using stronger client-side filtering and/or topics filtering to keep
some sanity navigating this list.

-- 
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] [all] [stable] No longer doing stable point releases

Dave Walker wrote:
 On 10 June 2015 at 09:53, Thomas Goirand z...@debian.org wrote:
 What would be your preferred option ?

 I see no point of doing D. I already don't use tarballs, and those who
 do could as well switch to generating them (how hard is it to run
 python setup.py sdist or git archive?).

 What counts is having a schedule date, where all distros are releasing a
 point release, so we have a common reference point. If that is a fully
 automated process, then great, less work for everyone, and it wont
 change anything from what we had in the past (we can even collectively
 decide for point release dates...).

That would be option B.

The main issue with B is that it doesn't work well once server component
versions start to diverge, which will be the case starting with Liberty.
You can't tag everything with the same version number anymore. We
already couldn't (with Swift using separate versioning), but we worked
around that by ignoring Swift from stable releases. As more projects opt
into that, that will no longer be a possible workaround.

So we could do what you're asking (option B) for Kilo stable releases,
but I think it's not really a viable option for stable/liberty onward.

 This is really one of the things I think we want to get away from...
 If *every* stable commit is treated with the seriousness of it
 creating a release, lets make every commit a release.
 
 This means that Debian may be using a (micro)patch release newer or
 older than a different distro, but the key is that it empowers the
 vendors and/or users to select a release cadence that best fits them,
 rather than being tied to an arbitrary upstream community wide date.

+1

It also removes the stupid encouragement to use all components from the
same date. With everything tagged at the same date, you kinda send the
message that those various things should be used together. With
everything tagged separately, you send te message that you can mix and
match components from stable/* as you see fit. I mean, it's totally
valid to use stable branch components from various points in time
together, since they are all supposed to work.

So I totally get that we should still have reference points to be able
to tell this is fixed in openstack/nova stable/liberty starting with
12.1.134post34 (or whatever we settle with). I totally get that any of
those should ship with relevant release notes. But that's about all I
think we need ?

-- 
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] [murano] shellcheck all .sh scripts in murano-deployment

2015-06-10 Thread Jeremy Stanley

On 2015-06-10 13:48:26 +0200 (+0200), Filip Blaha wrote:
 +1, nice idea. Shell script are not easy to review - large files, not
 covered by unit tests. Any automatic tool could be beneficial.

It's worth noting that just because your shell scripts don't have
their own validation tests doesn't mean they can't. For example see
the test-features.sh and test-functions.sh scripts in the
https://git.openstack.org/cgit/openstack-infra/devstack-gate/ repo,
making sure we maintain a contract on things like branch fallback
logic which is easy to subtly break if not tested.
-- 
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] (re)centralizing library release management

2015-06-10 Thread Paul Belanger


On 06/09/2015 01:25 PM, Doug Hellmann wrote:

Until now we have encouraged project teams to prepare their own
library releases as new versions of projects were needed. We've
started running into a couple of problems with that, with releases
not coming often enough, or at a bad time in the release cycle, or
with version numbering not being applied consistently, or without
proper announcements. To address these issues, the release management
team is proposing to create a small team of library release managers
to handle the process around all library releases (clients,
non-application projects, middleware, Oslo libraries, etc.). This
will give us a chance to collaborate and review the version numbers
for new releases, as well as stay on top of stale libraries with
fixes or features that sit unreleased for a period of time. It will
also be the first step to creating an automated review process for
release tags.

The process still needs to be worked out, but I envision it working
something like this:

The release liaison/PTL for the project team submits a request for
a new release, including the repo name, the SHA, the series (liberty,
kilo, etc.), and the proposed version number. The release team
checks the proposed version number against the unreleased changes
up to that SHA, and then either updates it to reflect semver or
uses it as it is provided. The release team would then handle the
tag push and the resulting announcements.

There would be a few conditions under which a new release might not
be immediately approved, but really only when the gate is wedged
and during freeze periods. The point of the change isn't to block
releases, just ensure consistency and good timing.

We have some tools to let us look for unreleased changes, and
eventually we can set up a recurring job to build that report so
we can propose releases to project teams with a large release
backlog. That will likely come later, though.

We can also pre-announce proposed releases if folks find that useful.

We will need a small number of volunteers to join this team, and
start building the required expertise in understanding the overall
state of the project, and in semantic versioning. We do not necessarily
want a liaison from every project -- think of this as the proto-team
for the group that eventually has core reviewer rights on the release
automation repository.

Doug

While I haven't participated in release management before, I'd like to 
volunteer my services to help. Where is the best place (IRC) to 
collaborate?


PB

__
OpenStack Development Mailing 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] [packaging] Adding packaging as an OpenStack project

On 06/10/2015 12:25 PM, Dave Walker wrote:
 The initial core reviewers was seeded by representatives of distro's and
 vendors to get their input on viability in distro's.

Really? James, were you made core on the requirements?

I once tried to follow the requirements repo, though it moves too fast,
and sometimes, it takes less than 2 days to get a new thing approved.
Also, this repository has more than just dependencies, there's a lot of
noise due to changes changes in projects.txt. I also don't mind any
upgrade for whatever oslo or client libs.

I'd love to have an easier way to voice my opinion without having all
the noise of that repo in my inbox. I'm not sure if there's a solution
to this problem though.

Thomas


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

Re: [openstack-dev] Enabling an Open Cloud with OpenStack

2015-06-10 Thread Zhipeng Huang

Hi Orran,

We also have a project called Tricircle that aim to solve similar problem,
but with a different approach with Mercador. You and your team are more
than welcome to join the discussion we will hold in Tricircle Meeting.

See the details at
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg54861.html,
and https://github.com/stackforge/tricircle , and also our PoC results
http://www.slideshare.net/JoeHuang7/test-report-for-open-stack-cascading-solution-to-support-1-million-v-ms-in-100-data-centers
:)

Hope you guys find it helpful.

On Wed, Jun 10, 2015 at 9:37 PM, Orran Krieger okr...@gmail.com wrote:

 Dear OpenStack community,


 The short version: We are proposing a new set of use cases for OpenStack
 and a set of
 changes to enable a multi-landlord cloud model, where multiple service
 providers can cooperate (and compete) to stand up services in a single
 cloud. We had great feedback from the community in the summit, and
 came away with two strong messages: 1) this is a radical enough change
 that we should do an end-to-end proof of concept, and 2) we should
 post to this list what we are doing to make it visible to the broader
 developer community; fully solving the problems of a multi-landlord
 cloud will impact more projects than we understand today. We hope to
 have available prototypes of the key enabling changes by the keystone
 mid-cycle and an end-to-end demo by the Tokyo summit.

 Two additional points:

  1. Solving the problems of landlords that don't trust each other
 also brings defense in depth for a single provider cloud;
 potentially preventing an exploit of one service from
 compromising an entire cloud.

  2. This work strongly relates to resource federation work that is
 ongoing in OpenStack, and is complementary to, and being persued
 in the context of the recently annouced Mercador project.

 We, of course, welcome participating by other developers interested in
 working with us on this through the Mercador project or by contacting
 us as per info below.

 The long version:
 --

 All current clouds are stood up by a single company or organization,
 creating a vertically integrated monopoly.  Any competition is between
 entire clouds and is limited by the customer's ability to move their
 data over the connectivity between clouds.  We think an alternative
 model is possible, where different organizations can stand up
 individual services in the same data centers, and the customer (or
 intermediaries acting on their behalf) can pick and choose between
 them.  We call this model of having multiple landlords in a cloud an
 Open Cloud eXchange (OCX)
 (http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf).

 The OCX model would enable more innovation by technology companies,
 enable cloud research and provide more choice to cloud consumers. We
 are developing this model in a new public cloud, the Massachusetts
 Open Cloud (MOC), that is just being started in the MGHPCC data center
 (http://www.mghpcc.org) shared between Boston University, Harvard
 University, the Massachusetts Institute of Technology, Northeastern
 University, and the University of Massachusetts.  Some use cases being
 explored in the context of the MOC illustrate the potential of this
 model:

 o Harvard and MIT both stand up their own OpenStack cloud for
  students, but provide resources on-demand to the MOC that can be used
  by researchers that collaborate between the universities and by
  external users.
 o A storage company stands up a new innovative block storage service
  on a few racks in the MGHPCC, operates it themselves, and makes it
  available to users of the MOC and/or the individual university
  clouds.  The storage company is in total control of price,
  automation, and SLA for the service, and users can choose if they
  want to use the service.
 o A company stands up a new compute service with innovative hardware
  (e.g., FPGAs, crypto accellerator) or pricing model.  A customer
  with a two Petabyte disk volume can switch to using that compute
  without having to move the data.
 o A research group at Boston University and Northeastern develops a
  highly elastic compute service that can checkpoint 1000s of servers
  in seconds into SSD, and broadcast provision a distributed
  application to allow an interactive medical imaging application that
  wants 1000s of servers for a few seconds.
 o A security sensitive life sciences company exploits software from
  the MACS project (http://www.bu.edu/hic/research/macs/) to
  distribute their data across two storage services from non-colluding
  providers.  The data is accessed from a Nova compute service running
  on a trusted compute platform developed collaboratively with
  Intel. Since all services are deployed in the same datacenter, the
  computation is efficient.
 o Students in a cloud computing course offered by Northeastern and
  Boston University faculty

Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs

2015-06-10 Thread Sean M. Collins

On Tue, Jun 09, 2015 at 05:21:18PM EDT, Kevin Benton wrote:
 I wasn't planning on wiping them out for now since I'm leveraging a lot of
 the extension loading that exists so someone can remove the namespaces if
 they want.

OK - I'll take it on if there's no objections

-- 
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] [packaging] Adding packaging as an OpenStack project

2015-06-10 Thread James Page

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/06/15 15:12, Thomas Goirand wrote:
 The initial core reviewers was seeded by representatives of
 distro's and
 vendors to get their input on viability in distro's.
 Really? James, were you made core on the requirements?

Believe it or not, I've not *always* worked on OpenStack for Ubuntu
:-); that pre-dates my direct involvement.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVeEgKAAoJEL/srsug59jDrqEQAK6jXUCDzHb8XIVM6GM82QOy
+6NXp99us8xDzq/2mWuZAUZ4abon4JvZmOjngSoQmTXs1e9L3HiQr4iTlW4ZlJ9w
JCL8Xlq2/SJL8KJ2hMFg6sWanJZ0eglJ21F/bq2Rz6/fjhx/i7q8CPLHJghG5RXm
2sk9seXHFLK3syW4g/sVmz3MkPAYwu6ZqFiTDDcgNjkD+OegoMltn/d+HRLf20G9
VeTuL6mjW2ZnnJozBuqJ+ZbX+Gc35OhV8NWFzhaPkMPNT48BULr7rpfAgQ22WXyP
v9EnXaYtzyhUQBOdyrKXoPLK2dhCTcqRGImM1lZl3mKJbG/jf8d9U24M20bw4kQE
h6LHOyH+PQQcsAm+uKH2mpB8c+XElmeL7BO9sSUsC30oL0QI3OxRcFt/wgIycHwd
f8OoXPc8RsZERlsWYPF9gA16bTRQn08vIgVweNKu7vkP5qR6nvOjCzRBoUZdlIpu
4tqlzprYDSzSAJi8mzDq+nw3YulXjuTk/vQusp4MCjfA3VXS1yry8i+1HpjF/MO/
eAoKpZM2ntksRcObj947yh7ncsxjrQmOXHPfqMlbZTa6NWmQnElufJJ0nk5s30el
cBxUTjLN4lvAc6xjZPXqHk1U0kiP95E0wAa3EMVSDLeULG4Hq57+bSE63zHTts77
Y+UyyJswgeA6ZHC+W5Ct
=egET
-END PGP SIGNATURE-

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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 10 June 2015 at 15:12, Thomas Goirand z...@debian.org wrote:
 On 06/10/2015 12:25 PM, Dave Walker wrote:
 The initial core reviewers was seeded by representatives of distro's and
 vendors to get their input on viability in distro's.

 Really? James, were you made core on the requirements?

 I once tried to follow the requirements repo, though it moves too fast,
 and sometimes, it takes less than 2 days to get a new thing approved.
 Also, this repository has more than just dependencies, there's a lot of
 noise due to changes changes in projects.txt. I also don't mind any
 upgrade for whatever oslo or client libs.

 I'd love to have an easier way to voice my opinion without having all
 the noise of that repo in my inbox. I'm not sure if there's a solution
 to this problem though.

On the Ubuntu side, I believe Chuck and myself were carrying the flag
(we had +2).  When the openstack/requirements project was created
James was less involved upstream, and two representatives of a distro
ought to have been enough.

An yes, I also found that the flow was too much to keep up with which
is why I tried to automate some of this.  I hoped the burden has
reduced somewhat, as prospective changes now need to do more of the
distro research themselves.

Is the library already packaged in the distros we target (Ubuntu
latest / Fedora latest)?

By adding something to OpenStack global-requirements.txt we are
basically demanding that Linux Distros package this for the next
release of OpenStack. If they already have, great. If not, we should
be cautious of adding it.:ref:`finding-distro-status`[0]

But only so much can be done by non-distro focussed upstream consumers...

[0] 
https://github.com/openstack/requirements/blob/master/README.rst#for-new-requirements

--
Kind Regards,
Dave Walker

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

Re: [openstack-dev] [cinder][nova] Is volume connection_info modeled/documented anywhere?

2015-06-10 Thread Duncan Thomas

I don't think you need an entry per driver, you need an entry per
connection type - iSCSI, FC, DRDB, CEPH being the ones I can think of off
the top of my head
On 10 Jun 2015 16:57, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:

 While investigating/discussing bug 1463525 [1] I remembered how little I
 know about what can actually come out of the connection_info dict returned
 from the os-initialize_connection cinder API call.

 So we added some debug logging in nova and I remembered that there are
 potentially credentials (auth_password) stored in connection_info, so we
 have a bug to clean that up in Nova [2].

 The plan is to model connection_info using objects where we have a parent
 object BdmConnectionInfo containing the common keys, like
 'driver_volume_type' and 'data', and then child objects for the
 vendor-specific connection_info objects, like RbdBdmConnectionInfo,
 ISCSIBdmConnectionInfo, etc.

 The problem I have right now is knowing what can all be in there, since
 there are a ton of vendor drivers in Cinder.

 Is anyone aware of a wiki page or devref or anything that documents what
 can be in that wild west connection_info dict?  If not, the first thing I
 was going to do was start documenting that - but where?  It seems it should
 really be modeled in Cinder since it is part of the API contract and if a
 vendor driver were to say rename or drop a key from the connection_info
 they were returning in os-initialize_connection it would be a backwards
 incompatible change.

 Is devref best for this with a listing for each vendor driver?  At least
 then it would be versioned with the code and updates could be made as new
 keys are added to connection_info or new drivers are added to Cinder.

 I'm looking for any advice here in how to get started since I don't
 primarily work on Cinder and don't have a full history here.

 [1] https://bugs.launchpad.net/cinder/+bug/1463525
 [2] https://bugs.launchpad.net/nova/+bug/1321785

 --

 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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

2015-06-10 Thread Ian Cordasco



On 6/10/15, 09:12, Thomas Goirand z...@debian.org wrote:

On 06/10/2015 12:25 PM, Dave Walker wrote:
 The initial core reviewers was seeded by representatives of distro's and
 vendors to get their input on viability in distro's.

Really? James, were you made core on the requirements?

I once tried to follow the requirements repo, though it moves too fast,
and sometimes, it takes less than 2 days to get a new thing approved.
Also, this repository has more than just dependencies, there's a lot of
noise due to changes changes in projects.txt. I also don't mind any
upgrade for whatever oslo or client libs.

I'd love to have an easier way to voice my opinion without having all
the noise of that repo in my inbox. I'm not sure if there's a solution
to this problem though.

Thomas

You should be able to subscribe to a subset of the changes in gerrit. I
don't recall if it only works for directories, but you should be able to
make something work for *requirements.txt. The docs are easy to find on
Google or DDG.

Cheers,
Ian

__
OpenStack Development Mailing 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] Enabling an Open Cloud with OpenStack

2015-06-10 Thread Orran Krieger

Dear OpenStack community,


The short version: We are proposing a new set of use cases for OpenStack and a 
set of
changes to enable a multi-landlord cloud model, where multiple service
providers can cooperate (and compete) to stand up services in a single
cloud. We had great feedback from the community in the summit, and
came away with two strong messages: 1) this is a radical enough change
that we should do an end-to-end proof of concept, and 2) we should
post to this list what we are doing to make it visible to the broader
developer community; fully solving the problems of a multi-landlord
cloud will impact more projects than we understand today. We hope to
have available prototypes of the key enabling changes by the keystone
mid-cycle and an end-to-end demo by the Tokyo summit.  

Two additional points: 

 1. Solving the problems of landlords that don't trust each other
also brings defense in depth for a single provider cloud;
potentially preventing an exploit of one service from
compromising an entire cloud.

 2. This work strongly relates to resource federation work that is
ongoing in OpenStack, and is complementary to, and being persued
in the context of the recently annouced Mercador project.

We, of course, welcome participating by other developers interested in
working with us on this through the Mercador project or by contacting
us as per info below.

The long version:
--

All current clouds are stood up by a single company or organization,
creating a vertically integrated monopoly.  Any competition is between
entire clouds and is limited by the customer's ability to move their
data over the connectivity between clouds.  We think an alternative
model is possible, where different organizations can stand up
individual services in the same data centers, and the customer (or
intermediaries acting on their behalf) can pick and choose between
them.  We call this model of having multiple landlords in a cloud an
Open Cloud eXchange (OCX)
(http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf 
http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf).

The OCX model would enable more innovation by technology companies,
enable cloud research and provide more choice to cloud consumers. We
are developing this model in a new public cloud, the Massachusetts
Open Cloud (MOC), that is just being started in the MGHPCC data center
(http://www.mghpcc.org http://www.mghpcc.org/) shared between Boston 
University, Harvard
University, the Massachusetts Institute of Technology, Northeastern
University, and the University of Massachusetts.  Some use cases being
explored in the context of the MOC illustrate the potential of this
model:

o Harvard and MIT both stand up their own OpenStack cloud for
 students, but provide resources on-demand to the MOC that can be used
 by researchers that collaborate between the universities and by
 external users.  
o A storage company stands up a new innovative block storage service
 on a few racks in the MGHPCC, operates it themselves, and makes it
 available to users of the MOC and/or the individual university
 clouds.  The storage company is in total control of price,
 automation, and SLA for the service, and users can choose if they
 want to use the service.
o A company stands up a new compute service with innovative hardware
 (e.g., FPGAs, crypto accellerator) or pricing model.  A customer
 with a two Petabyte disk volume can switch to using that compute
 without having to move the data.
o A research group at Boston University and Northeastern develops a
 highly elastic compute service that can checkpoint 1000s of servers
 in seconds into SSD, and broadcast provision a distributed
 application to allow an interactive medical imaging application that
 wants 1000s of servers for a few seconds. 
o A security sensitive life sciences company exploits software from
 the MACS project (http://www.bu.edu/hic/research/macs/ 
http://www.bu.edu/hic/research/macs/) to
 distribute their data across two storage services from non-colluding
 providers.  The data is accessed from a Nova compute service running
 on a trusted compute platform developed collaboratively with
 Intel. Since all services are deployed in the same datacenter, the
 computation is efficient.
o Students in a cloud computing course offered by Northeastern and
 Boston University faculty
 (https://okrieg.github.io/EC500/index.html 
https://okrieg.github.io/EC500/index.html) develop and stand up an
 experimental proxy service for open stack services that provides
 users of the MOC a Swift service that combines the inventory of
 multiple underlying Swift services.

While no existing cloud stack can support the OCX model out of the
box, OpenStack is much closer than anything else, and we have been
exploring what changes will be required to enable this model
(http://open.bu.edu/handle/2144/11214 http://open.bu.edu/handle/2144/11214) 
and worked with our partners
in the community to submit a number of

[openstack-dev] [cinder][nova] Is volume connection_info modeled/documented anywhere?

2015-06-10 Thread Matt Riedemann

While investigating/discussing bug 1463525 [1] I remembered how little I 
know about what can actually come out of the connection_info dict 
returned from the os-initialize_connection cinder API call.


So we added some debug logging in nova and I remembered that there are 
potentially credentials (auth_password) stored in connection_info, so we 
have a bug to clean that up in Nova [2].


The plan is to model connection_info using objects where we have a 
parent object BdmConnectionInfo containing the common keys, like 
'driver_volume_type' and 'data', and then child objects for the 
vendor-specific connection_info objects, like RbdBdmConnectionInfo, 
ISCSIBdmConnectionInfo, etc.


The problem I have right now is knowing what can all be in there, since 
there are a ton of vendor drivers in Cinder.


Is anyone aware of a wiki page or devref or anything that documents what 
can be in that wild west connection_info dict?  If not, the first thing 
I was going to do was start documenting that - but where?  It seems it 
should really be modeled in Cinder since it is part of the API contract 
and if a vendor driver were to say rename or drop a key from the 
connection_info they were returning in os-initialize_connection it would 
be a backwards incompatible change.


Is devref best for this with a listing for each vendor driver?  At least 
then it would be versioned with the code and updates could be made as 
new keys are added to connection_info or new drivers are added to Cinder.


I'm looking for any advice here in how to get started since I don't 
primarily work on Cinder and don't have a full history here.


[1] https://bugs.launchpad.net/cinder/+bug/1463525
[2] https://bugs.launchpad.net/nova/+bug/1321785

--

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

Re: [openstack-dev] [release][oslo] oslotest release 1.7.0 (liberty)

2015-06-10 Thread Victor Stinner

Good news: your fix is already merged into oslo.messaging ;-) 
oslo.messaging now uses directly mox3, on Python 2 and Python 3.


Victor

Le 10/06/2015 14:04, Victor Sergeyev a écrit :

Hi All,

this oslotest release break oslo.messaging gate - unittest fails
with ImportError, on import mox from six.moves - [0].
It caused by commit [1], which removed adding mox to six moves.

There is a fix for oslo.messaging - [2] - please, help to merge it.

[0] - http://paste.openstack.org/show/281091/
[1] -
https://github.com/openstack/oslotest/commit/9e0c8ad2c251274128499a7fcfb591c488d27d2b
[2] - https://review.openstack.org/190136

Thanks,
Victor

On Tue, Jun 9, 2015 at 6:14 PM, d...@doughellmann.com
mailto:d...@doughellmann.com wrote:

We are content to announce the release of:

oslotest 1.7.0: Oslo test framework

This release is part of the liberty release series.

With source available at:

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

For more details, please see the git log history below and:

http://launchpad.net/oslotest/+milestone/1.7.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslotest

Changes in oslotest 1.6.0..1.7.0


5bd9b31 Updated from global requirements
ff9b38e Fix argument handling in oslo_run_cross_tests
960e444 Add class to deal with clouds.yaml support
1c0863f Remove unneeded runtime pbr dep
5f2e635 Updated from global requirements
f8a5a3c Advertise support for Python3.4 / Remove support for Python 3.3
a063f25 Do not sync run_cross_tests.sh
0782ab7 Remove unused discover dependency
9e0c8ad Remove six.moves call

Diffstat (except docs and test files)
-

openstack-common.conf  |  7 --
oslotest/__init__.py   |  1 -
oslotest/functional.py | 59
++
oslotest/moxstubout.py |  2 +-
requirements.txt   |  3 +--
setup.cfg  |  6 +
tox.ini|  3 +--
8 files changed, 83 insertions(+), 30 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 674130c..1486ede 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5,2 +4,0 @@
-pbr=0.6,!=0.7,1.0
-discover
@@ -14,0 +13 @@ mox3=0.7.0
+os-client-config=1.2.0



__
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




__
OpenStack Development Mailing 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] (re)centralizing library release management

Paul Belanger wrote:
 While I haven't participated in release management before, I'd like to
 volunteer my services to help. Where is the best place (IRC) to
 collaborate?

I would encourage prospective release managers to join
#openstack-relmgr-office where Doug and I discuss that sort of things,
and (if timing allows) attend the release team meeting, or read the logs
afterwards if you can't attend. It's currently set to a EU-friendly
Monday 1300 UTC.

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] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

2015-06-10 Thread yang, xing

Hi Chen,

You can ask if OpenStack Infrastructure team can set up CI for this driver.  
They have set up CI's for a few Cinder drivers based on open source storage 
systems.

Thanks,
Xing


From: Li, Chen [mailto:chen...@intel.com]
Sent: Wednesday, June 10, 2015 3:48 AM
To: OpenStack Development Mailing List (not for usage questions) 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI 
for HDFS driver

Hello Manila,

There is a HDFS driver in Manila summited by our team in Kilo, so I guess we do 
own this driver in Manila for current situation.

But, CI systems are really new to us, and we heard from other teams that they 
took almost one year to implement a CI for going through all the company 
processes and building all related staff for it.
And , the biggest issue we have is there is not enough resource to actually 
implement and maintain the CI as that is not allowed by the team's strategy.

We strongly believe the HDFS driver will be really useful in Manila/Openstack, 
and might be used by other Openstack projects such as Sahara/Cognitive which 
are big data related projects in the near future, thus we don't want to see the 
driver to be remove.

Do we have a volunteer to take over the CI for HDFS driver as it is an open 
source distributed storage system which actually has no vendor dependency ?

Looking forward to your reply.

Thanks.
-chen

__
OpenStack Development Mailing 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] Switching to SQLAlchemy 1.0.x

2015-06-10 Thread Mike Bayer




On 6/10/15 3:26 AM, Thomas Goirand wrote:

Hi Mike,

Thanks a lot for your quick reply which is very useful to me.

On 06/09/2015 07:08 PM, Mike Bayer wrote:

On 6/9/15 9:26 AM, Thomas Goirand wrote:

Hi,

The python-sqlalchemy package has been uploaded to Debian Experimental,
and is about to be uploaded to Debian Unstable. So I wonder what's the
state of the project regarding upgrading SQLA.

Maybe Mike can tell what kind of issue we may run into? How much work
will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be
compatible with both 9.x and 1.x (which would be the best way forward)?

The short answer is that there are no supported use cases that have been
intentionally changed in any backwards incompatible way in 1.0 and all
Openstack code should be able to accommodate from 0.9.x - 1.0.x without
any change.

Ah, super cool!

I saw that this passed all tests:
https://review.openstack.org/#/c/189847/


whew!  :)




Could we get it approved?

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



__
OpenStack Development Mailing 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] [murano] shellcheck all .sh scripts in murano-deployment

2015-06-10 Thread Filip Blaha


Thanks for comment and suggestion!

there is also shutil2 framework for unit testing over shell scripts. We 
shall consider it whether it could bring us value for the effort. I 
personally have no strong opinion about that. Little contradiction to my 
previous mail:-)


Regards
Filip



On 06/10/2015 03:34 PM, Jeremy Stanley wrote:

On 2015-06-10 13:48:26 +0200 (+0200), Filip Blaha wrote:

+1, nice idea. Shell script are not easy to review - large files, not
covered by unit tests. Any automatic tool could be beneficial.

It's worth noting that just because your shell scripts don't have
their own validation tests doesn't mean they can't. For example see
the test-features.sh and test-functions.sh scripts in the
https://git.openstack.org/cgit/openstack-infra/devstack-gate/ repo,
making sure we maintain a contract on things like branch fallback
logic which is easy to subtly break if not tested.



__
OpenStack Development Mailing 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] [packaging] Adding packaging as an OpenStack project

2015-06-10 Thread Joe Gordon

On Wed, Jun 10, 2015 at 5:24 PM, Ian Cordasco ian.corda...@rackspace.com
wrote:



 On 6/10/15, 09:12, Thomas Goirand z...@debian.org wrote:

 On 06/10/2015 12:25 PM, Dave Walker wrote:
  The initial core reviewers was seeded by representatives of distro's and
  vendors to get their input on viability in distro's.
 
 Really? James, were you made core on the requirements?
 
 I once tried to follow the requirements repo, though it moves too fast,
 and sometimes, it takes less than 2 days to get a new thing approved.
 Also, this repository has more than just dependencies, there's a lot of
 noise due to changes changes in projects.txt. I also don't mind any
 upgrade for whatever oslo or client libs.
 
 I'd love to have an easier way to voice my opinion without having all
 the noise of that repo in my inbox. I'm not sure if there's a solution
 to this problem though.
 
 Thomas

 You should be able to subscribe to a subset of the changes in gerrit. I
 don't recall if it only works for directories, but you should be able to
 make something work for *requirements.txt. The docs are easy to find on
 Google or DDG.


Query to see only *requirements.txt changes:

  project:openstack/requirements  file:^.*requirements.txt is:open

how to subscribe to a subset of changes:

  https://review.openstack.org/Documentation/user-notify.html



 Cheers,
 Ian

 __
 OpenStack Development Mailing 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][fwaas] FWaaS IRC meetings to happen alternate Wed (no mtg today).

2015-06-10 Thread Sridar Kandaswamy (skandasw)

Hi All:

Just a reminder to FWaaS meeting attendees, as discussed in last weeks FWaaS 
IRC [1], with all the PTO’s going on and the need for time to build up on the 
SG alignment discussions – it was felt that it would be good to go to an 
alternate week format. So the next meeting will be on Jun 17 [2].

Whenever there is a need, we can revert back to the weekly format.

Thanks

Sridar

[1] 
http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-06-03-18.31.log.html
[2] https://wiki.openstack.org/wiki/Meetings/FWaaS

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

Re: [openstack-dev] [cinder][nova] Is volume connection_info modeled/documented anywhere?

2015-06-10 Thread John Griffith

On Wed, Jun 10, 2015 at 7:54 AM, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:

 While investigating/discussing bug 1463525 [1] I remembered how little I
 know about what can actually come out of the connection_info dict returned
 from the os-initialize_connection cinder API call.

 So we added some debug logging in nova and I remembered that there are
 potentially credentials (auth_password) stored in connection_info, so we
 have a bug to clean that up in Nova [2].

 The plan is to model connection_info using objects where we have a parent
 object BdmConnectionInfo containing the common keys, like
 'driver_volume_type' and 'data', and then child objects for the
 vendor-specific connection_info objects, like RbdBdmConnectionInfo,
 ISCSIBdmConnectionInfo, etc.

 The problem I have right now is knowing what can all be in there, since
 there are a ton of vendor drivers in Cinder.

 Is anyone aware of a wiki page or devref or anything that documents what
 can be in that wild west connection_info dict?  If not, the first thing I
 was going to do was start documenting that - but where?  It seems it should
 really be modeled in Cinder since it is part of the API contract and if a
 vendor driver were to say rename or drop a key from the connection_info
 they were returning in os-initialize_connection it would be a backwards
 incompatible change.

 Is devref best for this with a listing for each vendor driver?  At least
 then it would be versioned with the code and updates could be made as new
 keys are added to connection_info or new drivers are added to Cinder.

 I'm looking for any advice here in how to get started since I don't
 primarily work on Cinder and don't have a full history here.

 [1] https://bugs.launchpad.net/cinder/+bug/1463525
 [2] https://bugs.launchpad.net/nova/+bug/1321785

 --

 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


Hi Matt,

This used to be much simpler than it is now, so I think documenting it in
the cinder dev docs is a great idea.  The basics of initialize_connection
are documented via a comment (a not so great one) in the code here [1]
which will point you to here [2].

The challenge is as you've noticed things like RBD and now FC and all of
the other crazy transport layers that are getting thrown in.  I don't have
good info on the non-iscsi items, but sounds like you found the RBD stuff
the hard way, maybe the FC stuff is in the code somewhere as well.

I think each of the unique items have their own libvirt connection class,
so that kinda helps organize it a bit.

Also there the provider_* fields in the model update that come in (best
place to see those is in the DB model).

Anyway, I think this is would be great for us to have; I'm happy to help as
much or as little as you like, just hit me up on IRC if you want.

Thanks,
John

[1]:
https://github.com/openstack/cinder/blob/master/cinder/volume/targets/iscsi.py#L278

[2]:
https://github.com/openstack/cinder/blob/master/cinder/volume/targets/iscsi.py#L53
__
OpenStack Development Mailing 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] vif type libvirt-network

2015-06-10 Thread Andreas Scheuring

Hi Daniel, Neil and others, 

I was thinking about introducing libvirt-network as a new vif type to
nova. It can be used when Neutron prepares a libvirt network for
attaching guests.

Would you see any general concerns with such an approach? Anything that
I need to consider with libvirt networks in addition? Maybe I should
mention one thing due to the discussion this morning: No plug/unplug
behavior would required.

Any feedback is welcome!


I added a blueprint and wrote a spec with more details [1]. This
blueprint would make the macvtap-vif blueprint [2] dispensable.

The neutron code exploiting this libvirt network vif type will land on
stackforge. It will manage macvtap backed libvirt networks -- offer
guest attachments via macvtap. [3] 



[1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
[2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
[3] https://launchpad.net/networking-macvtap
(I'm still waiting for the repo to be approved, so for now I only have a
launchpad project to ref to).

-- 
Andreas 
(irc: scheuran)




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

Re: [openstack-dev] [Ironic] [Inspector] Toward 2.0.0 release

2015-06-10 Thread Yuiko Takada

Hi, Dmitry,

I guess the whole idea of new release models is NOT to tie projects to each
 other any more except for The Big Release twice a year :) So I think no, we
 don't need to. We still can do it, if we have something to release by the
 time Ironic releases, but I suggest deciding it on case-by-case basis.

OK, I see.

One more concern, about Tempest integration test which I will implement in
V2.1.0,
it seems like that we cannot add Ironic-inspector's tests into Tempest even
if integration tests.
Please see:
https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent

But I heard from you that Devananda thinks we need this in tempest itself.
[3]
Do you know something like current situation?


Best Regards,
Yuiko Takada

2015-06-09 15:59 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:

 On 06/09/2015 03:49 AM, Yuiko Takada wrote:

 Hi, Dmitry,

 Thank you for notifying.

 I've updated our summit etherpad [3] with whatever priorities I
 remembered, please have a look. I've also untargeted a few things in
 launchpad [4] (and will probably untarget more later on). Please
 assign yourself, if you want something done in this release time
 frame.

 I've assigned one item to myself in [3], and also I added one BP to [4],
 so please take a look.
 https://blueprints.launchpad.net/ironic-inspector/+spec/delete-db-api


 Looks good, though I don't think it's a big priority for 2.0.0. Definitely
 worth doing for 2.1.0.

 Thanks for assigning for tempest work, that's definitely a priority right
 now.


 BTW, how do you think about Ironic-inspector's release model?
 You wrote Version released with Ironic Liberty as
 Ironic-inspector Version 2.1.0 in etherpad [3],
 but as you know, Ironic's release model has changed to feature
 releases.(right?)
 Should we make our release model same as Ironic?


 I guess the whole idea of new release models is NOT to tie projects to
 each other any more except for The Big Release twice a year :) So I think
 no, we don't need to. We still can do it, if we have something to release
 by the time Ironic releases, but I suggest deciding it on case-by-case
 basis.



 Best Regards,
 Yuiko Takada(Inspector team member)

 2015-06-08 20:38 GMT+09:00 Dmitry Tantsur dtant...@redhat.com
 mailto:dtant...@redhat.com:


 Hello, Inspector team!

 The renaming process is going pretty well, the last thing we need to
 do is to get Infra approval and actual rename [1][2].

 I'd like to allow people (e.g. myself) to start packaging inspector
 under it's new name, so I'd like to make 2.0.0 release as soon as
 possible (as opposed to scheduling it to particular date). All
 breaking changes should land by this release - I don't expect 3.0.0
 soon :)

 I've updated our summit etherpad [3] with whatever priorities I
 remembered, please have a look. I've also untargeted a few things in
 launchpad [4] (and will probably untarget more later on). Please
 assign yourself, if you want something done in this release time
 frame.

 I would like 2.1.0 to be released with Ironic Liberty and be
 properly supported.

 Let me know what you think.

 Cheers,
 Dmitry

 [1] https://review.openstack.org/#/c/188030/
 [2] https://review.openstack.org/#/c/188798/
 [3] https://etherpad.openstack.org/p/liberty-ironic-discoverd
 [4] https://bugs.launchpad.net/ironic-inspector/+milestone/2.0.0


 __
 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




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



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

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

Re: [openstack-dev] [Nova] Liberty Priorties for Nova

2015-06-10 Thread Andreas Scheuring

Daniel, 
if I got it right, the vif script blueprint only is about plug/unplug
operations and not about generating new xml representations for vif
types. What if for a new vif type it's sufficient to have the
get_config_* method updated? In this case plug/unplug would be handled
by libvirt (like with many other existing vif types). The plug/unplug
methods would just contain a pass.

Would you tend to be supportive in such cases?

Thanks!
 
-- 
Andreas 
(irc: scheuran)


On Tue, 2015-06-09 at 15:28 +0100, Daniel P. Berrange wrote:
 On Tue, Jun 09, 2015 at 03:07:51PM +0100, Neil Jerram wrote:
  On 04/06/15 13:05, Neil Jerram wrote:
  Hi John,
  
  On 04/06/15 12:21, John Garbutt wrote:
  Hi,
  
  We had a great discussion at the summit around priorities:
  https://etherpad.openstack.org/p/YVR-nova-liberty-priorities
  
  I have made a stab at writing that up here, please to review if you
  are interested:
  https://review.openstack.org/#/c/187272/
  
  Note we plan to keep focus on the reviews using the etherpad like we
  did in kilo:
  https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
  
  As you may have seen, I've collated libvirt/VIF type work at
  https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.  Where
  would you prefer any discussion about that to continue?  Here on the ML,
  or in that review job?
  
  Hello again...
  
  So, just pinging again about the libvirt/VIF type work that I've collated at
  https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.  I'm keen if
  possible to have some kind of next step for discussing whether and how this
  work can be integrated into Nova's Liberty cycle.
  
  I wonder if it would help to present this work at a higher level -
  especially as it's really a grouping of three different kinds of work, and
  it may be that there is an elephant in the room of one of those kinds, which
  needs to be brought more into the open.
  
  Firstly there is a group of simple changes for new VIF types: TAP, macvtap,
  Infiniband SR-IOV; and removal of mlnx_direct.  Changes of similar intent,
  scale and scope went in during Kilo, and I imagine that these could be
  reviewed and merged quite quickly, at any time from now on.  It would be
  nice from my point of view to have that 'done', and perhaps from others'
  point of view too.
  
  Secondly there is the VIF plug script idea, and it's here that the elephant
  may be.  I'm afraid that some of the interested people (including me) missed
  it, but I heard that the core team discussed this and expressed concern, in
  one of the Vancouver sessions, about 'not wanting Nova to become a
  pass-through API'.  Since then, spec work has continued, but the only core
  input has come from Dan PB, who wasn't in that Vancouver session - so I'm
  worried that the Nova core team as a whole might not support this idea, and
  that the ongoing spec refinement might turn out to be rearranging the deck
  chairs on the Titanic.
 
 As you said, I wasn't there, so I don't know what the objections were, but
 I'm personally not supportive of adding any new VIF types until we have
 the VIF plugging script work done. This concept is critical to preventing
 the further explosion in the number of VIF types we need, and in allowing
 vendors to add new neutron mechanisms without always requiring a lock-step
 update to Nova.
 
 So from that POV I think the VIF script thing needs to be the #1 priority
 wrt VIF driver work in Nova/libvirt for Liberty.
 
 Regards,
 Daniel


__
OpenStack Development Mailing 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] Liberty Process, Deadlines and Dates for Nova

2015-06-10 Thread John Garbutt

On 4 June 2015 at 12:42, John Garbutt j...@johngarbutt.com wrote:
 Hi,

 Following up from nova-meetings and this summit session:
 https://etherpad.openstack.org/p/YVR-nova-liberty-process

snip

 With that in mind, does this seem like a good idea?
 June 12: spec review day (to be confirmed)

Note this is happening on Friday, and its confirmed.

A day where I hope everyone can help review nova-specs, so we can get
as many specs merged before the spec freeze deadline thats coming up
soon.

We can discuss the details more in the nova-meeting tomorrow.

 July 10: feature review bash day (to be confirmed)
 August 7: bug triage day (to be confirmed)
 September 11: bug review bash day (to be confirmed)

 I am adding more details here:
 https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule

I have updated the above wiki page. It helps define what all the
deadlines mean, and how the exceptions will be processed.

I noticed I missed out a few dates in the original list, so here is
the updated list:
* June 23-25: liberty-1 -- spec freeze for L, backlog stays open
* July 13-17: non-priority feature proposal freeze
* July 21-23: mid-cycle meetup
* July 28-30: liberty-2 -- non-priority feature freeze
* August 17-21: Feature Proposal Freeze
* September 1-3: liberty-3 -- align with string freeze, etc, open specs for M

Thanks,
John

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

Re: [openstack-dev] [OpenStack Foundation] Openstack Diversity Working Group

2015-06-10 Thread Tom Fifield

If anyone needs help with the timezone conversion, I recommend

http://www.timeanddate.com/worldclock/meeting.html

Just put in Portland and your nearest city into the boxes and you'll
get an hour-by-hour breakdown :)

On 10/06/15 23:39, Barrett, Carol L wrote:
 The Doodle time zone doesn’t seem to be appearing in the local timebased
 upon the viewer.
 
  
 
 Sorry – The time zone is US/Pacific time (UTC-7), you’ll need to do your
 own conversion.
 
  
 
 Thanks
 
 Carol
 
  
 
 *From:*Sousou, Imad [mailto:imad.sou...@intel.com]
 *Sent:* Tuesday, June 09, 2015 11:34 AM
 *To:* foundat...@lists.openstack.org; openst...@lists.openstack.org;
 commun...@lists.openstack.org; foundation-bo...@lists.openstack.org;
 openstack-dev@lists.openstack.org
 *Subject:* [OpenStack Foundation] Openstack Diversity Working Group
 
  
 
 Stackers – We’re happy to announce the creation of a Diversity Working
 Group. The genesis for this work group was a discussion at the May
 meeting of the OpenStack Board of Directors ahead of the Vancouver Summit.
 
  
 
 The Board is committed to fostering an inclusive and welcoming place for
 all people to collaborate to drive innovation and design cutting-edge
 data center capabilities, while finding the best answers to our most
 pressing challenges. To achieve this, the Board formed this Work Group
 to determine what actions are required to fulfill this commitment. Three
 Board members volunteered to work with community members in this Work
 Group and bring updates/requests to the Board for discussion and action
 on a regular basis, starting with the July meeting.
 
  
 
 If you’re interested in joining this effort, please:
 
 · Join the Foundation mail list to participate in discussions
 and shape the direction: click here
 http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
 
 · Visit the wiki page for this work group to learn more about
 the charter: click here https://wiki.openstack.org/wiki/Diversity
 
 · Plan to join the kick-off IRC meeting and let us know what
 day/times work for you by accessing the Doodle here: click here
 http://doodle.com/z85c23dtexx8qzq7
 
  
 
 We will send out the results of the Doodle to the mail list and look
 forward to working with you to foster a strong and diverse community.
 
  
 
 Thanks
 
 Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)
 
  
 
  
 
  
 
  
 
  
 
  
 
  
 
 
 
 ___
 Foundation mailing list
 foundat...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
 


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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 10 June 2015 at 17:06, Fox, Kevin M kevin@pnnl.gov wrote:
 So... as an op, without release notes, how am I supposed to figure out the 
 proper upgrade procedure's when you often have to lockstep, in the right 
 order, nova+neutron upgrades (or other project combinations)?

 Thanks,
 Kevin

Hi Kevin,

I suspect there is some confusion here between stable point releases
and major releases.  The major releases are still continuing as
expected with rich release notes.  This is talking about stable patch
releases such as:

https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.3

As you can see there is only notices in Known Issues and Limitations
section of low impact.  I do not believe we've ever required ordering
in the updates of these, as they are supposed to be pretty
conservative changes that shouldn't enforce limitations like that.

HTH

--
Kind Regards,
Dave Walker

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

2015-06-10 Thread Barrett, Carol L

The Doodle time zone doesn't seem to be appearing in the local timebased upon 
the viewer.

Sorry - The time zone is US/Pacific time (UTC-7), you'll need to do your own 
conversion.

Thanks
Carol

From: Sousou, Imad [mailto:imad.sou...@intel.com]
Sent: Tuesday, June 09, 2015 11:34 AM
To: foundat...@lists.openstack.org; openst...@lists.openstack.org; 
commun...@lists.openstack.org; foundation-bo...@lists.openstack.org; 
openstack-dev@lists.openstack.org
Subject: [OpenStack Foundation] Openstack Diversity Working Group

Stackers - We're happy to announce the creation of a Diversity Working Group. 
The genesis for this work group was a discussion at the May meeting of the 
OpenStack Board of Directors ahead of the Vancouver Summit.

The Board is committed to fostering an inclusive and welcoming place for all 
people to collaborate to drive innovation and design cutting-edge data center 
capabilities, while finding the best answers to our most pressing challenges. 
To achieve this, the Board formed this Work Group to determine what actions are 
required to fulfill this commitment. Three Board members volunteered to work 
with community members in this Work Group and bring updates/requests to the 
Board for discussion and action on a regular basis, starting with the July 
meeting.

If you're interested in joining this effort, please:

* Join the Foundation mail list to participate in discussions and shape 
the direction: click 
herehttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

* Visit the wiki page for this work group to learn more about the 
charter: click herehttps://wiki.openstack.org/wiki/Diversity

* Plan to join the kick-off IRC meeting and let us know what day/times 
work for you by accessing the Doodle here: click 
herehttp://doodle.com/z85c23dtexx8qzq7

We will send out the results of the Doodle to the mail list and look forward to 
working with you to foster a strong and diverse community.

Thanks
Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)







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

Re: [openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick

2015-06-10 Thread Daniel P. Berrange

On Wed, Jun 10, 2015 at 10:40:02AM -0500, Matt Riedemann wrote:
 This is a follow-on to the thread [1] asking about modeling the
 connection_info dict returned from the os-initialize_connection API.
 
 The more I think about modeling that in Nova, the more I think it should
 really be modeled in Cinder with an oslo.versionedobject since it is an API
 contract with the caller (Nova in this case) and any changes to the
 connection_info should require a version change (new/renamed/dropped
 fields).
 
 That got me thinking that if both Cinder and Nova are going to use this
 model, it needs to live in a library, so that would be os-brick now, right?
 
 In terms of modeling, I don't think we want an object for each vendor
 specific backend since (1) there are a ton of them so it'd be like herding
 cats and (2) most are probably sharing common attributes.  So I was thinking
 something more along the lines of classes or types of backends, like local
 vs shared storage, fibre channel, etc.

Yes, I think experiance with the VIF drivers in Neutron/Nova has shown
that we should try to have an N:1 mapping between the vendor drivers
and the Nova side plugin. This avoids the need to lock-step upgrade
the Nova code every time a new plugin appears on the cinder side,
and avoids re-inventing the same code over  over for each vendor.

 I'm definitely not a storage guy so I don't know the best way to delineate
 all of these, but here is a rough idea so far. [2]  This is roughly based on
 how I see things modeled in the nova.virt.libvirt.volume module today, but
 there isn't a hierarchy there.
 
 os-brick could contain the translation shim for converting the serialized
 connection_info dict into a hydrated ConnectionInfo object based on the type
 (have some kind of factory pattern in os-brick that does the translation
 based on driver_volume_type maybe given some mapping).
 
 Then when Nova gets the connection_info back from Cinder
 os-initialize_connection, it can send that into os-brick's translator
 utility and get back the ConnectionInfo object and access the attributes
 from that.
 
 Thoughts?

Agree, that it does seem like we could be sharing the object definitions
between Nova  Cinder, instead of re-creating them in both projects.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-10 Thread Fox, Kevin M

So... as an op, without release notes, how am I supposed to figure out the 
proper upgrade procedure's when you often have to lockstep, in the right order, 
nova+neutron upgrades (or other project combinations)?

Thanks,
Kevin

From: Thomas Goirand [z...@debian.org]
Sent: Wednesday, June 10, 2015 1:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [stable] No longer doing stable point
releases

On 06/05/2015 02:46 PM, Thierry Carrez wrote:
 So.. summarizing the various options again:

 Plan A
 Just drop stable point releases.
 (-) No more release notes
 (-) Lack of reference points to compare installations

 Plan B
 Push date-based tags across supported projects from time to time.
 (-) Encourages to continue using same version across the board
 (-) Almost as much work as making proper releases

 Plan C
 Let projects randomly tag point releases whenever
 (-) Still a bit costly in terms of herding cats

 Plan D
 Drop stable point releases, publish per-commit tarballs
 (-) Requires some infra changes, takes some storage space

 Plans B, C and D also require some release note / changelog generation
 from data maintained *within* the repository.

 Personally I think the objections raised against plan A are valid. I
 like plan D, since it's more like releasing every commit than not
 releasing anymore. I think it's the most honest trade-off. I could go
 with plan C, but I think it's added work for no additional value to the
 user.

 What would be your preferred option ?

I see no point of doing D. I already don't use tarballs, and those who
do could as well switch to generating them (how hard is it to run
python setup.py sdist or git archive?).

What counts is having a schedule date, where all distros are releasing a
point release, so we have a common reference point. If that is a fully
automated process, then great, less work for everyone, and it wont
change anything from what we had in the past (we can even collectively
decide for point release dates...).

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

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

2015-06-10 Thread John Wood

Hello folks,

Thanks for the consideration of this feature. Does it seem realistic for a 
Liberty release of Keystone middleware to expose X-Group-Ids, or would this be 
an M and beyond sort of thing?

Thanks,
John


From: Henry Nash henryna...@mac.commailto:henryna...@mac.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, June 5, 2015 at 12:49 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing 
X-Group- in token validation

The one proviso is that in single LDAP situations, the cloud provider can chose 
(for backward compatibility reasons) to allow the underlying LDAP user/group 
ID….so we might want to advise this to be disabled (there’s a config switch to 
use the Public ID mapping for even this case).

Henry
On 5 Jun 2015, at 18:19, Dolph Mathews 
dolph.math...@gmail.commailto:dolph.math...@gmail.com wrote:


On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash 
henry.n...@uk.ibm.commailto:henry.n...@uk.ibm.com wrote:
So I think that GroupID's are actually unique and safesince in the multi 
LDAP case we provide an indirection already in Keystone and issue a Public ID 
(this is true for bother users and groups), that we map to the underlying local 
ID in the particular LDAP backend.

Oh, awesome! I didn't realize we did that for groups as well. So then, we're 
safe exposing X-Group-Ids to services via keystonemiddleware.auth_token but 
still not X-Group-Names (in any trivial form).



Henry


From:   Dolph Mathews dolph.math...@gmail.commailto:dolph.math...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Henry Nash hen...@linux.vnet.ibm.commailto:hen...@linux.vnet.ibm.com, Henry 
Nash/UK/IBM@IBMGB
Date:   05/06/2015 15:38
Subject:Re: [openstack-dev] [keystone][barbican] Regarding exposing 
X-Group- in token validation






On Thu, Jun 4, 2015 at 10:17 PM, John Wood 
john.w...@rackspace.commailto:john.w...@rackspace.com wrote:
Hello folks,

Regarding option C, if group IDs are unique within a given cloud/context, and 
these are discoverable by clients that can then set the ACL on a secret in 
Barbican, then that seems like a viable option to me. As it is now, the user 
information provided to the ACL is the user ID information as found in 
X-User-Ids now, not user names.

To Kevin’s point though, are these group IDs unique across domains now, or in 
the future? If not the more complex tuples suggested could be used, but seem 
more error prone to configure on an ACL.

Well, that's a good question, because that depends on the backend, and our 
backend architecture has recently gotten very complicated in this area.

If groups are backed by SQL, then they're going to be globally unique UUIDs, so 
the answer is always yes.

If they're backed by LDAP, then actually it depends on LDAP, but the answer 
should be yes.

But the nightmare scenario we now support is domain-specific identity drivers, 
where each domain can actually be configured to talk to a different LDAP 
server. In that case, I don't think you can make any guarantees about group ID 
uniqueness :( Instead, each domain could provide whatever IDs it wants, and 
those might conflict with those of other domains. We have a workaround for a 
similar issue with user IDs, but it hasn't been applied to groups, leaving them 
quite broken in this scenario. I'd consider this to be an issue we need to 
solve in Keystone, though, not something other projects need to worry about. 
I'm hoping Henry Nash can chime in and correct me!


Thanks,
John

From: Fox, Kevin M kevin@pnnl.govmailto:kevin@pnnl.gov
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, June 4, 2015 at 6:01 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org

Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing 
X-Group- in token validation

In Juno I tried adding a user in Domain A to group in Domain B. That currently 
is not supported. Would be very handy though.

We're getting a ways from the original part of the thread, so I may have lost 
some context, but I think the original question was, if barbarian can add group 
names to their resource acls.

Since two administrative domains can issue the same group name, its not safe I 
believe.

Simply ensuring the group name is associated with a user and the domain for the 
user matches the domain for the group wouldn't work because someone with 
control of their own domain can just make a
user and give them

[openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick

2015-06-10 Thread Matt Riedemann

This is a follow-on to the thread [1] asking about modeling the 
connection_info dict returned from the os-initialize_connection API.


The more I think about modeling that in Nova, the more I think it should 
really be modeled in Cinder with an oslo.versionedobject since it is an 
API contract with the caller (Nova in this case) and any changes to the 
connection_info should require a version change (new/renamed/dropped 
fields).


That got me thinking that if both Cinder and Nova are going to use this 
model, it needs to live in a library, so that would be os-brick now, right?


In terms of modeling, I don't think we want an object for each vendor 
specific backend since (1) there are a ton of them so it'd be like 
herding cats and (2) most are probably sharing common attributes.  So I 
was thinking something more along the lines of classes or types of 
backends, like local vs shared storage, fibre channel, etc.


I'm definitely not a storage guy so I don't know the best way to 
delineate all of these, but here is a rough idea so far. [2]  This is 
roughly based on how I see things modeled in the 
nova.virt.libvirt.volume module today, but there isn't a hierarchy there.


os-brick could contain the translation shim for converting the 
serialized connection_info dict into a hydrated ConnectionInfo object 
based on the type (have some kind of factory pattern in os-brick that 
does the translation based on driver_volume_type maybe given some mapping).


Then when Nova gets the connection_info back from Cinder 
os-initialize_connection, it can send that into os-brick's translator 
utility and get back the ConnectionInfo object and access the attributes 
from that.


Thoughts?

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066450.html
[2] 
https://docs.google.com/drawings/d/1geSKQXz4SqfXllq1Pk5o2YVCycZVf_i6ThY88r9YF4A/edit?usp=sharing


--

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

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

2015-06-10 Thread Dolph Mathews

We're aiming for a Spec Proposal Freeze deadline for Liberty of June
23rd, but are requiring that specs are approved by our spec reviewers by
that date. The spec [1] is currently pretty straightforward and provides us
several benefits, so I don't expect it to be a complicated process, but is
currently pending a revision from myself. I'm confident in Liberty at this
point.

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

On Wed, Jun 10, 2015 at 10:35 AM, John Wood john.w...@rackspace.com wrote:

  Hello folks,

  Thanks for the consideration of this feature. Does it seem realistic for
 a Liberty release of Keystone middleware to expose X-Group-Ids, or would
 this be an M and beyond sort of thing?

  Thanks,
 John


   From: Henry Nash henryna...@mac.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Friday, June 5, 2015 at 12:49 PM

 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing
 X-Group- in token validation

   The one proviso is that in single LDAP situations, the cloud provider
 can chose (for backward compatibility reasons) to allow the underlying LDAP
 user/group ID….so we might want to advise this to be disabled (there’s a
 config switch to use the Public ID mapping for even this case).

  Henry

 On 5 Jun 2015, at 18:19, Dolph Mathews dolph.math...@gmail.com wrote:


 On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash henry.n...@uk.ibm.com wrote:

 So I think that GroupID's are actually unique and safesince in the
 multi LDAP case we provide an indirection already in Keystone and issue a
 Public ID (this is true for bother users and groups), that we map to the
 underlying local ID in the particular LDAP backend.


  Oh, awesome! I didn't realize we did that for groups as well. So then,
 we're safe exposing X-Group-Ids to services via
 keystonemiddleware.auth_token but still not X-Group-Names (in any trivial
 form).




 Henry


   From:  Dolph Mathews dolph.math...@gmail.com  To:  OpenStack
 Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org, Henry Nash hen...@linux.vnet.ibm.com,
 Henry Nash/UK/IBM@IBMGB   Date:  05/06/2015 15:38   Subject:  Re:
 [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in
 token validation

 --




 On Thu, Jun 4, 2015 at 10:17 PM, John Wood *john.w...@rackspace.com*
 john.w...@rackspace.com wrote:
 Hello folks,

 Regarding option C, if group IDs are unique within a given cloud/context,
 and these are discoverable by clients that can then set the ACL on a secret
 in Barbican, then that seems like a viable option to me. As it is now, the
 user information provided to the ACL is the user ID information as found in
 X-User-Ids now, not user names.

 To Kevin’s point though, are these group IDs unique across domains now,
 or in the future? If not the more complex tuples suggested could be used,
 but seem more error prone to configure on an ACL.

 Well, that's a good question, because that depends on the backend, and
 our backend architecture has recently gotten very complicated in this area.

 If groups are backed by SQL, then they're going to be globally unique
 UUIDs, so the answer is always yes.

 If they're backed by LDAP, then actually it depends on LDAP, but the
 answer should be yes.

 But the nightmare scenario we now support is domain-specific identity
 drivers, where each domain can actually be configured to talk to a
 different LDAP server. In that case, I don't think you can make any
 guarantees about group ID uniqueness :( Instead, each domain could provide
 whatever IDs it wants, and those might conflict with those of other
 domains. We have a workaround for a similar issue with user IDs, but it
 hasn't been applied to groups, leaving them quite broken in this scenario.
 I'd consider this to be an issue we need to solve in Keystone, though, not
 something other projects need to worry about. I'm hoping Henry Nash can
 chime in and correct me!


 Thanks,
 John

 *From: *Fox, Kevin M *kevin@pnnl.gov* kevin@pnnl.gov
 * Reply-To: *OpenStack Development Mailing List (not for usage
 questions) *openstack-dev@lists.openstack.org*
 openstack-dev@lists.openstack.org
 * Date: *Thursday, June 4, 2015 at 6:01 PM
 * To: *OpenStack Development Mailing List (not for usage questions) 
 *openstack-dev@lists.openstack.org* openstack-dev@lists.openstack.org

 * Subject: *Re: [openstack-dev] [keystone][barbican] Regarding exposing
 X-Group- in token validation

 In Juno I tried adding a user in Domain A to group in Domain B. That
 currently is not supported. Would be very handy though.

 We're getting a ways from the original part of the thread, so I may have
 lost some context, but I think the original question was, if barbarian can
 add group names to their resource acls.

 Since two administrative

Re: [openstack-dev] [javascript] Linters

2015-06-10 Thread Michael Krotscheck

On Tue, Jun 9, 2015 at 3:37 PM Robert Collins robe...@robertcollins.net
wrote:

 On 10 June 2015 at 04:01, Michael Krotscheck krotsch...@gmail.com wrote:
  Well, it looks like everyone has disqualified jslint and jshint, so let's
  just make a decision there and remove them from the running. Unless I
 hear a
  compelling reason to use something that has the infamous do no evil
  license in it, let's dump it.
 ...
  As for how this is synchronized, a brief discussion in the infra channel
  proposed that we put global javascript requirements in the
  global-requirements repo, and then update the update.py script in that
 repo
  to also handle bower.json and package.json. Then, if we build an
 eslint/jscs
  plugin similar to our hacking rules, we can just update that when we
 want to
  modify the linting rules. Any objections?

 Yes, I think this should live in openstack/requirements.

 bower.json is clearly js specific; package.json isn't AFAICT - can you
 give me some sane pointers to go level up on that?


There are two package managers in the JavaScript world right now, one that
focuses on node.js/server dependencies (karma, lint, express, etc), and one
that focuses on in-browser dependencies (angular, bootstrap, etc). They're
both required for thick browser clients, but for server apps you only
really need package.json

https://docs.npmjs.com/files/package.json
https://github.com/stackforge/refstack/blob/master/refstack-ui/package.json
https://github.com/angular-ui/bootstrap/blob/master/package.json
https://github.com/openstack/horizon/blob/master/package.json


 In the absence of information I'm assuming we should make a subdir
 'js' and put bower.json and package.json in there (and do the same for
 the python things in a subdir called python for symmetry, though
 backwards compat and tooling considerations may mean that we have to
 prepare for that. The reason being that if package.json is js
 specific, its just confusing to have it live at the top level. Also we
 may want to call them global-$thing, since if we do have js in the
 requirements repo itself at some point, it would be good not to
 conflict on names.


FYI, it looks like the monasca team may want to start doing similar things
with Java. More information after I hunt them down this morning :)


 I'm not at all sure that update.py should handle the json files per
 se; will the policy for those files be the same as we use for python?


Add linting rule sets to this list, contained either in .jscsrc or
.eslintrc. Javascript does not have the privilege of pep8 being baked into
the language tooling, so we have to sync it ourselves.


 If not it might be cleaner to have a new entry point. OTOH I'll need
 to look closely at a few real {bower,package}.json files to proffer an
 useful opinion. [Perhaps you covered this in IRC - it didn't come
 through in your summary].


It depends on what you think update.py is supposed to do. If I look at that
repository, I would argue that the purpose is to Synchronize common files
and properties across registered openstack projects. In this case, a
requirement is defined as something required to meet a minimum set of
project sanity standards.

Also, I'm in the middle of rearranging update.py to handle PEP 426 and so
 we should probably coordinate so we don't tromp on each other.


Do you have a patch?

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

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

2015-06-10 Thread Jeremy Stanley

On 2015-06-10 14:39:46 + (+), yang, xing wrote:
 You can ask if OpenStack Infrastructure team can set up CI for
 this driver. They have set up CI's for a few Cinder drivers based
 on open source storage systems.

To be fair, the Infra team hasn't really written the jobs to test
those, but we have pointed the developers responsible for the
drivers to our documentation and reviewed the changes they submit to
add the jobs to our CI.
-- 
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

[openstack-dev] Announcing Gertty 1.2.0

2015-06-10 Thread James E. Blair

Announcing Gertty 1.2.0
===

Gertty is a console-based interface to the Gerrit Code Review system.

Gertty is designed to support a workflow similar to reading network
news or mail.  It syncs information from Gerrit to local storage to
support disconnected operation and easy manipulation of local git
repos.  It is fast and efficient at dealing with large numbers of
changes and projects.

The full README with installation instructions may be found here:

  https://git.openstack.org/cgit/stackforge/gertty/tree/README.rst

Changes since 1.1.0:


* Changes may be reviewed directly from the change list.

* Multiple changes may be reviewed at once by selecting them from the
  change list.  This can be very useful for mass application of changes
  across many repositories, or to leave comments about dependencies,
  etc, on a whole series of changes.

* The local database and git repositories are pruned of closed changes
  to save space and speed up operations.  By default, changes closed
  more than two months ago are removed, but the value is configurable.

* Searches by filename, age, reviewer, and messages are now supported.

* Change IDs are now supported as simple searches (without a search
  predicate).

* Syncing operations have been improved.

* The file name is always displayed at the top of the diff screen.

* Change IDs, topics, and project names are now searchable links on the
  change screen.

* A URL (e.g., https://review.example.com/#/c/1234/) may be copied into
  the search box to open a change directly.

* The permalink is now displayed on the change screen for easy copy/paste.

* Local checkout and cherry-pick are supported directly from the change
  list.

* Starred and owned changes are synced regardless of whether the project
  is subscribed.

* If Gertty is about to upload a review of a change where someone else
  has since left a more negative vote than the one it is about to
  upload, Gertty will cancel the upload operation and mark the change
  as held for re-review and alert the user.  In this manner, offline
  reviewers can avoid accidentally ignoring potentially important
  negative feedback on a change.

* Scrolling by mouse wheel is now supported.

* Times are displayed in the local timezone, or optionally (by
  configuration) in UTC.

* Several other display and performance improvements.

Thanks to the following people whose changes are included in this
release:

  Adam Spiers
  Christoph Gysin
  James Polley
  Jan Kundrát
  Jeremy Stanley
  K Jonathan Harker
  Matthew Treinish
  Miguel Grinberg
  Paul Belanger

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

[openstack-dev] [murano] backporting changes to stable/juno and stable/kilo

2015-06-10 Thread Kirill Zaitsev

Hi all. I’ve been looking through the bugs/fixes we’ve made during kilo cycle. 
Some of them are worthy of being backported to stable/juno. And some of the 
fixes we’ve already made in liberty are worthy of being backported to 
stable/kilo.

Since we’ve agreed on using tags for bugs I’ve marked those bugs as 
juno-backport-potential and kilo-backport-potential.

Here are the links for them 

murano bugs with tag 'juno-backport-potential’ and without a tag 
‘in-stable-juno’ : http://j.mp/murano-juno-backport
murano bugs in murano with tag ‘kilo-backport-potential’ and without a tag 
‘in-stable-kilo’: http://j.mp/murano-kilo-backport

python-muranoclient bugs with tag 'juno-backport-potential’ and without a tag 
‘in-stable-juno’ : http://j.mp/muranoclient-juno-backport
python-muranoclient bugs in murano with tag ‘kilo-backport-potential’ and 
without a tag ‘in-stable-kilo’: http://j.mp/muranoclient-kilo-backport

Sorry for using url shortener, the links are really large and would clutter the 
email otherwise. I also hope I didn’t mess up with them. =) You can construct 
them from Launchpads advanced search.

If you have any objections to the list of bugs to be backported — you can 
comment in respective bugs on l-pad and we can discuss it on a per-bug basis.
If you're aware of any bugs, that have backport potential that are not present 
on the list: feel free to tag them.

-- 
Kirill Zaitsev
Murano team
Software Engineer
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] [nova] vif type libvirt-network

2015-06-10 Thread Neil Jerram


On 10/06/15 15:47, Andreas Scheuring wrote:

Hi Daniel, Neil and others,

I was thinking about introducing libvirt-network as a new vif type to
nova. It can be used when Neutron prepares a libvirt network for
attaching guests.

Would you see any general concerns with such an approach? Anything that
I need to consider with libvirt networks in addition? Maybe I should
mention one thing due to the discussion this morning: No plug/unplug
behavior would required.

Any feedback is welcome!


I added a blueprint and wrote a spec with more details [1]. This
blueprint would make the macvtap-vif blueprint [2] dispensable.

The neutron code exploiting this libvirt network vif type will land on
stackforge. It will manage macvtap backed libvirt networks -- offer
guest attachments via macvtap. [3]



[1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
[2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
[3] https://launchpad.net/networking-macvtap
(I'm still waiting for the repo to be approved, so for now I only have a
launchpad project to ref to).


Thanks, Andreas, this looks interesting.  I wonder if

network
  namexyz/name
  forward mode=route\
  ...
/network

domain
  ...
  interface type='network'
source network='xyx'/
  /interface
  ...
/domain

would provide the connectivity that my Calico project wants to set up 
[1] - i.e. where all data to and from VMs is routed on the compute host 
- instead of


domain
  ...
  interface type='ethernet'
...
  /interface
  ...
/domain

Do you happen to know how data gets routed _to_ a VM, in the 
type='network' case?


Regards,
Neil


[1] http://docs.projectcalico.org/en/latest/home.html

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

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

2015-06-10 Thread Kyle Mestery

On Wed, Jun 10, 2015 at 2:11 PM, Carl Baldwin c...@ecbaldwin.net wrote:

Folks,

As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
propose Brian Haley as a member of the Neutron L3 core reviewer team.
Brian has been a long time contributor in Neutron showing expertise
particularly in IPv6, iptables, and Linux kernel matters. His
knowledge and involvement will be very important especially in this
area. Brian has become a trusted member of our community. His review
stats [2][3][4] place him comfortably with other Neutron core
reviewers. He regularly runs proposed patches himself and gives
insightful feedback. He has shown a lot of interest in the success of
Neutron.

Existing Neutron core reviewers from the L3 area of focus, please vote
+1/-1 for the addition of Brian to the core reviewer team.
Specifically, I'm looking for votes from Henry, Assaf, and Mark.

Thanks for being the first Lieutenant to nominate a core reviewer to your
area of focus Carl! I obviously think Brian is a great choice here, and I'm
glad to see you growing the L3 area in Neutron.

Thanks,
Kyle

Thanks!
Carl

[1]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
[2]
https://review.openstack.org/#/q/reviewer:%22Brian+Haley+%253Cbrian.haley%2540hp.com%253E%22,n,z
[3] http://stackalytics.com/report/contribution/neutron-group/90
[4] http://stackalytics.com/?user_id=brian-haleymetric=marks

__
OpenStack Development Mailing 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] Proposing Brian Haley to Neutron L3 Core Reviewer Team

2015-06-10 Thread Assaf Muller

- Original Message -
Folks,

Existing Neutron core reviewers from the L3 area of focus, please vote
+1/-1 for the addition of Brian to the core reviewer team.
Specifically, I'm looking for votes from Henry, Assaf, and Mark.

Thanks!
Carl

[openstack-dev] [oslo] Adopt mox3

2015-06-10 Thread Davanum Srinivas

Oslo folks, everyone,

mox3 needs to be maintained since some of our projects use it and we
have it in our global requirements.

Here's the proposal from Doug - https://review.openstack.org/#/c/190330/

Any objections? Please chime in here or on the review.

thanks,
dims

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

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

Re: [openstack-dev] [openstack-operators][openstack][chef] Pre-release of knife-openstack is out (1.2.0.rc1)

2015-06-10 Thread JJ Asghar


 On Jun 4, 2015, at 6:12 PM, JJ Asghar jasg...@chef.io wrote:
 
 I have cut a new release of the knife-openstack[1] gem today. We have a 
 couple new features[2] which has been asked for a while.


I have pushed another pre-release (1.2.0.rc2) of knife-openstack. 

The main change is support for the `—bootstrap-template` now.

 
 If you would like to give it a shot and report back any issues you might 
 find[3].
 
 gem install knife-openstack --pre
 
 I’m hoping to give this a week or two to bake, then I’ll push it to master 
 and a 1.2.0 release.
 
 If you have any questions, thoughts, concerns please don’t hesitate to reach 
 out!
 
 [1]: https://rubygems.org/gems/knife-openstack 
 https://rubygems.org/gems/knife-openstack
 [2]: https://github.com/chef/knife-openstack/pull/165/files 
 https://github.com/chef/knife-openstack/pull/165/files
 [3]: https://github.com/chef/knife-openstack/issues 
 https://github.com/chef/knife-openstack/issues
 
 -JJ
 

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] [nova] vif type libvirt-network

2015-06-10 Thread Neil Jerram


Hi Ian,

Thanks for your reply!

On 10/06/15 21:07, Ian Wells wrote:

I don't see a problem with this, though I think you do want plug/unplug
calls to be passed on to Neutron so that has the opportunity to set up
the binding from its side (usage 0) and tear it down when you're done
with it (usage 1).

There may be a set of races you need to deal with, too - what happens if
Nova starts a VM attached to a Neutron network binding that has yet to
be set up?  Neutron doesn't (well, technically, shouldn't be expected
to) do things instantaneously on a call, even binding, or you get into
the realm of distributed system failure case analysis.


Good point.  Andreas, how do you think the timing of the Nova and 
Neutron parts will work?



Neil, are you trying to route to the host - where this will work,
because a libvirt network is L2 - or to the VM - where this won't, for
the same reason?


Consider data that's arriving at a local VM, and has come from a VM on 
another compute host.


  VM - Host A - Host B - VM
10.0.0.1  10.0.0.2

In Host B's routing table there is a rule like this:

10.0.0.2/32 dev tap12345-CD

where tap12345-CD is the TAP interface towards the VM.  Does that answer 
your question, and would that be possible with a libvirt network?


Thanks,
Neil



--
Ian.


On 10 June 2015 at 12:16, Neil Jerram neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:

On 10/06/15 15:47, Andreas Scheuring wrote:

Hi Daniel, Neil and others,

I was thinking about introducing libvirt-network as a new vif
type to
nova. It can be used when Neutron prepares a libvirt network for
attaching guests.

Would you see any general concerns with such an approach?
Anything that
I need to consider with libvirt networks in addition? Maybe I should
mention one thing due to the discussion this morning: No plug/unplug
behavior would required.

Any feedback is welcome!


I added a blueprint and wrote a spec with more details [1]. This
blueprint would make the macvtap-vif blueprint [2] dispensable.

The neutron code exploiting this libvirt network vif type will
land on
stackforge. It will manage macvtap backed libvirt networks -- offer
guest attachments via macvtap. [3]



[1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
[2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
[3] https://launchpad.net/networking-macvtap
(I'm still waiting for the repo to be approved, so for now I
only have a
launchpad project to ref to).


Thanks, Andreas, this looks interesting.  I wonder if

network
   namexyz/name
   forward mode=route\
   ...
/network

domain
   ...
   interface type='network'
 source network='xyx'/
   /interface
   ...
/domain

would provide the connectivity that my Calico project wants to set
up [1] - i.e. where all data to and from VMs is routed on the
compute host - instead of

domain
   ...
   interface type='ethernet'
 ...
   /interface
   ...
/domain

Do you happen to know how data gets routed _to_ a VM, in the
type='network' case?

Regards,
 Neil


[1] http://docs.projectcalico.org/en/latest/home.html


__
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




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



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

Re: [openstack-dev] [Openstack] [OpenStack Foundation] Openstack Diversity Working Group

2015-06-10 Thread Pete Chadwick

Doodle does this automatically. At least it presented me with what
appeared to be US East times. There is a box on the upper right that
tells you the time zone and lets you change it.

Pete


On Wed, 2015-06-10 at 23:43 +0800, Tom Fifield wrote:
 If anyone needs help with the timezone conversion, I recommend
 
 http://www.timeanddate.com/worldclock/meeting.html
 
 Just put in Portland and your nearest city into the boxes and you'll
 get an hour-by-hour breakdown :)
 
 On 10/06/15 23:39, Barrett, Carol L wrote:
  The Doodle time zone doesn’t seem to be appearing in the local timebased
  upon the viewer.
  
   
  
  Sorry – The time zone is US/Pacific time (UTC-7), you’ll need to do your
  own conversion.
  
   
  
  Thanks
  
  Carol
  
   
  
  *From:*Sousou, Imad [mailto:imad.sou...@intel.com]
  *Sent:* Tuesday, June 09, 2015 11:34 AM
  *To:* foundat...@lists.openstack.org; openst...@lists.openstack.org;
  commun...@lists.openstack.org; foundation-bo...@lists.openstack.org;
  openstack-dev@lists.openstack.org
  *Subject:* [OpenStack Foundation] Openstack Diversity Working Group
  
   
  
  Stackers – We’re happy to announce the creation of a Diversity Working
  Group. The genesis for this work group was a discussion at the May
  meeting of the OpenStack Board of Directors ahead of the Vancouver Summit.
  
   
  
  The Board is committed to fostering an inclusive and welcoming place for
  all people to collaborate to drive innovation and design cutting-edge
  data center capabilities, while finding the best answers to our most
  pressing challenges. To achieve this, the Board formed this Work Group
  to determine what actions are required to fulfill this commitment. Three
  Board members volunteered to work with community members in this Work
  Group and bring updates/requests to the Board for discussion and action
  on a regular basis, starting with the July meeting.
  
   
  
  If you’re interested in joining this effort, please:
  
  · Join the Foundation mail list to participate in discussions
  and shape the direction: click here
  http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
  
  · Visit the wiki page for this work group to learn more about
  the charter: click here https://wiki.openstack.org/wiki/Diversity
  
  · Plan to join the kick-off IRC meeting and let us know what
  day/times work for you by accessing the Doodle here: click here
  http://doodle.com/z85c23dtexx8qzq7
  
   
  
  We will send out the results of the Doodle to the mail list and look
  forward to working with you to foster a strong and diverse community.
  
   
  
  Thanks
  
  Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)
  
   
  
   
  
   
  
   
  
   
  
   
  
   
  
  
  
  ___
  Foundation mailing list
  foundat...@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
  
 
 
 ___
 Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 

-- 
Pete Chadwick
Senior Product Manager
SUSE
pchadw...@suse.com
(M) +1.617.281.2847

www.suse.com


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

[openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

2015-06-10 Thread Carl Baldwin

Folks,

As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
propose Brian Haley as a member of the Neutron L3 core reviewer team.
Brian has been a long time contributor in Neutron showing expertise
particularly in IPv6, iptables, and Linux kernel matters.  His
knowledge and involvement will be very important especially in this
area.  Brian has become a trusted member of our community.  His review
stats [2][3][4] place him comfortably with other Neutron core
reviewers.  He regularly runs proposed patches himself and gives
insightful feedback.  He has shown a lot of interest in the success of
Neutron.

Existing Neutron core reviewers from the L3 area of focus, please vote
+1/-1 for the addition of Brian to the core reviewer team.
Specifically, I'm looking for votes from Henry, Assaf, and Mark.

Thanks!
Carl

[1] 
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
[2] 
https://review.openstack.org/#/q/reviewer:%22Brian+Haley+%253Cbrian.haley%2540hp.com%253E%22,n,z
[3] http://stackalytics.com/report/contribution/neutron-group/90
[4] http://stackalytics.com/?user_id=brian-haleymetric=marks

__
OpenStack Development Mailing 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] Online Migrations.

2015-06-10 Thread Philip Schwartz

All, 

I am taking over work on https://review.openstack.org/#/c/154521/ from 
Johanness and have spent some time today discussing the current patchset and 
what is remaining with Dan and Johannes.

I wanted to broach the topic of the remaining development with the lists to 
make sure we go in the right direction with it as it is not an easy  problem to 
solve. 

The remaining work is to have a way of preventing database contracts from 
running until data migrations that the column interacts with are complete, this 
is not an easy problem to solve as the goal of the online migrations is to do 
pure model based schema migrations and there is no way of currently identifying 
when a data migration has taken place and a contract is safe to perform.

The first thought I had was to default to a requirement of a data migration 
removing data from a column and have the default check of the contract be one 
of verifying that the column is currently empty. This has the issue of not 
working in all cases, especially around Foreign Keys.

At this point I would like to open this discussion up to all in order to make 
sure the best solution is chosen for this problem..

-Ph
__
OpenStack Development Mailing 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] Proposing Brian Haley to Neutron L3 Core Reviewer Team

2015-06-10 Thread Henry Gessau

+1 Brian will be a great addition for L3

On Wed, Jun 10, 2015, Carl Baldwin c...@ecbaldwin.net wrote:
Folks,

Existing Neutron core reviewers from the L3 area of focus, please vote
+1/-1 for the addition of Brian to the core reviewer team.
Specifically, I'm looking for votes from Henry, Assaf, and Mark.

Thanks!
Carl

Re: [openstack-dev] Online Migrations.

2015-06-10 Thread Philip Schwartz

I like the idea of having a named condition, but the issue is how to maintain 
and control multiple of these conditions in a system that will use model 
against current schema to determine changes.

I also agree that we should get the current patch in as soon as possible and 
can move my -1 as a hold from it if others don’t mind it going as is while we
work on the next part. I have updated the patchset to pass check’s this 
afternoon.

-Ph

 On Jun 10, 2015, at 4:34 PM, Dan Smith d...@danplanet.com wrote:
 
 The remaining work is to have a way of preventing database contracts
 from running until data migrations that the column interacts with are
 complete, this is not an easy problem to solve as the goal of the
 online migrations is to do pure model based schema migrations and
 there is no way of currently identifying when a data migration has
 taken place and a contract is safe to perform.
 
 I'd still like to see what we have done so far merged as soon as
 possible. That facilitates testing the main goal of it, which is
 actually moving the schema along. It's experimental and completely
 optional, and should have a may eat your lunch warning anyway.
 
 The first thought I had was to default to a requirement of a data
 migration removing data from a column and have the default check of
 the contract be one of verifying that the column is currently empty.
 This has the issue of not working in all cases, especially around
 Foreign Keys.
 
 I'm not sure if SQLAlchemy will balk at this or not, but we could do
 something like:
 
 
  class NameRemovedCondition(object):
  def satisfied(self):
  # Check to see if name has been fully migrated
 
 
  class Instance(sqla.Model):
  id = sqla.Integer()
  uuid = sqla.String()
  name = RemovedField(original=sqla.String(),
condition=NameCondition())
 
 
 Then the schema migration bit can catch RemovedField entries, know what
 they were (so that it can leave that bit alone), and only remove them
 when condition is satisfied. Complex migrations that affect multiple
 columns can share a condition that checks the full situation.
 
 Like I said, I'd like to get the existing patch merged so that we can
 discuss options for this remaining bit in a smaller scope.
 
 --Dan
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Mechanism drivers and Neutron server forking?

2015-06-10 Thread Kyle Mestery

On Wed, Jun 10, 2015 at 2:25 PM, Neil Jerram neil.jer...@metaswitch.com
wrote:



 On 08/06/15 22:02, Kevin Benton wrote:

 This depends on what initialize is supposed to be doing. If it's just a
 one-time sync with a back-end, then I think calling it once in each
 child process might not be what we want.

 I left a comment on Terry's patch. I think we should just use the
 callback manager to have a pre-fork and post-fork even to let
 drivers/plugins do whatever is appropriate for them.


 Can you point me to more detail about the callback manager (or registry)?
 I haven't come across that yet.


http://docs.openstack.org/developer/neutron/devref/callbacks.html



 Thanks,
 Neil

 __
 OpenStack Development Mailing 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] Online Migrations.

2015-06-10 Thread Dan Smith

 The remaining work is to have a way of preventing database contracts
 from running until data migrations that the column interacts with are
 complete, this is not an easy problem to solve as the goal of the
 online migrations is to do pure model based schema migrations and
 there is no way of currently identifying when a data migration has
 taken place and a contract is safe to perform.

I'd still like to see what we have done so far merged as soon as
possible. That facilitates testing the main goal of it, which is
actually moving the schema along. It's experimental and completely
optional, and should have a may eat your lunch warning anyway.

 The first thought I had was to default to a requirement of a data
 migration removing data from a column and have the default check of
 the contract be one of verifying that the column is currently empty.
 This has the issue of not working in all cases, especially around
 Foreign Keys.

I'm not sure if SQLAlchemy will balk at this or not, but we could do
something like:


  class NameRemovedCondition(object):
  def satisfied(self):
  # Check to see if name has been fully migrated


  class Instance(sqla.Model):
  id = sqla.Integer()
  uuid = sqla.String()
  name = RemovedField(original=sqla.String(),
condition=NameCondition())


Then the schema migration bit can catch RemovedField entries, know what
they were (so that it can leave that bit alone), and only remove them
when condition is satisfied. Complex migrations that affect multiple
columns can share a condition that checks the full situation.

Like I said, I'd like to get the existing patch merged so that we can
discuss options for this remaining bit in a smaller scope.

--Dan

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

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

2015-06-10 Thread Neil Jerram




On 08/06/15 22:02, Kevin Benton wrote:

This depends on what initialize is supposed to be doing. If it's just a
one-time sync with a back-end, then I think calling it once in each
child process might not be what we want.

I left a comment on Terry's patch. I think we should just use the
callback manager to have a pre-fork and post-fork even to let
drivers/plugins do whatever is appropriate for them.


Can you point me to more detail about the callback manager (or 
registry)?  I haven't come across that yet.


Thanks,
Neil

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

Re: [openstack-dev] [Openstack-operators] [ops][tags][packaging] [tc] ops:packaging tag - a little common sense, please

2015-06-10 Thread Maish Saidel-Keesing


Forgive the top posting.

Thank you Jay for your clarification and apology.

I wrote the piece below **before** you sent out your email this 
afternoon, so again this is nothing personal and not targeted at any 
**specific** person.


With that said, I still think that what I have to say is still relevant 
(if I am raked over the coals for it, then so be it), and should be 
voiced here on both of these lists, and is quoted here below in full.



Hello all.

I would like to bring to your attention the following log from last 
nights TC meeting [1] (if you have not already gone through it)


Starting at
20:17:42 ttx #topic Discuss differences between Ops and TC tags

Ending at
20:27:13 ttx #topic Add the Searchlight Project

With some highlights

*20:19:47 - ---: they are also setting themselves up for failure, 
IMHO, and a situation where the data will be almost immediately stale 
and worse than in the openstack.org wiki. **
* *20:21:37 -- what ops want is not so much tags as more targeted 
analytics data (extension to bitergia/stackalytics) by the sounds of it *
*20:22:45 - I prefer 1/ really, but I'm more than happy to let 
their current strategy fail and then revisit. **
* *20:24:42 -- --: I have *already* engaged with them. and 
their answer has been f off, we'll do it our way. **
* *20:25:46 *  looks forward to the 
ops:packaged:centos:call-me-maybe:ok-with-cern-this-week tag*


(in order to not single out any single person from the meeting last 
night I have removed the names from the snippet - the originals are in 
the raw log).


Personally I find some of the comments highly condescending, and in some 
cases blatantly a pure insult.
It could be that some of it was supposed to be humorous, was said in the 
'spur of the moment', but I think it is appropriate to remind people 
that all of these things are logged, and available for eternity.


If that is the way that certain members of the TC would like treat an 
initiative that was not born purely as a part of the developer 
community, but as part of the other side of the fence then I am sorry 
but this is destined to fail. Before it even starts.


Yes some of the comments are true, there are things to fix, but instead 
of going down the route of we know better, because we know OpenStack 
and we have been here for 10 cycles already, so let us let them stew in 
their own juice and not help them out, they could be more receptive and 
embrace change and live up to their motto of being more inclusive.


If this attitude continues we will find ourselves after another cycle or 
two (or ten), and the community (and the TC) will still not have proper 
input from what they deem to be an 'important' factor in the community.


It seems to me that the operations aspect of OpenStack is of no interest 
to them - unless it is done their way and their way only.


To me this is classic case of typical OpenStack - That way is no good, I 
have a better way of doing it.


A large number of bytes were spilled during the TC elections of why 
Operators feel excluded from the OpenStack community.


For me, the interaction in the meeting above, is a perfect example of why.

As was voiced already on the mailing list lately [2]
 Not cool .! Not even a little bit.

***Again I would like to stress this is not a personal attack on any 
single member of the TC - but a general feeling *I have* of the wrong 
attitude that is coming across from the people that are supposed to be 
representing and leading the WHOLE OpenStack community.***


I would appreciate your thoughts and comments.

[1] 
http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-06-09-20.01.log.txt

[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066031.html
--

On 06/10/15 20:51, Jay Pipes wrote:
Cross-posting to -operators and -dev because this involves *packagers* 
of OpenStack, as well as operators who use those packages.


Hello Operators,

First, let me start out by saying if you were offended by my snarky 
comments at yesterday's TC meeting [1] regarding the direction of the 
Ops Tags Team, I apologize. Sometimes I am snarky and/or moody, 
especially when I feel strongly about something, as is the case here. 
Please accept my apologies. Let's move on.


= tl;dr =

* The proposed things are not tags
* Operators should not be curating packaging tags (packagers should)
* Tags should not have a value component
* Packaging tags should be release-specific, or they will be wrong

= The details =

OK, that said, here are the issues I have with the proposed 
ops:packaging tags [2].


= The proposed things are not tags =

The things being proposed by the Ops Tags Team are in fact not tags, 
which are simple strings of binary information that have a 
well-defined and singular meaning.


What the Ops Tags Team has proposed is structured, schema-full data 
objects. There is nothing wrong with having a structured object for 
purposes of generating useful information. But

Re: [openstack-dev] [nova] vif type libvirt-network

2015-06-10 Thread Ian Wells

I don't see a problem with this, though I think you do want plug/unplug
calls to be passed on to Neutron so that has the opportunity to set up the
binding from its side (usage 0) and tear it down when you're done with it
(usage 1).

There may be a set of races you need to deal with, too - what happens if
Nova starts a VM attached to a Neutron network binding that has yet to be
set up?  Neutron doesn't (well, technically, shouldn't be expected to) do
things instantaneously on a call, even binding, or you get into the realm
of distributed system failure case analysis.

Neil, are you trying to route to the host - where this will work, because a
libvirt network is L2 - or to the VM - where this won't, for the same
reason?
-- 
Ian.


On 10 June 2015 at 12:16, Neil Jerram neil.jer...@metaswitch.com wrote:

 On 10/06/15 15:47, Andreas Scheuring wrote:

 Hi Daniel, Neil and others,

 I was thinking about introducing libvirt-network as a new vif type to
 nova. It can be used when Neutron prepares a libvirt network for
 attaching guests.

 Would you see any general concerns with such an approach? Anything that
 I need to consider with libvirt networks in addition? Maybe I should
 mention one thing due to the discussion this morning: No plug/unplug
 behavior would required.

 Any feedback is welcome!


 I added a blueprint and wrote a spec with more details [1]. This
 blueprint would make the macvtap-vif blueprint [2] dispensable.

 The neutron code exploiting this libvirt network vif type will land on
 stackforge. It will manage macvtap backed libvirt networks -- offer
 guest attachments via macvtap. [3]



 [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
 [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
 [3] https://launchpad.net/networking-macvtap
 (I'm still waiting for the repo to be approved, so for now I only have a
 launchpad project to ref to).


 Thanks, Andreas, this looks interesting.  I wonder if

 network
   namexyz/name
   forward mode=route\
   ...
 /network

 domain
   ...
   interface type='network'
 source network='xyx'/
   /interface
   ...
 /domain

 would provide the connectivity that my Calico project wants to set up [1]
 - i.e. where all data to and from VMs is routed on the compute host -
 instead of

 domain
   ...
   interface type='ethernet'
 ...
   /interface
   ...
 /domain

 Do you happen to know how data gets routed _to_ a VM, in the
 type='network' case?

 Regards,
 Neil


 [1] http://docs.projectcalico.org/en/latest/home.html


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

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

[openstack-dev] [Glance] [all] python-glanceclient release 0.19.0

2015-06-10 Thread Nikhil Komawar

The python-glanceclient release management team is pleased to announce:

Release of python-glanceclient version 0.19.0

Please find the details related to the release at:

  
https://launchpad.net/python-glanceclient/liberty/0.19.0https://launchpad.net/python-glanceclient/+milestone/v0.17.0

Please report the issues through launchpad:

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

-- 

Thanks,
Nikhil


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

[openstack-dev] [ops][tags][packaging] ops:packaging tag - a little common sense, please

2015-06-10 Thread Jay Pipes

Cross-posting to -operators and -dev because this involves *packagers* 
of OpenStack, as well as operators who use those packages.


Hello Operators,

First, let me start out by saying if you were offended by my snarky 
comments at yesterday's TC meeting [1] regarding the direction of the 
Ops Tags Team, I apologize. Sometimes I am snarky and/or moody, 
especially when I feel strongly about something, as is the case here. 
Please accept my apologies. Let's move on.


= tl;dr =

* The proposed things are not tags
* Operators should not be curating packaging tags (packagers should)
* Tags should not have a value component
* Packaging tags should be release-specific, or they will be wrong

= The details =

OK, that said, here are the issues I have with the proposed 
ops:packaging tags [2].


= The proposed things are not tags =

The things being proposed by the Ops Tags Team are in fact not tags, 
which are simple strings of binary information that have a well-defined 
and singular meaning.


What the Ops Tags Team has proposed is structured, schema-full data 
objects. There is nothing wrong with having a structured object for 
purposes of generating useful information. But please don't call these 
things tags, because they aren't.


Before I move on to other issues, I'd like to point out that the more 
you go down the route of adding more and more attributes, most of which 
would be optional, to these structured documents, the more you will run 
into a problem of having stale and misleading data contained in these 
JSON files. And that will lead to a worse user experience for operators 
than the current wiki, which, like all wikis, is notoriously out-of-date 
in many places.


A tag should mean one thing, and one thing only, to encourage clarity. 
The definition of the tag should be decisive regarding why a particular 
project has been tagged with that tag.


= Operators should not be curating packaging tags =

*Packagers* should be curating tags that correspond to whether or not 
packages exist for particular projects in OpenStack. Operators consume 
these packages, for sure, but the packagers in the upstream operating 
system communities are the ones that know the most accurate information 
about the state of packaging for a particular project and a particular 
release.


I strongly believe that these ops:packaged tags should really just be 
tags in the openstack/governance repository (i.e. regular TC tags) and 
be curated by the packaging community, which means they would not have 
the ops: prefix on them.


= Remove value component from the tag =

The current proposal for both ops:packaged and ops:production-use [3] 
tag definitions include a value component. For example, the 
ops:packaged tags must include one of the following values:


 - good
 - beginning
 - warning
 - no

With each of the above values attempting to indicate to the audience 
that the packages for a particular project are in varying states of 
repair and bug-freeness. There are a number of problems with including 
this value in the tag:


1) This value judgement about the packaging quality is ripe for getting 
out-of-date VERY quickly. Who is going to continually update the value 
parts for the different projects? Things change very quickly in 
packaging-land. Bugs are fixed, new packages built and published. Who in 
the ops community is going to track this? Please see point above about 
Operators should not be curating packaging tags.


2) All software, including packages, has bugs. This is something that 
the Ops community just needs to accept and get over. Quabbling with each 
other about what constitutes a major bug in packaging and how many 
major bugs bugs constitute a warning value is less than useful to 
the audience here. Instead, the ops community should focus on providing 
useful documentation and links to the audience, in the form of long-form 
release notes or opinions about packages and documentation on the 
OpenStack wiki.


= Packaging tags should be release-specific, or they will be wrong =

For these packaging tags, the release must be part of the tag itself, 
otherwise the information it denotes would be indeterminate.


As an example, suppose you have a tag that looks like this:

 ops:packaged:centos:good

And in the tag definition you say that the tag is applied to projects 
that have CentOS RPM packages available within the last 6 months. 
Well, as you all know, packages are published for a *particular release 
of OpenStack*. So, if Nova is tagged with ops:packaged:centos:good in, 
say, August 2015, the tag would ostensibly be saying that packages exist 
for Nova in Kilo. However, once November rolls around, and packages for 
Liberty don't (yet) exist, are you going to remove this 
ops:packaged:centos:good tag from Nova or (worse) change it to 
ops:pacakged:centos:no?


Instead, have the tag be specific to a release of OpenStack:

packaged:centos:kilo

= In summary =

In short, I would love it if the Ops Tags

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

2015-06-10 Thread yang, xing

Thanks Jeremy.  I assume Chen could follow this example to add a job for the 
HDFS driver?

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


Thanks,
Xing


-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org] 
Sent: Wednesday, June 10, 2015 11:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd 
party CI for HDFS driver

On 2015-06-10 14:39:46 + (+), yang, xing wrote:
 You can ask if OpenStack Infrastructure team can set up CI for this 
 driver. They have set up CI's for a few Cinder drivers based on open 
 source storage systems.

To be fair, the Infra team hasn't really written the jobs to test those, but we 
have pointed the developers responsible for the drivers to our documentation 
and reviewed the changes they submit to add the jobs to our CI.
--
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

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

Re: [openstack-dev] [Ironic] weekly meetings and sub-team reports and people

2015-06-10 Thread Jim Rollenhagen

On Tue, Jun 09, 2015 at 04:33:41PM -0400, Ruby Loo wrote:
 Hi,
 
 I noticed (from reading the logs[1]) that there weren't many folks in this
 week's weekly meeting. And no cores attended. And the sub-team reports (in
 our etherpad[2]) were woefully lacking. I guess that means only driver
 developers are working like mad (just kidding).
 
I'd really like to investigate moving this meeting to a different time.
While it is beneficial for the sake of inclusivity, I tend to see not
many cores attending (if at all), and usually not a ton of discussion.

// jim

 I'm hoping this was a one-off due to a blue moon or a unicorn-sighting;)
 But I did want to take the opportunity to remind the leads of sub-teams --
 you don't have to attend the meeting, but please use this opportunity to
 communicate anything that you feel is useful to communicate to the rest of
 the group. (It is fine if there is nothing to report; no news is good news.)
 
 Recently, someone wondered who our cross-project liaisons were -- you can
 find that via the 'People' section in the main Ironic wiki[3].
 
  --ruby
 
 [1]
 http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-06-09-05.06.log.html
 [2] https://etherpad.openstack.org/p/IronicWhiteBoard
 [3] https://wiki.openstack.org/wiki/Ironic#People

 __
 OpenStack Development Mailing 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] [javascript] Linters