Re: [openstack-dev] [glance] Replication on image create

[Flavio Percoco]

On 14/01/15 05:46 -0700, Boden Russell wrote:



On 1/14/15 1:38 AM, Flavio Percoco wrote:

On 13/01/15 21:24 -0500, Jay Pipes wrote:

On 01/13/2015 04:55 PM, Boden Russell wrote:

Looking for some feedback from the glance dev team on a potential BP…


This is the solution that I would recommend. Frankly, this kind of
replication should be an async out-of-band process similar to
bittorrent. Just have bittorrent or rsync or whatever replicate the
image bits to a set of target locations and then call the
glanceclient.v2.client.images.add_location() method:

https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L211


to add the URI of the replicated image bits.


It recently landed in Glance an async workers engine (?) that allows
for this kind of things to exists. For instance, it'll be used for
image introspection to extract information from images after they have
been *imported* into glance.

The right hooks that trigger this async workers maybe need to be
defined better but the infrastructure is there. Once that's more
solid, you'll be able to write your own plugin that will do that job
on every glance image import.



While I understand the motivation for suggesting the "out of band"
approach (async workers or separate process), my major concern here is
the additional processing required. In my particular scenario this would
require the out of band process to pull the image bits back down from
the remote location and then push them back up to the replication
locations. If the image size is decent, this could be a fairly expensive
operation. Moreover an out of band process (IMO) would make for a less
than optimal user experience as users would have to query the image
locations metadata to understand if the image has replicated yet.
Perhaps async workers improves this user experience a bit (can query
worker status), but it still seems cleaner (IMO) to have the replication
happen in-line with the image create flow.


That's one valid point of view, yes. However, you could also see it
this way. While should a user wait for the image to be available in
the three locations before he/she can use the image? The point of
replicating it - afaict based on what you said - is to have it
redundant and accessible from locations that are closer to some users.
If you make this part of the image creation process, you'd need to
wait until the images are fully replicated before you can actually use
it (which is not nice for users). If you instead use async workers,
you can make the image available as soon as one of the locations is
ready to serve the image.

As far as the transfering bits problem goes, the best way to avoid it
is to upload the bits offline (assuming you're using stores like http,
which doesn't have support for internal replication) and then add
locations to an image. This way, you'd have to upload the image bits N
times, where N is the number of replicast you want, instead of N+1
times, which includes the upload to one if the glance nodes.

I'm not saying the above is the ultimate solution and that glance
won't ever support this. However, it's worht noting that such
solutions are not considered bad practice whatsoever.

All that being said, it'd be very nice if you could open a spec on
this topic so we can discuss over the spec review and one of us (or
you) can implement it if we reach consensus.

Cheers,
Flavio





In a prototype I implemented #1 which can be done with no impact outside
of the store driver code itself.


I'm not entirely sure how you did that considering the http storage
backend is readonly. Are you saying you implemented the add() method
for the glance_store._drivers.http.Store class?


I was trying to generalize my use case to other glance store drivers,
but my generalization using the http store driver was obviously a poor
choice... My interest and PoC is based on the VMware datastore driver.


Let me ask more directly -- if we wanted to enhance the VMware datastore
driver to support replication (as I described in approach #1 of my
initial email) is this something the community would consider (assume
changes are contained to the VMware datastore driver), or would such an
enhancement be an uphill battle to get reviewed / merged?


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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [horizon] static files handling, bower/

[Tihomir Trifonov]

All we need is to have someone spend some time to make it possible to have
a common meta files(configs, package descriptions, etc.) so that they can
be interchangeable and used by both Bower and pip, e.g. some tool to sync
changes made in one config and adding it to another. Then - whoever prefers
Bower - will use Bower, that's mostly for development, and whoever prefers
pip - will use pip. Ideally, it seems fine to have the static files into
separate git repo(s), as it is now in XStatic.

I'll try to make an (incomplete or maybe not so correct) list of the stages
a static file goes through:

1. Development - all we need is versions of uncompressed js and css files.
We can

On Thu, Jan 15, 2015 at 12:05 AM,  wrote:

> I won't stop to comment on this statement other than to say Javascript is
>> quite relevant to Oracle, Oracle's customers, and Oracle's partners.
>>
>> Your argument is a boondoggle. Refusing to use node because your favorite
>> platform doesn't support it is not the fault of node.js, it's the fault of
>> the platform.
>>
>
> Not to belabor the thread, but yes, of course JavaScript is very
> relevant to Oracle, Solaris, our customers/partners, etc. And that
> includes both client and server-side. As Drew stated, as of this moment
> we haven't yet made Node.js available on SPARC but I expect that to
> change in the future. But the question or potential concern remains as
> to whether adding a non-Python/pip build dependency makes sense.
>
> I'm not particularly well-versed in the Horizon build process so
> perhaps I'm way off base. But given that a distribution's Horizon build
> package embeds various JavaScript libraries to be used by the browser,
> how those libraries are obtained during the build process is an
> interesting build detail. I thought the intent of the XStatic work was
> to provide Python wrappers around the various JavaScript libraries so
> they could be pulled down via pip. Since there's already a Python
> requirements.txt file for versioning information, that seemed to be a
> nice way of indicating which versions of the JavaScript libraries could
> be used by Horizon and Python was used all the way through the build.
>
> I realize that it takes work to build the XStatic packages but given
> the Python packages are basically wrappers, it seems creating those and
> uploading them to pypi could be automated by using Bower and setup.py
> but perhaps translating the metadata isn't straightforward.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [horizon] static files handling, bower/

[Tihomir Trifonov]

Ops, sent the prev mail before finishing it...

1. Development - all we need is versions of uncompressed js and css files.
We can use bower or pip requirements to get specific versions.
2. Testing - we need to do first some 'uglify'-ing tasks, using pyscss or
grunt and to run tests on that. Is is possible to have both configurations
for grunt and pyscss ?
3. Packaging - again - 'uglifyng' some scripts and css to make packages
contain ready for production static files.


This seems like quite work to prepare the whole environment, but will it
work for the needs we have?


On Thu, Jan 15, 2015 at 10:12 AM, Tihomir Trifonov 
wrote:

> All we need is to have someone spend some time to make it possible to have
> a common meta files(configs, package descriptions, etc.) so that they can
> be interchangeable and used by both Bower and pip, e.g. some tool to sync
> changes made in one config and adding it to another. Then - whoever prefers
> Bower - will use Bower, that's mostly for development, and whoever prefers
> pip - will use pip. Ideally, it seems fine to have the static files into
> separate git repo(s), as it is now in XStatic.
>
> I'll try to make an (incomplete or maybe not so correct) list of the
> stages a static file goes through:
>
> 1. Development - all we need is versions of uncompressed js and css files.
> We can
>
> On Thu, Jan 15, 2015 at 12:05 AM,  wrote:
>
>> I won't stop to comment on this statement other than to say Javascript is
>>> quite relevant to Oracle, Oracle's customers, and Oracle's partners.
>>>
>>> Your argument is a boondoggle. Refusing to use node because your favorite
>>> platform doesn't support it is not the fault of node.js, it's the fault
>>> of
>>> the platform.
>>>
>>
>> Not to belabor the thread, but yes, of course JavaScript is very
>> relevant to Oracle, Solaris, our customers/partners, etc. And that
>> includes both client and server-side. As Drew stated, as of this moment
>> we haven't yet made Node.js available on SPARC but I expect that to
>> change in the future. But the question or potential concern remains as
>> to whether adding a non-Python/pip build dependency makes sense.
>>
>> I'm not particularly well-versed in the Horizon build process so
>> perhaps I'm way off base. But given that a distribution's Horizon build
>> package embeds various JavaScript libraries to be used by the browser,
>> how those libraries are obtained during the build process is an
>> interesting build detail. I thought the intent of the XStatic work was
>> to provide Python wrappers around the various JavaScript libraries so
>> they could be pulled down via pip. Since there's already a Python
>> requirements.txt file for versioning information, that seemed to be a
>> nice way of indicating which versions of the JavaScript libraries could
>> be used by Horizon and Python was used all the way through the build.
>>
>> I realize that it takes work to build the XStatic packages but given
>> the Python packages are basically wrappers, it seems creating those and
>> uploading them to pypi could be automated by using Bower and setup.py
>> but perhaps translating the metadata isn't straightforward.
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Tihomir Trifonov
>



-- 
Regards,
Tihomir Trifonov
__
OpenStack Development Mailing 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][Horizon] User self registration and management

[David Chadwick]

Hi Adrian

Morgan is right in saying that an external IdP would solve many of your
user management problems, but then of course, you will be using
federated keystone  which you seem reluctant to do :-) However, if you
have an IdP under your full control then you can allow users to self
register and reset their passwords.

The next problem you will then face, is user authorisation - as opposed
to user authentication. The VO roles blueprint that we have worked on
addresses the authorisation problem. So when you are ready for this, let
me know

regards

David

On 15/01/2015 00:42, Morgan Fainberg wrote:
>>
>> On Jan 13, 2015, at 9:06 PM, Adrian Turjak  wrote:
>>
>> Hello openstack-dev,
>>
>> I'm wondering if there is any interest or need for an open-source user
>> registration and management service for people using OpenStack.
>>
>> We're currently at a point where we need a way for users to sign up
>> themselves, choose their own password, and request new users to be added
>> to their project. There doesn't seem to be anything out there, and most
>> vendors seem to have built their own systems to handle this or even
>> their own dashboard systems that do.
>>
>> Horizon is built around the client tools, and your own personal token,
>> so it can't handle creating new users. Plus Keystone doesn't really have
>> any good way of handling temporary (unapproved) users and projects.
>>
>> The suggested approach seems to be to build a service to sit along
>> Keystone, have it's own admin creds so it can create new users, and also
>> store temp user data locally until the user is approved.
>>
>> Unless we can find a suitable solution for us quickly, we're likely to
>> be developing such a service. It would ideally have a pluggable approval
>> workflow, allowing new user requests, new project requests, creation of
>> clients in external client database/ERP systems. Plus it would have a
>> password reset-token system for having new users supply their password
>> once they are approved, which would also allow existing users to request
>> password resets.
>>
>> Part of our requirements are easy to integrate into Horizon, fitting
>> neatly into the OpenStack ecosystem along other services, and being easy
>> to update/alter once we have hierarchical multi-tenancy and if it makes
>> some things easier.
>>
>> I've written up a proposal to help us define our requirements, and a
>> copy of that is attached, and on etherpad:
>> https://etherpad.openstack.org/p/User_Management_Service
>>
>> Plus I've attached a couple of diagrams, which are sadly not UML, but
>> should give you some idea of two of the primary use cases.
>>
>> Is this useful to anyone? Is this entirely the wrong approach? If it is
>> a useful service is there any interest in collaboration?
>>
>> Thanks for any feedback.
>>
>> Cheers,
>> -Adrian Turjak
> 
> I have an alternative recommendation (rather than using Keystone’s API and 
> user-management). Keystone’s user management is lacking a lot of features a 
> full fledged IDP (identity provider) would have. “Password reset”, “password 
> complexity”, “password reuse”, failed login locking, etc. I would recommend 
> that you implement this service to write to a full featured IDP (LDAP, 
> FreeIPA, Active Directory, etc) and have Keystone hook into that more-full 
> featured IDP. You might even find that the IDP selected has a lot of these 
> features built-in (and/or could be fronted in a horizon panel).
> 
> This recommendation comes from past experience implementing almost exactly 
> this feature (and having it go through a number of incarnations). The 
> benefits of using a full-fledged IDP outweigh the ease of using the Keystone 
> API to manage users, especially since there is non-trivial engineering that 
> will go into the project.
> 
> You could also utilize an IDP that can issue SAML assertions and go with a 
> Federated Identity setup for Keystone. Again your tool could work with an IDP 
> that has a better set of features that Keystone’s current build-in identity 
> (user/group) store does.
> 
> Cheers,
> Morgan
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing 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][gate][stable] How eventlet 0.16.1 broke the gate

[Joe Gordon]

Eventlet released 0.16.1 on 2015-01-14 [0], which removed a deprecated API
that nova stable/* still used. This caused nova-compute in stable/juno and
stable/icehouse to crash thus breaking grenade on master. In 24 hours this
bug caused 671 grenade jobs to fail[1]!

After some quick debugging of this cryptic error suppressing stacktrace [2]
we got to the real stacktrace:
" File "nova/virt/libvirt/__init__.py", line 15, in 

from nova.virt.libvirt import driver
  File "nova/virt/libvirt/driver.py", line 48, in 
from eventlet import util as eventlet_util

ImportError: cannot import name util" [3]
and capped the eventlet version on stable/* [4]

As dependency bugs go this was a pretty typical one, so why am I writing
this? Because we knew about this bug before it hit the gate, yet it was
still an issue. The util module was removed in 0.16.0 but 'sneaked into'
the build [5] so 0.16.1 fixed that. Before 0.16.1 was released this bug
only impacted people who installed eventlet 0.16.0 from source and not from
pip. Luckily someone did this and filed a bug [6] and a fix for this was
landed on master on January 7th, and by the 10th the fix was backported to
stable/juno and ready [7].  In the mean time, we had an unusually bad week
dealing with new library versions; boto 2.35.0 was released and broke
master and stable/juno [8] and sqlalchemy-migrate broke glance on master
and stable as well [9].  And by the time these issues were fixed, and the
tests would pass, eventlet 0.16.1 was already out. Unfortunately, there are
a very small number of people who work on fixing dependency issues, some of
them were traveling and the rest were over worked, so figuring out what
went wrong with all the new packages came down to a handful of overworked
people.

So how could we have avoided this problem? By capping stable branch
requirements so we only have to worry about uncapped dependencies on
master. Capping stable branches has been previous discussed but no action
has been taken. So going forward I propose we pin all requirements,
including transitive, on stable branches. This way the release of new
dependencies cannot automatically break stable branches and thus break
grenade on master.

I think we can implement this using `pip freeze` to get a list of all the
installed libraries and `pip install -r --no-deps` to install the specific
package versions.  I am not sure how best to handle package versions being
removed from pypi though. Or at the very least we can cap requirements in
global requirements and at least reduce the number of packages we install
uncapped versions of.

Thoughts?

best,
Joe

[0] https://pypi.python.org/pypi/eventlet/0.16.1
[1] http://status.openstack.org/elastic-recheck/#1410626
[2]
http://logs.openstack.org/98/115998/59/check/check-grenade-dsvm/e57eb40/logs/old/screen-n-cpu.txt.gz
[3] http://paste.openstack.org/show/157558/
[4]
https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z
[5] https://github.com/eventlet/eventlet/releases/tag/v0.16.1
[6] https://bugs.launchpad.net/nova/+bug/1407685
[7]
https://review.openstack.org/#/q/Idbb9d2b53829dae0e807cd1260dee3dce155d5f3,n,z
[8] https://bugs.launchpad.net/nova/+bug/1408987
[9] https://bugs.launchpad.net/glance/+bug/1410494
__
OpenStack Development Mailing 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][gate][stable] How eventlet 0.16.1 broke the gate

[ZhiQiang Fan]

+1

how about the deep dependency? for example, we depends package A, and pin
it, but A->B->C, then B and C are not pined since they are not directly
depended, then what should we do? pin everything?

On Thu, Jan 15, 2015 at 5:35 PM, Joe Gordon  wrote:

> Eventlet released 0.16.1 on 2015-01-14 [0], which removed a deprecated
> API that nova stable/* still used. This caused nova-compute in stable/juno
> and stable/icehouse to crash thus breaking grenade on master. In 24 hours
> this bug caused 671 grenade jobs to fail[1]!
>
> After some quick debugging of this cryptic error suppressing stacktrace
> [2] we got to the real stacktrace:
> " File "nova/virt/libvirt/__init__.py", line 15, in 
>
> from nova.virt.libvirt import driver
>   File "nova/virt/libvirt/driver.py", line 48, in 
> from eventlet import util as eventlet_util
>
> ImportError: cannot import name util" [3]
> and capped the eventlet version on stable/* [4]
>
> As dependency bugs go this was a pretty typical one, so why am I writing
> this? Because we knew about this bug before it hit the gate, yet it was
> still an issue. The util module was removed in 0.16.0 but 'sneaked into'
> the build [5] so 0.16.1 fixed that. Before 0.16.1 was released this bug
> only impacted people who installed eventlet 0.16.0 from source and not from
> pip. Luckily someone did this and filed a bug [6] and a fix for this was
> landed on master on January 7th, and by the 10th the fix was backported to
> stable/juno and ready [7].  In the mean time, we had an unusually bad week
> dealing with new library versions; boto 2.35.0 was released and broke
> master and stable/juno [8] and sqlalchemy-migrate broke glance on master
> and stable as well [9].  And by the time these issues were fixed, and the
> tests would pass, eventlet 0.16.1 was already out. Unfortunately, there are
> a very small number of people who work on fixing dependency issues, some of
> them were traveling and the rest were over worked, so figuring out what
> went wrong with all the new packages came down to a handful of overworked
> people.
>
> So how could we have avoided this problem? By capping stable branch
> requirements so we only have to worry about uncapped dependencies on
> master. Capping stable branches has been previous discussed but no action
> has been taken. So going forward I propose we pin all requirements,
> including transitive, on stable branches. This way the release of new
> dependencies cannot automatically break stable branches and thus break
> grenade on master.
>
> I think we can implement this using `pip freeze` to get a list of all the
> installed libraries and `pip install -r --no-deps` to install the specific
> package versions.  I am not sure how best to handle package versions being
> removed from pypi though. Or at the very least we can cap requirements in
> global requirements and at least reduce the number of packages we install
> uncapped versions of.
>
> Thoughts?
>
> best,
> Joe
>
> [0] https://pypi.python.org/pypi/eventlet/0.16.1
> [1] http://status.openstack.org/elastic-recheck/#1410626
> [2]
> http://logs.openstack.org/98/115998/59/check/check-grenade-dsvm/e57eb40/logs/old/screen-n-cpu.txt.gz
> [3] http://paste.openstack.org/show/157558/
> [4]
> https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z
> [5] https://github.com/eventlet/eventlet/releases/tag/v0.16.1
> [6] https://bugs.launchpad.net/nova/+bug/1407685
> [7]
> https://review.openstack.org/#/q/Idbb9d2b53829dae0e807cd1260dee3dce155d5f3,n,z
> [8] https://bugs.launchpad.net/nova/+bug/1408987
> [9] https://bugs.launchpad.net/glance/+bug/1410494
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
__
OpenStack Development Mailing 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][gate][stable] How eventlet 0.16.1 broke the gate

[Matthew Gilliard]

> capping stable branch requirements so we only have to worry about uncapped 
> dependencies on master

+1 this is a sensible idea not just from the POV of grenade testing,
but general stability of the stable releases.  As per Joe's link [5]
we can see 3rd party libraries may make breaking changes in minor
releases, so we should pin to the exact version (ie ==X.Y.Z, rather
than saying we'll allow increases in the Z for bugfixes).

> how about the deep dependency?

We should pin transitive dependencies too. If we don't then we're open
to new 3rd party releases breaking things just as before.

  mg

On Thu, Jan 15, 2015 at 9:51 AM, ZhiQiang Fan  wrote:
> +1
>
> how about the deep dependency? for example, we depends package A, and pin
> it, but A->B->C, then B and C are not pined since they are not directly
> depended, then what should we do? pin everything?
>
> On Thu, Jan 15, 2015 at 5:35 PM, Joe Gordon  wrote:
>>
>> Eventlet released 0.16.1 on 2015-01-14 [0], which removed a deprecated API
>> that nova stable/* still used. This caused nova-compute in stable/juno and
>> stable/icehouse to crash thus breaking grenade on master. In 24 hours this
>> bug caused 671 grenade jobs to fail[1]!
>>
>> After some quick debugging of this cryptic error suppressing stacktrace
>> [2] we got to the real stacktrace:
>> " File "nova/virt/libvirt/__init__.py", line 15, in 
>>
>> from nova.virt.libvirt import driver
>>   File "nova/virt/libvirt/driver.py", line 48, in 
>> from eventlet import util as eventlet_util
>>
>> ImportError: cannot import name util" [3]
>> and capped the eventlet version on stable/* [4]
>>
>> As dependency bugs go this was a pretty typical one, so why am I writing
>> this? Because we knew about this bug before it hit the gate, yet it was
>> still an issue. The util module was removed in 0.16.0 but 'sneaked into' the
>> build [5] so 0.16.1 fixed that. Before 0.16.1 was released this bug only
>> impacted people who installed eventlet 0.16.0 from source and not from pip.
>> Luckily someone did this and filed a bug [6] and a fix for this was landed
>> on master on January 7th, and by the 10th the fix was backported to
>> stable/juno and ready [7].  In the mean time, we had an unusually bad week
>> dealing with new library versions; boto 2.35.0 was released and broke master
>> and stable/juno [8] and sqlalchemy-migrate broke glance on master and stable
>> as well [9].  And by the time these issues were fixed, and the tests would
>> pass, eventlet 0.16.1 was already out. Unfortunately, there are a very small
>> number of people who work on fixing dependency issues, some of them were
>> traveling and the rest were over worked, so figuring out what went wrong
>> with all the new packages came down to a handful of overworked people.
>>
>> So how could we have avoided this problem? By capping stable branch
>> requirements so we only have to worry about uncapped dependencies on master.
>> Capping stable branches has been previous discussed but no action has been
>> taken. So going forward I propose we pin all requirements, including
>> transitive, on stable branches. This way the release of new dependencies
>> cannot automatically break stable branches and thus break grenade on master.
>>
>> I think we can implement this using `pip freeze` to get a list of all the
>> installed libraries and `pip install -r --no-deps` to install the specific
>> package versions.  I am not sure how best to handle package versions being
>> removed from pypi though. Or at the very least we can cap requirements in
>> global requirements and at least reduce the number of packages we install
>> uncapped versions of.
>>
>> Thoughts?
>>
>> best,
>> Joe
>>
>> [0] https://pypi.python.org/pypi/eventlet/0.16.1
>> [1] http://status.openstack.org/elastic-recheck/#1410626
>> [2]
>> http://logs.openstack.org/98/115998/59/check/check-grenade-dsvm/e57eb40/logs/old/screen-n-cpu.txt.gz
>> [3] http://paste.openstack.org/show/157558/
>> [4]
>> https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z
>> [5] https://github.com/eventlet/eventlet/releases/tag/v0.16.1
>> [6] https://bugs.launchpad.net/nova/+bug/1407685
>> [7]
>> https://review.openstack.org/#/q/Idbb9d2b53829dae0e807cd1260dee3dce155d5f3,n,z
>> [8] https://bugs.launchpad.net/nova/+bug/1408987
>> [9] https://bugs.launchpad.net/glance/+bug/1410494
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> blog: zqfan.github.com
> git: github.com/zqfan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/o

[openstack-dev] [Fuel]When will fuel support centos 7?

[me,apporc]

Hi,

Do we have plan for centos 7 ?



Regards,

apporc
__
OpenStack Development Mailing 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][gate][stable] How eventlet 0.16.1 broke the gate

[Nikola Đipanov]

On 01/15/2015 10:35 AM, Joe Gordon wrote:

> So how could we have avoided this problem? By capping stable branch
> requirements so we only have to worry about uncapped dependencies on
> master. Capping stable branches has been previous discussed but no
> action has been taken. So going forward I propose we pin all
> requirements, including transitive, on stable branches. This way the
> release of new dependencies cannot automatically break stable branches
> and thus break grenade on master.
> 

This is an absolute must IMHO, including transitive dependencies,
because if they are not capped - they can cause other issues like bring
in additional deps a stable release is not even supposed to have, among
all the usual issues.

The problem as I understand it is that this breaks how we do upgrades
testing in the gate, AKA "the granade job" (all in a single VM, install
everything from pip). IMHO this is broken and needs to be fixed ASAP, if
capping breaks it.

N.


__
OpenStack Development Mailing 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] Concerns about Gnocchi's performance

[张灿]

Hello,

I’m testing gnocchi to work with ceilometer these days and I have some concerns 
about its performance.

I noticed in the code, every time a measure gets updated, gnocchi first reads 
all the previous contents of that measure, updates the measure in memory and 
writes the updated contents as well as original contents back. IMHO, the 
overhead here could be very large. As an improvement, I propose we use some 
form of `seek` that only modifies the updated parts.

So I’d like to hear about your opinions, and if there’s already a solution, 
please point it to me.



Regards,
Can Zhang


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

Re: [openstack-dev] Concerns about Gnocchi's performance

[Julien Danjou]

On Thu, Jan 15 2015, 张灿 wrote:

Hi,

> I noticed in the code, every time a measure gets updated, gnocchi first reads
> all the previous contents of that measure, updates the measure in memory and
> writes the updated contents as well as original contents back. IMHO, the
> overhead here could be very large. As an improvement, I propose we use some
> form of `seek` that only modifies the updated parts.

Yep, that's the main downside of the use of the Carbonara based backend
in Gnocchi. But honestly, since it's download/upload are parallel and
the file size is quite small, sending a metric should be pretty fast in
most circumstances. Though that's sure it's gonna be faster with
backends where you just have to send the actual metrics (OpenTSDB or
InfluxDB likely).

> So I’d like to hear about your opinions, and if there’s already a
> solution, please point it to me.

I'd love to improve the backends you describe with some sort of `seek'
solution, unfortunately I don't think it'll be possible to do so using
Swift. Though it might be possible to do so using Ceph and the file
based backends, so maybe it'd be worth looking at that. Any help
appreciated!

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


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

Re: [openstack-dev] [Fuel] Empty role - status

[Andrey Danin]

Answers inline.

On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L  wrote:

> Hi,
>
> Empty role is ready [1], thanks to granular deployment feature
> I didn't have to hardcode some hacks in Astute again.
>
> But there are several things which I want to mention/discuss:
>
> 1. in the patch you can see the name of the role and its description
> I would like to ask you to verify it and provide some other options if
> you
> have any
> 2. we have a minor problem with the progress bar, we will figure out how
> to fix it in Astute with Vladimir S.
> 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific
> and it
> doesn't allow us to make efficient partitioning schema, e.g. it means
> that we
> cannot allocate root partition for all of the disks (provisioning will
> fail), the
> current workaround is to allocate root partition with minimal size
> (about 15G) and leave the rest of the space as is (unallocated). As
> far as I can see from the bug it's not so easy to fix the problem,
> actually
> image based provisioning fixes the problem, but it's not an option for
> the
> current release. Maybe you have some other ideas how to fix this
> problem?
>
> I would leave it as is - 15 GB. A user or plugin can adjust it for its
needs.


> Thanks,
>
> [1] https://review.openstack.org/#/c/147230/
> [2] https://bugs.launchpad.net/fuel/+bug/1278964
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Andrey Danin
ada...@mirantis.com
skype: gcon.monolake
__
OpenStack Development Mailing 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] MagnetoDB kilo-1 milestone release

[Ilya Sviridov]

Hello openstackers,

MagnetoDB team is happy to announce the release of kilo-1 milestone [1]

This milestone we focused on operability and monitoring aspects of
MagnetoDB.

* Backup/Restore API has been introduced
* Monitoring API has been introduced and implemented for Cassandra
* The API URI format has been changed to split logically different
functionality and simplify deployment
* Updated documentation [2]

The bunch of bags have been fixed [1].

Thanks everyone for making it possible!

With best regards,
Ilya Sviridov

[1] https://launchpad.net/magnetodb/kilo/kilo-1
[2] https://magnetodb.readthedocs.org/en/2015.1.0b1/






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

Re: [openstack-dev] [horizon] static files handling, bower/

[Radomir Dopieralski]

On 14/01/15 23:05, david.co...@oracle.com wrote:
> I'm not particularly well-versed in the Horizon build process so
> perhaps I'm way off base. But given that a distribution's Horizon build
> package embeds various JavaScript libraries to be used by the browser,
> how those libraries are obtained during the build process is an
> interesting build detail. I thought the intent of the XStatic work was
> to provide Python wrappers around the various JavaScript libraries so
> they could be pulled down via pip. Since there's already a Python
> requirements.txt file for versioning information, that seemed to be a
> nice way of indicating which versions of the JavaScript libraries could
> be used by Horizon and Python was used all the way through the build.
> 
> I realize that it takes work to build the XStatic packages but given
> the Python packages are basically wrappers, it seems creating those and
> uploading them to pypi could be automated by using Bower and setup.py
> but perhaps translating the metadata isn't straightforward.

This has actually been discussed. The problem is, that it adds
considerable complexity and some amount of work, while solves exactly
zero problems. You are just sweeping the node.js dependency under the
rug, because now, instead of being a direct dependency (for development)
of Horizon, it becomes a dependency (for building) of a package that
Horizon is dependent on. That doesn't solve anything, since all
distributions insist on building their own packages from sources, not
relying on pre-built binaries.

So what we settled on is a compromise. Horizon will not care *how* the
static files got there. Whether you put them there by hand, use Bower,
or install your distribution's packages -- Horizon doesn't care. And
neither do the tests written for Horizon, or the build scripts. They
just assume the files are where you configured them. Period. Let me
repeat that:

***You will not need Node.js or Bower to build and test Horizon.***

The packagers for different distributions will want to make packages for
the JavaScript and CSS libraries on their own anyways, and they will
want to test Horizon with those -- not with what Bower installs.

The only place where you will need Bower (but only for convenience, as
you may as well install everything manually or with your own scripts) is
the development machine. For convenience, we will keep the list of
dependencies in a format compatible with Bower -- but it's a simple JSON
file that can be read by any other tool or script, written in any language.

I hope that clears it.

-- 
Radomir Dopieralski

__
OpenStack Development Mailing 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] Concerns about Gnocchi's performance

[张灿]

> On Jan 15, 2015, at 18:46, Julien Danjou  wrote:
> 
> Yep, that's the main downside of the use of the Carbonara based backend
> in Gnocchi. But honestly, since it's download/upload are parallel and
> the file size is quite small, sending a metric should be pretty fast in
> most circumstances. Though that's sure it's gonna be faster with
> backends where you just have to send the actual metrics (OpenTSDB or
> InfluxDB likely).
> 

As a further question, how do you estimate the storage impact of a vm 
instance’s metrics? I’m not very sure about the `back_window` and `definition` 
part, could you clarify that for me?




Regards,
Can Zhang


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

Re: [openstack-dev] [Fuel]When will fuel support centos 7?

[Igor Kalnitsky]

Hi,

Yes, we do have a plan for CentOS 7, but as far as I know it was
postponed to MOS 7.0. That means we will not have Cent OS 7 in
upcoming release.

- Igor

On Thu, Jan 15, 2015 at 1:16 PM, me,apporc  wrote:
> Hi,
>
> Do we have plan for centos 7 ?
>
>
>
> Regards,
>
> apporc
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Fuel]When will fuel support centos 7?

[Mike Scherbakov]

CentOS 7 is not considered as essential / critical priority blueprint for
Fuel 6.1. There is a plan to support new version of CentOS, and I know some
folks started a research/move in this direction in some areas, such as
l23network puppet module for instance.

It would be great to see help to make it happen in Fuel 7.0, if not in 6.1.

On Thu, Jan 15, 2015 at 3:22 PM, Igor Kalnitsky 
wrote:

> Hi,
>
> Yes, we do have a plan for CentOS 7, but as far as I know it was
> postponed to MOS 7.0. That means we will not have Cent OS 7 in
> upcoming release.
>
> - Igor
>
> On Thu, Jan 15, 2015 at 1:16 PM, me,apporc 
> wrote:
> > Hi,
> >
> > Do we have plan for centos 7 ?
> >
> >
> >
> > Regards,
> >
> > apporc
> >
> >
> >
> __
> > OpenStack Development Mailing 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
>



-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing 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 Havana installation using devstack

[abhishek jain]

I'm also facing the same trouble.
On Jan 15, 2015 12:05 PM, "masoom alam"  wrote:

> No
>
> I want Havana purposefully.
>
> Thanks
>
> On Thu, Jan 15, 2015 at 10:45 AM, iKhan  wrote:
>
>> Go with stable/icehouse then.
>>
>> On Thu Jan 15 2015 at 11:13:37 AM masoom alam 
>> wrote:
>>
>>> Hi every one,
>>>
>>> How can I install Openstack Havana using devstack.
>>>
>>> The problem is that Havana branch does not exist on Github.
>>>
>>> git clone https://github.com/openstack-dev/devstack.git -b stable/havana
>>>
>>> Please guide.
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing 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
>>
>>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] Openstack Havana installation using devstack

[Sean Dague]

The stable/havana branch of devstack was deleted when the stable/havana
branches of the projects were end of lifed.

Even if you could reconstruct it, it wouldn't work, because various
dependencies would have upgraded to incompatible versions.

stable/icehouse is the oldest version of OpenStack that devstack supports.

On 01/15/2015 07:36 AM, abhishek jain wrote:
> I'm also facing the same trouble.
> 
> On Jan 15, 2015 12:05 PM, "masoom alam"  > wrote:
> 
> No 
> 
> I want Havana purposefully. 
> 
> Thanks
> 
> On Thu, Jan 15, 2015 at 10:45 AM, iKhan  > wrote:
> 
> Go with stable/icehouse then.
> 
> On Thu Jan 15 2015 at 11:13:37 AM masoom alam
> mailto:masoom.a...@gmail.com>> wrote:
> 
> Hi every one, 
> 
> How can I install Openstack Havana using devstack. 
> 
> The problem is that Havana branch does not exist on Github. 
> 
> git clone https://github.com/openstack-dev/devstack.git -b
> stable/havana
> 
> Please guide. 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request@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
> 
> 
> 
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> 
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Openstack] Openstack Havana installation using devstack

[Denis Makogon]

On Thu, Jan 15, 2015 at 2:36 PM, abhishek jain 
wrote:

> I'm also facing the same trouble.
> On Jan 15, 2015 12:05 PM, "masoom alam"  wrote:
>
>> No
>>
>> I want Havana purposefully.
>>
>> Thanks
>>
>> On Thu, Jan 15, 2015 at 10:45 AM, iKhan  wrote:
>>
>>> Go with stable/icehouse then.
>>>
>>> On Thu Jan 15 2015 at 11:13:37 AM masoom alam 
>>> wrote:
>>>
 Hi every one,

 How can I install Openstack Havana using devstack.

 The problem is that Havana branch does not exist on Github.

 git clone https://github.com/openstack-dev/devstack.git -b
 stable/havana

 Please guide.



Github is not what you might relay on. Feel free to use git.o.o



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

Kind regards,
Denis M.
__
OpenStack Development Mailing 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][gate][stable] How eventlet 0.16.1 broke the gate

[Sean Dague]

On 01/15/2015 05:21 AM, Nikola Đipanov wrote:
> On 01/15/2015 10:35 AM, Joe Gordon wrote:
> 
>> So how could we have avoided this problem? By capping stable branch
>> requirements so we only have to worry about uncapped dependencies on
>> master. Capping stable branches has been previous discussed but no
>> action has been taken. So going forward I propose we pin all
>> requirements, including transitive, on stable branches. This way the
>> release of new dependencies cannot automatically break stable branches
>> and thus break grenade on master.
>>
> 
> This is an absolute must IMHO, including transitive dependencies,
> because if they are not capped - they can cause other issues like bring
> in additional deps a stable release is not even supposed to have, among
> all the usual issues.
> 
> The problem as I understand it is that this breaks how we do upgrades
> testing in the gate, AKA "the granade job" (all in a single VM, install
> everything from pip). IMHO this is broken and needs to be fixed ASAP, if
> capping breaks it.

That's a mis understanding of the last issue, grenade handles this fine.

The capping only caused a problem because we were upgrading components
in an incorrect issue: Swift upgrading before Ceilometer, even though
Ceilometer had middleware installed in Swift. Which meant that for
almost ever we were actually running new Swift with old Ceilometer
middleware.

That was fixed here - https://review.openstack.org/#/c/142075/

The policy decision to cap stable requirements was agreed to previously
(and at summit this year), it just needs someone to implement. This also
came up in this keystoneclient thread from last week -
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html

Volunteers welcomed.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Openstack] Openstack Havana installation using devstack

[Tim Gao]

Hi

You can find the latest havana commit here:
http://git.openstack.org/cgit/openstack/nova/tag/?id=havana-eol

2015-01-15 20:44 GMT+08:00 Denis Makogon :

>
>
> On Thu, Jan 15, 2015 at 2:36 PM, abhishek jain 
> wrote:
>
>> I'm also facing the same trouble.
>> On Jan 15, 2015 12:05 PM, "masoom alam"  wrote:
>>
>>> No
>>>
>>> I want Havana purposefully.
>>>
>>> Thanks
>>>
>>> On Thu, Jan 15, 2015 at 10:45 AM, iKhan  wrote:
>>>
 Go with stable/icehouse then.

 On Thu Jan 15 2015 at 11:13:37 AM masoom alam 
 wrote:

> Hi every one,
>
> How can I install Openstack Havana using devstack.
>
> The problem is that Havana branch does not exist on Github.
>
> git clone https://github.com/openstack-dev/devstack.git -b
> stable/havana
>
> Please guide.
>
>
>
> Github is not what you might relay on. Feel free to use git.o.o
> 
>
>
>>
> 
> __
> OpenStack Development Mailing 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


>>>
>>> ___
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openst...@lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> Kind regards,
> Denis M.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Tim Gao
__
OpenStack Development Mailing 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 Havana installation using devstack

[Ihar Hrachyshka]

On 01/15/2015 01:42 PM, Sean Dague wrote:

The stable/havana branch of devstack was deleted when the stable/havana
branches of the projects were end of lifed.


That said, tag is still there: 
http://git.openstack.org/cgit/openstack-dev/devstack/tag/?id=havana-eol


__
OpenStack Development Mailing 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-Infra] [ThirdPartyCI] Need help setting up CI

[Eduard Matei]

Hi Ramy,

The issue with disconnect/abort no longer happens, so i guess it was some
issues with networking.

Regarding the ssh keys i finally used Jenkins Configuration Provider Plugin
to inject ssh keys as a pre-build step, then i added a manual execution
step to scp the logs to the server, so now everything appears to be working.

Now for the REAL tests:
looking at
https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
it seems i need to put the code to install my "third party libs" in the
pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
BEFORE installing devstack. The problem is we need our "third party libs"
to be installed (actually configured) AFTER installing devstack, since they
install on top of devstack and do some configuration on devstack.

How could i integrate my code into devstack-vm-gate-wrap.sh so that my libs
are installed after devstack but before running tempest.
Also, as a side question, do i need to run all the test (since they already
run in dsvm-tempest-full) or can i run only our internal functionality
tests? (in this case i don't need devstack-vm-gate-wrap.sh and i can run
custom code directly from jenkins job).

Thanks,

Eduard

On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy  wrote:

>  Double check your ssh public/private key, authorized keys configuration
> in the slave & log server.
>
> They should all match up. No passwords should be requested.
>
> Try doing a manual scp as Jenkins user from the slave to the log server
> (as Jenkins user there too).
>
>
>
> Regarding manually setting up the publisher, I don’t know. Jenkins Job
> Builder configuration I referenced below should work correctly.
>
>
>
> Ramy
>
>
>
> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
> *Sent:* Wednesday, January 14, 2015 6:56 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
> setting up CI
>
>
>
> Hi Ramy,
>
>
>
> I think i managed to setup SCP plugin and updated zuul.conf but it only
> uploads the console.html not the logs
>
> I have an SCP site pointing to the apache server and the root location is
> /srv/static, and in the dsvm job manually added a post-build step, Publish
> Artifacts to SCP Repository, with source: logs/** and destination
> logs/${LOG_PATH} and also checked Copy Console Log.
>
>
>
> The destination path is created, but it only contains console.html.
>
>
>
> I tried to manually scp the directory, but the jenkins user in the
> devstack_slave asks for a password when trying to ssh to apache server.
>
>
>
> Thanks,
>
> Eduard
>
>
>
> On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei <
> eduard.ma...@cloudfounders.com> wrote:
>
>  Thanks Ramy, i'll try to set it up manually.
>
>
>
> Meanwhile i found another problem: jobs are failing because of error or
> are being aborted.
>
> FATAL: java.io.IOException: Unexpected termination of the channel
>
> hudson.remoting.RequestAbortedException 
> :
>  java.io.IOException: Unexpected termination of the channel
>
>
>
> Is this related to another warning i got:
>
> WARNING: devstack run took > 15 minutes, this is a very slow node.
>
>
>
> Is there a timeout for how long a job is allowed to run?
>
> Most jobs take between 40 and 60 minutes, some are able to run successfully, 
> some are aborted or get this error.
>
>
>
> Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.
>
> Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB 
> vHDD).
>
>
>
> Thanks,
>
> Eduard
>
>
>
> On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy 
> wrote:
>
>  Hi Eduard,
>
>
>
> Apache logs server address is set here (should probably add some
> comment/doc for that)
>
>
> https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10
>
>
>
> Jenkins will get configured here:
> https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb
>
> Note that you need to restart Jenkins for those changes to take effect.
> After it’s set, you can use the Jenkins UI to ‘test’ the connection.
>
>
>
> Jenkins Job Builder publishers are here:
> https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L110
>
>
>
> Use the publishers as shown here:
>
>
> https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
>
>
>
> Zuul will then use this url when commenting in gerrit:
> https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/manifests/master.pp#L18
>
>
>
>
>
> Ramy
>
>
>
> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
> *Sent:* Tuesday, January 13, 2015 2:31 AM
>
>
> 

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

[Eduard Matei]

Hi,
Just so i don't start another thread: it seems that sometimes Zuul gets
stuck (sometimes in Looking for lost builds, sometimes doing nothing) and
it misses notifications.
I added a Jenkins timer job to restart it every 30 minutes. Is there a fix
for this or something to change in config?

Thanks,
Eduard

On Thu, Jan 15, 2015 at 2:56 PM, Eduard Matei <
eduard.ma...@cloudfounders.com> wrote:

> Hi Ramy,
>
> The issue with disconnect/abort no longer happens, so i guess it was some
> issues with networking.
>
> Regarding the ssh keys i finally used Jenkins Configuration Provider
> Plugin to inject ssh keys as a pre-build step, then i added a manual
> execution step to scp the logs to the server, so now everything appears to
> be working.
>
> Now for the REAL tests:
> looking at
> https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
> it seems i need to put the code to install my "third party libs" in the
> pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
> BEFORE installing devstack. The problem is we need our "third party libs"
> to be installed (actually configured) AFTER installing devstack, since they
> install on top of devstack and do some configuration on devstack.
>
> How could i integrate my code into devstack-vm-gate-wrap.sh so that my
> libs are installed after devstack but before running tempest.
> Also, as a side question, do i need to run all the test (since they
> already run in dsvm-tempest-full) or can i run only our internal
> functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh
> and i can run custom code directly from jenkins job).
>
> Thanks,
>
> Eduard
>
> On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy 
> wrote:
>
>>  Double check your ssh public/private key, authorized keys configuration
>> in the slave & log server.
>>
>> They should all match up. No passwords should be requested.
>>
>> Try doing a manual scp as Jenkins user from the slave to the log server
>> (as Jenkins user there too).
>>
>>
>>
>> Regarding manually setting up the publisher, I don’t know. Jenkins Job
>> Builder configuration I referenced below should work correctly.
>>
>>
>>
>> Ramy
>>
>>
>>
>> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
>> *Sent:* Wednesday, January 14, 2015 6:56 AM
>>
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
>> help setting up CI
>>
>>
>>
>> Hi Ramy,
>>
>>
>>
>> I think i managed to setup SCP plugin and updated zuul.conf but it only
>> uploads the console.html not the logs
>>
>> I have an SCP site pointing to the apache server and the root location is
>> /srv/static, and in the dsvm job manually added a post-build step, Publish
>> Artifacts to SCP Repository, with source: logs/** and destination
>> logs/${LOG_PATH} and also checked Copy Console Log.
>>
>>
>>
>> The destination path is created, but it only contains console.html.
>>
>>
>>
>> I tried to manually scp the directory, but the jenkins user in the
>> devstack_slave asks for a password when trying to ssh to apache server.
>>
>>
>>
>> Thanks,
>>
>> Eduard
>>
>>
>>
>> On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei <
>> eduard.ma...@cloudfounders.com> wrote:
>>
>>  Thanks Ramy, i'll try to set it up manually.
>>
>>
>>
>> Meanwhile i found another problem: jobs are failing because of error or
>> are being aborted.
>>
>> FATAL: java.io.IOException: Unexpected termination of the channel
>>
>> hudson.remoting.RequestAbortedException 
>> :
>>  java.io.IOException: Unexpected termination of the channel
>>
>>
>>
>> Is this related to another warning i got:
>>
>> WARNING: devstack run took > 15 minutes, this is a very slow node.
>>
>>
>>
>> Is there a timeout for how long a job is allowed to run?
>>
>> Most jobs take between 40 and 60 minutes, some are able to run successfully, 
>> some are aborted or get this error.
>>
>>
>>
>> Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.
>>
>> Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB 
>> vHDD).
>>
>>
>>
>> Thanks,
>>
>> Eduard
>>
>>
>>
>> On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy 
>> wrote:
>>
>>  Hi Eduard,
>>
>>
>>
>> Apache logs server address is set here (should probably add some
>> comment/doc for that)
>>
>>
>> https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10
>>
>>
>>
>> Jenkins will get configured here:
>> https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb
>>
>> Note that you need to restart Jenkins for those changes to take effect.
>> After it’s set, you can use the Jenkins UI to ‘test’ the connection.
>>
>>
>>
>> Jenkins Job Builder publishers are here:
>> https://github.com/rasselin/os-ext-te

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

[Amit Das]

Hi Eduard,

Can you put the logs or details for below comment:

it seems that sometimes Zuul gets stuck (sometimes in Looking for lost
> builds, sometimes doing nothing) and it misses notifications.


I guess, we too have been facing the same issue with Zuul.


Regards,
Amit
*CloudByte Inc.* 

On Thu, Jan 15, 2015 at 6:29 PM, Eduard Matei <
eduard.ma...@cloudfounders.com> wrote:

> Hi,
> Just so i don't start another thread: it seems that sometimes Zuul gets
> stuck (sometimes in Looking for lost builds, sometimes doing nothing) and
> it misses notifications.
> I added a Jenkins timer job to restart it every 30 minutes. Is there a fix
> for this or something to change in config?
>
> Thanks,
> Eduard
>
> On Thu, Jan 15, 2015 at 2:56 PM, Eduard Matei <
> eduard.ma...@cloudfounders.com> wrote:
>
>> Hi Ramy,
>>
>> The issue with disconnect/abort no longer happens, so i guess it was some
>> issues with networking.
>>
>> Regarding the ssh keys i finally used Jenkins Configuration Provider
>> Plugin to inject ssh keys as a pre-build step, then i added a manual
>> execution step to scp the logs to the server, so now everything appears to
>> be working.
>>
>> Now for the REAL tests:
>> looking at
>> https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
>> it seems i need to put the code to install my "third party libs" in the
>> pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
>> BEFORE installing devstack. The problem is we need our "third party libs"
>> to be installed (actually configured) AFTER installing devstack, since they
>> install on top of devstack and do some configuration on devstack.
>>
>> How could i integrate my code into devstack-vm-gate-wrap.sh so that my
>> libs are installed after devstack but before running tempest.
>> Also, as a side question, do i need to run all the test (since they
>> already run in dsvm-tempest-full) or can i run only our internal
>> functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh
>> and i can run custom code directly from jenkins job).
>>
>> Thanks,
>>
>> Eduard
>>
>> On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy 
>> wrote:
>>
>>>  Double check your ssh public/private key, authorized keys
>>> configuration in the slave & log server.
>>>
>>> They should all match up. No passwords should be requested.
>>>
>>> Try doing a manual scp as Jenkins user from the slave to the log server
>>> (as Jenkins user there too).
>>>
>>>
>>>
>>> Regarding manually setting up the publisher, I don’t know. Jenkins Job
>>> Builder configuration I referenced below should work correctly.
>>>
>>>
>>>
>>> Ramy
>>>
>>>
>>>
>>> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
>>> *Sent:* Wednesday, January 14, 2015 6:56 AM
>>>
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
>>> help setting up CI
>>>
>>>
>>>
>>> Hi Ramy,
>>>
>>>
>>>
>>> I think i managed to setup SCP plugin and updated zuul.conf but it only
>>> uploads the console.html not the logs
>>>
>>> I have an SCP site pointing to the apache server and the root location
>>> is /srv/static, and in the dsvm job manually added a post-build step,
>>> Publish Artifacts to SCP Repository, with source: logs/** and destination
>>> logs/${LOG_PATH} and also checked Copy Console Log.
>>>
>>>
>>>
>>> The destination path is created, but it only contains console.html.
>>>
>>>
>>>
>>> I tried to manually scp the directory, but the jenkins user in the
>>> devstack_slave asks for a password when trying to ssh to apache server.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Eduard
>>>
>>>
>>>
>>> On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei <
>>> eduard.ma...@cloudfounders.com> wrote:
>>>
>>>  Thanks Ramy, i'll try to set it up manually.
>>>
>>>
>>>
>>> Meanwhile i found another problem: jobs are failing because of error or
>>> are being aborted.
>>>
>>> FATAL: java.io.IOException: Unexpected termination of the channel
>>>
>>> hudson.remoting.RequestAbortedException 
>>> :
>>>  java.io.IOException: Unexpected termination of the channel
>>>
>>>
>>>
>>> Is this related to another warning i got:
>>>
>>> WARNING: devstack run took > 15 minutes, this is a very slow node.
>>>
>>>
>>>
>>> Is there a timeout for how long a job is allowed to run?
>>>
>>> Most jobs take between 40 and 60 minutes, some are able to run 
>>> successfully, some are aborted or get this error.
>>>
>>>
>>>
>>> Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.
>>>
>>> Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB 
>>> vHDD).
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Eduard
>>>
>>>
>>>
>>> On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy 
>>> wrote:
>>>
>>>  Hi Eduard,
>>>
>>>
>>>
>>> Apache logs server address is set here (should probably 

Re: [openstack-dev] Concerns about Gnocchi's performance

[Julien Danjou]

On Thu, Jan 15 2015, 张灿 wrote:

> As a further question, how do you estimate the storage impact of a vm
> instance’s metrics? I’m not very sure about the `back_window` and `definition`
> part, could you clarify that for me?

That defines the number of measure (data points) that are stored for
each metric. The size of an actual metric depends on these parameters.
So depending on the granularity and the number of points, the size of a
metric can go from a few kilobytes to a few megabytes.

-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


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

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Thierry Carrez]

Sean Dague wrote:
> The policy decision to cap stable requirements was agreed to previously
> (and at summit this year), it just needs someone to implement.

+1

We started to implement it (in Oslo libraries iirc) and then reverted
because we encountered problems. We concluded a proper cross-project
spec should be written so that we can try to anticipate issues better.

I don't have a totally clear view of the issue(s) we encoutered last
time, though. Could someone write a postmortem or point me to one ? Or
was the upgrading components issue (fixed in
https://review.openstack.org/#/c/142075/) the only problem ?

-- 
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] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Sean Dague]

On 01/15/2015 08:38 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> The policy decision to cap stable requirements was agreed to previously
>> (and at summit this year), it just needs someone to implement.
> 
> +1
> 
> We started to implement it (in Oslo libraries iirc) and then reverted
> because we encountered problems. We concluded a proper cross-project
> spec should be written so that we can try to anticipate issues better.
> 
> I don't have a totally clear view of the issue(s) we encoutered last
> time, though. Could someone write a postmortem or point me to one ? Or
> was the upgrading components issue (fixed in
> https://review.openstack.org/#/c/142075/) the only problem ?

My recollection is the component upgrade order was a big problem, but
not the only one.

The other thing that happened was partial capping doesn't work, because
something else moves forward and breaks you from below. So the patch
will need to hit everything at once.

Unresolved entirely is the tertiary dependencies (not direct
dependencies of any OpenStack project). That will need another mechanism
to seed them before any installation happens.

Whether or not pip should be pinned is also a good question, especially
because pbr requires pip, so the install -U on pbr tends to uplift pip
even if it was previously downgraded.

That's the things I can think off from the top of my head.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

[Eduard Matei]

Hi Amit,
This is the only logging i see:
2015-01-15 14:48:28,034 DEBUG zuul.Gerrit: Change  status: NEW
2015-01-15 14:48:28,035 INFO zuul.Gerrit: Updating information for 146460,5
2015-01-15 14:51:07,851 DEBUG zuul.Gearman: Looking for lost builds
2015-01-15 14:56:07,852 DEBUG zuul.Gearman: Looking for lost builds
2015-01-15 15:01:00,627 DEBUG zuul.Scheduler: Prepare to exit
2015-01-15 15:01:00,627 DEBUG zuul.Scheduler: Waiting for exit
2015-01-15 15:01:00,627 DEBUG zuul.Scheduler: Run handler awake
2015-01-15 15:01:00,627 DEBUG zuul.Scheduler: Checking if all builds are
complete
2015-01-15 15:01:00,628 DEBUG zuul.Scheduler: All builds are complete
2015-01-15 15:01:00,628 DEBUG zuul.Scheduler: Exiting


At 15.01 it was restarted by jenkins and between 14:48 and 15:01 there was
a job that finished but Gerrit didn't post the results.

Eduard

On Thu, Jan 15, 2015 at 3:06 PM, Amit Das  wrote:

> Hi Eduard,
>
> Can you put the logs or details for below comment:
>
> it seems that sometimes Zuul gets stuck (sometimes in Looking for lost
>> builds, sometimes doing nothing) and it misses notifications.
>
>
> I guess, we too have been facing the same issue with Zuul.
>
>
> Regards,
> Amit
> *CloudByte Inc.* 
>
> On Thu, Jan 15, 2015 at 6:29 PM, Eduard Matei <
> eduard.ma...@cloudfounders.com> wrote:
>
>> Hi,
>> Just so i don't start another thread: it seems that sometimes Zuul gets
>> stuck (sometimes in Looking for lost builds, sometimes doing nothing) and
>> it misses notifications.
>> I added a Jenkins timer job to restart it every 30 minutes. Is there a
>> fix for this or something to change in config?
>>
>> Thanks,
>> Eduard
>>
>> On Thu, Jan 15, 2015 at 2:56 PM, Eduard Matei <
>> eduard.ma...@cloudfounders.com> wrote:
>>
>>> Hi Ramy,
>>>
>>> The issue with disconnect/abort no longer happens, so i guess it was
>>> some issues with networking.
>>>
>>> Regarding the ssh keys i finally used Jenkins Configuration Provider
>>> Plugin to inject ssh keys as a pre-build step, then i added a manual
>>> execution step to scp the logs to the server, so now everything appears to
>>> be working.
>>>
>>> Now for the REAL tests:
>>> looking at
>>> https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
>>> it seems i need to put the code to install my "third party libs" in the
>>> pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
>>> BEFORE installing devstack. The problem is we need our "third party libs"
>>> to be installed (actually configured) AFTER installing devstack, since they
>>> install on top of devstack and do some configuration on devstack.
>>>
>>> How could i integrate my code into devstack-vm-gate-wrap.sh so that my
>>> libs are installed after devstack but before running tempest.
>>> Also, as a side question, do i need to run all the test (since they
>>> already run in dsvm-tempest-full) or can i run only our internal
>>> functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh
>>> and i can run custom code directly from jenkins job).
>>>
>>> Thanks,
>>>
>>> Eduard
>>>
>>> On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy 
>>> wrote:
>>>
  Double check your ssh public/private key, authorized keys
 configuration in the slave & log server.

 They should all match up. No passwords should be requested.

 Try doing a manual scp as Jenkins user from the slave to the log server
 (as Jenkins user there too).



 Regarding manually setting up the publisher, I don’t know. Jenkins Job
 Builder configuration I referenced below should work correctly.



 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Wednesday, January 14, 2015 6:56 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
 help setting up CI



 Hi Ramy,



 I think i managed to setup SCP plugin and updated zuul.conf but it only
 uploads the console.html not the logs

 I have an SCP site pointing to the apache server and the root location
 is /srv/static, and in the dsvm job manually added a post-build step,
 Publish Artifacts to SCP Repository, with source: logs/** and destination
 logs/${LOG_PATH} and also checked Copy Console Log.



 The destination path is created, but it only contains console.html.



 I tried to manually scp the directory, but the jenkins user in the
 devstack_slave asks for a password when trying to ssh to apache server.



 Thanks,

 Eduard



 On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei <
 eduard.ma...@cloudfounders.com> wrote:

  Thanks Ramy, i'll try to set it up manually.



 Meanwhile i found another problem: jobs are failing beca

Re: [openstack-dev] [API] Upgrading to API WG Recommendations

[michael mccune]

On 01/14/2015 08:40 PM, Ian Cordasco wrote:

The point was brought up that some recommendations that the working group
forms will be jarring for APIs to implement when going from vN.* to vN+1.0
for both developers and consumers. Client libraries often provide
compatibility (or upgrade-path) versions to help bridge the gap between
going from vN.* to vN+1.0. As a group, we’re looking for feedback from the
developers on the following topics:

- Does this seem preferable?


i think it's a really nice idea to have some sort of guidelines to 
assist with the development of compatibility version. i know i would use 
it =)



- Does it sound reasonable and maintainable?


good question, my fear would be that we would start strong but fade once 
more than a few versions were published. having a clear procedure for 
updating and maintaining the guidelines might help.



- Does it seem reasonable as a way of improving user experience and
upgradability?


for me, yes.


If you have a positive feeling for this idea, there are a couple
follow-ups:

- Should the API WG recommend a strategy for this versioning path?
- If so, should the versioning path work like:

   - vN.M -> vN.99 -> vN+1.0
 We would use .99 to indicate that you it’s compatible with vN.* but
also provides information/endpoints in vN+1)
   - or vN.M -> vN+1.0 -> vN+2.0
 In this case we would make N+1 be the compatibility version (perhaps
do not allow increments of the minor version) and N+2 would be the version
of the API that is fully in-compliance with the Working Group’s final
recommendations.


this is an interesting idea. i think it would be nice if we could 
develop something that would be a clear indication to developers exactly 
which version and capabilities an api is presenting.


of those two options, i'm leaning more towards the vN.99 approach.

thanks for bringing it up Ian!

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] [nova] Networks are not cleaned up in build failure

[Brian Haley]

On 01/14/2015 02:15 PM, Andrew Laski wrote:
> 
> On 01/14/2015 12:57 PM, Murray, Paul (HP Cloud) wrote:
>>
>> Hi All, 
>>
>> I recently experienced failures getting images from Glance while spawning
>> instances. This step comes after building the networks in the guild sequence.
>> When the Glance failure occurred the instance was cleaned up and rescheduled
>> as expected, but the networks were not cleaned up. On investigation I found
>> that the cleanup code for the networks is in the compute manager’s
>> _/do_build_run/_instance() method as follows:
>>
>> # NOTE(comstud): Deallocate networks if the driver wants
>> # us to do so.
>> if self.driver.deallocate_networks_on_reschedule(instance):
>> self._cleanup_allocated_networks(context, instance,
>> requested_networks)
>>
>> The default behavior in for the deallocate_networks_on_schedule() method
>> defined in ComputeDriver is:
>>
>> def deallocate_networks_on_reschedule(self, instance):
>> """Does the driver want networks deallocated on reschedule?"""
>> return False
>>
>> Only the Ironic driver over rides this method to return True, so I think this
>> means the networks will not be cleaned up for any other virt driver.
>>
>>  
>>
>> Is this really the desired behavior?
>>
> 
> Yes.  Other than when using Ironic there is nothing specific to a particular
> host in the networking setup.  This means it is not necessary to deallocate 
> and
> reallocate networks when an instance is rescheduled, so we can avoid the
> unnecessary work of doing it.

That's either not true any more, or not true when DVR is enabled in Neutron,
since in this case the port['binding:host_id'] value has been initialized to a
compute node, and won't get updated when nova-conductor re-schedules the VM
elsewhere.

This causes the neutron port to stay on the original compute node, and any
neutron operations (like floatingip-associate) happen on the "old" port, leaving
the VM unreachable.

> If the instance goes to ERROR then the network will get cleaned up when the
> instance is deleted.

I think we need to clean-up even in this case now too.

-Brian

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

[openstack-dev] [gantt] Scheduler hangout for today

[Don Dugger]

This is the hangout to talk about Gantt issues today.

- Forwarded message from Google+  -

Date: Thu, 15 Jan 2015 06:43:50 -0800 (PST)
From: Google+ 
To: n0...@n0ano.com
Subject: Don Dugger is inviting you to join his hangout

Join Don's hangout

Hangouts are a great new way to video chat on Google+.
- Video chat with up to 9 people
- Watch YouTube videos together


Join Google+ now to hang out with Don.

Join Google+: 
https://plus.google.com/_/notifications/emlink?emr=15764514854518710435&emid=CIjpk5OelsMCFSHEQgodBSQAWA&path=%2Fup%2F%3Fgpinv%3DAMIXal8mlqUxWdfR68cy0FCPOmDMthaOg2P8TwzAh8SiB7k64gUqAPcvPvN8PwJ-tK09p7v4d0p9KosmdP6fjdVCju646GE-2qH2u0l5M1o28JqWklHa2Dc%26gpsrc%3Dhonen%26skww%3D1%26rtsl%3D1%26continue%3Dhttps%253A%252F%252Fplus.google.com%252Fhangouts%252F_%252Fgrbckm5vx7sj5gihbhhmnbiclea%253Fhcb%253D1%2526hii%253D103683676109584436432%2526hit%253D1421332981848%2526hs%253D87%2526hio%253D116378663745799369569&dt=1421333030577&uob=13

Couldn't connect with Don? Start a hangout with him now:
https://plus.google.com/_/notifications/emlink?emr=15764514854518710435&emid=CIjpk5OelsMCFSHEQgodBSQAWA&path=%2Fup%2F%3Fgpinv%3DAMIXal8mlqUxWdfR68cy0FCPOmDMthaOg2P8TwzAh8SiB7k64gUqAPcvPvN8PwJ-tK09p7v4d0p9KosmdP6fjdVCju646GE-2qH2u0l5M1o28JqWklHa2Dc%26gpsrc%3Dhonen%26skww%3D1%26rtsl%3D1%26continue%3Dhttps%253A%252F%252Fplus.google.com%252F_%252Fnotifications%252Femlink%253Femr%253D15764514854518710435%2526emid%253DCIjpk5OelsMCFSHEQgodBSQAWA%2526path%253D%25252Fhangouts%2526dt%253D1421333030577%2526uob%253D13&dt=1421333030577&uob=13

Or download the Google+ mobile app to make sure you never miss another
hangout:
http://www.google.com/intl/en/+/learnmore/mobile/



Learn more about Google+: http://www.google.com/+/learnmore/




- End forwarded message -

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0...@n0ano.com
Ph: 303/443-3786

__
OpenStack Development Mailing 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]Why nova mounts FS for LXC container instead of libvirt?

[Dmitry Guryanov]

On 01/12/2015 06:35 PM, Daniel P. Berrange wrote:

On Mon, Jan 12, 2015 at 06:28:53PM +0300, Dmitry Guryanov wrote:

On 01/05/2015 02:30 PM, Daniel P. Berrange wrote:

On Tue, Dec 30, 2014 at 05:18:19PM +0300, Dmitry Guryanov wrote:

Hello,

Libvirt can create loop or nbd device for LXC container and mount it by
itself, for instance, you can add something like this to xml config:


   
   
   


But nova mounts filesystem for container by itself. Is this because rhel-6
doesn't support filesystems with type='file' or there are some other reasons?

The support for mounting using NBD in OpenStack pre-dated the support
for doing this in Libvirt. In faact the reason I added this feature to
libvirt was precisely because OpenStack was doing this.

We haven't switched Nova over to use this new syntax yet though, because
that would imply a change to the min required libvirt version for LXC.
That said we should probably make such a change, because honestly no
one should be using LXC without using user namespaces, othewise their
cloud is horribly insecure. This would imply making the min libvirt for
LXC much much newer than it is today.


It's not very hard to replace mounting in nova with generating proper xml
config. Can we do it before kilo release? Are there any people, who use
openstack with LXC in production?

Looking at libvirt history, it would mean we mandate 1.0.6 as the min
libvirt for use with the LXC driver.

Regards,
Daniel


I've created RFC patches:

https://review.openstack.org/#/c/147535/
https://review.openstack.org/#/c/147534/
https://review.openstack.org/#/c/147533/


--
Dmitry Guryanov


__
OpenStack Development Mailing 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][cinder][infra] Ceph CI status update

[Matt Riedemann]

On 12/16/2014 2:48 PM, Matt Riedemann wrote:



On 12/11/2014 10:36 AM, Jon Bernard wrote:

Heya, quick Ceph CI status update.  Once the test_volume_boot_pattern
was marked as skipped, only the revert_resize test was failing.  I have
submitted a patch to nova for this [1], and that yields an all green
ceph ci run [2].  So at the moment, and with my revert patch, we're in
good shape.

I will fix up that patch today so that it can be properly reviewed and
hopefully merged.  From there I'll submit a patch to infra to move the
job to the check queue as non-voting, and we can go from there.

[1] https://review.openstack.org/#/c/139693/
[2]
http://logs.openstack.org/93/139693/1/experimental/check-tempest-dsvm-full-ceph/12397fd/console.html


Cheers,



Jon,

Thanks, this is something I'm supposed to be tracking actually given the
Kilo priorities for the project, it's nice to know that someone is
already fixing this stuff. :)

I've reviewed https://review.openstack.org/#/c/139693/ so it's close,
just needs a small fix.



With Jon's fix [1] the ceph job on the experimental queue is passing now 
[2].


This is great to see.

I think there are still some skipped tests due to known bugs but those 
can be worked out now that we have a baseline.


I'd also like to move forward on getting this into the check queue, but 
remain non-voting for the time being until it's burned in a bit (to make 
sure there aren't any bad intermittent failures lurking in there).


[1] https://review.openstack.org/#/c/139693/
[2] 
http://logs.openstack.org/93/139693/9/experimental/check-tempest-dsvm-full-ceph/e97ba57/console.html


--

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] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Jeremy Stanley]

On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
[...]
> The other thing that happened was partial capping doesn't work,
> because something else moves forward and breaks you from below. So
> the patch will need to hit everything at once.

Right, and we _have_ to start using stable branches on all
clients/libraries to backport fixes as part of that. This means that
the stable branch management workflow is about to become pervasive
across some teams who were previously (blissfully?) ignorant of it.

> Unresolved entirely is the tertiary dependencies (not direct
> dependencies of any OpenStack project). That will need another
> mechanism to seed them before any installation happens.
[...]

I won't go so far as to call it intractable, but I took a stab at it
about a year ago and building the dependency graph properly to be
able to do a depth-first ordering is nontrivial (enough that after
about a week hacking on possible solutions I gave up and switched to
more productive tasks). The primary complications I ran into were
identifying setup_requires in transitive dependencies and dealing
with platform/version-specific dependencies. That said, there's a
very good chance that more recent improvements in setuptools, pip
and virtualenv could make this task easier.

> That's the things I can think off from the top of my head.

The implementation, from a devstack-gate perspective, is also going
to require a decision on whether we stick with stable/relname for
branches of libraries too or switch to some extended branch mapping
mechanism to be able to track stable/relnum branches for those. And
we're going to need more jobs to ensure that clients (specifically)
retain backward-compatibility from an appdev and end user
perspective since they'll no longer get any testing as server
dependencies on stable branches (due to being capped there).
-- 
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] [Fuel] [nailgun] [UI] network_check_status fleild for environments

[Vitaly Kramskikh]

Folks,

I want to discuss possibility to add network verification status field for
environments. There are 2 reasons for this:

1) One of the most frequent reasons of deployment failure is wrong network
configuration. In the current UI network verification is completely
optional and sometimes users are even unaware that this feature exists. We
can warn the user before the start of deployment if network check failed of
wasn't performed.

2) Currently network verification status is partially tracked by status of
the last network verification task. Sometimes its results become stale, and
the UI removes the task. There are a few cases when the UI does this, like
changing network settings, adding a new node, etc (you can grep
"removeFinishedNetworkTasks" to see all the cases). This definitely should
be done on backend.

What is your opinion on this?

-- 
Vitaly Kramskikh,
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] [TripleO] nominating James Polley for tripleo-core

[Alexis Lee]

Clint Byrum said on Wed, Jan 14, 2015 at 10:14:45AM -0800:
> holidays. However, I believe James has demonstrated superb review skills
> and a commitment to the project that shows broad awareness of the
> project.

Big +1. Thanks for taking the time to meta-review, Clint.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

__
OpenStack Development Mailing 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] About DVR limit

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Joehuang,
Thanks for your input and description of the problem.
What you are stating is just have DVR functionality for East-West traffic and 
all North-South traffic should go through the Centralized Router.
The North-South distributed reduces the burden in the Centralized Node. We 
eventually need to get away from the centralized node model.
I am not sure why there would be a use case to go back to the centralized model.

We were even initially planning to distribute the SNAT, but we just left it 
there centralized just to support the legacy services such as VPN.
Once we have service insertion and service chaining then we can distribute the 
SNAT functionality.

If you have a use case and willing to work on it and contribute code upstream, 
please let me know.

Thanks
Swami

From: joehuang [mailto:joehu...@huawei.com]
Sent: Wednesday, January 14, 2015 7:07 PM
To: 龚永生; Vasudevan, Swaminathan (PNB Roseville)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: Re:RE: [openstack-dev] About DVR limit

Hello,

Yongseng, correct, your description is much more concise, we need a 
configuration:

east-west, DVR
south-north, legacy mode.

Best Regards
Chaoyi Huang ( Joe Huang )

From: 龚永生 [mailto:gong.yongsh...@99cloud.net]
Sent: Thursday, January 15, 2015 10:18 AM
To: Vasudevan, Swaminathan (PNB Roseville)
Cc: joehuang; OpenStack Development Mailing List (not for usage questions)
Subject: Re:RE: [openstack-dev] About DVR limit


Hi, Swami, Joehuang,
in dvr compute nodes, it is 1:1 NAT FIP, means the floatingip for VM, and  it 
is in the namespace of qrouter-.
but in dvr_snat node, it is 1:N NAT IP, it is for neutron router, and for the 
VMs which have no 1:1 FIP, implemented in namesapce snat-xxx.

Joehuang's case can be implemented in legacy mode, I.E. non DVR,
but for the east-west traffic, we should consider the DVR, So I think there is 
a case:
east-west, DVR
south-north, legacy mode.


Thanks
yong sheng gong


在 2015-01-14 13:40:32，"Vasudevan, Swaminathan (PNB Roseville)" 
mailto:swaminathan.vasude...@hp.com>> 写道：
Hi Joehuang,
FIP today as of Juno can be both in centralized node (dvr_snat) and distributed 
“dvr” compute nodes.
Thanks
Swami

From: joehuang [mailto:joehu...@huawei.com]
Sent: Tuesday, January 13, 2015 7:49 PM
To: OpenStack Development Mailing List (not for usage questions); 龚永生
Cc: Vasudevan, Swaminathan (PNB Roseville)
Subject: RE: [openstack-dev] About DVR limit

Hi, Swami,

I would like to know whether the FIP under DVR could be configured to 
distributed mode or central mode in Kilo, not find relevant information from 
http://specs.openstack.org/openstack/neutron-specs/.

For example, it will be helpful for following FIP use cases: 1) FIP will be 
addressed centrally by dedicated hardware 2) not all compute nodes have public 
address.

Best Regards
Chaoyi Huang ( Joe Huang )

From: Stamina than Valued an [mailto:souminat...@yahoo.com]
Sent: Wednesday, January 14, 2015 11:05 AM
To: 龚永生
Cc: swaminathan.vasude...@hp.com; 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] About DVR limit

Hi yong Zheng,
Yes your understanding is right.
We only support ovs driver.
Regarding HA and multi network support, it will be available in kilo.

Public address consumption for north south traffic for compute node is also 
true. But to address this issue we do have a proposal that is worked out by the 
l3 sub team.

I hope this clarifies your doubts.

Please let me know if I can help you with anything else.

Thanks
Swami

Sent from my iPad

On Jan 13, 2015, at 6:01 PM, 龚永生 
mailto:gong.yongsh...@99cloud.net>> wrote:
Hi,
 I am yong sheng gong, I want to know if the DVR has these limits besides the 
documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:

1. one subnet can be connected to DVR router only once, which is confirmed by 
BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway
2. one network cannot have more than one subnet connecting to DVR routers


So the DVR limits the neutron model to:
one network has just one subnet, and one subnet cannot connect to more than one 
DVR routers.


ps.
req and limits documented at 
http://docs.openstack.org/networking-guide/content/ha-dvr.html::
 DVR requirements

*You must use the ML2 plug-in for Open VSwitch (OVS) to enable DVR.

*Be sure that your firewall or security groups allows UDP traffic over 
the VLAN, GRE, or VXLAN port to pass between the compute hosts.

 DVR limitations

*Distributed virtual router configurations work with the Open vSwitch 
Modular Layer 2 driver only for Juno.

*In order to enable true north-south bandwidth between hypervisors 
(compute nodes), you must use public IP addresses for every compute node and 
enable floating IPs.

*For now, based on the current neutron design and architecture, DHCP 
canno

[openstack-dev] [oslo] why we have 2 sets of tests in oslo libraries

[Doug Hellmann]

As part of the work on dropping the use of the oslo namespace [1], many of our 
library repositories now have 2 sets of tests. One set is under the new package 
(for example, “oslo_config/tests”), and uses the new import scheme (“from 
oslo_config import cfg”). To protect against regressions in the old public API, 
we have kept the original copies of the tests in a directory at the top level 
of the repository using the old import names (“from oslo.config import cfg”). 
The logic of most of the tests are identical now, aside from differences in the 
imports.

For new code, we only need to add tests in the new location inside the library 
package (“oslo_config/tests”). New symbols do not need to work through the old 
namespace, so using a new function or class may require updating imports in a 
consuming project.

The tests for the old public API should not be modified, except as we find 
redundancy that we can delete for testing private symbols. I did clean up some 
of the tests as I went along, but in a lot of cases it was faster to just 
update the imports. After we have all of the libraries released, I plan to 
spend more time going through the test suites and cleaning them up carefully, 
but that’s not a high priority task.

My goal is to be able to remove both the old namespace package and the related 
tests during the next cycle. We will have to check adoption progress as we get 
close to the end of Kilo to determine whether that is possible. Liaisons, 
please assume that we’re going to try to do it and work on updating all 
consuming projects.

Doug


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

Re: [openstack-dev] [oslo] why we have 2 sets of tests in oslo libraries

[Doug Hellmann]

> On Jan 15, 2015, at 12:01 PM, Doug Hellmann  wrote:
> 
> As part of the work on dropping the use of the oslo namespace [1], many of 
> our library repositories now have 2 sets of tests. One set is under the new 
> package (for example, “oslo_config/tests”), and uses the new import scheme 
> (“from oslo_config import cfg”). To protect against regressions in the old 
> public API, we have kept the original copies of the tests in a directory at 
> the top level of the repository using the old import names (“from oslo.config 
> import cfg”). The logic of most of the tests are identical now, aside from 
> differences in the imports.
> 
> For new code, we only need to add tests in the new location inside the 
> library package (“oslo_config/tests”). New symbols do not need to work 
> through the old namespace, so using a new function or class may require 
> updating imports in a consuming project.
> 
> The tests for the old public API should not be modified, except as we find 
> redundancy that we can delete for testing private symbols. I did clean up 
> some of the tests as I went along, but in a lot of cases it was faster to 
> just update the imports. After we have all of the libraries released, I plan 
> to spend more time going through the test suites and cleaning them up 
> carefully, but that’s not a high priority task.
> 
> My goal is to be able to remove both the old namespace package and the 
> related tests during the next cycle. We will have to check adoption progress 
> as we get close to the end of Kilo to determine whether that is possible. 
> Liaisons, please assume that we’re going to try to do it and work on updating 
> all consuming projects.
> 
> Doug
> 

The missing footnote:
[1] 
https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages


__
OpenStack Development Mailing 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] reckoning time for nova ec2 stack

[Matt Riedemann]

On 1/13/2015 9:27 PM, Matt Riedemann wrote:



On 1/13/2015 12:11 PM, Steven Hardy wrote:

On Tue, Jan 13, 2015 at 10:00:04AM -0600, Matt Riedemann wrote:

Looks like the fix we merged didn't actually fix the problem. I have
a patch
[1] to uncap the boto requirement on master and it's failing the ec2
tests
in tempest the same as before.


FWIW, I just re-tested and boto 2.35.1 works fine for me locally, if you
revert my patch it breaks again with "Signature not provided" errors (for
all ec2 API requests).

If you look at the failures in the log, it actually looks like a
different
problem:

EC2ResponseError: EC2ResponseError: 401 Unauthorized

This is not the same as the original error which rejected any request
inside the nova API before even calling keystone with a message like
this:

AuthFailure: Signature not provided

AFAICT this means my patch is working, and there's a different problem
affecting only a subset of the ec2 boto tests.

Steve

__

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



Yeah, new bug reported, looks like we're hitting 401 Unauthorized errors
when trying to create security groups in the test:

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



I have a debug patch up here to try and recreate the tempest failures 
with latest boto but using a nova debug change also to get more 
information when we fail.


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

--

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] [TripleO] nominating James Polley for tripleo-core

[Chuck Carlino]

On 01/15/2015 08:49 AM, Alexis Lee wrote:

Clint Byrum said on Wed, Jan 14, 2015 at 10:14:45AM -0800:

holidays. However, I believe James has demonstrated superb review skills
and a commitment to the project that shows broad awareness of the
project.

Big +1. Thanks for taking the time to meta-review, Clint.


Alexis


I don't get a vote, but just wanted to point out James' excellent 
contributions in chasing down neutron issues.


Hmm, now that I've said it, I'm not entirely certain he'd have wanted me 
to :P


ChuckC

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

Re: [openstack-dev] [horizon] function expressions vs function declarations in JavaScript

[Aaron Sahlin]

Just to expand a bit on Thai's response..   Make the changes to 
horizon/doc/source/contributing.rst and submit a patch, once that gets 
approval then

go update the wiki.

On 1/14/2015 3:49 PM, Thai Q Tran wrote:


Wow, that IS interesting. No process required, just modify 
/horizon/doc/source/contributing.rst and submit a patch.


-Matthew Farina  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 


From: Matthew Farina 
Date: 01/14/2015 12:20PM
Subject: Re: [openstack-dev] [horizon] function expressions vs 
function declarations in JavaScript


Thai, I'm still poking around at JavaScript things and did a little 
testing on function declarations vs function expressions. Seems 
Firefox is faster with function expressions by quite a bit at parse 
time. For reference see http://jsperf.com/mfer-function-types.


I'm not suggesting what we do. I'm just sharing a data point I found 
surprising.


I'm curious about the process for proposing changes to 
https://wiki.openstack.org/wiki/Horizon/Javascript. Is there any process?



On Wed, Jan 14, 2015 at 1:15 PM, Thai Q Tran > wrote:



It was definitely an interesting the read, I never really noticed
the subtle difference. Since then I have also read a few other
thoughts on it.
For me, function declarations can get convoluted very fast if not
use correctly.
Surely, you should never define functions inside of an if
statement, and quite confusing to do it after a return statement.
But they do have their uses when used correctly.
I think it ultimately depends on what you are trying to do and
whether it make sense to use declarations vs expressions.
As long as people understand the difference, and take it
case-by-case, its not really something I'm going to mull over too
much.

-Matthew Farina mailto:m...@mattfarina.com>> wrote: -
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
From: Matthew Farina mailto:m...@mattfarina.com>>
Date: 01/14/2015 07:04AM
Subject: [openstack-dev] [horizon] function expressions vs
function declarations in JavaScript


JavaScript has multiple ways to deal with functions. There are
function declarations and function expressions (and named function
expressions).

In looking at some reviews and the current code I found some
inconsistencies which leads me to ask, is there any guidance for
handling this in Horizon? I noticed no documentation in
https://wiki.openstack.org/wiki/Horizon/Javascript.

Thanks,
Matt


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage 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] Networks are not cleaned up in build failure

[Andrew Laski]

On 01/15/2015 09:33 AM, Brian Haley wrote:

On 01/14/2015 02:15 PM, Andrew Laski wrote:

On 01/14/2015 12:57 PM, Murray, Paul (HP Cloud) wrote:

Hi All,

I recently experienced failures getting images from Glance while spawning
instances. This step comes after building the networks in the guild sequence.
When the Glance failure occurred the instance was cleaned up and rescheduled
as expected, but the networks were not cleaned up. On investigation I found
that the cleanup code for the networks is in the compute manager’s
_/do_build_run/_instance() method as follows:

 # NOTE(comstud): Deallocate networks if the driver wants
 # us to do so.
 if self.driver.deallocate_networks_on_reschedule(instance):
 self._cleanup_allocated_networks(context, instance,
 requested_networks)

The default behavior in for the deallocate_networks_on_schedule() method
defined in ComputeDriver is:

 def deallocate_networks_on_reschedule(self, instance):
 """Does the driver want networks deallocated on reschedule?"""
 return False

Only the Ironic driver over rides this method to return True, so I think this
means the networks will not be cleaned up for any other virt driver.

  


Is this really the desired behavior?


Yes.  Other than when using Ironic there is nothing specific to a particular
host in the networking setup.  This means it is not necessary to deallocate and
reallocate networks when an instance is rescheduled, so we can avoid the
unnecessary work of doing it.

That's either not true any more, or not true when DVR is enabled in Neutron,
since in this case the port['binding:host_id'] value has been initialized to a
compute node, and won't get updated when nova-conductor re-schedules the VM
elsewhere.

This causes the neutron port to stay on the original compute node, and any
neutron operations (like floatingip-associate) happen on the "old" port, leaving
the VM unreachable.


Gotcha.  Then we should be rebinding that port on a reschedule or go 
back to de/reallocating.  I'm assuming there's some way to handle the 
port being moved or resizes would be broken for the same reason.


If we do need to move back to de/reallocation of networks I think it 
would be better to remove the conditional nature of it and just do it.  
If the deallocate_networks_on_reschedule method defaults to True I don't 
see a case where it would be overridden by a driver given the 
information above.



If the instance goes to ERROR then the network will get cleaned up when the
instance is deleted.

I think we need to clean-up even in this case now too.

-Brian

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



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

Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

[Clint Byrum]

Excerpts from Chuck Carlino's message of 2015-01-15 09:43:41 -0800:
> On 01/15/2015 08:49 AM, Alexis Lee wrote:
> > Clint Byrum said on Wed, Jan 14, 2015 at 10:14:45AM -0800:
> >> holidays. However, I believe James has demonstrated superb review skills
> >> and a commitment to the project that shows broad awareness of the
> >> project.
> > Big +1. Thanks for taking the time to meta-review, Clint.
> >
> >
> > Alexis
> 
> I don't get a vote, but just wanted to point out James' excellent 
> contributions in chasing down neutron issues.
> 
> Hmm, now that I've said it, I'm not entirely certain he'd have wanted me 
> to :P
> 

Awesome, so James is our Neutron person now. :)

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

Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

[Dan Prince]

On Wed, 2015-01-14 at 10:14 -0800, Clint Byrum wrote:
> Hello! It has been a while since we expanded our review team. The
> numbers aren't easy to read with recent dips caused by the summit and
> holidays. However, I believe James has demonstrated superb review skills
> and a commitment to the project that shows broad awareness of the
> project.
> 
> Below are the results of a meta-review I did, selecting recent reviews
> by James with comments and a final score. I didn't find any reviews by
> James that I objected to.
> 
> https://review.openstack.org/#/c/133554/ -- Took charge and provided
> valuable feedback. +2
> https://review.openstack.org/#/c/114360/ -- Good -1 asking for better
> commit message and then timely follow-up +1 with positive comments for
> more improvement. +2
> https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec.
> 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this
> is only really about 7 - 10 working days and acceptable. +2
> https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of
> recent change with alternatives to the approach submitted as patches.
> https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in
> agreement with everyone else. +1
> https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with
> consideration for other reviewers. +2
> https://review.openstack.org/#/c/113983/ -- Thorough spec review with
> grammar pedantry noted as something that would not prevent a positive
> review score. +2
> 
> All current tripleo-core members are invited to vote at this time. Thank
> you!

+1

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



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

Re: [openstack-dev] [TripleO] Switching CI back to amd64

[Dan Prince]

On Wed, 2015-01-07 at 10:51 +, Derek Higgins wrote:
> Hi All,
> I intended to bring this up at this mornings meeting but the train I
> was on had no power sockets (and I had no battery) so sending to the
> list instead.
> 
> We currently run our CI with on images built for i386, we took this
> decision a while back to save memory ( at the time is allowed us to move
> the amount of memory required in our VMs from 4G to 2G (exactly where in
> those bands the hard requirements are I don't know)
> 
> Since then we have had to move back to 3G for the i386 VM as 2G was no
> longer enough so the saving in memory is no longer as dramatic.
> 
> Now that the difference isn't as dramatic, I propose we switch back to
> amd64 (with 4G vms) in order to CI on what would be closer to a
> production deployment and before making the switch wanted to throw the
> idea out there for others to digest.
> 
> This obviously would impact our capacity as we will have to reduce the
> number of testenvs per testenv hosts. Our capacity (in RH1 and roughly
> speaking) allows us to run about 1440 ci jobs per day. I believe we can
> make the switch and still keep capacity above 1200 with a few other changes
> 1. Add some more testenv hosts, we have 2 unused hosts at the moment and
> we can probably take 2 of the compute nodes from the overcloud.
> 2. Kill VM's at the end of each CI test (as opposed to leaving them
> running until the next CI test kills them), allowing us to more
> successfully overcommit on RAM
> 3. maybe look into adding swap on the test env hosts, they don't
> currently have any, so over committing RAM is a problem the the OOM
> killer is handling from time to time (I only noticed this yesterday).
> 
> The other benefit to doing this is that is we were to ever want to CI
> images build with packages (this has come up in previous meetings) we
> wouldn't need to provide i386 packages just for CI, while the rest of
> the world uses the amd64.

+1. I've been wishing we'd switch back to x86_64 for a while now. Even
if it takes a bit more space I think ultimately this makes thing a bit
easier on us so lets do it.

Dan

> 
> Thanks,
> Derek.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 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] [oslo.messaging] Performance testing. Initial steps.

[Denis Makogon]

Good day to All,

The question that i’d like to raise here is not simple one, so i’d like to
involve as much readers as i can. I’d like to speak about
oslo.messaging performance
testing. As community we’ve put lots of efforts in making oslo.messaging
widely used drivers stable as much as possible. Stability is a good thing,
but is it enough for saying “works well”? I’d say that it’s not.

Since oslo.messaging uses driver-based messaging workflow, it makes sense
to dig into each driver and collect all required/possible performance
metrics.

First of all, it does make sense to figure out how to perform performance
testing, first that came into my mind is to simulate high load on one of
corresponding drivers. Here comes the question of how it can be
accomplished withing available oslo.messaging tools - high load on any
driver can perform an application that:

   - can populate multiple emitters(rpc clients) and consumers (rpc
   servers).
   - can force clients to send messages of pre-defined number of messages
   of any length.

Another thing is why do we need such thing. Profiling, performance testing
can improve the way in which our drivers were implemented. It can show us
actual “bottlenecks” in messaging process, in general. In some cases it
does make sense to figure out where problem takes its place - whether AMQP
causes messaging problems or certain driver that speaks to AMQP fails.

Next thing that i want to discuss the architecture of profiling/performance
testing. As i can see it seemed to be a “good” way to add profiling code to
each driver. If there’s any objection or better solution, please bring them
to the light.

Once we’d have final design for profiling we would need to figure out tools
for profiling. After searching over the web, i found pretty interesting
topic related to python profiling [1]. After certain investigations it does
makes sense discuss next profiling options(apply one or both):

   - Line-by-line timing and execution frequency with a profiler (there are
   possible Pros and Cons, but i would say the per-line statistics is more
   than appreciable at initial performance testing steps)
   - Memory/CPU consumption

Metrics. The most useful metric for us is time, any time-based metric,
since it is very useful to know at which step or/and by whom delay/timeout
caused, for example, so as it said, we would be able to figure out whether
AMQP or driver fails to do what it was designed for.

Before proposing spec i’d like to figure out any other requirements, use
cases and restrictions for messaging performance testing. Also, if there
any stories of success in boosting python performance - feel free to share
it.



[1] http://www.huyng.com/posts/python-performance-analysis/

Kind regards,

Denis Makogon

IRC: denis_makogon

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

Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

[Clint Byrum]

In about 24 hours we've seen 9 core +1's, one non-core +1, and only one
dissenting opinion from James himself which I think we have properly
dismissed. With my nomination counting as an additional +1, that is 10,
which is 50% of the 20 cores active the last 90 days.

I believe this vote has carried. Please welcome James Polley to the
TripleO core reviewer team. :)

Excerpts from Clint Byrum's message of 2015-01-14 10:14:45 -0800:
> Hello! It has been a while since we expanded our review team. The
> numbers aren't easy to read with recent dips caused by the summit and
> holidays. However, I believe James has demonstrated superb review skills
> and a commitment to the project that shows broad awareness of the
> project.
> 
> Below are the results of a meta-review I did, selecting recent reviews
> by James with comments and a final score. I didn't find any reviews by
> James that I objected to.
> 
> https://review.openstack.org/#/c/133554/ -- Took charge and provided
> valuable feedback. +2
> https://review.openstack.org/#/c/114360/ -- Good -1 asking for better
> commit message and then timely follow-up +1 with positive comments for
> more improvement. +2
> https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec.
> 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this
> is only really about 7 - 10 working days and acceptable. +2
> https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of
> recent change with alternatives to the approach submitted as patches.
> https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in
> agreement with everyone else. +1
> https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with
> consideration for other reviewers. +2
> https://review.openstack.org/#/c/113983/ -- Thorough spec review with
> grammar pedantry noted as something that would not prevent a positive
> review score. +2
> 
> All current tripleo-core members are invited to vote at this time. Thank
> you!

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

[openstack-dev] [TripleO] Part two of core reviewer team -- pruning

[Clint Byrum]

Hello! Now that we've added James, I have some suggestions for members
that should be dropped.

I have communicated with some of these individuals and confirmed they
are not interested in continuing. So for posterity sake I'm noting
these two removals, effective immediately:

Tzu-mainn Chen
Imre Farkas

The following members have not submitted any reviews in 90 days, but I
wasn't able to contact them immediately. If you are on this list and
would like to stay or step down, please reply directly to me or on the
list. Since we still have data blips from the traditional December
break, I don't think we should think too much about the numbers beyond
this until next month.


Members with no reviews in 90 days:

Martyn Taylor
Radomir Dopieralski

__
OpenStack Development Mailing 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.messaging] Performance testing. Initial steps.

[Doug Hellmann]

> On Jan 15, 2015, at 1:30 PM, Denis Makogon  wrote:
> 
> Good day to All,
> 
> The question that i’d like to raise here is not simple one, so i’d like to 
> involve as much readers as i can. I’d like to speak about oslo.messaging 
> performance testing. As community we’ve put lots of efforts in making 
> oslo.messaging widely used drivers stable as much as possible. Stability is a 
> good thing, but is it enough for saying “works well”? I’d say that it’s not.
> Since oslo.messaging uses driver-based messaging workflow, it makes sense to 
> dig into each driver and collect all required/possible performance metrics.
> First of all, it does make sense to figure out how to perform performance 
> testing, first that came into my mind is to simulate high load on one of 
> corresponding drivers. Here comes the question of how it can be accomplished 
> withing available oslo.messaging tools - high load on any driver can perform 
> an application that:
>   • can populate multiple emitters(rpc clients) and consumers (rpc 
> servers).
>   • can force clients to send messages of pre-defined number of messages 
> of any length.

That makes sense.

> Another thing is why do we need such thing. Profiling, performance testing 
> can improve the way in which our drivers were implemented. It can show us 
> actual “bottlenecks” in messaging process, in general. In some cases it does 
> make sense to figure out where problem takes its place - whether AMQP causes 
> messaging problems or certain driver that speaks to AMQP fails.
> Next thing that i want to discuss the architecture of profiling/performance 
> testing. As i can see it seemed to be a “good” way to add profiling code to 
> each driver. If there’s any objection or better solution, please bring them 
> to the light.

What sort of extra profiling code do you anticipate needing?

> Once we’d have final design for profiling we would need to figure out tools 
> for profiling. After searching over the web, i found pretty interesting topic 
> related to python profiling [1]. After certain investigations it does makes 
> sense discuss next profiling options(apply one or both):
>   • Line-by-line timing and execution frequency with a profiler (there 
> are possible Pros and Cons, but i would say the per-line statistics is more 
> than appreciable at initial performance testing steps)
>   • Memory/CPU consumption
> Metrics. The most useful metric for us is time, any time-based metric, since 
> it is very useful to know at which step or/and by whom delay/timeout caused, 
> for example, so as it said, we would be able to figure out whether AMQP or 
> driver fails to do what it was designed for.
> Before proposing spec i’d like to figure out any other requirements, use 
> cases and restrictions for messaging performance testing. Also, if there any 
> stories of success in boosting python performance - feel free to share it.

The metrics to measure depend on the goal. Do we think the messaging code is 
using too much memory? Is it too slow? Or is there something else causing 
concern?

> 
> 
> 
> [1] http://www.huyng.com/posts/python-performance-analysis/
> 
> Kind regards,
> Denis Makogon
> IRC: denis_makogon
> dmako...@mirantis.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Murano][Heat][Mistral] Use and adoption of YAQL

[Dmitri Zimine]

Folks, 

We use YAQL in Mistral for referencing variables, expressing conditions, etc. 
Murano is using it extensively, I saw Heat folks thought of using it, at least 
once :) May be others...

We are learning that YAQL incredibly powerful comparing to alternatives like 
Jinja2 templates used  in salt / ansible. 

But with lack of documentation, it becomes one of adoption blockers to Mistral 
(we got very vocal user feedback on this).

This is pretty much all the docs I can offer our users on YAQL so far. Not 
much. 
http://yaql.readthedocs.org/en/latest/
https://github.com/ativelkov/yaql/blob/master/README.rst
https://murano.readthedocs.org/en/latest/murano_pl/murano_pl.html#yaql

Are there any plans to fix it? 

Are there interest from other projects to use YAQL? 

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

Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

[Anita Kuno]

On 01/16/2015 07:39 AM, Clint Byrum wrote:
> In about 24 hours we've seen 9 core +1's, one non-core +1, and only one
> dissenting opinion from James himself which I think we have properly
> dismissed. With my nomination counting as an additional +1, that is 10,
> which is 50% of the 20 cores active the last 90 days.
> 
> I believe this vote has carried. Please welcome James Polley to the
> TripleO core reviewer team. :)

/me hands James is custodial mop and bucket

Congratulations James and my condolences. :D

Anita.
> 
> Excerpts from Clint Byrum's message of 2015-01-14 10:14:45 -0800:
>> Hello! It has been a while since we expanded our review team. The
>> numbers aren't easy to read with recent dips caused by the summit and
>> holidays. However, I believe James has demonstrated superb review skills
>> and a commitment to the project that shows broad awareness of the
>> project.
>>
>> Below are the results of a meta-review I did, selecting recent reviews
>> by James with comments and a final score. I didn't find any reviews by
>> James that I objected to.
>>
>> https://review.openstack.org/#/c/133554/ -- Took charge and provided
>> valuable feedback. +2
>> https://review.openstack.org/#/c/114360/ -- Good -1 asking for better
>> commit message and then timely follow-up +1 with positive comments for
>> more improvement. +2
>> https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec.
>> 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this
>> is only really about 7 - 10 working days and acceptable. +2
>> https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of
>> recent change with alternatives to the approach submitted as patches.
>> https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in
>> agreement with everyone else. +1
>> https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with
>> consideration for other reviewers. +2
>> https://review.openstack.org/#/c/113983/ -- Thorough spec review with
>> grammar pedantry noted as something that would not prevent a positive
>> review score. +2
>>
>> All current tripleo-core members are invited to vote at this time. Thank
>> you!
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing 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] Networks are not cleaned up in build failure

[Brian Haley]

On 01/15/2015 12:55 PM, Andrew Laski wrote:
> On 01/15/2015 09:33 AM, Brian Haley wrote:
>> On 01/14/2015 02:15 PM, Andrew Laski wrote:
>>> On 01/14/2015 12:57 PM, Murray, Paul (HP Cloud) wrote:
 Hi All,

 I recently experienced failures getting images from Glance while spawning
 instances. This step comes after building the networks in the guild 
 sequence.
 When the Glance failure occurred the instance was cleaned up and 
 rescheduled
 as expected, but the networks were not cleaned up. On investigation I found
 that the cleanup code for the networks is in the compute manager’s
 _/do_build_run/_instance() method as follows:

  # NOTE(comstud): Deallocate networks if the driver wants
  # us to do so.
  if self.driver.deallocate_networks_on_reschedule(instance):
  self._cleanup_allocated_networks(context, instance,
  requested_networks)

 The default behavior in for the deallocate_networks_on_schedule() method
 defined in ComputeDriver is:

  def deallocate_networks_on_reschedule(self, instance):
  """Does the driver want networks deallocated on reschedule?"""
  return False

 Only the Ironic driver over rides this method to return True, so I think 
 this
 means the networks will not be cleaned up for any other virt driver.

  
 Is this really the desired behavior?

>>> Yes.  Other than when using Ironic there is nothing specific to a particular
>>> host in the networking setup.  This means it is not necessary to deallocate 
>>> and
>>> reallocate networks when an instance is rescheduled, so we can avoid the
>>> unnecessary work of doing it.
>> That's either not true any more, or not true when DVR is enabled in Neutron,
>> since in this case the port['binding:host_id'] value has been initialized to 
>> a
>> compute node, and won't get updated when nova-conductor re-schedules the VM
>> elsewhere.
>>
>> This causes the neutron port to stay on the original compute node, and any
>> neutron operations (like floatingip-associate) happen on the "old" port, 
>> leaving
>> the VM unreachable.
> 
> Gotcha.  Then we should be rebinding that port on a reschedule or go back to
> de/reallocating.  I'm assuming there's some way to handle the port being moved
> or resizes would be broken for the same reason.
> 
> If we do need to move back to de/reallocation of networks I think it would be
> better to remove the conditional nature of it and just do it.  If the
> deallocate_networks_on_reschedule method defaults to True I don't see a case
> where it would be overridden by a driver given the information above.

Andrew,

I was able to run a test here on a multi-node setup with DVR enabled:

- Booted VM
- Associated floating IP
- Updated binding:host_id (as admin) using the neutron API:

  $ neutron port-update $port -- --binding:host_id=novacompute5

The port was correctly moved to the other compute node and the floating IP
configured.  So that showed me the agents all did the right thing as far as I
can tell.  I know Paul was looking at the nova code to try and update just this
field, I'll check-in with him regarding that so we can get a patch up soon.

-Brian

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

Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

[Anita Kuno]

On 01/14/2015 01:06 PM, matt wrote:
> Hey Mike!
> 
> Thanks for this info.  Super helpful to me at least.  I am very interested
> in hearing more about nova-network to neutron migrations.
> 
> -Matt
> 
Hello Matt:

Please start attending the weekly meetings:
https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration
follow the logs from it:
http://eavesdrop.openstack.org/meetings/nova_net_to_neutron_migration/
as well as the logs for the neutron weekly meeting:
http://eavesdrop.openstack.org/meetings/networking/
and the nova weekly meeting:
http://eavesdrop.openstack.org/meetings/nova/

After you have had a chance to update yourself, please ask any questions
either at one of the above meetings or do email me.

Thank you Matt,
Anita.

> On Tue, Jan 13, 2015 at 1:53 PM, Michael Still  wrote:
> 
>> Hi, I just wanted to make sure people know that a small group of us
>> got together in a hallway at linux.conf.au 2015 to talk about this. It
>> wasn't an attempt to exclude anyone, we just all happened to be in the
>> same place at the same time.
>>
>> To that end, we made some notes from the chat, which are at
>> https://etherpad.openstack.org/p/nova-network-migration-lca2015 .
>> Specific points to note are that Angus Lees has volunteered to help
>> Oleg with the spec for this, and that we'd very much like to see a
>> discussion of this at the Nova midcycle meetup in a couple of weeks.
>>
>> I'd also like to call out that there's a link to the mailing list
>> thread where we discussed CERN's concerns in the etherpad for
>> reference as well.
>>
>> Cheers,
>> Michael
>>
>> On Sat, Dec 20, 2014 at 3:59 AM, Anita Kuno  wrote:
>>> Rather than waste your time making excuses let me state where we are and
>>> where I would like to get to, also sharing my thoughts about how you can
>>> get involved if you want to see this happen as badly as I have been told
>>> you do.
>>>
>>> Where we are:
>>> * a great deal of foundation work has been accomplished to achieve
>>> parity with nova-network and neutron to the extent that those involved
>>> are ready for migration plans to be formulated and be put in place
>>> * a summit session happened with notes and intentions[0]
>>> * people took responsibility and promptly got swamped with other
>>> responsibilities
>>> * spec deadlines arose and in neutron's case have passed
>>> * currently a neutron spec [1] is a work in progress (and it needs
>>> significant work still) and a nova spec is required and doesn't have a
>>> first draft or a champion
>>>
>>> Where I would like to get to:
>>> * I need people in addition to Oleg Bondarev to be available to help
>>> come up with ideas and words to describe them to create the specs in a
>>> very short amount of time (Oleg is doing great work and is a fabulous
>>> person, yay Oleg, he just can't do this alone)
>>> * specifically I need a contact on the nova side of this complex
>>> problem, similar to Oleg on the neutron side
>>> * we need to have a way for people involved with this effort to find
>>> each other, talk to each other and track progress
>>> * we need to have representation at both nova and neutron weekly
>>> meetings to communicate status and needs
>>>
>>> We are at K-2 and our current status is insufficient to expect this work
>>> will be accomplished by the end of K-3. I will be championing this work,
>>> in whatever state, so at least it doesn't fall off the map. If you would
>>> like to help this effort please get in contact. I will be thinking of
>>> ways to further this work and will be communicating to those who
>>> identify as affected by these decisions in the most effective methods of
>>> which I am capable.
>>>
>>> Thank you to all who have gotten us as far as well have gotten in this
>>> effort, it has been a long haul and you have all done great work. Let's
>>> keep going and finish this.
>>>
>>> Thank you,
>>> Anita.
>>>
>>> [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron
>>> [1] https://review.openstack.org/#/c/142456/
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> openstack-operat...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>> --
>> Rackspace Australia
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
> 


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

Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

[matt]

Will do.

On Thu, Jan 15, 2015 at 12:08 PM, Anita Kuno  wrote:

> On 01/14/2015 01:06 PM, matt wrote:
> > Hey Mike!
> >
> > Thanks for this info.  Super helpful to me at least.  I am very
> interested
> > in hearing more about nova-network to neutron migrations.
> >
> > -Matt
> >
> Hello Matt:
>
> Please start attending the weekly meetings:
> https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration
> follow the logs from it:
> http://eavesdrop.openstack.org/meetings/nova_net_to_neutron_migration/
> as well as the logs for the neutron weekly meeting:
> http://eavesdrop.openstack.org/meetings/networking/
> and the nova weekly meeting:
> http://eavesdrop.openstack.org/meetings/nova/
>
> After you have had a chance to update yourself, please ask any questions
> either at one of the above meetings or do email me.
>
> Thank you Matt,
> Anita.
>
> > On Tue, Jan 13, 2015 at 1:53 PM, Michael Still 
> wrote:
> >
> >> Hi, I just wanted to make sure people know that a small group of us
> >> got together in a hallway at linux.conf.au 2015 to talk about this. It
> >> wasn't an attempt to exclude anyone, we just all happened to be in the
> >> same place at the same time.
> >>
> >> To that end, we made some notes from the chat, which are at
> >> https://etherpad.openstack.org/p/nova-network-migration-lca2015 .
> >> Specific points to note are that Angus Lees has volunteered to help
> >> Oleg with the spec for this, and that we'd very much like to see a
> >> discussion of this at the Nova midcycle meetup in a couple of weeks.
> >>
> >> I'd also like to call out that there's a link to the mailing list
> >> thread where we discussed CERN's concerns in the etherpad for
> >> reference as well.
> >>
> >> Cheers,
> >> Michael
> >>
> >> On Sat, Dec 20, 2014 at 3:59 AM, Anita Kuno 
> wrote:
> >>> Rather than waste your time making excuses let me state where we are
> and
> >>> where I would like to get to, also sharing my thoughts about how you
> can
> >>> get involved if you want to see this happen as badly as I have been
> told
> >>> you do.
> >>>
> >>> Where we are:
> >>> * a great deal of foundation work has been accomplished to achieve
> >>> parity with nova-network and neutron to the extent that those involved
> >>> are ready for migration plans to be formulated and be put in place
> >>> * a summit session happened with notes and intentions[0]
> >>> * people took responsibility and promptly got swamped with other
> >>> responsibilities
> >>> * spec deadlines arose and in neutron's case have passed
> >>> * currently a neutron spec [1] is a work in progress (and it needs
> >>> significant work still) and a nova spec is required and doesn't have a
> >>> first draft or a champion
> >>>
> >>> Where I would like to get to:
> >>> * I need people in addition to Oleg Bondarev to be available to
> help
> >>> come up with ideas and words to describe them to create the specs in a
> >>> very short amount of time (Oleg is doing great work and is a fabulous
> >>> person, yay Oleg, he just can't do this alone)
> >>> * specifically I need a contact on the nova side of this complex
> >>> problem, similar to Oleg on the neutron side
> >>> * we need to have a way for people involved with this effort to
> find
> >>> each other, talk to each other and track progress
> >>> * we need to have representation at both nova and neutron weekly
> >>> meetings to communicate status and needs
> >>>
> >>> We are at K-2 and our current status is insufficient to expect this
> work
> >>> will be accomplished by the end of K-3. I will be championing this
> work,
> >>> in whatever state, so at least it doesn't fall off the map. If you
> would
> >>> like to help this effort please get in contact. I will be thinking of
> >>> ways to further this work and will be communicating to those who
> >>> identify as affected by these decisions in the most effective methods
> of
> >>> which I am capable.
> >>>
> >>> Thank you to all who have gotten us as far as well have gotten in this
> >>> effort, it has been a long haul and you have all done great work. Let's
> >>> keep going and finish this.
> >>>
> >>> Thank you,
> >>> Anita.
> >>>
> >>> [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron
> >>> [1] https://review.openstack.org/#/c/142456/
> >>>
> >>> ___
> >>> OpenStack-operators mailing list
> >>> openstack-operat...@lists.openstack.org
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >>
> >>
> >> --
> >> Rackspace Australia
> >>
> >> ___
> >> OpenStack-operators mailing list
> >> openstack-operat...@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.

Re: [openstack-dev] [Fuel] Empty role - status

[Andrew Woodward]

[from another thread]
On Wed, Jan 14, 2015 at 2:24 AM, Igor Kalnitsky  wrote:
>
> Guys,
>
> We want to introduce an "empty role" as a basis for plugins. For
> instance, the user select nodes, assign empty role and names it
> somehow like "CONTRAIL". In this step, vanilla fuel will just
> provision a node (since it's an empty role) and the plugin (in post
> hooks) can select all empty roles with node.name == "CONTRAIL" and
> deploy some stuff on that node.
>
> Obviously, it's hackish. But it's a simple approach that requires a
> minimum time. In future, we'll introduce pluggable roles, but that's
> another story.


So far from the review we simply added an role with a base OS, this
provides a nearly useless experience for plugin developers. This is
heavy on hacking even for plugin-devs

issues:
1) you get one role
2) you have to come up with some random way to identify nodes from
each other if you do. We can't set hostname, and node.name in the
nailgun is never in astute.yaml (which is a tech debt that we have
code to fix)
3) disk layout is fixed, and uselessly small, plugin-author will have
a lot of rework to do here
4) multiple plugins that need roles will effectively fight with each other

We can add roles in the releases API as it is, a plugin should be able
to leverage this, the only gap currently is [1] which is not an API
currently (new from granular deployments).

Because of this, it would be more useful to just call these API's
during installing the plugin. Worse case, the plugin author can do
this themselves if we add the install_script support [2]

[1] 
https://review.openstack.org/#/c/147230/2/nailgun/nailgun/orchestrator/graph_configuration.py
[2] https://review.openstack.org/#/c/137301/

On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin  wrote:
> Answers inline.
>
> On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L  wrote:
>>
>> Hi,
>>
>> Empty role is ready [1], thanks to granular deployment feature
>> I didn't have to hardcode some hacks in Astute again.
>>
>> But there are several things which I want to mention/discuss:
>>
>> 1. in the patch you can see the name of the role and its description
>> I would like to ask you to verify it and provide some other options if
>> you
>> have any
>> 2. we have a minor problem with the progress bar, we will figure out how
>> to fix it in Astute with Vladimir S.
>> 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific
>> and it
>> doesn't allow us to make efficient partitioning schema, e.g. it means
>> that we
>> cannot allocate root partition for all of the disks (provisioning will
>> fail), the
>> current workaround is to allocate root partition with minimal size
>> (about 15G) and leave the rest of the space as is (unallocated). As
>> far as I can see from the bug it's not so easy to fix the problem,
>> actually
>> image based provisioning fixes the problem, but it's not an option for
>> the
>> current release. Maybe you have some other ideas how to fix this
>> problem?
>>
> I would leave it as is - 15 GB. A user or plugin can adjust it for its
> needs.
>
>>
>> Thanks,
>>
>> [1] https://review.openstack.org/#/c/147230/
>> [2] https://bugs.launchpad.net/fuel/+bug/1278964
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andrew
Mirantis
Ceph community

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

Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

[James Slagle]

On Thu, Jan 15, 2015 at 1:39 PM, Clint Byrum  wrote:
> In about 24 hours we've seen 9 core +1's, one non-core +1, and only one
> dissenting opinion from James himself which I think we have properly
> dismissed. With my nomination counting as an additional +1, that is 10,
> which is 50% of the 20 cores active the last 90 days.
>
> I believe this vote has carried. Please welcome James Polley to the
> TripleO core reviewer team. :)

I'm a little late to the party, but it was a +1 from me as well. James
has been doing really valuable reviews for a while now.

-- 
-- James Slagle
--

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

Re: [openstack-dev] [Fuel] Empty role - status

[Andrew Woodward]

On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin  wrote:
> Answers inline.
>
> On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L  wrote:
>>
>> Hi,
>>
>> Empty role is ready [1], thanks to granular deployment feature
>> I didn't have to hardcode some hacks in Astute again.
>>
>> But there are several things which I want to mention/discuss:
>>
>> 1. in the patch you can see the name of the role and its description
>> I would like to ask you to verify it and provide some other options if
>> you
>> have any
>> 2. we have a minor problem with the progress bar, we will figure out how
>> to fix it in Astute with Vladimir S.
>> 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific
>> and it
>> doesn't allow us to make efficient partitioning schema, e.g. it means
>> that we
>> cannot allocate root partition for all of the disks (provisioning will
>> fail), the
>> current workaround is to allocate root partition with minimal size
>> (about 15G) and leave the rest of the space as is (unallocated). As
>> far as I can see from the bug it's not so easy to fix the problem,
>> actually
>> image based provisioning fixes the problem, but it's not an option for
>> the
>> current release. Maybe you have some other ideas how to fix this
>> problem?
>>
> I would leave it as is - 15 GB. A user or plugin can adjust it for its
> needs.

Seriously? NO the 15G Min / Max 50G "min" for the OS allocation is too
small for a default value and not using the rest of the disk. While
the user may easily change this (by the way, most users don't they
expect better allocations), how do you expect the plugin-dev to deal
with this? The way this seams to push the plugin-dev is to do it
pre-deployment via code. We know already working with the disk
allocation is very painful, why are we pushing them to 'duplicate'
code. We need proper support of dynamically adding roles so they can
re-use our code

Is [2] the correct bug for the ubuntu OS volume issue? It's clearly
talking about small root disk values being wrong for all real
deployments.

I'll try to look for the proper bug w/regards to ubuntu OS, but the
gist is the limitation is that the OS volume can not span multiple
disks. The whole-disk allocator we use for ceph-osd should be proper
to work around this problem in a way.

>>
>> Thanks,
>>
>> [1] https://review.openstack.org/#/c/147230/
>> [2] https://bugs.launchpad.net/fuel/+bug/1278964
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andrew
Mirantis
Ceph community

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

Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

[Lukasz Oles]

Big +1, it would save me a lot of debugging time :)

On Thu, Jan 15, 2015 at 5:20 PM, Vitaly Kramskikh
 wrote:
> Folks,
>
> I want to discuss possibility to add network verification status field for
> environments. There are 2 reasons for this:
>
> 1) One of the most frequent reasons of deployment failure is wrong network
> configuration. In the current UI network verification is completely optional
> and sometimes users are even unaware that this feature exists. We can warn
> the user before the start of deployment if network check failed of wasn't
> performed.
>
> 2) Currently network verification status is partially tracked by status of
> the last network verification task. Sometimes its results become stale, and
> the UI removes the task. There are a few cases when the UI does this, like
> changing network settings, adding a new node, etc (you can grep
> "removeFinishedNetworkTasks" to see all the cases). This definitely should
> be done on backend.
>
> What is your opinion on this?
>
> --
> Vitaly Kramskikh,
> 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
>



-- 
Łukasz Oleś

__
OpenStack Development Mailing 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] The state of nova-network to neutron migration

[Anita Kuno]

On 01/16/2015 09:19 AM, Kris G. Lindgren wrote:
> Is the fact that neutron security groups don’t provide the same level of 
> isolation as nova security groups on your guys radar?
> 
> Specifically talking about:  https://bugs.launchpad.net/neutron/+bug/1274034
> 
> I am sure their are a few other thigns that nova is doing that neutron is 
> currently not.
> 
> 
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy, LLC.
Can I convince you to attend the weekly nova-net to neutron migration
meeting and ensure that it is?

Thanks Kris,
Anita.
> 
> From: matt mailto:m...@nycresistor.com>>
> Date: Thursday, January 15, 2015 at 1:10 PM
> To: Anita Kuno mailto:ante...@anteaya.info>>
> Cc: Angus Lees mailto:gusl...@gmail.com>>, OpenStack 
> Development Mailing List 
> mailto:openstack-dev@lists.openstack.org>>,
>  
> "openstack-operat...@lists.openstack.org"
>  
> mailto:openstack-operat...@lists.openstack.org>>
> Subject: Re: [Openstack-operators] The state of nova-network to neutron 
> migration
> 
> Will do.
> 
> On Thu, Jan 15, 2015 at 12:08 PM, Anita Kuno 
> mailto:ante...@anteaya.info>> wrote:
> On 01/14/2015 01:06 PM, matt wrote:
>> Hey Mike!
>>
>> Thanks for this info.  Super helpful to me at least.  I am very interested
>> in hearing more about nova-network to neutron migrations.
>>
>> -Matt
>>
> Hello Matt:
> 
> Please start attending the weekly meetings:
> https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration
> follow the logs from it:
> http://eavesdrop.openstack.org/meetings/nova_net_to_neutron_migration/
> as well as the logs for the neutron weekly meeting:
> http://eavesdrop.openstack.org/meetings/networking/
> and the nova weekly meeting:
> http://eavesdrop.openstack.org/meetings/nova/
> 
> After you have had a chance to update yourself, please ask any questions
> either at one of the above meetings or do email me.
> 
> Thank you Matt,
> Anita.
> 
>> On Tue, Jan 13, 2015 at 1:53 PM, Michael Still 
>> mailto:mi...@stillhq.com>> wrote:
>>
>>> Hi, I just wanted to make sure people know that a small group of us
>>> got together in a hallway at linux.conf.au 2015 to 
>>> talk about this. It
>>> wasn't an attempt to exclude anyone, we just all happened to be in the
>>> same place at the same time.
>>>
>>> To that end, we made some notes from the chat, which are at
>>> https://etherpad.openstack.org/p/nova-network-migration-lca2015 .
>>> Specific points to note are that Angus Lees has volunteered to help
>>> Oleg with the spec for this, and that we'd very much like to see a
>>> discussion of this at the Nova midcycle meetup in a couple of weeks.
>>>
>>> I'd also like to call out that there's a link to the mailing list
>>> thread where we discussed CERN's concerns in the etherpad for
>>> reference as well.
>>>
>>> Cheers,
>>> Michael
>>>
>>> On Sat, Dec 20, 2014 at 3:59 AM, Anita Kuno 
>>> mailto:ante...@anteaya.info>> wrote:
 Rather than waste your time making excuses let me state where we are and
 where I would like to get to, also sharing my thoughts about how you can
 get involved if you want to see this happen as badly as I have been told
 you do.

 Where we are:
 * a great deal of foundation work has been accomplished to achieve
 parity with nova-network and neutron to the extent that those involved
 are ready for migration plans to be formulated and be put in place
 * a summit session happened with notes and intentions[0]
 * people took responsibility and promptly got swamped with other
 responsibilities
 * spec deadlines arose and in neutron's case have passed
 * currently a neutron spec [1] is a work in progress (and it needs
 significant work still) and a nova spec is required and doesn't have a
 first draft or a champion

 Where I would like to get to:
 * I need people in addition to Oleg Bondarev to be available to help
 come up with ideas and words to describe them to create the specs in a
 very short amount of time (Oleg is doing great work and is a fabulous
 person, yay Oleg, he just can't do this alone)
 * specifically I need a contact on the nova side of this complex
 problem, similar to Oleg on the neutron side
 * we need to have a way for people involved with this effort to find
 each other, talk to each other and track progress
 * we need to have representation at both nova and neutron weekly
 meetings to communicate status and needs

 We are at K-2 and our current status is insufficient to expect this work
 will be accomplished by the end of K-3. I will be championing this work,
 in whatever state, so at least it doesn't fall off the map. If you would
 like to help this effort please get in contact. I will be thinking of
 ways to further this work and will be communicating to those who

Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

[Kyle Mestery]

On Thu, Jan 15, 2015 at 2:19 PM, Kris G. Lindgren 
wrote:

>   Is the fact that neutron security groups don’t provide the same level
> of isolation as nova security groups on your guys radar?
>
>  Specifically talking about:
> https://bugs.launchpad.net/neutron/+bug/1274034
>
> That bug is actually tracked by a BP as well which is approved and marked
as Kilo-2 [1].



>  I am sure their are a few other thigns that nova is doing that neutron
> is currently not.
>

That may be true. The plan which was agreed to and executed on by the TC
during Juno is here [2]. If there are other features people want from
nova-network in neutron, I encourage them to file bugs or specs to track
them.

[1] https://blueprints.launchpad.net/neutron/+spec/arp-spoof-patch-ebtables
[2]
https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee/Neutron_Gap_Coverage


>
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy, LLC.
>
>   From: matt 
> Date: Thursday, January 15, 2015 at 1:10 PM
> To: Anita Kuno 
> Cc: Angus Lees , OpenStack Development Mailing List <
> openstack-dev@lists.openstack.org>, "
> openstack-operat...@lists.openstack.org" <
> openstack-operat...@lists.openstack.org>
> Subject: Re: [Openstack-operators] The state of nova-network to neutron
> migration
>
>   Will do.
>
> On Thu, Jan 15, 2015 at 12:08 PM, Anita Kuno  wrote:
>
>> On 01/14/2015 01:06 PM, matt wrote:
>> > Hey Mike!
>> >
>> > Thanks for this info.  Super helpful to me at least.  I am very
>> interested
>> > in hearing more about nova-network to neutron migrations.
>> >
>> > -Matt
>> >
>> Hello Matt:
>>
>> Please start attending the weekly meetings:
>> https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration
>> follow the logs from it:
>> http://eavesdrop.openstack.org/meetings/nova_net_to_neutron_migration/
>> as well as the logs for the neutron weekly meeting:
>> http://eavesdrop.openstack.org/meetings/networking/
>> and the nova weekly meeting:
>> http://eavesdrop.openstack.org/meetings/nova/
>>
>> After you have had a chance to update yourself, please ask any questions
>> either at one of the above meetings or do email me.
>>
>> Thank you Matt,
>> Anita.
>>
>> > On Tue, Jan 13, 2015 at 1:53 PM, Michael Still 
>> wrote:
>> >
>> >> Hi, I just wanted to make sure people know that a small group of us
>> >> got together in a hallway at linux.conf.au 2015 to talk about this. It
>> >> wasn't an attempt to exclude anyone, we just all happened to be in the
>> >> same place at the same time.
>> >>
>> >> To that end, we made some notes from the chat, which are at
>> >> https://etherpad.openstack.org/p/nova-network-migration-lca2015 .
>> >> Specific points to note are that Angus Lees has volunteered to help
>> >> Oleg with the spec for this, and that we'd very much like to see a
>> >> discussion of this at the Nova midcycle meetup in a couple of weeks.
>> >>
>> >> I'd also like to call out that there's a link to the mailing list
>> >> thread where we discussed CERN's concerns in the etherpad for
>> >> reference as well.
>> >>
>> >> Cheers,
>> >> Michael
>> >>
>> >> On Sat, Dec 20, 2014 at 3:59 AM, Anita Kuno 
>> wrote:
>> >>> Rather than waste your time making excuses let me state where we are
>> and
>> >>> where I would like to get to, also sharing my thoughts about how you
>> can
>> >>> get involved if you want to see this happen as badly as I have been
>> told
>> >>> you do.
>> >>>
>> >>> Where we are:
>> >>> * a great deal of foundation work has been accomplished to achieve
>> >>> parity with nova-network and neutron to the extent that those involved
>> >>> are ready for migration plans to be formulated and be put in place
>> >>> * a summit session happened with notes and intentions[0]
>> >>> * people took responsibility and promptly got swamped with other
>> >>> responsibilities
>> >>> * spec deadlines arose and in neutron's case have passed
>> >>> * currently a neutron spec [1] is a work in progress (and it needs
>> >>> significant work still) and a nova spec is required and doesn't have a
>> >>> first draft or a champion
>> >>>
>> >>> Where I would like to get to:
>> >>> * I need people in addition to Oleg Bondarev to be available to
>> help
>> >>> come up with ideas and words to describe them to create the specs in a
>> >>> very short amount of time (Oleg is doing great work and is a fabulous
>> >>> person, yay Oleg, he just can't do this alone)
>> >>> * specifically I need a contact on the nova side of this complex
>> >>> problem, similar to Oleg on the neutron side
>> >>> * we need to have a way for people involved with this effort to
>> find
>> >>> each other, talk to each other and track progress
>> >>> * we need to have representation at both nova and neutron weekly
>> >>> meetings to communicate status and needs
>> >>>
>> >>> We are at K-2 and our current status is insufficient to expect this
>> work
>> >>> will be accomplished by the end of K-3. I wi

[openstack-dev] Resending: [nova] Request Spec Freeze Exception for: Remove direct nova DB/API access in Scheduler Filters

[Ed Leafe]

I sent this at the beginning of the exception process, but it did not appear on 
the list of exceptions mikal posted at today's nova meeting, so I'm re-sending.

> Begin forwarded message:
> 
> Date: January 8, 2015 at 8:50:57 AM CST
> From: Ed Leafe 
> To: "OpenStack Development Mailing List (openstack-dev@lists.openstack.org)" 
> 
> Subject: [openstack-dev] [nova] Request Spec Freeze Exception for: Remove 
> direct nova DB/API access in Scheduler Filters
> Reply-To: "OpenStack Development Mailing List \(not for usage questions\)" 
> 
> 
> Signed PGP part
> Hi,
> 
> This spec [1] has been on hold, as it was largely dependent on another
> spec [2] being approved first, as it has very similar requirements.
> Now that the latter has been approved, I am moving forward with the
> former. It is part of the scheduler cleanup effort that has been
> identified as a priority for Kilo.
> 
> Thanks for your consideration!
> 
> [1] https://review.openstack.org/#/c/138444/
> 
> [2]
> https://github.com/openstack/nova-specs/blob/master/specs/kilo/approved/isolate-scheduler-db-aggregates.rst
> 
> 
> -- Ed Leafe
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- Ed Leafe







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

[openstack-dev] [nova] Reminder of priority etherpad

[Michael Still]

Hi,

I know many of us are just coming back from holiday breaks -- I
certainly am. It came up in the nova meeting this morning that we've
stopped being so reliable at reviewing the priority review etherpad
when deciding what to review. So -- it would be cool if reviewers
(everyone, not just core) could make checking the state of priority
reviews on the etherpad as part of their review workflow.

The etherpad is at:

https://etherpad.openstack.org/p/kilo-nova-priorities-tracking

Thanks,
Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] Resending: [nova] Request Spec Freeze Exception for: Remove direct nova DB/API access in Scheduler Filters

[Michael Still]

Thanks for this, I will add it to the list.

Michael

On Fri, Jan 16, 2015 at 11:00 AM, Ed Leafe  wrote:
> I sent this at the beginning of the exception process, but it did not appear 
> on the list of exceptions mikal posted at today's nova meeting, so I'm 
> re-sending.
>
>> Begin forwarded message:
>>
>> Date: January 8, 2015 at 8:50:57 AM CST
>> From: Ed Leafe 
>> To: "OpenStack Development Mailing List (openstack-dev@lists.openstack.org)" 
>> 
>> Subject: [openstack-dev] [nova] Request Spec Freeze Exception for: Remove 
>> direct nova DB/API access in Scheduler Filters
>> Reply-To: "OpenStack Development Mailing List \(not for usage questions\)" 
>> 
>>
>> Signed PGP part
>> Hi,
>>
>> This spec [1] has been on hold, as it was largely dependent on another
>> spec [2] being approved first, as it has very similar requirements.
>> Now that the latter has been approved, I am moving forward with the
>> former. It is part of the scheduler cleanup effort that has been
>> identified as a priority for Kilo.
>>
>> Thanks for your consideration!
>>
>> [1] https://review.openstack.org/#/c/138444/
>>
>> [2]
>> https://github.com/openstack/nova-specs/blob/master/specs/kilo/approved/isolate-scheduler-db-aggregates.rst
>>
>>
>> -- Ed Leafe
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia

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

[openstack-dev] [neutron] Changes to the core team

[Kyle Mestery]

The last time we looked at core reviewer stats was in December [1]. In
looking at the current stats, I'm going to propose some changes to the core
team. Reviews are the most important part of being a core reviewer, so we
need to ensure cores are doing reviews. The stats for the 90 day period [2]
indicate some changes are needed for core reviewers who are no longer
reviewing on pace with the other core reviewers.

First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
been a core reviewer for a long time, and his past contributions are very
much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
with thoughtful reviews in the future, we can look at getting him back as a
Neutron core reviewer. But for now, his stats indicate he's not reviewing
at a level consistent with the rest of the Neutron core reviewers.

As part of the change, I'd like to propose Doug Wiegley as a new Neutron
core reviewer. Doug has been actively reviewing code across not only all
the Neutron projects, but also other projects such as infra. His help and
work in the services split in December were the reason we were so
successful in making that happen. Doug has also been instrumental in the
Neutron LBaaS V2 rollout, as well as helping to merge code in the other
neutron service repositories.

I'd also like to take this time to remind everyone that reviewing code is a
responsibility, in Neutron the same as other projects. And core reviewers
are especially beholden to this responsibility. I'd also like to point out
that +1/-1 reviews are very useful, and I encourage everyone to continue
reviewing code even if you are not a core reviewer.

Existing neutron cores, please vote +1/-1 for the addition of Doug to the
core team.

Thanks!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
[2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
__
OpenStack Development Mailing 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] Resend: [nova] Request Spec Freeze Exception for Enhance iSCSI multipath/failover support

[Tomoki Sekiyama]

Michael,



These wasn't on the list of of exceptions at today's nova meeting. Please
add them.

On 1/8/15, 11:48 , "Tomoki Sekiyama"  wrote:
>Hi,
>
>I have submitted 2 nova-specs [1][2] related to Cinder volumes iSCSI
>multipath/failover improvement.
>
>These specs are both for enabling Cinder to pass multiple iSCSI paths to
>Nova. [1] is for multipath use-case, where Nova will establish iSCSI
>sessions to all the given paths. [2] is for failover use-case, where Nova
>will try to establish alternative path when it fails to establish main
>path.
>
>These specs were blocked to wait for corresponding cinder-specs approval
>[3][4], which are now approved. Please consider these specs for spec
>freeze exception.
>
>nova-specs:
>[1] https://review.openstack.org/#/c/134299/
>[2] https://review.openstack.org/#/c/137468/
>
>cinder-specs:
>[3] https://review.openstack.org/#/c/136500/
>[4] https://review.openstack.org/#/c/131502/


Regards,
Tomoki Sekiyama


__
OpenStack Development Mailing 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] Changes to the core team

[Kevin Benton]

+1, without Doug's help fixing everything, the services split probably
wouldn't have happened.

On Thu, Jan 15, 2015 at 2:31 PM, Kyle Mestery  wrote:

> The last time we looked at core reviewer stats was in December [1]. In
> looking at the current stats, I'm going to propose some changes to the core
> team. Reviews are the most important part of being a core reviewer, so we
> need to ensure cores are doing reviews. The stats for the 90 day period [2]
> indicate some changes are needed for core reviewers who are no longer
> reviewing on pace with the other core reviewers.
>
> First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
> been a core reviewer for a long time, and his past contributions are very
> much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
> with thoughtful reviews in the future, we can look at getting him back as a
> Neutron core reviewer. But for now, his stats indicate he's not reviewing
> at a level consistent with the rest of the Neutron core reviewers.
>
> As part of the change, I'd like to propose Doug Wiegley as a new Neutron
> core reviewer. Doug has been actively reviewing code across not only all
> the Neutron projects, but also other projects such as infra. His help and
> work in the services split in December were the reason we were so
> successful in making that happen. Doug has also been instrumental in the
> Neutron LBaaS V2 rollout, as well as helping to merge code in the other
> neutron service repositories.
>
> I'd also like to take this time to remind everyone that reviewing code is
> a responsibility, in Neutron the same as other projects. And core reviewers
> are especially beholden to this responsibility. I'd also like to point out
> that +1/-1 reviews are very useful, and I encourage everyone to continue
> reviewing code even if you are not a core reviewer.
>
> Existing neutron cores, please vote +1/-1 for the addition of Doug to the
> core team.
>
> Thanks!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
> [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
>
> __
> OpenStack Development Mailing 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] [neutron] Changes to the core team

[Anita Kuno]

On 01/16/2015 11:31 AM, Kyle Mestery wrote:
> The last time we looked at core reviewer stats was in December [1]. In
> looking at the current stats, I'm going to propose some changes to the core
> team. Reviews are the most important part of being a core reviewer, so we
> need to ensure cores are doing reviews. The stats for the 90 day period [2]
> indicate some changes are needed for core reviewers who are no longer
> reviewing on pace with the other core reviewers.
> 
> First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
> been a core reviewer for a long time, and his past contributions are very
> much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
> with thoughtful reviews in the future, we can look at getting him back as a
> Neutron core reviewer. But for now, his stats indicate he's not reviewing
> at a level consistent with the rest of the Neutron core reviewers.
> 
> As part of the change, I'd like to propose Doug Wiegley as a new Neutron
> core reviewer. Doug has been actively reviewing code across not only all
> the Neutron projects, but also other projects such as infra. His help and
> work in the services split in December were the reason we were so
> successful in making that happen. Doug has also been instrumental in the
> Neutron LBaaS V2 rollout, as well as helping to merge code in the other
> neutron service repositories.
I don't have a vote here but I would like to echo Kyle's summary of the
value of Doug's work with infra with the services split effort. It
wouldn't have happened without Doug's patience, persistence and leadership.

Thanks,
Anita.
> 
> I'd also like to take this time to remind everyone that reviewing code is a
> responsibility, in Neutron the same as other projects. And core reviewers
> are especially beholden to this responsibility. I'd also like to point out
> that +1/-1 reviews are very useful, and I encourage everyone to continue
> reviewing code even if you are not a core reviewer.
> 
> Existing neutron cores, please vote +1/-1 for the addition of Doug to the
> core team.
> 
> Thanks!
> Kyle
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
> [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
> 
> 
> 
> __
> OpenStack Development Mailing 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] Changes to the core team

[Maru Newby]

+1 to Doug’s addition.  He’s been a workhorse in moving lbaas and the services 
split forward and his being able to finally merge code in the main repo should 
be a boon to our merge velocity.

Many thanks to Sumit for his long-serving dedication as a core reviewer.  I 
hope to see him return to the fold soon!


Maru

> On Jan 15, 2015, at 2:31 PM, Kyle Mestery  wrote:
> 
> The last time we looked at core reviewer stats was in December [1]. In 
> looking at the current stats, I'm going to propose some changes to the core 
> team. Reviews are the most important part of being a core reviewer, so we 
> need to ensure cores are doing reviews. The stats for the 90 day period [2] 
> indicate some changes are needed for core reviewers who are no longer 
> reviewing on pace with the other core reviewers.
> 
> First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has been 
> a core reviewer for a long time, and his past contributions are very much 
> thanked by the entire OpenStack Neutron team. If Sumit jumps back in with 
> thoughtful reviews in the future, we can look at getting him back as a 
> Neutron core reviewer. But for now, his stats indicate he's not reviewing at 
> a level consistent with the rest of the Neutron core reviewers.
> 
> As part of the change, I'd like to propose Doug Wiegley as a new Neutron core 
> reviewer. Doug has been actively reviewing code across not only all the 
> Neutron projects, but also other projects such as infra. His help and work in 
> the services split in December were the reason we were so successful in 
> making that happen. Doug has also been instrumental in the Neutron LBaaS V2 
> rollout, as well as helping to merge code in the other neutron service 
> repositories.
> 
> I'd also like to take this time to remind everyone that reviewing code is a 
> responsibility, in Neutron the same as other projects. And core reviewers are 
> especially beholden to this responsibility. I'd also like to point out that 
> +1/-1 reviews are very useful, and I encourage everyone to continue reviewing 
> code even if you are not a core reviewer.
> 
> Existing neutron cores, please vote +1/-1 for the addition of Doug to the 
> core team.
> 
> Thanks!
> Kyle
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
> [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
> __
> OpenStack Development Mailing 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] Changes to the core team

[Edgar Magana]

+1 For adding Doug as Core in Neutron!

I have seen his work on the services part and he is a great member of the 
OpenStack community!

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, January 15, 2015 at 2:31 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron] Changes to the core team

The last time we looked at core reviewer stats was in December [1]. In looking 
at the current stats, I'm going to propose some changes to the core team. 
Reviews are the most important part of being a core reviewer, so we need to 
ensure cores are doing reviews. The stats for the 90 day period [2] indicate 
some changes are needed for core reviewers who are no longer reviewing on pace 
with the other core reviewers.

First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has been a 
core reviewer for a long time, and his past contributions are very much thanked 
by the entire OpenStack Neutron team. If Sumit jumps back in with thoughtful 
reviews in the future, we can look at getting him back as a Neutron core 
reviewer. But for now, his stats indicate he's not reviewing at a level 
consistent with the rest of the Neutron core reviewers.

As part of the change, I'd like to propose Doug Wiegley as a new Neutron core 
reviewer. Doug has been actively reviewing code across not only all the Neutron 
projects, but also other projects such as infra. His help and work in the 
services split in December were the reason we were so successful in making that 
happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout, as 
well as helping to merge code in the other neutron service repositories.

I'd also like to take this time to remind everyone that reviewing code is a 
responsibility, in Neutron the same as other projects. And core reviewers are 
especially beholden to this responsibility. I'd also like to point out that 
+1/-1 reviews are very useful, and I encourage everyone to continue reviewing 
code even if you are not a core reviewer.

Existing neutron cores, please vote +1/-1 for the addition of Doug to the core 
team.

Thanks!
Kyle

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
[2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
__
OpenStack Development Mailing 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] reckoning time for nova ec2 stack

[Matt Riedemann]

On 1/15/2015 11:40 AM, Matt Riedemann wrote:



On 1/13/2015 9:27 PM, Matt Riedemann wrote:



On 1/13/2015 12:11 PM, Steven Hardy wrote:

On Tue, Jan 13, 2015 at 10:00:04AM -0600, Matt Riedemann wrote:

Looks like the fix we merged didn't actually fix the problem. I have
a patch
[1] to uncap the boto requirement on master and it's failing the ec2
tests
in tempest the same as before.


FWIW, I just re-tested and boto 2.35.1 works fine for me locally, if you
revert my patch it breaks again with "Signature not provided" errors
(for
all ec2 API requests).

If you look at the failures in the log, it actually looks like a
different
problem:

EC2ResponseError: EC2ResponseError: 401 Unauthorized

This is not the same as the original error which rejected any request
inside the nova API before even calling keystone with a message like
this:

AuthFailure: Signature not provided

AFAICT this means my patch is working, and there's a different problem
affecting only a subset of the ec2 boto tests.

Steve

__


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



Yeah, new bug reported, looks like we're hitting 401 Unauthorized errors
when trying to create security groups in the test:

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



I have a debug patch up here to try and recreate the tempest failures
with latest boto but using a nova debug change also to get more
information when we fail.

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



I finally narrowed this down to some code in keystone where it generates 
a signature and compares that to what nova is passing in on the request 
for ec2 credentials and they are different so keystone is rejecting the 
request with a 401.


http://logs.openstack.org/01/147601/3/check/check-tempest-dsvm-full/96bb05e/logs/apache/keystone.txt.gz#_2015-01-15_22_00_27_046

I'm assuming something needs to change in keystone to support the 
version 4 format?


--

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-dev] Running tox on Centos 6.5 with Python26

[John Warren]

Can someone tell me or point me to documentation about what the  
required yum and pip packages are to be able to run tox for glance,  
keystone, neutron, cinder and nova on Centos 6.5 with Python 2.6?  I  
looked at the openstack-infra/puppet-jenkins project and thought I  
installed everything in the slave.pp manifest, which presumably is  
sufficient to be able to run tox for all openstack projects, but when  
I try to run tox on nova (tox --recreate -epy26) I just get an error  
that indicates that no test cases were found.


Any help would be greatly appreciated.

John


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

[openstack-dev] [nova] [oslo] compare and swap progress

[Mike Bayer]

For those who haven’t seen it, I’d like to first share Jay Pipes’ unbelievably 
thorough blog post on Nova update concurrency, specifically as it relates to 
the issue of emitting an UPDATE on a "locked” row without using SELECT..FOR 
UPDATE (as well as why we *can’t* keep using SELECT..FOR UPDATE).  Go read it, 
I’ll wait here:  

http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/


Got all that? OK.   There’ve been two patches so far I’m aware of to 
implement this within a key area in nova.  We have Jay’s and Matt Booth’s:

https://review.openstack.org/109837
https://review.openstack.org/141115

So what I want to do with either of those (Matt’s seems to be a little further 
along) is factor out all that UPDATE stuff, and make a nice oslo.db function 
that will:

1. emit an UPDATE statement that matches a row on a full set of attributes 
present in a given object “specimen”;

2. if exactly one row matched, retrieve the primary key of that row using as 
efficient a means as possible given the backend database and schema design;

3. return a persistent version of the given “specimen” as though it was just 
SELECTed from the database.

I have that ready to go, which most likely can be of use in many more scenarios 
than just this one.  I invite folks to take a look:

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

Example:

 specimen = MyModel(
y='y9', z='z5', x=6,
uuid='136254d5-3869-408f-9da7-190e0072641a'
)

result = session.query(MyModel).update_on_match(
specimen,
'uuid', 
values={'x': 9, 'z': 'z3'})

# result is now a persistent version of "specimen" (at the moment
# the same object) with all the new values.  the UPDATE statement 
guaranteed
# to match all of x, y, z and uuid.






__
OpenStack Development Mailing 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][gate][stable] How eventlet 0.16.1 broke the gate

[Joe Gordon]

We can side step the dependency graphing and ordering issue by looking at
the list of curently installed packages via pip freeze and not installing
dependencies (pip install --no-deps)

After looking into this further here are the known issues:

* Partial capping won't work [0], so we need to pin all dependencies, we
can generate this list per file via "pip install -r" and "pip freeze", but
this doesn't address the issue of apt-get vs pip install. For example in
the stable gate we use suds 0.4.1 but only suds 0.4.0 is available via pip.
* Not all packages are installed in are standard dsvm-tempest env, so using
pip-freeze from that isn't enough
* We need to run this per requirements file and move to using pip install
--no-deps everywhere. As the global-requirements sync wouldn't work the
first time since files don't list all transient dependencies yet.
* We can still break if a package version is removed from pypi
* in pip-freeze we sometimes install versions lower then our minimum
version (python-libvirt!)



[0]
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html

On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley  wrote:

> On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
> [...]
> > The other thing that happened was partial capping doesn't work,
> > because something else moves forward and breaks you from below. So
> > the patch will need to hit everything at once.
>
> Right, and we _have_ to start using stable branches on all
> clients/libraries to backport fixes as part of that. This means that
> the stable branch management workflow is about to become pervasive
> across some teams who were previously (blissfully?) ignorant of it.
>
> > Unresolved entirely is the tertiary dependencies (not direct
> > dependencies of any OpenStack project). That will need another
> > mechanism to seed them before any installation happens.
> [...]
>
> I won't go so far as to call it intractable, but I took a stab at it
> about a year ago and building the dependency graph properly to be
> able to do a depth-first ordering is nontrivial (enough that after
> about a week hacking on possible solutions I gave up and switched to
> more productive tasks). The primary complications I ran into were
> identifying setup_requires in transitive dependencies and dealing
> with platform/version-specific dependencies. That said, there's a
> very good chance that more recent improvements in setuptools, pip
> and virtualenv could make this task easier.
>
> > That's the things I can think off from the top of my head.
>
> The implementation, from a devstack-gate perspective, is also going
> to require a decision on whether we stick with stable/relname for
> branches of libraries too or switch to some extended branch mapping
> mechanism to be able to track stable/relnum branches for those. And
> we're going to need more jobs to ensure that clients (specifically)
> retain backward-compatibility from an appdev and end user
> perspective since they'll no longer get any testing as server
> dependencies on stable branches (due to being capped there).
> --
> 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] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Joe Gordon]

On Fri, Jan 16, 2015 at 12:25 PM, Joe Gordon  wrote:

> We can side step the dependency graphing and ordering issue by looking at
> the list of curently installed packages via pip freeze and not installing
> dependencies (pip install --no-deps)
>
> After looking into this further here are the known issues:
>
> * Partial capping won't work [0], so we need to pin all dependencies, we
> can generate this list per file via "pip install -r" and "pip freeze", but
> this doesn't address the issue of apt-get vs pip install. For example in
> the stable gate we use suds 0.4.1 but only suds 0.4.0 is available via pip.
> * Not all packages are installed in are standard dsvm-tempest env, so
> using pip-freeze from that isn't enough
> * We need to run this per requirements file and move to using pip install
> --no-deps everywhere. As the global-requirements sync wouldn't work the
> first time since files don't list all transient dependencies yet.
> * We can still break if a package version is removed from pypi
> * in pip-freeze we sometimes install versions lower then our minimum
> version (python-libvirt!)
>
>
Exploring a few ideas here: https://review.openstack.org/#/c/147451/4


>
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html
>
> On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley  wrote:
>
>> On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
>> [...]
>> > The other thing that happened was partial capping doesn't work,
>> > because something else moves forward and breaks you from below. So
>> > the patch will need to hit everything at once.
>>
>> Right, and we _have_ to start using stable branches on all
>> clients/libraries to backport fixes as part of that. This means that
>> the stable branch management workflow is about to become pervasive
>> across some teams who were previously (blissfully?) ignorant of it.
>>
>> > Unresolved entirely is the tertiary dependencies (not direct
>> > dependencies of any OpenStack project). That will need another
>> > mechanism to seed them before any installation happens.
>> [...]
>>
>> I won't go so far as to call it intractable, but I took a stab at it
>> about a year ago and building the dependency graph properly to be
>> able to do a depth-first ordering is nontrivial (enough that after
>> about a week hacking on possible solutions I gave up and switched to
>> more productive tasks). The primary complications I ran into were
>> identifying setup_requires in transitive dependencies and dealing
>> with platform/version-specific dependencies. That said, there's a
>> very good chance that more recent improvements in setuptools, pip
>> and virtualenv could make this task easier.
>>
>> > That's the things I can think off from the top of my head.
>>
>> The implementation, from a devstack-gate perspective, is also going
>> to require a decision on whether we stick with stable/relname for
>> branches of libraries too or switch to some extended branch mapping
>> mechanism to be able to track stable/relnum branches for those. And
>> we're going to need more jobs to ensure that clients (specifically)
>> retain backward-compatibility from an appdev and end user
>> perspective since they'll no longer get any testing as server
>> dependencies on stable branches (due to being capped there).
>> --
>> 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] [Keystone][Horizon] User self registration and management

[Adrian Turjak]

Hello David,

We are definitely assessing the option, although even switching Keystone
to be backed by an LDAP service might also work, and not be a switch to
a fully federated system. I believe Keystone has had LDAP support since
Havana, and that was an option we had looked at. It also might be a
terrible option, we don't know yet, and would still mean dealing with
LDAP directly anyway for user management.

What seems weird though with a federated Keystone system though is that
you still have to store role and group information in Keystone so that
has to be propagate through somehow, or be automated in some way still
via an external service.

We don't at present have any concrete plans, and until now a pressing
need to do so hasn't come up, although there were always plans to.

As for the VO roles blueprint, how likely is that to be merged into
master, and are there any implementations of it? I assume the VO
entities mentioned in the proposal would be in Keystone, yes?

We need a solution in the next few months (ideally sooner), but while
building a quick hack of a service along Keystone could likely be done
quickly.

Cheers,
-Adrian

On 15/01/15 21:20, David Chadwick wrote:
> Hi Adrian
> 
> Morgan is right in saying that an external IdP would solve many of your
> user management problems, but then of course, you will be using
> federated keystone  which you seem reluctant to do :-) However, if you
> have an IdP under your full control then you can allow users to self
> register and reset their passwords.
> 
> The next problem you will then face, is user authorisation - as opposed
> to user authentication. The VO roles blueprint that we have worked on
> addresses the authorisation problem. So when you are ready for this, let
> me know
> 
> regards
> 
> David
> 
> On 15/01/2015 00:42, Morgan Fainberg wrote:
>>>
>>> On Jan 13, 2015, at 9:06 PM, Adrian Turjak  wrote:
>>>
>>> Hello openstack-dev,
>>>
>>> I'm wondering if there is any interest or need for an open-source user
>>> registration and management service for people using OpenStack.
>>>
>>> We're currently at a point where we need a way for users to sign up
>>> themselves, choose their own password, and request new users to be added
>>> to their project. There doesn't seem to be anything out there, and most
>>> vendors seem to have built their own systems to handle this or even
>>> their own dashboard systems that do.
>>>
>>> Horizon is built around the client tools, and your own personal token,
>>> so it can't handle creating new users. Plus Keystone doesn't really have
>>> any good way of handling temporary (unapproved) users and projects.
>>>
>>> The suggested approach seems to be to build a service to sit along
>>> Keystone, have it's own admin creds so it can create new users, and also
>>> store temp user data locally until the user is approved.
>>>
>>> Unless we can find a suitable solution for us quickly, we're likely to
>>> be developing such a service. It would ideally have a pluggable approval
>>> workflow, allowing new user requests, new project requests, creation of
>>> clients in external client database/ERP systems. Plus it would have a
>>> password reset-token system for having new users supply their password
>>> once they are approved, which would also allow existing users to request
>>> password resets.
>>>
>>> Part of our requirements are easy to integrate into Horizon, fitting
>>> neatly into the OpenStack ecosystem along other services, and being easy
>>> to update/alter once we have hierarchical multi-tenancy and if it makes
>>> some things easier.
>>>
>>> I've written up a proposal to help us define our requirements, and a
>>> copy of that is attached, and on etherpad:
>>> https://etherpad.openstack.org/p/User_Management_Service
>>>
>>> Plus I've attached a couple of diagrams, which are sadly not UML, but
>>> should give you some idea of two of the primary use cases.
>>>
>>> Is this useful to anyone? Is this entirely the wrong approach? If it is
>>> a useful service is there any interest in collaboration?
>>>
>>> Thanks for any feedback.
>>>
>>> Cheers,
>>> -Adrian Turjak
>>
>> I have an alternative recommendation (rather than using Keystone’s API and 
>> user-management). Keystone’s user management is lacking a lot of features a 
>> full fledged IDP (identity provider) would have. “Password reset”, “password 
>> complexity”, “password reuse”, failed login locking, etc. I would recommend 
>> that you implement this service to write to a full featured IDP (LDAP, 
>> FreeIPA, Active Directory, etc) and have Keystone hook into that more-full 
>> featured IDP. You might even find that the IDP selected has a lot of these 
>> features built-in (and/or could be fronted in a horizon panel).
>>
>> This recommendation comes from past experience implementing almost exactly 
>> this feature (and having it go through a number of incarnations). The 
>> benefits of using a full-fledged IDP outweigh the ease of using the Keystone 
>> API to mana

Re: [openstack-dev] [Keystone][Horizon] User self registration and management

[Adrian Turjak]

Typo fix, see below.

On 16/01/15 12:26, Adrian Turjak wrote:
> Hello David,
> 
> We are definitely assessing the option, although even switching Keystone
> to be backed by an LDAP service might also work, and not be a switch to
> a fully federated system. I believe Keystone has had LDAP support since
> Havana, and that was an option we had looked at. It also might be a
> terrible option, we don't know yet, and would still mean dealing with
> LDAP directly anyway for user management.
> 
> What seems weird though with a federated Keystone system though is that
> you still have to store role and group information in Keystone so that
> has to be propagate through somehow, or be automated in some way still
> via an external service.
> 
> We don't at present have any concrete plans, and until now a pressing
> need to do so hasn't come up, although there were always plans to.
> 
> As for the VO roles blueprint, how likely is that to be merged into
> master, and are there any implementations of it? I assume the VO
> entities mentioned in the proposal would be in Keystone, yes?
> 
> We need a solution in the next few months (ideally sooner), but while
> building a quick hack of a service along Keystone could likely be done
> quickly
, that wouldn't be a good long term solution.

> 
> Cheers,
> -Adrian
> 
> On 15/01/15 21:20, David Chadwick wrote:
>> Hi Adrian
>>
>> Morgan is right in saying that an external IdP would solve many of your
>> user management problems, but then of course, you will be using
>> federated keystone  which you seem reluctant to do :-) However, if you
>> have an IdP under your full control then you can allow users to self
>> register and reset their passwords.
>>
>> The next problem you will then face, is user authorisation - as opposed
>> to user authentication. The VO roles blueprint that we have worked on
>> addresses the authorisation problem. So when you are ready for this, let
>> me know
>>
>> regards
>>
>> David
>>
>> On 15/01/2015 00:42, Morgan Fainberg wrote:

 On Jan 13, 2015, at 9:06 PM, Adrian Turjak  wrote:

 Hello openstack-dev,

 I'm wondering if there is any interest or need for an open-source user
 registration and management service for people using OpenStack.

 We're currently at a point where we need a way for users to sign up
 themselves, choose their own password, and request new users to be added
 to their project. There doesn't seem to be anything out there, and most
 vendors seem to have built their own systems to handle this or even
 their own dashboard systems that do.

 Horizon is built around the client tools, and your own personal token,
 so it can't handle creating new users. Plus Keystone doesn't really have
 any good way of handling temporary (unapproved) users and projects.

 The suggested approach seems to be to build a service to sit along
 Keystone, have it's own admin creds so it can create new users, and also
 store temp user data locally until the user is approved.

 Unless we can find a suitable solution for us quickly, we're likely to
 be developing such a service. It would ideally have a pluggable approval
 workflow, allowing new user requests, new project requests, creation of
 clients in external client database/ERP systems. Plus it would have a
 password reset-token system for having new users supply their password
 once they are approved, which would also allow existing users to request
 password resets.

 Part of our requirements are easy to integrate into Horizon, fitting
 neatly into the OpenStack ecosystem along other services, and being easy
 to update/alter once we have hierarchical multi-tenancy and if it makes
 some things easier.

 I've written up a proposal to help us define our requirements, and a
 copy of that is attached, and on etherpad:
 https://etherpad.openstack.org/p/User_Management_Service

 Plus I've attached a couple of diagrams, which are sadly not UML, but
 should give you some idea of two of the primary use cases.

 Is this useful to anyone? Is this entirely the wrong approach? If it is
 a useful service is there any interest in collaboration?

 Thanks for any feedback.

 Cheers,
 -Adrian Turjak
>>>
>>> I have an alternative recommendation (rather than using Keystone’s API and 
>>> user-management). Keystone’s user management is lacking a lot of features a 
>>> full fledged IDP (identity provider) would have. “Password reset”, 
>>> “password complexity”, “password reuse”, failed login locking, etc. I would 
>>> recommend that you implement this service to write to a full featured IDP 
>>> (LDAP, FreeIPA, Active Directory, etc) and have Keystone hook into that 
>>> more-full featured IDP. You might even find that the IDP selected has a lot 
>>> of these features built-in (and/or could be fronted in a horizon panel).
>>>
>>> This r

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Sean Dague]

On 01/15/2015 06:25 PM, Joe Gordon wrote:
> We can side step the dependency graphing and ordering issue by looking
> at the list of curently installed packages via pip freeze and not
> installing dependencies (pip install --no-deps)
> 
> After looking into this further here are the known issues:
> 
> * Partial capping won't work [0], so we need to pin all dependencies, we
> can generate this list per file via "pip install -r" and "pip freeze",
> but this doesn't address the issue of apt-get vs pip install. For
> example in the stable gate we use suds 0.4.1 but only suds 0.4.0 is
> available via pip.
> * Not all packages are installed in are standard dsvm-tempest env, so
> using pip-freeze from that isn't enough
> * We need to run this per requirements file and move to using pip
> install --no-deps everywhere. As the global-requirements sync wouldn't
> work the first time since files don't list all transient dependencies yet.

So that's basically writing our own dependency system entirely, and
skipping pip's (vs. fudging around pip's issues). I expect that's going
to go poorly in the OpenStack ecosystem realm because a lot of very
repetitive manual analysis will need to be done on each project. And if
we want to bump a cap, regenerating all the graphs becomes another
manual process.

> * We can still break if a package version is removed from pypi
> * in pip-freeze we sometimes install versions lower then our minimum
> version (python-libvirt!)

That's because python-libvirt is not in any requirements.txt file, so
we're taking the system version.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [nova] reckoning time for nova ec2 stack

[Steven Hardy]

On Thu, Jan 15, 2015 at 04:49:37PM -0600, Matt Riedemann wrote:
> 
> 
> On 1/15/2015 11:40 AM, Matt Riedemann wrote:
> >
> >
> >On 1/13/2015 9:27 PM, Matt Riedemann wrote:
> >>
> >>
> >>On 1/13/2015 12:11 PM, Steven Hardy wrote:
> >>>On Tue, Jan 13, 2015 at 10:00:04AM -0600, Matt Riedemann wrote:
> >>>>Looks like the fix we merged didn't actually fix the problem. I have
> >>>>a patch
> >>>>[1] to uncap the boto requirement on master and it's failing the ec2
> >>>>tests
> >>>>in tempest the same as before.
> >>>
> >>>FWIW, I just re-tested and boto 2.35.1 works fine for me locally, if you
> >>>revert my patch it breaks again with "Signature not provided" errors
> >>>(for
> >>>all ec2 API requests).
> >>>
> >>>If you look at the failures in the log, it actually looks like a
> >>>different
> >>>problem:
> >>>
> >>>EC2ResponseError: EC2ResponseError: 401 Unauthorized
> >>>
> >>>This is not the same as the original error which rejected any request
> >>>inside the nova API before even calling keystone with a message like
> >>>this:
> >>>
> >>>AuthFailure: Signature not provided
> >>>
> >>>AFAICT this means my patch is working, and there's a different problem
> >>>affecting only a subset of the ec2 boto tests.
> >>>
> >>>Steve
> >>>
> >>>__
> >>>
> >>>
> >>>OpenStack Development Mailing List (not for usage questions)
> >>>Unsubscribe:
> >>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>Yeah, new bug reported, looks like we're hitting 401 Unauthorized errors
> >>when trying to create security groups in the test:
> >>
> >>https://bugs.launchpad.net/nova/+bug/1410622
> >>
> >
> >I have a debug patch up here to try and recreate the tempest failures
> >with latest boto but using a nova debug change also to get more
> >information when we fail.
> >
> >https://review.openstack.org/#/c/147601/
> >
> 
> I finally narrowed this down to some code in keystone where it generates a
> signature and compares that to what nova is passing in on the request for
> ec2 credentials and they are different so keystone is rejecting the request
> with a 401.
> 
> http://logs.openstack.org/01/147601/3/check/check-tempest-dsvm-full/96bb05e/logs/apache/keystone.txt.gz#_2015-01-15_22_00_27_046
> 
> I'm assuming something needs to change in keystone to support the version 4
> format?

Keystone already supports the hmac v4 format, the code which creates the
signature keystone compares with that in the request actually lives in
keystoneclient:

https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/ec2/utils.py#L156

We have been bitten by a couple of bugs in the past where boto changed the
way it calculated the signature (presumably in a way compatible with AWS),
but generally that breaks all requests not just a specific one as in this
case (CreateSecurityGroup).

Interestingly, this seems to work OK for me locally, e.g using
euca-add-group, which AFAICS is the same API action the test is failing on:

-bash-4.2$ source /opt/stack/devstack/accrc/demo/demo
-bash-4.2$ euca-add-group --debug --description foo shtest2
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Using access key provided by
client.
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Using secret key provided by
client.
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Method: POST
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Path: /services/Cloud/
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Data: 
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Headers: {}
2015-01-15 23:33:22,891 euca2ools [DEBUG]:Host: 192.168.0.4
2015-01-15 23:33:22,891 euca2ools [DEBUG]:Port: 8773
2015-01-15 23:33:22,891 euca2ools [DEBUG]:Params: {'Action':
'CreateSecurityGroup', 'GroupName': 'shtest2', 'Version': '2009-11-30',
'GroupDescription': 'foo'}
2015-01-15 23:33:22,891 euca2ools [DEBUG]:establishing HTTP connection:
kwargs={'port': 8773, 'timeout': 70}
2015-01-15 23:33:22,891 euca2ools [DEBUG]:Token: None
2015-01-15 23:33:22,891 euca2ools [DEBUG]:CanonicalRequest:
POST
/services/Cloud/

host:192.168.0.4:8773
x-amz-date:20150115T233322Z

host;x-amz-date
a364b884b3e7216

[openstack-dev] [Fuel] backport CI fixes for fuel-ostf stable branches

[Aleksandra Fedorova]

Hi, everyone,

to unify our CI setup for fuel-ostf repository we need to backport
fixes for run_test.sh script to all stable branches.

Sebastian created corresponding reviews:

6.0 https://review.openstack.org/147510/
5.1 https://review.openstack.org/147511/
5.0 https://review.openstack.org/147525/
4.1 https://review.openstack.org/147530/

These backports don't affect anything but the test run making it real
test run and not the empty placeholder. And with these patches merged
we will be able to use the same Jenkins job [1] for all branches.

Let's just merge them.

[1] https://review.fuel-infra.org/#/c/2035/

-- 
Aleksandra Fedorova
Fuel Devops Engineer
bookwar

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

Re: [openstack-dev] [horizon] static files handling, bower/

[Michael Krotscheck]

>
> > I think Oracle's got enough money to support Node.js on SPARC.
>
> How is money relevant here?
>

Well, normally the argument I've received is "We don't have the
time/resources/insert-other-fiscally-motivated-reason to support/work on
node". Ergo, money. But then, given Oracle's conduct around the whole Java
ridiculousness I'm not exactly favorably disposed towards anything or
anyone associated with them. They'd get a lot more respect if they
open-sourced Solaris.

Which actually reminds me of something: Infra only tests against Debian,
CentOS, and Fedora. It does not test Solaris. So, no offense, but I don't
care about your SPARC servers.

... that Node.js is an issue because we can not use it.  Not because we
>
don't WANT to use it.  This is an important distinction that you seem to
> have missed.
>

I haven't missed it, I just made the assumption that if someone wants to
use a tool, they would be busy porting that tool rather than arguing on a
list about it.

Case and point: I wanted to use javascript in OpenStack Infra, so I did a
ton of legwork to bring node, npm, bower, karma, jasmine, protractor, and
grunt into the infra toolchain.

> So let me reframe this argument a bit: If you refuse to allow us
> > frontend developers to use node, npm, and bower, then I expect you to
> > reciprocate and no longer use the python executable or pip to write your
> > code, and you can only debug using wsgi. Since those fill equivalent
> > roles in our various languages-du-jour, it seems like a perfectly fair
> > exchange. Deal?
>
> I'm sorry, what?  Python is fully supported on Solaris (both x86 and
> SPARC).  This discussion has nothing whatsoever to do with the
> 'language-du-jour'.
>

It has everything to do with it: There are javascript engineers that want
to use their tools, just like there are python engineers that want to user
their tools. You're saying we can't use javascript tools because of SPARC's
lack of support. I'm merely asking that our python engineers reciprocate
and abandon your own tools out of solidarity. After all, we're all in this
together, right?

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] Running tox on Centos 6.5 with Python26

[Joe Gordon]

On Fri, Jan 16, 2015 at 12:13 PM, John Warren 
wrote:

>
> Can someone tell me or point me to documentation about what the required
> yum and pip packages are to be able to run tox for glance, keystone,
> neutron, cinder and nova on Centos 6.5 with Python 2.6?  I looked at the
> openstack-infra/puppet-jenkins project and thought I installed everything
> in the slave.pp manifest, which presumably is sufficient to be able to run
> tox for all openstack projects, but when I try to run tox on nova (tox
> --recreate -epy26) I just get an error that indicates that no test cases
> were found.
>

trunk OpenStack services (nova, neutron, keystone, cinder etc.)  no longer
support python 26

http://lists.openstack.org/pipermail/openstack-dev/2014-November/051551.html
https://review.openstack.org/#/c/128736/


>
> Any help would be greatly appreciated.
>
> John
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] About DVR limit

[joehuang]

Hi, Swami,

The use case for central south-north mode: 1) All compute nodes not connecting 
to external network directly 2) FIP/SNAT/VPN function  will be done centrally 
on hardware router.

New questions about “We were even initially planning to distribute the SNAT”

Do you mean: 1) Dynamic routing will be implemented before that, 2 ) Full 
distributed SNAT or only provide multi-SNAT network nodes

Best Regards
Chaoyi Huang ( Joe Huang )


From: Vasudevan, Swaminathan (PNB Roseville) 
[mailto:swaminathan.vasude...@hp.com]
Sent: Friday, January 16, 2015 12:56 AM
To: joehuang; 龚永生
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: Re:RE: [openstack-dev] About DVR limit

Hi Joehuang,
Thanks for your input and description of the problem.
What you are stating is just have DVR functionality for East-West traffic and 
all North-South traffic should go through the Centralized Router.
The North-South distributed reduces the burden in the Centralized Node. We 
eventually need to get away from the centralized node model.
I am not sure why there would be a use case to go back to the centralized model.

We were even initially planning to distribute the SNAT, but we just left it 
there centralized just to support the legacy services such as VPN.
Once we have service insertion and service chaining then we can distribute the 
SNAT functionality.

If you have a use case and willing to work on it and contribute code upstream, 
please let me know.

Thanks
Swami

From: joehuang [mailto:joehu...@huawei.com]
Sent: Wednesday, January 14, 2015 7:07 PM
To: 龚永生; Vasudevan, Swaminathan (PNB Roseville)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: Re:RE: [openstack-dev] About DVR limit

Hello,

Yongseng, correct, your description is much more concise, we need a 
configuration:

east-west, DVR
south-north, legacy mode.

Best Regards
Chaoyi Huang ( Joe Huang )

From: 龚永生 [mailto:gong.yongsh...@99cloud.net]
Sent: Thursday, January 15, 2015 10:18 AM
To: Vasudevan, Swaminathan (PNB Roseville)
Cc: joehuang; OpenStack Development Mailing List (not for usage questions)
Subject: Re:RE: [openstack-dev] About DVR limit


Hi, Swami, Joehuang,
in dvr compute nodes, it is 1:1 NAT FIP, means the floatingip for VM, and  it 
is in the namespace of qrouter-.
but in dvr_snat node, it is 1:N NAT IP, it is for neutron router, and for the 
VMs which have no 1:1 FIP, implemented in namesapce snat-xxx.

Joehuang's case can be implemented in legacy mode, I.E. non DVR,
but for the east-west traffic, we should consider the DVR, So I think there is 
a case:
east-west, DVR
south-north, legacy mode.


Thanks
yong sheng gong


在 2015-01-14 13:40:32，"Vasudevan, Swaminathan (PNB Roseville)" 
mailto:swaminathan.vasude...@hp.com>> 写道：
Hi Joehuang,
FIP today as of Juno can be both in centralized node (dvr_snat) and distributed 
“dvr” compute nodes.
Thanks
Swami

From: joehuang [mailto:joehu...@huawei.com]
Sent: Tuesday, January 13, 2015 7:49 PM
To: OpenStack Development Mailing List (not for usage questions); 龚永生
Cc: Vasudevan, Swaminathan (PNB Roseville)
Subject: RE: [openstack-dev] About DVR limit

Hi, Swami,

I would like to know whether the FIP under DVR could be configured to 
distributed mode or central mode in Kilo, not find relevant information from 
http://specs.openstack.org/openstack/neutron-specs/.

For example, it will be helpful for following FIP use cases: 1) FIP will be 
addressed centrally by dedicated hardware 2) not all compute nodes have public 
address.

Best Regards
Chaoyi Huang ( Joe Huang )

From: Stamina than Valued an [mailto:souminat...@yahoo.com]
Sent: Wednesday, January 14, 2015 11:05 AM
To: 龚永生
Cc: swaminathan.vasude...@hp.com; 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] About DVR limit

Hi yong Zheng,
Yes your understanding is right.
We only support ovs driver.
Regarding HA and multi network support, it will be available in kilo.

Public address consumption for north south traffic for compute node is also 
true. But to address this issue we do have a proposal that is worked out by the 
l3 sub team.

I hope this clarifies your doubts.

Please let me know if I can help you with anything else.

Thanks
Swami

Sent from my iPad

On Jan 13, 2015, at 6:01 PM, 龚永生 
mailto:gong.yongsh...@99cloud.net>> wrote:
Hi,
 I am yong sheng gong, I want to know if the DVR has these limits besides the 
documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:

1. one subnet can be connected to DVR router only once, which is confirmed by 
BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway
2. one network cannot have more than one subnet connecting to DVR routers


So the DVR limits the neutron model to:
one network has just one subnet, and one subnet cannot connect to more than one 
DVR routers.


ps.
req and limits documented

Re: [openstack-dev] [Glance] IRC logging

[Geoff O'Callaghan]

On 13/01/2015 3:45 AM, "Jeremy Stanley"  wrote:
>
> There's really no way to _force_ official logging on all
> project-related channels. People who are opposed to the idea simply
> move their conversations to new channels. They'll straddle the line
> between "somewhat official looking" and "official enough to require
> logging."

Yeah while this is true you can certainly work to achieve this goal and if
there are side conversations that aren't logged then so be it.

Irc logs can be a very valuable resource.

Thanks
Geoff
__
OpenStack Development Mailing 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] Resend: [nova] Request Spec Freeze Exception for Enhance iSCSI multipath/failover support

[Michael Still]

Done.

Cheers,
Michael

On Fri, Jan 16, 2015 at 11:37 AM, Tomoki Sekiyama
 wrote:
> Michael,
>
>
>
> These wasn't on the list of of exceptions at today's nova meeting. Please
> add them.
>
> On 1/8/15, 11:48 , "Tomoki Sekiyama"  wrote:
>>Hi,
>>
>>I have submitted 2 nova-specs [1][2] related to Cinder volumes iSCSI
>>multipath/failover improvement.
>>
>>These specs are both for enabling Cinder to pass multiple iSCSI paths to
>>Nova. [1] is for multipath use-case, where Nova will establish iSCSI
>>sessions to all the given paths. [2] is for failover use-case, where Nova
>>will try to establish alternative path when it fails to establish main
>>path.
>>
>>These specs were blocked to wait for corresponding cinder-specs approval
>>[3][4], which are now approved. Please consider these specs for spec
>>freeze exception.
>>
>>nova-specs:
>>[1] https://review.openstack.org/#/c/134299/
>>[2] https://review.openstack.org/#/c/137468/
>>
>>cinder-specs:
>>[3] https://review.openstack.org/#/c/136500/
>>[4] https://review.openstack.org/#/c/131502/
>
>
> Regards,
> Tomoki Sekiyama
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Rackspace Australia

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

Re: [openstack-dev] [neutron] Changes to the core team

[Armando M.]

+1

On 15 January 2015 at 14:46, Edgar Magana  wrote:

>  +1 For adding Doug as Core in Neutron!
>
>  I have seen his work on the services part and he is a great member of
> the OpenStack community!
>
>  Edgar
>
>   From: Kyle Mestery 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, January 15, 2015 at 2:31 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [neutron] Changes to the core team
>
>The last time we looked at core reviewer stats was in December [1]. In
> looking at the current stats, I'm going to propose some changes to the core
> team. Reviews are the most important part of being a core reviewer, so we
> need to ensure cores are doing reviews. The stats for the 90 day period [2]
> indicate some changes are needed for core reviewers who are no longer
> reviewing on pace with the other core reviewers.
>
>  First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
> been a core reviewer for a long time, and his past contributions are very
> much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
> with thoughtful reviews in the future, we can look at getting him back as a
> Neutron core reviewer. But for now, his stats indicate he's not reviewing
> at a level consistent with the rest of the Neutron core reviewers.
>
>  As part of the change, I'd like to propose Doug Wiegley as a new Neutron
> core reviewer. Doug has been actively reviewing code across not only all
> the Neutron projects, but also other projects such as infra. His help and
> work in the services split in December were the reason we were so
> successful in making that happen. Doug has also been instrumental in the
> Neutron LBaaS V2 rollout, as well as helping to merge code in the other
> neutron service repositories.
>
> I'd also like to take this time to remind everyone that reviewing code is
> a responsibility, in Neutron the same as other projects. And core reviewers
> are especially beholden to this responsibility. I'd also like to point out
> that +1/-1 reviews are very useful, and I encourage everyone to continue
> reviewing code even if you are not a core reviewer.
>
> Existing neutron cores, please vote +1/-1 for the addition of Doug to the
> core team.
>
> Thanks!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
> [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
>
> __
> OpenStack Development Mailing 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] [cinder] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014

[Mike Perez]

*Note: A more detailed email about this has been sent to all Cinder
volume driver maintainers directly.*

In the Jan 14th 2015 16:00 UTC Cinder IRC meeting [1], it was agreed
by Cinder core and participating vendors that the deadline for vendors
to have a third party CI would be:

March 19th 2015

There are requirements set for OpenStack Third Party CI's [2]. In
addition Cinder third party CI's must:

1) Test all volume drivers your company has integrated in Cinder.
2) Test all fabrics your solution uses.

For example, if your company has two volume drivers in Cinder and they
both use ISCSI and FibreChannel, you would need to have a CI that
tests against four backends and reports the results for each backend,
for every Cinder upstream patch. To test we're using a subset of tests
in Tempest [6].

To get started, read OpenStack's third party testing documentation
[32]. There are a variety of solutions [3] that help setting up a CI,
third party mentoring meetings [4], and designated people to answer
questions with setting up a third party CI in the #openstack-cinder
room [5].

If a solution is not being tested in a CI system and reporting to
OpenStack gerrit Cinder patches by the deadline of March 19th 2015, a
volume driver could be removed from the Cinder repository as of the
Kilo release. Without a CI system, Cinder core is unable to verify
your driver works in the Kilo release of Cinder. We will make sure
OpenStack users are aware of this via the OpenStack users mailing list
and Kilo release notes.

Cinder third party CI's have been discussed throughout a variety of
ways last year:

* Cinder IRC Meetings: [1][9][10][11][12][13][14][15][16]
* Midcycle meetups: [17]
* OpenStack dev list: [18][19][20][21][22][23][24][25][26][27][28][29]
* Design summit sessions: [30][31]

If there is something not clear about this email, please email me
*directly* with your question. You can also reach me as thingee on
Freenode IRC in the #openstack-cinder channel. Again I want you all to
be successful in this, and take advantage of this testing you will
have with your product. Please communicate with me and reach out to
the team for help.

--
Mike Perez

[1] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-21
[2] - http://ci.openstack.org/third_party.html#requirements
[3] - 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Existing_CI_Solutions
[4] - https://wiki.openstack.org/wiki/Meetings/ThirdParty
[5] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions
[6] - 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
[7] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-12-10-16.00.log.html#l-471
[8] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.log.html#l-34
[9] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html#l-224
[10] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-59
[11] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-08-16.00.log.html#l-17
[12] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-17-16.00.log.html#l-244
[13] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-02-16.01.log.html#l-141
[14] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-23-16.00.log.html#l-161
[15] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-06-18-16.02.log.html#l-255
[16] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-21-16.00.log.html#l-310
[17] - https://etherpad.openstack.org/p/cinder-meetup-summer-2014
[18] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045137.html
[19] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-October/047673.html
[20] - http://lists.openstack.org/pipermail/openstack-dev/2014-July/039103.html
[21] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-December/051957.html
[22] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-August/043392.html
[23] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-August/042672.html
[24] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-August/041748.html
[25] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026999.html
[26] - http://lists.openstack.org/pipermail/openstack-dev/2014-March/028707.html
[27] - http://lists.openstack.org/pipermail/openstack-dev/2014-July/039057.html
[28] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027527.html
[29] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-August/041704.html
[30] - 
https://etherpad.openstack.org/p/juno-cinder-3rd-party-cert-and-verification
[31] - http://junodesignsummit.sched.org/event/56eae44976e986f39c858d784344c7d0
[32] - http://ci.openstack.org/third_party.html

__
OpenStack

Re: [openstack-dev] [neutron] Changes to the core team

[Henry Gessau]

On Thu, Jan 15, 2015, Kyle Mestery  wrote:
> As part of the change, I'd like to propose Doug Wiegley as a new Neutron core
> reviewer. Doug has been actively reviewing code across not only all the
> Neutron projects, but also other projects such as infra. His help and work in
> the services split in December were the reason we were so successful in making
> that happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout,
> as well as helping to merge code in the other neutron service repositories.

+1 for 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

[openstack-dev] libvirt memory ballooning [nova]

[Vikash Kumar]

All,

   There is blueprint for enabling  libvirt memory ballooning
https://blueprints.launchpad.net/nova/+spec/libvirt-memory-ballooning in
openstack nova. I think for Hyper-V , its already in place. Can we discuss
about the design and implementation and target for L release?


Regards,
Vikash
__
OpenStack Development Mailing 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] How to debug test cases in Openstack

[Abhishek Talwar/HYD/TCS]

Hi,

I have been trying to debug the test cases in OpenStack, but I am not getting 
successful with it. So if someone can help me with that. The last response from 
the dev-list was to use " $ ./run_tests.sh -d [test module path] 
" but this gives bDb quit error.

So kindly help me this.
-- 
Thanks and Regards
Abhishek Talwar
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

[openstack-dev] [TEMPEST] Doubts regarding testing in OpenStack

[Abhishek Talwar/HYD/TCS]

Hi,

I am bit confused regarding the testing in OpenStack. The run_tests.sh script ( 
that is at the root of every component may it be nova,keystone etc ) , does it 
run only the unit tests covered under that component or it runs the test cases 
it tempest too (for ex scenario tests, api tests etc).

Please provide me some information regarding this. 


-- 
Thanks and Regards
Abhishek Talwar
Employee ID : 770072
Assistant System Engineer
Tata Consultancy Services,Gurgaon
India
Contact Details : +918377882003
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

[openstack-dev] [Fuel] [Scale] [UI] Improvements to handle 200+ nodes

[Vitaly Kramskikh]

Folks,

Currently Fuel UI can handle large amounts of nodes due to a recent
refactoring - rendering and operations with nodes became much faster. But
that large amount of nodes also requires UX improvement, I'd love to hear
your ideas and opinions on these proposals:

   1. Introduce compact node representation and let users switch between
   standart and compact view. Compact view will display only node name and
   status and will allow to display 4-8 nodes in a row instead of only one.
   2. Currently it is only possible to filter node by names. Filtering
   feature could be extended to allow filtering by other parameters: status,
   roles, manufacturer, RAM, disk space. There are 2 options (I'd like to hear
   which one you prefer):
  1. Form-based filter (beside a single input for name there will be
  controls for other parameters)
  2. Query language-based filter (like one used in Gerrit)
  3. Add ability to add arbitrary tags with values to nodes and also
   allow filtering by them.


-- 
Vitaly Kramskikh,
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] [Neutron][L3][Devstack] Bug during delete floating IPs?

[Kevin Benton]

We don't have asserts anywhere else. I don't think it makes sense to only
put a couple in.

On Sun, Jan 11, 2015 at 8:29 AM, Sunil Kumar  wrote:

>  Actually, I just noticed that a patch which has been pending review
> since Sep is not merged, and that actually fixes the root cause.
>
> https://review.openstack.org/#/c/119269/
>
> Having said that, I think the code can definitely use some touching. If
> router_ids is not supposed to be None, it should be asserted (enforcing a
> contract with the plugin APIs!) instead of letting python crib about it.
> Also, the code in plugins/ml2/plugin.py should not even be call
> l3plugin.notify_routers_updated if the router_ids set is empty. I think
> assert also belongs there.
>
> -Sunil
> --
> *From:* Salvatore Orlando [sorla...@nicira.com]
> *Sent:* Sunday, January 11, 2015 7:25 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][L3][Devstack] Bug during delete
> floating IPs?
>
>   I think Kevin is right - the actual root cause lies in plugins for
> which disassociate_floating_ips returns None rather than an (empty)
> iterable.
>
>  A quick check revealed that at least:
> neutron.plugins.embrane.base_plugin.EmbranePlugin
>
> neutron.plugions.cisco.service_plugins.cisco_router_plugin.CiscoRouterPlugin
>
>  can return None in some circumstances.
> I reckon the plugins should be fixed.
> While Sunil's patch fixes the issue it does not make a lot of sense since
> it call notify_routers_updated with None for routers_id.
> I agree with his intention of making the ml2 plugin more robust, but in my
> opinion when router_ids is None or empty the notification method should
> probably not be called at all.
>
>  Salvatore
>
> On 11 January 2015 at 12:02, Kevin Benton  wrote:
>
>> That only seems to bury the root cause because router_ids shouldn't be
>> none in this case with the reference L3 plugin.
>>
>>  The ML2 plugin calls disassociate_floatingips with do_notify set to
>> False so it should always be at least an empty set coming back.
>>
>>  Which L3 plugin were you using? Perhaps the implementation of
>> disassociate_floatingips was incorrect.
>>
>>  On Sat, Jan 10, 2015 at 11:42 PM, Sunil Kumar  wrote:
>>
>>>   This trivial patch fixes the tracebacks:
>>>
>>> $ cat disassociate_floating_ips.patch
>>> --- neutron/db/l3_db.py.orig2015-01-10 22:20:30.101506298 -0800
>>> +++ neutron/db/l3_db.py 2015-01-10 22:24:18.111479818 -0800
>>> @@ -1257,4 +1257,4 @@
>>>
>>>  def notify_routers_updated(self, context, router_ids):
>>>  super(L3_NAT_db_mixin, self).notify_routers_updated(
>>> -context, list(router_ids), 'disassociate_floatingips', {})
>>> +context, list(router_ids) if router_ids else None,
>>> 'disassociate_floatingips', {})
>>>
>>>
>>> -Sunil
>>> --
>>> *From:* Sunil Kumar [su...@embrane.com]
>>> *Sent:* Saturday, January 10, 2015 7:07 PM
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* [openstack-dev] [Neutron][L3][Devstack] Bug during delete
>>> floating IPs?
>>>
>>>Not sure if its something seen by others. I hit this when I run
>>> tempest.scenario.test_network_basic_ops.TestNetworkBasicOps against master:
>>>
>>> 2015-01-10 17:45:13.227 5350 DEBUG neutron.plugins.ml2.plugin
>>> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Deleting port
>>> e5deb014-0063-4d55-8ee3-5ba3524fee14 delete_port
>>> /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:995
>>> 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils
>>> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Created new semaphore
>>> "db-access" internal_lock
>>> /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:206
>>> 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils
>>> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Acquired semaphore "db-access"
>>> lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:229
>>> 2015-01-10 17:45:13.252 5350 DEBUG neutron.plugins.ml2.plugin
>>> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Calling delete_port for
>>> e5deb014-0063-4d55-8ee3-5ba3524fee14 owned by network:floatingip
>>> delete_port /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:1043
>>> 2015-01-10 17:45:13.254 5350 DEBUG neutron.openstack.common.lockutils
>>> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Releasing semaphore "db-access"
>>> lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:238
>>> 2015-01-10 17:45:13.282 5350 ERROR neutron.api.v2.resource
>>> [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] delete failed
>>> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource Traceback
>>> (most recent call last):
>>> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
>>> "/opt/stack/new/neutron/neutron/api/v2/resource.py", line 83, in resource
>>> 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource result =
>>

[openstack-dev] [Horizon] - Blueprint for Adding Version Information on the System Info Page

[Yamini Sardana]

Dear all,

I had raised a blueprint on Horizon for adding Version Information on the 
System Info Page. Its been a while and it is still in new state.

https://blueprints.launchpad.net/horizon/+spec/version-info-on-system-info-page

Please provide your thoughts on this and also if it can be implemented and 
targetted for kilo release.

Best Regards
Yamini Sardana
Tata Consultancy Services
Ground to 8th Floors, Building No. 1 & 2,
Skyview Corporate Park, Sector 74A,NH 8
Gurgaon - 122 004,Haryana
India
Ph:- +91 124 6213082
Mailto: yamini.sard...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

[openstack-dev] [nova][qa][pci] Intel PCI CI , testing method/env and test cases

[yongli he]

Hi, all

Intel PCI CI use  hardware machine to testing PCI,  there are some 
change to devstack, tempest

use Jerkins  dispatch task.

basic information:
* the topology:
log server <--->  Jenkins server <> node pool
* use devstack deploy testing env.

PCI CI 's  main problem is how to know pci information and how configure 
nova/tempest:
 1)  the test cases should know the  machine's  pci device 
information ( to checking the allocated pci does passed to vm)
 2)  how Jerkins  deliver these pci information  to 
nova/devstack/tempest


how Intel CI solve these problem:
  1)  Q:how the test cases know the allocated machine's  pci device 
information :
   A: each node might have different HW for PCI, different 
number of PCI devices so there is a configure file

   for each node storing the node's pci information.

   * test node local config file:
 pci.conf
pci_info=name:PCI_network_card,vendor_id:8086,product_id:1520,count:20; ...

   2) Q:  how Jekins  deliver pci information  to nova/devstack/tempest
A: Jekins  allocated a node for a pach set, then sent a 
scripts to :

*  configure the devstack
 then,  devstack configure the nova pci 
pci_passthrough_whitelist and alias
* exporting a env var storing the pci_info for tempest pci 
test cases ( this  need improve, of course)
  now the test case know everything to create  VM with PCI 
devices.


  What changed to devstack/tempest:
* devstack
   adding  "insert_pci"  to  devstack/functions-common
* tempest
adding linux utils to get pci device information from vm
adding routines to create pci flavor
https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/blob/master/pci_tempest_patch/0001-Add-Intel-PCI-functions.patch

* test cases
https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/tree/master/pci_testcases

What can be improvement and what is common( maybe into devstack/tempest)?
   * tempest use env variable  deliver information to tempest cases 
need improve, may be a config option
   * the pci information could be simplify by use interface name 
instead of  vendor_id/product_id

   * "init_pci" might be valuable to devstack
   * test cases:
   landing the test cases to nova function testing (pending):
 https://review.openstack.org/#/c/141270/
   trying put  some improved test case to tempest(rejected):
https://review.openstack.org/#/c/139000/

Regards
Yongli h...@intel.com

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

Re: [openstack-dev] [nova][ThirdPartyCI][PCI] Intel Third party Hardware based CI for PCI

[yongli he]

在 2015年01月13日 03:12, Kurt Taylor 写道:
The public link for your test logs should really be a host name 
instead of an IP address. That way if you have to change it again in 
the future, you won't have dead links in old comments. You may already 
know, but all of the requirements and recommendations are here: 
http://git.openstack.org/cgit/openstack-infra/system-config/tree/doc/source/third_party.rst

thanks very much, we does considering change to a dns name.

Yongli He


Kurt Taylor (krtaylor)

On Sun, Jan 11, 2015 at 11:18 PM, yongli he > wrote:


在 2015年01月08日 10:31, yongli he 写道:
to make a more stable service we upgrade the networking device, 
then the log server address change to a new

IP address:  198.175.100.33

so  the sample log change to(replace the 192.55.68.190 to new
address):


http://198.175.100.33/143614/6/
http://198.175.100.33/139900/4
http://198.175.100.33/143372/3/
http://198.175.100.33/141995/6/
http://198.175.100.33/137715/13/
http://198.175.100.33/133269/14/

Yongli He



Hi,

Intel  set up a Hardware based Third Part CI.   it's already 
running sets of PCI test cases

for several  weeks (do not sent out comments, just log the result)
the log server and these test cases seems fairly stable now.   to
begin given comments  to nova
repository,  what other necessary work need to be address?

Details:
1. ThirdPartySystems
 Information
https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-PCI-CI

2. a sample logs:


3. Test cases on github:

https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/tree/master/pci_testcases



Thanks
Yongli He




__
OpenStack Development Mailing 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] [neutron] Changes to the core team

[Salvatore Orlando]

I agree with the proposed changes.

I would also like to take a chance to thank Sumit for the effort he has put
in this project over several years - he has been in the core team since the
project's inception and has been a witness of all its developments - both
the good and the bad ones!

Salvatore

On 16 January 2015 at 04:38, Henry Gessau  wrote:

> On Thu, Jan 15, 2015, Kyle Mestery  wrote:
> > As part of the change, I'd like to propose Doug Wiegley as a new Neutron
> core
> > reviewer. Doug has been actively reviewing code across not only all the
> > Neutron projects, but also other projects such as infra. His help and
> work in
> > the services split in December were the reason we were so successful in
> making
> > that happen. Doug has also been instrumental in the Neutron LBaaS V2
> rollout,
> > as well as helping to merge code in the other neutron service
> repositories.
>
> +1 for 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
>
__
OpenStack Development Mailing 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] Doubts regarding testing in OpenStack

[Salvatore Orlando]

You are right.

run_tests.sh simply runs unit tests which cover tempest's code itself.

In order to run the tests for the various OpenStack services, use tox.
In tox.ini there are several environments defined which run different sets
of tests.
When all you want to do is run just a specific test module or test case, it
is possible to use the 'all' environment. For instance, to run only
scenarios I usually do:

tox -eall -- tempest.scenario

Hope this helps,
Salvatore


On 16 January 2015 at 05:48, Abhishek Talwar/HYD/TCS <
abhishek.tal...@tcs.com> wrote:

> Hi,
>
> I am bit confused regarding the testing in OpenStack. The run_tests.sh
> script ( that is at the root of every component may it be nova,keystone etc
> ) , does it run only the unit tests covered under that component or it runs
> the test cases it tempest too (for ex scenario tests, api tests etc).
>
> Please provide me some information regarding this.
>
>
> --
> Thanks and Regards
> Abhishek Talwar
> Employee ID : 770072
> Assistant System Engineer
> Tata Consultancy Services,Gurgaon
> India
> Contact Details : +918377882003
>
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev