[openstack-dev] [Fuel] Using host networking for docker containers

2014-08-09 Thread Dmitriy Shulyak
Hi team,

I want to discuss benefits of using host networking [1] for docker
containers, on master node.

This feature was added in docker 0.11 and basicly means - reuse host
networking stack, without
creating separate namespace for each container.

In my opinion it will result in much more stable install/upgrade of master
node.

1. There will be no need for dhcrelay/dhcrelay_monitor on host
2. No dnat port forwarding
3. Performance improvement for pxe boot ???

Is there any real benefits of using separate namespaces in security terms?

To implement this we will need:

1. Update docker to recent version 0.12/1.x, we will do it anyway, yes?
2. Run docker containers with --net=host

Ofcourse it will require running containers in privileged mode, but afaik
we are already doing this for other reasons.

So, what do you think?

[1] https://github.com/docker/docker/issues/2012
[2] https://docs.docker.com/articles/networking/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][CI] VMware mine sweeper for Neutron temporarily disabled

2014-08-09 Thread Salvatore Orlando
The root cause for the issue was the fact that our devstack VMs were still
running libvirt 0.9.8 and we missed the commit where libvirt 0.9.11 was
forced as a minimum requirement.

This has been fixed for a while now. However, I made a mistake and as a
result some patches have received a -1 from VMware mine sweeper about half
an hour after the CI system upvoted the same patch. This has been rectified
as well now.

My apologies to all the developers affected.

Salvatore


On 31 July 2014 02:19, Paddu Krishnan (padkrish) padkr...@cisco.com wrote:

  I am still hitting this issue. Are the infrastructure related failures
 white-listed?

  Thanks,
 Paddu

   From: Joe Gordon joe.gord...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Wednesday, July 30, 2014 4:18 PM
 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][CI] VMware mine sweeper for
 Neutron temporarily disabled


 On Jul 29, 2014 12:46 PM, Salvatore Orlando sorla...@nicira.com wrote:
 
  Minesweeper for Neutron is now running again.
  We updated the image for our compute nodes to ensure it is compliant
 with commit [1].

 Does this mean you had libvirt  0.9.11 in minesweeper? I am wondering if
 others will hit the issue (and maybe we revert the minimum) or not.

 
  We are still observing occasional infrastructure-related issues
 manifesting as request timeout failures. We will soon whitelist those
 failures so that mine sweeper won't vote when they're  hit.
 
  Regards,
  Salvatore
 
  [1]
 https://github.com/openstack/nova/commit/842b2abfe76dede55b3b61ebaad5a90c356c5ace
 
 
 
 
  On 28 July 2014 13:07, Salvatore Orlando sorla...@nicira.com wrote:
 
  Hi,
 
  We have been witnessing some issues in our infrastructure which
 resulted in Mine Sweeper test run failures. Unfortunately these failures
 resulted in -1s being put on several patches.
 
  Mine sweeper is now temporarily disabled and our team is already
 working on solving the issue.
  In the meanwhile, you can trigger a recheck with recheck-vmware to
 remove the negative score from your patch.
 
  Salvatore
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] The future of the integrated release

2014-08-09 Thread Eoghan Glynn


  We seem to be unable to address some key issues in the software we
  produce, and part of it is due to strategic contributors (and core
  reviewers) being overwhelmed just trying to stay afloat of what's
  happening. For such projects, is it time for a pause ? Is it time to
  define key cycle goals and defer everything else ?
 
 I think it's quite reasonable for a project to set aside some time to
 focus on stability, whether that is a whole release cycle or just a
 milestone. However, I think your question here is more about
 OpenStack-wide issues, and how we enco^D^D^D^D whether we can require
 integrated projects that are seen as having gate-affecting instability
 to pause and address that.
 
  On the integrated release side, more projects means stretching our
  limited strategic resources more. Is it time for the Technical Committee
  to more aggressively define what is in and what is out ? If we go
  through such a redefinition, shall we push currently-integrated projects
  that fail to match that definition out of the integrated release inner
  circle ?
 
 The integrated release is an overloaded term at the moment. Outside
 of the developer community, I see it often cited as a blessing of a
 project's legitimacy and production-worthiness. While I feel that a
 non-production-ready project should not be in the integrated
 release, this has not been upheld as a litmus test for integration in
 the past. Also, this does not imply that non-integrated projects
 should not be used in production. I've lost track of how many times
 I've heard someone say, Why would I deploy Ironic when it hasn't
 graduated yet.
 
 Integration is foremost an artifact of our testing and development
 processes -- an indication that a project has been following the
 release cadence, adheres to cross-project norms, is ready for
 cogating, and can be counted on to produce timely and stable builds at
 release time. This can plainly be seen by looking at the criteria for
 incubation and integration in our governance repo [1]. As written
 today, this does not have anything to do with the technical merit or
 production-worthiness of a project. It also does not have anything to
 do with what layer the project sits at -- whether it is IaaS, PaaS,
 or SaaS does not dictate whether it can be integrated.
 
 The TC has begun to scrutinize new projects more carefully on
 technical grounds, particularly since some recently-integrated
 projects have run into scaling limitations that have hampered their
 adoption. I believe this sort of technical guidance (or curation, if
 you will) is an essential function of the TC. We've learned that
 integration bestows legitimacy, as well as assumptions of stability,
 performance, and scalability, upon projects which are integrated.
 While that wasn't the intent, I think we need to accept that that is
 where we stand. We will be faced with some hard decisions regarding
 projects, both incubated and already integrated, which are clearly not
 meeting those expectations today.

How does this relate to the recent gap analysis undertaken by the
TC for already integrated projects, in order to measure their status
against the steadily rising bar for integration?

That aforementioned process is actually still ongoing, with the TC
doing progress reviews against the projects' action plans throughout
the Juno cycle.

Cheers,
Eoghan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn

Hi Folks,

Dina Belova has recently landed some infra patches[1,2] to create
an experimental mongodb-based Tempest job. This effectively just
overrides the ceilometer storage backend config so that mongodb
is used instead of sql-alchemy. The new job has been running
happily for a few days so I'd like now to consider the path
forwards with this.

One of our Juno goals under the TC gap analysis was to more fully
gate against mongodb, given that this is the storage backend
recommended/supported by many distros. The sql-alchemy backend,
on the other hand, is more suited for proofs of concept or small
deployments. However up to now we've been hampered from reflecting
that reality in the gate, due to the gate being stuck on Precise
for a long time, as befits LTS, and the version of mongodb needed
by ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu
release (in fact it was limited to 2.0.4).

So the orientation towards gating on sql-alchemy was mostly
driven by legacy issues in the gate's usage of Precise, as
opposed to this being considered the most logical basket in
which to put all our testing eggs.

However, we're now finally in the brave new world of Trusty :)
So I would like to make the long-delayed change over soon.

This would involve transposing the roles of sql-alchemy and
mongodb in the gate - the mongodb variant becomes the blessed
job run by default, whereas the sql-alchemy based job to
relegated to the second tier.

So my questions are:

 (a) would the QA side of the house be agreeable to this switch?

and:

 (b) how long would the mongodb job need to be stable in this
 experimental mode before we pull the trigger on swicthing?

If the answer to (a) is yes, we can get infra patches proposed
early next week to make the swap.

Cheers,
Eoghan

[1] 
https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z
[2] 
https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Boris Pavlovic
Eoghan,

Nice work on this. I think that first of all this job should be run on
every patch for some period of time (not only in experimental pipe)

By the way, If you would like we can help from Rally side.
We are running benchmarks on every patch in it's gates. Ceilometer is fully
turned on in these jobs, so we can be first adopters and switch to mongodb.
This will ensure that everything works stable even under load, and i hope
convince people to switch integrate gate to mongo.


Best regards,
Boris Pavlovic


On Sat, Aug 9, 2014 at 3:19 PM, Eoghan Glynn egl...@redhat.com wrote:


 Hi Folks,

 Dina Belova has recently landed some infra patches[1,2] to create
 an experimental mongodb-based Tempest job. This effectively just
 overrides the ceilometer storage backend config so that mongodb
 is used instead of sql-alchemy. The new job has been running
 happily for a few days so I'd like now to consider the path
 forwards with this.

 One of our Juno goals under the TC gap analysis was to more fully
 gate against mongodb, given that this is the storage backend
 recommended/supported by many distros. The sql-alchemy backend,
 on the other hand, is more suited for proofs of concept or small
 deployments. However up to now we've been hampered from reflecting
 that reality in the gate, due to the gate being stuck on Precise
 for a long time, as befits LTS, and the version of mongodb needed
 by ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu
 release (in fact it was limited to 2.0.4).

 So the orientation towards gating on sql-alchemy was mostly
 driven by legacy issues in the gate's usage of Precise, as
 opposed to this being considered the most logical basket in
 which to put all our testing eggs.

 However, we're now finally in the brave new world of Trusty :)
 So I would like to make the long-delayed change over soon.

 This would involve transposing the roles of sql-alchemy and
 mongodb in the gate - the mongodb variant becomes the blessed
 job run by default, whereas the sql-alchemy based job to
 relegated to the second tier.

 So my questions are:

  (a) would the QA side of the house be agreeable to this switch?

 and:

  (b) how long would the mongodb job need to be stable in this
  experimental mode before we pull the trigger on swicthing?

 If the answer to (a) is yes, we can get infra patches proposed
 early next week to make the swap.

 Cheers,
 Eoghan

 [1]
 https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z
 [2]
 https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Devananda van der Veen
On Aug 9, 2014 4:22 AM, Eoghan Glynn egl...@redhat.com wrote:


 Hi Folks,

 Dina Belova has recently landed some infra patches[1,2] to create
 an experimental mongodb-based Tempest job. This effectively just
 overrides the ceilometer storage backend config so that mongodb
 is used instead of sql-alchemy. The new job has been running
 happily for a few days so I'd like now to consider the path
 forwards with this.

 One of our Juno goals under the TC gap analysis was to more fully
 gate against mongodb, given that this is the storage backend
 recommended/supported by many distros. The sql-alchemy backend,
 on the other hand, is more suited for proofs of concept or small
 deployments. However up to now we've been hampered from reflecting
 that reality in the gate, due to the gate being stuck on Precise
 for a long time, as befits LTS, and the version of mongodb needed
 by ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu
 release (in fact it was limited to 2.0.4).

 So the orientation towards gating on sql-alchemy was mostly
 driven by legacy issues in the gate's usage of Precise, as
 opposed to this being considered the most logical basket in
 which to put all our testing eggs.

 However, we're now finally in the brave new world of Trusty :)
 So I would like to make the long-delayed change over soon.

 This would involve transposing the roles of sql-alchemy and
 mongodb in the gate - the mongodb variant becomes the blessed
 job run by default, whereas the sql-alchemy based job to
 relegated to the second tier.

 So my questions are:

  (a) would the QA side of the house be agreeable to this switch?

 and:

  (b) how long would the mongodb job need to be stable in this
  experimental mode before we pull the trigger on swicthing?

 If the answer to (a) is yes, we can get infra patches proposed
 early next week to make the swap.

 Cheers,
 Eoghan

 [1]
https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z
 [2]
https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z


My interpretation of the gap analysis [1] is merely that you have coverage,
not that you switch to it and relegate the SQLAlchemy tests to second
chair. I believe that's a dangerous departure from current standards. A
dependency on mongodb, due to it's AGPL license, and lack of sufficient
support for a non-AGPL storage back end, has consistently been raised as a
blocking issue for Marconi. [2]

-Deva

[1]
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage

[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html
is a very articulate example of this objection
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn


  Hi Folks,
  
  Dina Belova has recently landed some infra patches[1,2] to create
  an experimental mongodb-based Tempest job. This effectively just
  overrides the ceilometer storage backend config so that mongodb
  is used instead of sql-alchemy. The new job has been running
  happily for a few days so I'd like now to consider the path
  forwards with this.
  
  One of our Juno goals under the TC gap analysis was to more fully
  gate against mongodb, given that this is the storage backend
  recommended/supported by many distros. The sql-alchemy backend,
  on the other hand, is more suited for proofs of concept or small
  deployments. However up to now we've been hampered from reflecting
  that reality in the gate, due to the gate being stuck on Precise
  for a long time, as befits LTS, and the version of mongodb needed
  by ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu
  release (in fact it was limited to 2.0.4).
  
  So the orientation towards gating on sql-alchemy was mostly
  driven by legacy issues in the gate's usage of Precise, as
  opposed to this being considered the most logical basket in
  which to put all our testing eggs.
  
  However, we're now finally in the brave new world of Trusty :)
  So I would like to make the long-delayed change over soon.
  
  This would involve transposing the roles of sql-alchemy and
  mongodb in the gate - the mongodb variant becomes the blessed
  job run by default, whereas the sql-alchemy based job to
  relegated to the second tier.
  
  So my questions are:
  
  (a) would the QA side of the house be agreeable to this switch?
  
  and:
  
  (b) how long would the mongodb job need to be stable in this
  experimental mode before we pull the trigger on swicthing?
  
  If the answer to (a) is yes, we can get infra patches proposed
  early next week to make the swap.
  
  Cheers,
  Eoghan
  
  [1]
  https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z
  [2]
  https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z
  
 
 My interpretation of the gap analysis [1] is merely that you have coverage,
 not that you switch to it and relegate the SQLAlchemy tests to second chair.
 I believe that's a dangerous departure from current standards. A dependency
 on mongodb, due to it's AGPL license, and lack of sufficient support for a
 non-AGPL storage back end, has consistently been raised as a blocking issue
 for Marconi. [2]

Sure, the main goal is to have full mongodb-based coverage in the gate.

So, if the QA/infra folks are prepared to host *both* jobs, then I'd be
happy to change my request to simply:

  let's promote the mongodb-based Tempest variant to the first tier,
  to run alongside the current sqlalchemy-based job 

Does that work for you Devananda?

Cheers,
Eoghan
 
 -Deva
 
 
 [1]
 https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage
 
 [2] http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html
 is a very articulate example of this objection

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn


 Eoghan,
 
 Nice work on this. I think that first of all this job should be run on every
 patch for some period of time (not only in experimental pipe)
 
 By the way, If you would like we can help from Rally side.
 We are running benchmarks on every patch in it's gates. Ceilometer is fully
 turned on in these jobs, so we can be first adopters and switch to mongodb.

Hi Boris,

Excellent, that additional coverage would certainly be helpful.

Though in terms of the performance characteristics reported by
Rally, I'm guessing we wouldn't see much change, given the faster
metering store access would all be happening asynchronously to
the paths measured by Rally, amiright?

Cheers,
Eoghan

 This will ensure that everything works stable even under load, and i hope
 convince people to switch integrate gate to mongo.
 
 
 Best regards,
 Boris Pavlovic
 
 
 On Sat, Aug 9, 2014 at 3:19 PM, Eoghan Glynn  egl...@redhat.com  wrote:
 
 
 
 Hi Folks,
 
 Dina Belova has recently landed some infra patches[1,2] to create
 an experimental mongodb-based Tempest job. This effectively just
 overrides the ceilometer storage backend config so that mongodb
 is used instead of sql-alchemy. The new job has been running
 happily for a few days so I'd like now to consider the path
 forwards with this.
 
 One of our Juno goals under the TC gap analysis was to more fully
 gate against mongodb, given that this is the storage backend
 recommended/supported by many distros. The sql-alchemy backend,
 on the other hand, is more suited for proofs of concept or small
 deployments. However up to now we've been hampered from reflecting
 that reality in the gate, due to the gate being stuck on Precise
 for a long time, as befits LTS, and the version of mongodb needed
 by ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu
 release (in fact it was limited to 2.0.4).
 
 So the orientation towards gating on sql-alchemy was mostly
 driven by legacy issues in the gate's usage of Precise, as
 opposed to this being considered the most logical basket in
 which to put all our testing eggs.
 
 However, we're now finally in the brave new world of Trusty :)
 So I would like to make the long-delayed change over soon.
 
 This would involve transposing the roles of sql-alchemy and
 mongodb in the gate - the mongodb variant becomes the blessed
 job run by default, whereas the sql-alchemy based job to
 relegated to the second tier.
 
 So my questions are:
 
 (a) would the QA side of the house be agreeable to this switch?
 
 and:
 
 (b) how long would the mongodb job need to be stable in this
 experimental mode before we pull the trigger on swicthing?
 
 If the answer to (a) is yes, we can get infra patches proposed
 early next week to make the swap.
 
 Cheers,
 Eoghan
 
 [1]
 https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z
 [2]
 https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Joshua Harlow
+2 from me,

More mongodb adoption (as stated) when it's questionable legally doesn't seem 
like a good long term strategy (I know it will/does impact yahoo adopting or 
using ceilometer...). Is this another one of those tactical changes that we 
keep on making that ends up being yet another piece of technical debt that 
someone will have to cleanup :-/

If we thought a little more about this strategically maybe we would end up in a 
better place short term *and* long term??

Sent from my really tiny device...

On Aug 9, 2014, at 8:59 AM, Devananda van der Veen 
devananda@gmail.commailto:devananda@gmail.com wrote:


On Aug 9, 2014 4:22 AM, Eoghan Glynn 
egl...@redhat.commailto:egl...@redhat.com wrote:


 Hi Folks,

 Dina Belova has recently landed some infra patches[1,2] to create
 an experimental mongodb-based Tempest job. This effectively just
 overrides the ceilometer storage backend config so that mongodb
 is used instead of sql-alchemy. The new job has been running
 happily for a few days so I'd like now to consider the path
 forwards with this.

 One of our Juno goals under the TC gap analysis was to more fully
 gate against mongodb, given that this is the storage backend
 recommended/supported by many distros. The sql-alchemy backend,
 on the other hand, is more suited for proofs of concept or small
 deployments. However up to now we've been hampered from reflecting
 that reality in the gate, due to the gate being stuck on Precise
 for a long time, as befits LTS, and the version of mongodb needed
 by ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu
 release (in fact it was limited to 2.0.4).

 So the orientation towards gating on sql-alchemy was mostly
 driven by legacy issues in the gate's usage of Precise, as
 opposed to this being considered the most logical basket in
 which to put all our testing eggs.

 However, we're now finally in the brave new world of Trusty :)
 So I would like to make the long-delayed change over soon.

 This would involve transposing the roles of sql-alchemy and
 mongodb in the gate - the mongodb variant becomes the blessed
 job run by default, whereas the sql-alchemy based job to
 relegated to the second tier.

 So my questions are:

  (a) would the QA side of the house be agreeable to this switch?

 and:

  (b) how long would the mongodb job need to be stable in this
  experimental mode before we pull the trigger on swicthing?

 If the answer to (a) is yes, we can get infra patches proposed
 early next week to make the swap.

 Cheers,
 Eoghan

 [1] 
 https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z
 [2] 
 https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z


My interpretation of the gap analysis [1] is merely that you have coverage, not 
that you switch to it and relegate the SQLAlchemy tests to second chair. I 
believe that's a dangerous departure from current standards. A dependency on 
mongodb, due to it's AGPL license, and lack of sufficient support for a 
non-AGPL storage back end, has consistently been raised as a blocking issue for 
Marconi. [2]

-Deva

[1] 
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage

[2] http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html 
is a very articulate example of this objection

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn


 +2 from me,
 
 More mongodb adoption (as stated) when it's questionable legally doesn't seem
 like a good long term strategy (I know it will/does impact yahoo adopting or
 using ceilometer...). Is this another one of those tactical changes that we
 keep on making that ends up being yet another piece of technical debt that
 someone will have to cleanup :-/
 
 If we thought a little more about this strategically maybe we would end up in
 a better place short term *and* long term??

Hi Joshua,

Since we currently do support mongodb as an *optional* storage driver,
and some distros do recommend its usage, then surely we should test this
driver fully in the upstream gate to support those users who take that
option?

(i.e. those users who accept MongoDB Inc's assurances[1] in regard to
licensing of the client-side driver)

Cheers,
Eohgan

[1] http://www.mongodb.org/about/licensing/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Joshua Harlow
Agreed, testing options is good; and should likely be disjoint from the legal 
questions around mongodb...

Although if there is really only one viable  scalable option and that option 
has legal usage questions surrounding it then it makes me wonder how much we 
are kidding ourselves on there being anything optional about this... Not 
something I can answer but someone likely should?.?.

I guess it really depends on what the desired outcome of testing with mongodb 
is, if the outcome is to satisfy a TC requirement for improved testing via 
*any* backend then this would seem applicable. If instead it's around testing a 
backend that isn't legally encumbered (and is also realistically viable to use) 
then we are in a different area altogether...

Just my 2cents.

Sent from my really tiny device...

 On Aug 9, 2014, at 10:53 AM, Eoghan Glynn egl...@redhat.com wrote:
 
 
 
 +2 from me,
 
 More mongodb adoption (as stated) when it's questionable legally doesn't seem
 like a good long term strategy (I know it will/does impact yahoo adopting or
 using ceilometer...). Is this another one of those tactical changes that we
 keep on making that ends up being yet another piece of technical debt that
 someone will have to cleanup :-/
 
 If we thought a little more about this strategically maybe we would end up in
 a better place short term *and* long term??
 
 Hi Joshua,
 
 Since we currently do support mongodb as an *optional* storage driver,
 and some distros do recommend its usage, then surely we should test this
 driver fully in the upstream gate to support those users who take that
 option?
 
 (i.e. those users who accept MongoDB Inc's assurances[1] in regard to
 licensing of the client-side driver)
 
 Cheers,
 Eohgan
 
 [1] http://www.mongodb.org/about/licensing/
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] The future of the integrated release

2014-08-09 Thread John Griffith
On Fri, Aug 8, 2014 at 1:31 AM, Nikola Đipanov ndipa...@redhat.com wrote:

 On 08/08/2014 12:12 AM, Stefano Maffulli wrote:
  On 08/07/2014 01:41 PM, Eoghan Glynn wrote:
  My point was simply that we don't have direct control over the
  contributors' activities
 
  This is not correct and I've seen it repeated too often to let it go
  uncorrected: we (the OpenStack project as a whole) have a lot of control
  over contributors to OpenStack. There is a Technical Committee and a
  Board of Directors, corporate members and sponsors... all of these can
  do a lot to make things happen. For example, the Platinum members of the
  Foundation are required at the moment to have at least 'two full time
  equivalents' and I don't see why the board couldn't change that
  requirement, make it more specific.
 

 Even if this were true (I don't know if it is or not), I have a hard
 time imagining that any such attempt would be effective enough to solve
 the current problems.

 I think that OSS software wins in places it does mostly because it *does
 not* get managed like a corporate software project. Trying to fit any
 classical PM methodology on top of a (very active mind you) OSS project
 will likely fail IMHO, due to not only lack of control over contributors
 time, but widely different incentives of participating parties.

​+1

I see this as a step in the wrong direction for sure.  I also don't know
about the slots approach that's being discussed.  Seems a better way to
address some of this is content criteria sort of like what's been
discussed on and off in this thread.  So an LTS model of sorts, like saying
these are the types of changes for this release.​  Maybe that's buried in
some of that proposals here not sure.

We're starting to do some content based rules in Cinder based with respect
to milestones, for example we tried to say hey, if you want to add a new
3'rd party driver for Cinder, you need to do it by the second milestone so
the remainder of the release can be focused on the core.  This didn't work
out as well as we'd hoped but I think we can get better (and there's been
some suggestion of moving it further up like first milestone).  We've also
tried things like cleanup submissions, so things like additions of
hacking rules etc have specific windows.  One of the reasons for this is
just simply to keep from unintentionally forcing everything behind these
changes in the queue to fail and need a rebase.

I don't know that what we've tried so far is really the right approach, but
it was a descent learning experience and I think we can take something away
from it and try a new approach with what we've learned (this will be a
topic for Paris for sure).

Anyway, the slots and runway approach is a bit off putting for me; but I
don't want to form any opinions until I read more about what Michael has to
say based on the Nova meeting.  Also want to make sure I fully understand
the concepts (which I might not currently).

The only thing I would say is that moving further and further to models
that limit slots or whatever might have an unintended consequence of
pushing away new contributors that maybe aren't being driven by their
employer or tactical motivations.  Kinda be a bummer to put up walls like
that I think.  It's pretty hard to submit changes already, we've got a lot
of process and spend a lot of time on consensus building, I'd hate to make
those things to take up even more of our time.  Process is good IMO but it
should be implemented to save time, not require more of it.


 N.

  OpenStack is not an amateurish project done by volunteers in their free
  time.  We have lots of leverage we can apply to get things done.
 
  /stef
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn


 Agreed, testing options is good; and should likely be disjoint from the legal
 questions around mongodb...
 
 Although if there is really only one viable  scalable option and that option
 has legal usage questions surrounding it then it makes me wonder how much we
 are kidding ourselves on there being anything optional about this... Not
 something I can answer but someone likely should?.?.
 
 I guess it really depends on what the desired outcome of testing with mongodb
 is, if the outcome is to satisfy a TC requirement for improved testing via
 *any* backend then this would seem applicable. If instead it's around
 testing a backend that isn't legally encumbered (and is also realistically
 viable to use) then we are in a different area altogether...

Usual IANAL caveats, I just want to ensure that some code that's used in
the wild to also be tested upstream :)

So as stated in response to Devananda, I'm happy for this change to have
more the character of an *expansion* in overall coverage, as opposed to
an *exchange* of one type of coverage for another.

Assuming of course that the QA/infra side of the house are willing to
accommodate that, it would seem to satisfy both requirements?

Not to open another hornet's nest, but note that there is actually a
third opensource option for ceilometer storage, in the form of the
hbase driver (Apache 2.0 being the applicable license for the backend
in this case). In performance testing done by Ilya Tyaptin, this
backend shows same-ballpark performance characteristics to mongodb.

Cheers,
Eoghan
 
 Just my 2cents.
 
 Sent from my really tiny device...
 
  On Aug 9, 2014, at 10:53 AM, Eoghan Glynn egl...@redhat.com wrote:
  
  
  
  +2 from me,
  
  More mongodb adoption (as stated) when it's questionable legally doesn't
  seem
  like a good long term strategy (I know it will/does impact yahoo adopting
  or
  using ceilometer...). Is this another one of those tactical changes that
  we
  keep on making that ends up being yet another piece of technical debt that
  someone will have to cleanup :-/
  
  If we thought a little more about this strategically maybe we would end up
  in
  a better place short term *and* long term??
  
  Hi Joshua,
  
  Since we currently do support mongodb as an *optional* storage driver,
  and some distros do recommend its usage, then surely we should test this
  driver fully in the upstream gate to support those users who take that
  option?
  
  (i.e. those users who accept MongoDB Inc's assurances[1] in regard to
  licensing of the client-side driver)
  
  Cheers,
  Eohgan
  
  [1] http://www.mongodb.org/about/licensing/
  
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] The future of the integrated release

2014-08-09 Thread Jeremy Stanley
On 2014-08-08 09:43:54 -0700 (-0700), Devananda van der Veen wrote:
[...]
 this sounds like it will also solve the current problem when a
 core reviewer has gone on vacation after blocking something for
 procedural reasons.

I don't really think so, unless I'm misunderstanding which vacation
problem you're talking about. We can either make a vote carry over
on subsequent patchsets (in which case you need someone to reverse
or delete the -2 before you can merge it) or not (in which case you
will lose that -2 on the next uploaded patchset and have to keep
reapplying it manually).

Unless perhaps you're suggesting that we should allow approved
changes to merge even with a workflow -2 from another reviewer
(keeping in mind that we don't currently allow changes with a
workflow -1 to merge).
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] The future of the integrated release

2014-08-09 Thread Joshua Harlow
+1 to what john said,

I would also like to wait and see on this... I'd rather be honest with 
ourselves, and to contributors new and old, and admit core reviewers are air 
traffic controllers (directing the project vs reviewing changes, two very 
different things IMHO) and reflecting that in what we say, what we do and how 
the community operates... (the long term effects of such a change may be hard 
to predict IMHO).

But I'll hold more of my opinion until I see more details on this...

Sent from my really tiny device...

On Aug 9, 2014, at 11:41 AM, John Griffith 
john.griff...@solidfire.commailto:john.griff...@solidfire.com wrote:




On Fri, Aug 8, 2014 at 1:31 AM, Nikola Đipanov 
ndipa...@redhat.commailto:ndipa...@redhat.com wrote:
On 08/08/2014 12:12 AM, Stefano Maffulli wrote:
 On 08/07/2014 01:41 PM, Eoghan Glynn wrote:
 My point was simply that we don't have direct control over the
 contributors' activities

 This is not correct and I've seen it repeated too often to let it go
 uncorrected: we (the OpenStack project as a whole) have a lot of control
 over contributors to OpenStack. There is a Technical Committee and a
 Board of Directors, corporate members and sponsors... all of these can
 do a lot to make things happen. For example, the Platinum members of the
 Foundation are required at the moment to have at least 'two full time
 equivalents' and I don't see why the board couldn't change that
 requirement, make it more specific.


Even if this were true (I don't know if it is or not), I have a hard
time imagining that any such attempt would be effective enough to solve
the current problems.

I think that OSS software wins in places it does mostly because it *does
not* get managed like a corporate software project. Trying to fit any
classical PM methodology on top of a (very active mind you) OSS project
will likely fail IMHO, due to not only lack of control over contributors
time, but widely different incentives of participating parties.
​+1

I see this as a step in the wrong direction for sure.  I also don't know about 
the slots approach that's being discussed.  Seems a better way to address 
some of this is content criteria sort of like what's been discussed on and 
off in this thread.  So an LTS model of sorts, like saying these are the types 
of changes for this release.​  Maybe that's buried in some of that proposals 
here not sure.

We're starting to do some content based rules in Cinder based with respect to 
milestones, for example we tried to say hey, if you want to add a new 3'rd 
party driver for Cinder, you need to do it by the second milestone so the 
remainder of the release can be focused on the core.  This didn't work out as 
well as we'd hoped but I think we can get better (and there's been some 
suggestion of moving it further up like first milestone).  We've also tried 
things like cleanup submissions, so things like additions of hacking rules 
etc have specific windows.  One of the reasons for this is just simply to keep 
from unintentionally forcing everything behind these changes in the queue to 
fail and need a rebase.

I don't know that what we've tried so far is really the right approach, but it 
was a descent learning experience and I think we can take something away from 
it and try a new approach with what we've learned (this will be a topic for 
Paris for sure).

Anyway, the slots and runway approach is a bit off putting for me; but I don't 
want to form any opinions until I read more about what Michael has to say based 
on the Nova meeting.  Also want to make sure I fully understand the concepts 
(which I might not currently).

The only thing I would say is that moving further and further to models that 
limit slots or whatever might have an unintended consequence of pushing away 
new contributors that maybe aren't being driven by their employer or tactical 
motivations.  Kinda be a bummer to put up walls like that I think.  It's pretty 
hard to submit changes already, we've got a lot of process and spend a lot of 
time on consensus building, I'd hate to make those things to take up even more 
of our time.  Process is good IMO but it should be implemented to save time, 
not require more of it.


N.

 OpenStack is not an amateurish project done by volunteers in their free
 time.  We have lots of leverage we can apply to get things done.

 /stef

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

2014-08-09 Thread Jeremy Stanley
On 2014-08-08 09:06:29 -0400 (-0400), Russell Bryant wrote:
[...]
 We've seen several times that building and maintaining 3rd party
 CI is a *lot* of work.

Building and maintaining *any* CI is a *lot* of work, not the least
of which is the official OpenStack project CI (I believe Monty
mentioned in #openstack-infra last night that our CI is about twice
the size of Travis-CI now, not sure what metric he's comparing there
though).

 Like you said in [1], doing this in infra's CI would be ideal. I
 think 3rd party should be reserved for when running it in the
 project's infrastructure is not an option for some reason
 (requires proprietary hw or sw, for example).

Add to the not an option for some reason list, software which is
not easily obtainable through typical installation channels (PyPI,
Linux distro-managed package repositories for their LTS/server
releases, et cetera) or which requires gyrations which destabilize
or significantly complicate maintenance of the overall system as
well as reproducibility for developers. It may be possible to work
around some of these concerns via access from multiple locations
coupled with heavy caching, but adding that in for a one-off source
is hard to justify the additional complexity too.

 I wonder if the job could be as simple as one with an added step
 in the config to install latest libvirt from source.  Dan, do you
 think someone could add a libvirt-current.tar.gz to
 http://libvirt.org/sources/ ? Using the latest release seems
 better than master from git.
[...]

Would getting it into EPEL for CentOS 7 or UCA for Ubuntu 14.04 LTS
hopefully be an option?
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

2014-08-09 Thread Jay Pipes
Paul, does this friend of a friend have a reproduceable test script for 
this?


Thanks!
-jay

On 08/08/2014 04:42 PM, Kevin Benton wrote:

If this is true, I think the issue is not on Neutron side but the Nova
side.
Neutron just receives and handles individual port requests. It has no
notion of the order in which they are attached to the VM.

Can you add the Nova tag to get some visibility to the Nova devs?


On Fri, Aug 8, 2014 at 11:32 AM, CARVER, PAUL pc2...@att.com
mailto:pc2...@att.com wrote:

I’m hearing “friend of a friend” that people have looked at the code
and determined that the order of networks on a VM is not guaranteed.
Can anyone confirm whether this is true? If it is true, is there any
reason why this is not considered a bug? I’ve never seen it happen
myself.

__ __

To elaborate, I’m being told that if you create some VMs with
several vNICs on each and you want them to be, for example:

__ __

__1)__Management Network

__2)__Production Network

__3)__Storage Network

__ __

You can’t count on all the VMs having eth0 connected to the
management network, eth1 on the production network, eth2 on the
storage network.

__ __

I’m being told that they will come up like that most of the time,
but sometimes you will see, for example, a VM might wind up with
eth0 connected to the production network, eth1 to the storage
network, and eth2 connected to the storage network (or some other
permutation.)

__ __

__ __


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

2014-08-09 Thread Armando M.
On 9 August 2014 10:16, Jay Pipes jaypi...@gmail.com wrote:

 Paul, does this friend of a friend have a reproduceable test script for
 this?

 Thanks!
 -jay


We would also need to know the OpenStack release where this issue manifest
itself. A number of bugs have been raised in the past around this type of
issue, and the last fix I recall is this one:

https://bugs.launchpad.net/nova/+bug/1300325

It's possible that this might have regressed, though.

Cheers,
Armando
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] tempest bug

2014-08-09 Thread Nikesh Kumar Mahalka
I have reported a bug as tempest volume-type test failed for hp_msa_fc
driver in tempest
project.
Bug Id is Bug #1353850
My Tempest tests are failed on cinder driver.



No one till responded to my bug.
I am new in this area.
Please help me to solve this.



Regards
Nikesh
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] tempest bug

2014-08-09 Thread John Griffith
On Sat, Aug 9, 2014 at 1:58 PM, Nikesh Kumar Mahalka 
nikeshmaha...@vedams.com wrote:

 I have reported a bug as tempest volume-type test failed for hp_msa_fc
 driver in tempest
 project.
 Bug Id is Bug #1353850
 My Tempest tests are failed on cinder driver.



 No one till responded to my bug.
 I am new in this area.
 Please help me to solve this.



 Regards
 Nikesh

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ​Hi Nikesh,

No need to send the note to the dev-list, but if you do you sould probably
ref the bug number [1].

What you're running into isn't actually a bug, I think I pointed you to
this before, but take a look at the Configuring devstack to use your
driver section of the Cinder Wiki here: [2].  You'll need to set the
variables to tell Tempest what Vendor and Protocol settings to use.

Grab myself or somebody else on IRC (#openstack-cinder) and we can help you
get things set up properly.

Thanks,
John

[1]: https://bugs.launchpad.net/tempest/+bug/1353850
[2]: ​https://wiki.openstack.org/wiki/Cinder
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Neutron][LBaaS] Improvements to current reviews

2014-08-09 Thread Brandon Logan
So I've done some work on improving the code on the current pending
reviews.  And would like to get peoples' opinions on whether I should
add antoher patch set to those reviews, or add the changes as as another
review dependent on the pending ones.

To be clear, no matter what the first review in the chain will not
change:
https://review.openstack.org/#/c/105331/

However, if adding another patch set is preferrable then plugin and db
implementation review would get another patch set and then obviously
anything depending on that.

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

My opinion is that I'd like to get both of these in as a new patch set.
Reason being that the reviews don't have any +2's and there is
uncertainty because of the GBP discussion.  So, I don't think it'd be a
major issue if a new patch set was created.  Speak up if you think
otherwise.  I'd like to get as many people's thoughts as possible.

The changes are:

1) Added data models, which are just plain python object mimicking the
sql alchemy models, but don't have the overhead or dynamic nature of
being sql alchemy models.  These data models are now returned by the
database methods, instead of the sql alchemy objects.  Also, I moved the
definition of the sql alchemy models into its own module.  I've been
wanting to do this but since I thought I was running out of time I left
it for later.

These shouldn't cause many merge/rebase conflicts, but it probably cause
a few because the sql alchemy models were moved to a different module.


2) The LoadBalancerPluginv2 no longer inherits from the
LoadBalancerPluginDbv2.  The database is now a composite attribute of
the plugin (i.e. plugin.db.get_loadbalancer()).  This cleans up the code
a bit and removes the necessity for _delete_db_entity methods that the
drivers needed because now they can actually call the database methods.
Also, this makes testing more clear, though I have not added any tests
for this because the previous tests are sufficient for now.  Adding the
appropriate tests would add 1k or 2k lines most likely.

This will likely cause more conflicts because the _db_delete_entity
methods have been removed.  However, the new driver interface/mixins
defined a db_method for all drivers to use, so if that is being used
there shouldn't be any problems.

Thanks,
Brandon




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][LBaaS] Improvements to current reviews

2014-08-09 Thread Doug Wiegley
I think you should update the current reviews (new patch set, not additional 
review.)

Doug


 On Aug 9, 2014, at 3:34 PM, Brandon Logan brandon.lo...@rackspace.com 
 wrote:
 
 So I've done some work on improving the code on the current pending
 reviews.  And would like to get peoples' opinions on whether I should
 add antoher patch set to those reviews, or add the changes as as another
 review dependent on the pending ones.
 
 To be clear, no matter what the first review in the chain will not
 change:
 https://review.openstack.org/#/c/105331/
 
 However, if adding another patch set is preferrable then plugin and db
 implementation review would get another patch set and then obviously
 anything depending on that.
 
 https://review.openstack.org/#/c/105609/
 
 My opinion is that I'd like to get both of these in as a new patch set.
 Reason being that the reviews don't have any +2's and there is
 uncertainty because of the GBP discussion.  So, I don't think it'd be a
 major issue if a new patch set was created.  Speak up if you think
 otherwise.  I'd like to get as many people's thoughts as possible.
 
 The changes are:
 
 1) Added data models, which are just plain python object mimicking the
 sql alchemy models, but don't have the overhead or dynamic nature of
 being sql alchemy models.  These data models are now returned by the
 database methods, instead of the sql alchemy objects.  Also, I moved the
 definition of the sql alchemy models into its own module.  I've been
 wanting to do this but since I thought I was running out of time I left
 it for later.
 
 These shouldn't cause many merge/rebase conflicts, but it probably cause
 a few because the sql alchemy models were moved to a different module.
 
 
 2) The LoadBalancerPluginv2 no longer inherits from the
 LoadBalancerPluginDbv2.  The database is now a composite attribute of
 the plugin (i.e. plugin.db.get_loadbalancer()).  This cleans up the code
 a bit and removes the necessity for _delete_db_entity methods that the
 drivers needed because now they can actually call the database methods.
 Also, this makes testing more clear, though I have not added any tests
 for this because the previous tests are sufficient for now.  Adding the
 appropriate tests would add 1k or 2k lines most likely.
 
 This will likely cause more conflicts because the _db_delete_entity
 methods have been removed.  However, the new driver interface/mixins
 defined a db_method for all drivers to use, so if that is being used
 there shouldn't be any problems.
 
 Thanks,
 Brandon
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

2014-08-09 Thread shihanzhang
Hi Paul, as I know, nova can guarante the ordering of vNICS, can you provide 
the reproduceable test script for this, I am glad to test it








At 2014-08-10 01:16:16, Jay Pipes jaypi...@gmail.com wrote:
Paul, does this friend of a friend have a reproduceable test script for 
this?

Thanks!
-jay

On 08/08/2014 04:42 PM, Kevin Benton wrote:
 If this is true, I think the issue is not on Neutron side but the Nova
 side.
 Neutron just receives and handles individual port requests. It has no
 notion of the order in which they are attached to the VM.

 Can you add the Nova tag to get some visibility to the Nova devs?


 On Fri, Aug 8, 2014 at 11:32 AM, CARVER, PAUL pc2...@att.com
 mailto:pc2...@att.com wrote:

 I’m hearing “friend of a friend” that people have looked at the code
 and determined that the order of networks on a VM is not guaranteed.
 Can anyone confirm whether this is true? If it is true, is there any
 reason why this is not considered a bug? I’ve never seen it happen
 myself.

 __ __

 To elaborate, I’m being told that if you create some VMs with
 several vNICs on each and you want them to be, for example:

 __ __

 __1)__Management Network

 __2)__Production Network

 __3)__Storage Network

 __ __

 You can’t count on all the VMs having eth0 connected to the
 management network, eth1 on the production network, eth2 on the
 storage network.

 __ __

 I’m being told that they will come up like that most of the time,
 but sometimes you will see, for example, a VM might wind up with
 eth0 connected to the production network, eth1 to the storage
 network, and eth2 connected to the storage network (or some other
 permutation.)

 __ __

 __ __


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev