Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

2015-06-20 Thread Anna Kamyshnikova 
Congratulations Rossella!

On Sat, Jun 20, 2015 at 1:50 AM, Kevin Benton  wrote:

> It's been a week with no negative feedback. Welcome to the team Rossella!
>
> On Mon, Jun 15, 2015 at 2:53 AM, Oleg Bondarev 
> wrote:
>
>> +1
>>
>> On Mon, Jun 15, 2015 at 12:14 PM, Ihar Hrachyshka 
>> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> No doubt +1.
>>>
>>> On 06/12/2015 09:44 PM, Kevin Benton wrote:
>>> > Hello!
>>> >
>>> > As the Lieutenant of the built-in control plane[1], I would like
>>> > Rossella Sblendido to be a member of the control plane core
>>> > reviewer team.
>>> >
>>> > Her review stats are in line with other cores[2] and her feedback
>>> > on patches related to the agents has been great. Additionally, she
>>> > has been working quite a bit on the blueprint to restructure the L2
>>> > agent code so she is very familiar with the agent code and the APIs
>>> > it leverages.
>>> >
>>> > Existing cores that have spent time working on the reference
>>> > implementation (agents and AMQP code), please vote +1/-1 for her
>>> > addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl
>>> > and Oleg; you have all been reviewing things in these areas
>>> > recently so I would like to hear from you specifically.
>>> >
>>> > 1.
>>> > http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht
>>> ml#core-review-hierarchy
>>> 
>>> >
>>> >
>>> 2. http://stackalytics.com/report/contribution/neutron-group/30
>>> >
>>> > Cheers -- 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
>>> >
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJVfpdmAAoJEC5aWaUY1u574skIAOm15mNKujH3X3XSpwtmy+V4
>>> cWNvjYZy0lCG2lbyAwGwgQD0Ybs88/RKOZPPpu9gugAuWcFQRHMSMcsahaTLcH5B
>>> 6imK0tEUUn2HdCd9522kEWtf7Hkpux6p5TLQQo2tucvIBQohJuU42EidfKs9Peat
>>> ed/2kiXm+TGRSnZHAYwzJIrttux3ntTLQeTvElo+4vUQEQJNwm8eguXiAPENEjr9
>>> 7Ou3TgnYeLXsfVopHXNV+jtkHDr92giB4joODqwc8RNDKE2+dhaqDxCrXq6ksYq7
>>> RFiyVy1qve394ebP0Ta0dq6LKmAYZCnRC9i928GSK5RvQBvcnJRiyFGIgtn4Qu0=
>>> =59av
>>> -END PGP SIGNATURE-
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Regards,
Ann Kamyshnikova
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] Debian already using Python 3.5: please gate on that

2015-06-20 Thread Doug Hellmann 
Excerpts from Robert Collins's message of 2015-06-20 16:22:51 +1200:
> On 19 June 2015 at 02:18, Ian Cordasco  wrote:
> >
> >
> > On 6/18/15, 08:44, "Thomas Goirand"  wrote:
> 
> > Does this mean that Debian is going to ignore classifiers for all projects
> > that list 3.4 without listing 3.5 and will start reporting bugs against
> > them before upstream projects have time to start testing against 3.5? Why
> > is Debian running tests against versions of python that upstream doesn't
> > claim to support?
> 
> I think this is taking a rather extreme interpretation of Thomas'
> email. Here's what I read:
> 
>  - Debian 9.0 is hoping to be 3.5 not 3.4
>  - The experimental staging area in Debian has 3.5 already and is
> starting to find out what packages are going to have issues
>  - Some of OpenStack does.
>  - Please introduce 3.5 as a supported Python as soon as we can.
> 
> Which is I think a reasonable request.

+1

> Whether we want to support 3.4 and 3.5, or just 3.4 and then just 3.5
> is an ecosystem question IMO, not an upstream one. 3.4 and 3.5 are
> very similar when you consider the feature set crossover with 2.7.

Right, and IIRC that's why we said at the summit that we would rather
not take the resources (in terms of people and CI servers) to run tests
against both, yet. Let's get one project fully working on one version of
python 3, and then we can start thinking about whether we need to
test multiple versions.

OTOH, if Canonical doesn't release a version of 3.4 that removes the
core dump bug soon, I will support moving fully to 3.5 or another test
platform, because that bug is causing us trouble in Oslo still.

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] Debian already using Python 3.5: please gate on that

2015-06-20 Thread Dave Walker 
On 20 Jun 2015 1:05 pm, "Doug Hellmann"  wrote:

>
> > Whether we want to support 3.4 and 3.5, or just 3.4 and then just 3.5
> > is an ecosystem question IMO, not an upstream one. 3.4 and 3.5 are
> > very similar when you consider the feature set crossover with 2.7.
>
> Right, and IIRC that's why we said at the summit that we would rather
> not take the resources (in terms of people and CI servers) to run tests
> against both, yet. Let's get one project fully working on one version of
> python 3, and then we can start thinking about whether we need to
> test multiple versions.

Having information available, even if there is not immediate intent to
support seems like something we should constantly be driving for.  It
should certainly be non-voting, but if resources are limited - perhaps a
periodic job, rather that gate?

> OTOH, if Canonical doesn't release a version of 3.4 that removes the
> core dump bug soon, I will support moving fully to 3.5 or another test
> platform, because that bug is causing us trouble in Oslo still.

s/Canonical/ubuntu

Can you link to the bug? I did a quick search, but couldn't find it quickly.

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

Re: [openstack-dev] Debian already using Python 3.5: please gate on that

2015-06-20 Thread Doug Hellmann 
Excerpts from Dave Walker's message of 2015-06-20 14:05:48 +0100:
> On 20 Jun 2015 1:05 pm, "Doug Hellmann"  wrote:
> 
> >
> > > Whether we want to support 3.4 and 3.5, or just 3.4 and then just 3.5
> > > is an ecosystem question IMO, not an upstream one. 3.4 and 3.5 are
> > > very similar when you consider the feature set crossover with 2.7.
> >
> > Right, and IIRC that's why we said at the summit that we would rather
> > not take the resources (in terms of people and CI servers) to run tests
> > against both, yet. Let's get one project fully working on one version of
> > python 3, and then we can start thinking about whether we need to
> > test multiple versions.
> 
> Having information available, even if there is not immediate intent to
> support seems like something we should constantly be driving for.  It
> should certainly be non-voting, but if resources are limited - perhaps a
> periodic job, rather that gate?
> 
> > OTOH, if Canonical doesn't release a version of 3.4 that removes the
> > core dump bug soon, I will support moving fully to 3.5 or another test
> > platform, because that bug is causing us trouble in Oslo still.
> 
> s/Canonical/ubuntu
> 
> Can you link to the bug? I did a quick search, but couldn't find it quickly.
> 

Hmm, https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907 is
marked as released but somehow it's still being triggered for
oslo.messaging.

Doug

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

Re: [openstack-dev] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).

2015-06-20 Thread Flavio Percoco 

On 19/06/15 13:43 -0700, Clint Byrum wrote:

Excerpts from Flavio Percoco's message of 2015-06-18 23:14:49 -0700:

[snip]

I'd like to clarify something about the AMQP 1.0 driver. It's not a
direct replacement for the qpidd one because it uses an entirely
different protocol that recently became a standard.



Could you clarify where the code actually is, or more specifically, why
the code doesn't follow the same organization as the others? There's no
"impl_amqp" and the tests don't live in tests/drivers, but in
tests/test_amqp_driver. I left it out because I didn't realize this new
driver lived in tree.


As Ken mentioned in a different email, the amqp driver was created as
a protocol specific driver rather than a "technology (as in software)"
based driver. Therefore, at the time, it was decided to put it in a
different package to separate it from others.

Now that you mentioned this, we could really move out of protocols and
rename the `amqp` package into `impl_amqp` but still keep it as a
package.

TBH, I prefer using packages to organize these drivers since some of
them (or all?) require more than one module to be implemented.



Anyway, this driver appears to land in the "prospective drivers" category
in the spec. We failed to call out drivers that are still considered
experimental, however I kind of feel like the driver should be out
of tree until such time as it is usable enough that it _could_ have an
integration test.

So, is it feasible that this driver will fall in-line with the others in
the next 6 months, or should we be looking at either revising the
policy, or moving it out of tree until it is capable of that?


Yes, I'm confident this will happen. It went from having a single gate
running funcitonal tests to running unittests in all gates but python3
(this will be solved in the next week or two) and the original
functional gate.

The team is working on adding an integrated gate for this driver as
well. If by the time the freeze is coming the driver is still not
running integrated tests, I'd agree on removing it.

As it stands right now, it is moving on the right direction.

[snip]



Can we use debtcollector to decorate the main driver class? A warning
will be printted every time an instance of such class is created
(rather than at import time).

If we don't want to add a dependency on that, we could just use a
DeprecationWarning as Doug mentioned.



From a user perspective, as long as it only warns once per invocation of
the consuming process (so it should warn when nova-conductor starts, not
when nova-conductor sends a message), then I think we should just use
DeprecationWarning's because they're relatively simple. Unless I'm
missing something magical that debtcollector does.


I don't think you're missing anything. I'm asking because this is what
debtcollator was created for.

--
@flaper87
Flavio Percoco


pgpo1NrEhDH8v.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] [oslo][messaging] Expanding the oslo.messaging core team

2015-06-20 Thread Flavio Percoco 

On 19/06/15 18:23 +0200, Mehdi Abaakouk wrote:

+1

Le 2015-06-19 14:54, Doug Hellmann a écrit :
Excerpts from Davanum Srinivas (dims)'s message of 2015-06-19 
07:46:47 -0400:

Hi Team,

We have had active and continuing contributions [1] from the following
in Blueprints, Reviews, Commits and Summit/Email discussions:
* Ken Giusti
* Oleksii Zamiatin
* Victor Sergeyev


+1 for all three



Ken and Oleksii are spearheading important drivers that will help
expand choices of messaging infrastructure in OpenStack to boot and
Victor is helping harden the existing code.

So can we please invite them to join the oslo.messaging core team

Thanks,
Dims

[1] http://stackalytics.com/?module=oslo.messaging



+1 for all three!

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

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


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


--
@flaper87
Flavio Percoco


pgpqJjf1I2EO1.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] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).

2015-06-20 Thread Flavio Percoco 

On 19/06/15 15:01 +, Ken Giusti wrote:



On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco  wrote:

   On 18/06/15 16:37 -0400, Doug Hellmann wrote:
   >Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700:
   >> Hello! I know there's been a lot of churn and misunderstanding over the
   >> recent devstack changes, so I wanted to make it clear where we're going
   >> with messaging drivers now that the policy [1] was approved.
   >>
   >> According to the policy, drivers need to have at least 60% unit test
   >> coverage, and an integration test suite with at least 3 "popular"
   >> OpenStack projects, with preference for Nova, Cinder, and Glance, and
   >> individuals who will support said test suite.
   >>
   >> So, with that, the following is the status of each driver in tree right
   >> now:
   >>
   >> rabbit - 89% Unit test coverage. Being the default in devstack, and
   >> the default in nearly every project's config files, this one is heavily
   >> integration tested. There are multiple individuals who have proven to
   >> be able to debug failures related to RabbitMQ and are well known in
   >> the community.
   >
   >+1
   >
   >>
   >> qpid - Unit test coverage is at 77%, so it passes that bar. I cannot
   >> find any integration testing being done, so it fails that. I also have
   >> not found anyone who will step up and support it. So this should be
   >> deprecated immediately.
   >
   >+1 - I believe Ken and the other folks interested in this indicated that
   >the AMQP 1.0 driver should replace this one.

   The qpid driver should be deprecated, I'll be doing so in the next
   couple of days. Look forward to the patch.


+1
 

   >
   >Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is
   >separate from the driver named "qpid").

   I'd like to clarify something about the AMQP 1.0 driver. It's not a
   direct replacement for the qpidd one because it uses an entirely
   different protocol that recently became a standard.

   The reason I mention this is because it doesn't really require qpidd -
   not the double d - which is the broker daemon in the qpid family. I
   guess the confusion comes because the library it sits on top off is
   called qpid-proton.

   The qpid family is a set of tools that provide messaging capabilities.
   Among those you find qpidd (broker daemon), qpid-proton (amqp1.0
   library), qpid-dispatch (message router). It's confusing indeed.

   The importance of this distinction is that the amqp1.0 driver in
   oslo.messaging is intended as a protocol based driver and not
   targetting any technology. That is to say, that it could be written
   using a library that is not qpid-proton and it can talk to any message
   router or message broker that has support for amqp 1.0.



+1 - yeah, we really shouldn't be considering the amqp1 driver as simply the
"replacement qpid driver" - as Flavio points out it has the potential to
provide compatibility with other messaging back ends.

Clint - can you also include separate metrics for the amqp1 driver? 



oslo_messaging/_drivers/protocols/amqp/controller 302 46 0 80 18 82%
oslo_messaging/_drivers/protocols/amqp/driver 134 13 0 28 6 88%
oslo_messaging/_drivers/protocols/amqp/drivertasks 52 5 0 8 2 85%
oslo_messaging/_drivers/protocols/amqp/eventloop 195 43 0 64 18 71%

Cheers,
Flavio



 

   The ones we're targetting for the gate are rabbitmq (with the amqp 1.0
   plugin enabled) and qpidd.

   Since we're at it, let me share some updates:

   The driver unittests now run on every python2 job and the work on
   python3 is almost done. There's also a functional tests gate like we
   have for other drivers.

   The missing bit is an integration gate, which we'll be start working
   on in the next couple of days.

   Hope the above helps clarifying confusions around this driver.

   >
   >>
   >> zmq - Unit test coverage is 74%. There are no currently active
   integration
   >> tests in OpenStack's infrastructure. Several individuals have self
   >> identified as being willing to work on creating them. We have not had
   >> the conversations yet about ongoing support. I recommend we continue to
   >> support their effort to become policy compliant. If that does not
   solidify
   >> by M3 of Liberty, or if the "new" zmq driver appears with integration
   >> tests and support manpower, then we can deprecate at that time.
   >
   >+1 - I know interest has been growing in this, so let's keep it going
   >and see where we end up.
   >
   >>
   >> There's also the question of _how_ to deprecate them. I figure we should
   >> deprecate when the driver is loaded. Is there an existing mechanism
   >> that someone can point me to, or should I look at adding that to
   >> oslo.messaging/stevedore?
   >
   >Normally we would recommend using versionutils from oslo.log, but we've
   >been trying to avoid making oslo.log a dependency of the oslo libs
   >because it uses some of them and that introduces cycles.

Re: [openstack-dev] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).

2015-06-20 Thread Flavio Percoco 

On 19/06/15 15:01 +, Ken Giusti wrote:



On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco  wrote:

   On 18/06/15 16:37 -0400, Doug Hellmann wrote:
   >Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700:
   >> Hello! I know there's been a lot of churn and misunderstanding over the
   >> recent devstack changes, so I wanted to make it clear where we're going
   >> with messaging drivers now that the policy [1] was approved.
   >>
   >> According to the policy, drivers need to have at least 60% unit test
   >> coverage, and an integration test suite with at least 3 "popular"
   >> OpenStack projects, with preference for Nova, Cinder, and Glance, and
   >> individuals who will support said test suite.
   >>
   >> So, with that, the following is the status of each driver in tree right
   >> now:
   >>
   >> rabbit - 89% Unit test coverage. Being the default in devstack, and
   >> the default in nearly every project's config files, this one is heavily
   >> integration tested. There are multiple individuals who have proven to
   >> be able to debug failures related to RabbitMQ and are well known in
   >> the community.
   >
   >+1
   >
   >>
   >> qpid - Unit test coverage is at 77%, so it passes that bar. I cannot
   >> find any integration testing being done, so it fails that. I also have
   >> not found anyone who will step up and support it. So this should be
   >> deprecated immediately.
   >
   >+1 - I believe Ken and the other folks interested in this indicated that
   >the AMQP 1.0 driver should replace this one.

   The qpid driver should be deprecated, I'll be doing so in the next
   couple of days. Look forward to the patch.


+1


As promissed: https://review.openstack.org/#/c/193804/

Cheers,
Flavio


 

   >
   >Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is
   >separate from the driver named "qpid").

   I'd like to clarify something about the AMQP 1.0 driver. It's not a
   direct replacement for the qpidd one because it uses an entirely
   different protocol that recently became a standard.

   The reason I mention this is because it doesn't really require qpidd -
   not the double d - which is the broker daemon in the qpid family. I
   guess the confusion comes because the library it sits on top off is
   called qpid-proton.

   The qpid family is a set of tools that provide messaging capabilities.
   Among those you find qpidd (broker daemon), qpid-proton (amqp1.0
   library), qpid-dispatch (message router). It's confusing indeed.

   The importance of this distinction is that the amqp1.0 driver in
   oslo.messaging is intended as a protocol based driver and not
   targetting any technology. That is to say, that it could be written
   using a library that is not qpid-proton and it can talk to any message
   router or message broker that has support for amqp 1.0.



+1 - yeah, we really shouldn't be considering the amqp1 driver as simply the
"replacement qpid driver" - as Flavio points out it has the potential to
provide compatibility with other messaging back ends.

Clint - can you also include separate metrics for the amqp1 driver? 


 

   The ones we're targetting for the gate are rabbitmq (with the amqp 1.0
   plugin enabled) and qpidd.

   Since we're at it, let me share some updates:

   The driver unittests now run on every python2 job and the work on
   python3 is almost done. There's also a functional tests gate like we
   have for other drivers.

   The missing bit is an integration gate, which we'll be start working
   on in the next couple of days.

   Hope the above helps clarifying confusions around this driver.

   >
   >>
   >> zmq - Unit test coverage is 74%. There are no currently active
   integration
   >> tests in OpenStack's infrastructure. Several individuals have self
   >> identified as being willing to work on creating them. We have not had
   >> the conversations yet about ongoing support. I recommend we continue to
   >> support their effort to become policy compliant. If that does not
   solidify
   >> by M3 of Liberty, or if the "new" zmq driver appears with integration
   >> tests and support manpower, then we can deprecate at that time.
   >
   >+1 - I know interest has been growing in this, so let's keep it going
   >and see where we end up.
   >
   >>
   >> There's also the question of _how_ to deprecate them. I figure we should
   >> deprecate when the driver is loaded. Is there an existing mechanism
   >> that someone can point me to, or should I look at adding that to
   >> oslo.messaging/stevedore?
   >
   >Normally we would recommend using versionutils from oslo.log, but we've
   >been trying to avoid making oslo.log a dependency of the oslo libs
   >because it uses some of them and that introduces cycles. Dims had a
   >patch recently that just used a DeprecationWarning, and relied on
   >oslo.log to redirect the warning to the log file. That seems like a good
   >pattern to repeat.

   Can we use debtcollector t

Re: [openstack-dev] [oslo.messaging][zeromq] Next step

2015-06-20 Thread Joshua Harlow 

Alec Hothan (ahothan) wrote:

Do we have a good understanding of what is expected of zmq wrt rabbitMQ?
Like in what part of the bell curve or use cases would you see it? Or
indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could
handle better?
I have tried to find any information on very large scale deployment of
OpenStack and could not get a firm number (in terms of number of compute
nodes).


Jump on #openstack-operators and ask around around, I can likely get you 
some *ballpark* numbers to but folks in that channel may be able to 
provide you some as well...



Does the OpenStack foundation keeps track of this information somewhere?

   Alec



On 6/19/15, 12:56 AM, "Thierry Carrez"  wrote:


Flavio Percoco wrote:

There's a 95% of deployments using rabbit not because rabbit is the
best solution for all OpenStack problems but because it was the one
that works best now. The lack of support on other drivers caused this
and as long this lack of support on such drivers persist, it won't
change.

There is 95% of deployments using rabbit because RabbitMQ serves the
middle of the Bell curve of the use cases perfectly well.

For OpenStack to be ubiquitous, we need to extend beyond our comfort
zone of use cases and support technology that will let us address those.
I see zmq has an enabler for that: it will solve other classes of
problems triggered by extreme use cases.

So yes, obviously RabbitMQ dominance should (and will naturally) drive
the development and maintenance efforts. But we should at least try to
not make the lives of those who explore new trails (and reach to new use
cases) miserable.

--
Thierry Carrez (ttx)




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


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

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

2015-06-20 Thread Miguel Lavalle 
Complimenti per il nuovo lavoro!

On Fri, Jun 19, 2015 at 5:50 PM, Kevin Benton  wrote:

> It's been a week with no negative feedback. Welcome to the team Rossella!
>
> On Mon, Jun 15, 2015 at 2:53 AM, Oleg Bondarev 
> wrote:
>
>> +1
>>
>> On Mon, Jun 15, 2015 at 12:14 PM, Ihar Hrachyshka 
>> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> No doubt +1.
>>>
>>> On 06/12/2015 09:44 PM, Kevin Benton wrote:
>>> > Hello!
>>> >
>>> > As the Lieutenant of the built-in control plane[1], I would like
>>> > Rossella Sblendido to be a member of the control plane core
>>> > reviewer team.
>>> >
>>> > Her review stats are in line with other cores[2] and her feedback
>>> > on patches related to the agents has been great. Additionally, she
>>> > has been working quite a bit on the blueprint to restructure the L2
>>> > agent code so she is very familiar with the agent code and the APIs
>>> > it leverages.
>>> >
>>> > Existing cores that have spent time working on the reference
>>> > implementation (agents and AMQP code), please vote +1/-1 for her
>>> > addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl
>>> > and Oleg; you have all been reviewing things in these areas
>>> > recently so I would like to hear from you specifically.
>>> >
>>> > 1.
>>> > http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht
>>> ml#core-review-hierarchy
>>> 
>>> >
>>> >
>>> 2. http://stackalytics.com/report/contribution/neutron-group/30
>>> >
>>> > Cheers -- 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
>>> >
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJVfpdmAAoJEC5aWaUY1u574skIAOm15mNKujH3X3XSpwtmy+V4
>>> cWNvjYZy0lCG2lbyAwGwgQD0Ybs88/RKOZPPpu9gugAuWcFQRHMSMcsahaTLcH5B
>>> 6imK0tEUUn2HdCd9522kEWtf7Hkpux6p5TLQQo2tucvIBQohJuU42EidfKs9Peat
>>> ed/2kiXm+TGRSnZHAYwzJIrttux3ntTLQeTvElo+4vUQEQJNwm8eguXiAPENEjr9
>>> 7Ou3TgnYeLXsfVopHXNV+jtkHDr92giB4joODqwc8RNDKE2+dhaqDxCrXq6ksYq7
>>> RFiyVy1qve394ebP0Ta0dq6LKmAYZCnRC9i928GSK5RvQBvcnJRiyFGIgtn4Qu0=
>>> =59av
>>> -END PGP SIGNATURE-
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing 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
>
>
__
OpenStack Development Mailing 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][keystone] Nova calls to Keystone

2015-06-20 Thread Sajeesh Cimson Sasi 
Hi All,
   I need your advice for the implementation of the following blueprint. 
https://review.openstack.org/#/c/160605 .
   All the use cases mentioned in the blueprint have  been implemented and the 
complete code is up for review.
  https://review.openstack.org/#/c/149828/
  However, we have an issue on which we need your input. In the nova quota api 
call, keystone calls are made to
  get the parent_id and the child project or sub project list. This is required 
because nova doesn't store any information
  regarding the hierarchy. Hierarchy Information is  taken during run time,  
from keystone. Since the keystone calls are
  made inside the api call, it is not possible to give any dummy or  fake 
values while writing the unit tests. If the keystone
  call was made outside the api call, we could have given fake values in the 
test cases. However,  the keystone calls for
   parent_id and child projects are made inside the api call.
  Can anyone suggest an elegant solution to this problem? What is the proper 
way to implement this ?
Did anybody encounter and solve a  similar  problem ? Many thanks for any 
suggestions!
 best regards
   sajeesh
__
OpenStack Development Mailing 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][ceilometer] proposal to send bulk hypervisor stats data in periodic notifications

2015-06-20 Thread Matt Riedemann 



On 6/17/2015 10:52 AM, Matt Riedemann wrote:

Without getting into the details from the etherpad [1], a few of us in
IRC today were talking about how the ceilometer compute-agent polls
libvirt directly for guest VM statistics and how ceilometer should
really be getting this information from nova via notifications sent from
a periodic task in the nova compute manager.

Nova already has the get_instance_diagnostics virt driver API which is
nice in that it has structured versioned instance diagnostic information
regardless of virt driver (unlike the v2 os-server-diagnostics API which
is a free-form bag of goodies depending on which virt driver is used,
which makes it mostly untestable and not portable).  The problem is the
get_instance_diagnostics virt driver API is per-instance, so it's not
efficient in the case that you want bulk instance data for a given
compute host.

So the idea is to add a new virt driver API to get the bulk data and
emit that via a structured versioned payload similar to
get_instance_diagnostics but for all instances.

Eventually the goal is for nova to send what ceilometer is collecting
today [2] and then ceilometer can just consume that notification rather
than doing the direct hypervisor polling it has today.

Anyway, this is the high level idea, the details/notes are in the
etherpad along with next steps.

Feel free to chime in now with reasons why this is crazy and will never
work and we shouldn't waste our time on it.

[1] https://etherpad.openstack.org/p/nova-hypervisor-bulk-stats-notify
[2]
http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-compute-meters.html




Waking up from a rare nap opportunity on a Saturday, this is what was 
bothering me:


The proposal in the etherpad assumes that we are just getting bulk 
host/domain/guest VM stats from the hypervisor and sending those in a 
notification, but how do we go about filtering those out to only 
instances that were booted through Nova?


Jason pointed out the ceilometer code gets all of the non-error state 
instances from nova first [1] and then for each of those it does the 
domain lookup from libvirt, filtering out any that are in SHUTOFF state [2].


When talking about the new virt driver API for bulk stats, danpb said to 
use virConnectGetAllDomainStats with libvirt [3] but I'm not aware of 
that being able to filter out instances that weren't created by nova.  I 
don't think we want a notification from nova about the hypervisor stats 
to include things that were created outside nova, like directly through 
virsh or vCenter.


For at least libvirt, if virConnectGetAllDomainStats returns the domain 
metadata then we can filter those since there is nova-specific metadata 
in the domains created through nova [4] but I'm not sure that's true 
about the other virt types in nova (I think the vCenter driver tags VMs 
somehow as being created by OpenStack/Nova, but not sure about 
xen/hyper-v/ironic).


I guess adding support for something like bulk guest VM stats in a nova 
virt driver would have a pre-requisite of being able to uniquely 
identify guest VMs from the hypervisor as being created by nova.


Otherwise we'd just basically be moving the same thing that ceilometer 
is doing today into nova, as a per-instance loop and then using the 
os-server-diagnostics virt driver calls from the compute manager (at 
least saving us a compute API call from ceilometer every 10 minutes).


Thoughts?

[1] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/discovery.py#L35
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L111
[3] 
http://libvirt.org/html/libvirt-libvirt-domain.html#virConnectGetAllDomainStats

[4] http://paste.openstack.org/show/308305/

--

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][ceilometer] proposal to send bulk hypervisor stats data in periodic notifications

2015-06-20 Thread Daniel P. Berrange 
On Sat, Jun 20, 2015 at 01:50:53PM -0500, Matt Riedemann wrote:
> Waking up from a rare nap opportunity on a Saturday, this is what was
> bothering me:
> 
> The proposal in the etherpad assumes that we are just getting bulk
> host/domain/guest VM stats from the hypervisor and sending those in a
> notification, but how do we go about filtering those out to only instances
> that were booted through Nova?

In general I would say that is an unsupported deployment scenario to
have other random virt guests running on a nova compute node.

Having said that, when nova uses libguestfs, it will create some temp
guests via libvirt, so we do have to consider that possibility.

Even today with the general list domains virt driver call, we could be
getting domains that weren't launched by Nova I believe.

> Jason pointed out the ceilometer code gets all of the non-error state
> instances from nova first [1] and then for each of those it does the domain
> lookup from libvirt, filtering out any that are in SHUTOFF state [2].
> 
> When talking about the new virt driver API for bulk stats, danpb said to use
> virConnectGetAllDomainStats with libvirt [3] but I'm not aware of that being
> able to filter out instances that weren't created by nova.  I don't think we
> want a notification from nova about the hypervisor stats to include things
> that were created outside nova, like directly through virsh or vCenter.
> 
> For at least libvirt, if virConnectGetAllDomainStats returns the domain
> metadata then we can filter those since there is nova-specific metadata in
> the domains created through nova [4] but I'm not sure that's true about the
> other virt types in nova (I think the vCenter driver tags VMs somehow as
> being created by OpenStack/Nova, but not sure about xen/hyper-v/ironic).

The nova database hsa a list of domains that it owns, so if you query the
database for a list of valid UUIDs for the host, you can use that to filter
the domains that libvirt reports by comparing UUIDs.

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

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

Re: [openstack-dev] [kolla][magnum] Medical semi-emergency with my tooth

2015-06-20 Thread Adrian Otto 
Steve,

Although I am on the road this week, I may be able to attend the Magnum team 
meeting Tuesday if you do not feel up to it. I will check in with you on Monday 
and see how you are doing. Get well soon!

Adrian



Sent from my Verizon Wireless 4G LTE smartphone


 Original message 
From: "Steven Dake (stdake)" 
Date: 06/19/2015 10:11 PM (GMT-07:00)
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla][magnum] Medical semi-emergency with my tooth

Hey Kolla cats (and Magnum cats),

I have a tooth infection, which isn’t super serious, but the pain levels are 
about a 8 out of 10 on the holy fuck scale.  As a result, my work is a bit 
impaired.  I may be a bit MIA in the next week while I sort out the medical 
problem and get my tooth into a manageable state of pain.  Please keep working 
towards getting the blueprints for liberty 1 in a completed state, fixing 
confirmed bugs, and confirming triaged bugs.

Making matters worse for me personally, because our government is a bunch of 
baby-sitter fail, my Dentist can only call in AC3 over the phone and he is in a 
different state presently.  He said what I really need is oxycodone.  He did 
give me a zpac which may reduce the pain levels by getting rid of the root 
infection.

Anyway, our community is self sufficient so this is more to inform people  the 
Kolla PTL could be MIA over the next week.  If I need someone to handle the 
wendesday meeting I’ll reach out to someone via irc.

Regards
-steve

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

Re: [openstack-dev] Debian already using Python 3.5: please gate on that

2015-06-20 Thread Mark Kirkwood 

On 21/06/15 01:32, Doug Hellmann wrote:

Excerpts from Dave Walker's message of 2015-06-20 14:05:48 +0100:

On 20 Jun 2015 1:05 pm, "Doug Hellmann"  wrote:




Whether we want to support 3.4 and 3.5, or just 3.4 and then just 3.5
is an ecosystem question IMO, not an upstream one. 3.4 and 3.5 are
very similar when you consider the feature set crossover with 2.7.


Right, and IIRC that's why we said at the summit that we would rather
not take the resources (in terms of people and CI servers) to run tests
against both, yet. Let's get one project fully working on one version of
python 3, and then we can start thinking about whether we need to
test multiple versions.


Having information available, even if there is not immediate intent to
support seems like something we should constantly be driving for.  It
should certainly be non-voting, but if resources are limited - perhaps a
periodic job, rather that gate?


OTOH, if Canonical doesn't release a version of 3.4 that removes the
core dump bug soon, I will support moving fully to 3.5 or another test
platform, because that bug is causing us trouble in Oslo still.


s/Canonical/ubuntu

Can you link to the bug? I did a quick search, but couldn't find it quickly.



Hmm, https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907 is
marked as released but somehow it's still being triggered for
oslo.messaging.



FWIW http://packages.ubuntu.com/search?keywords=python3.4 suggests that 
Trusty is still using python 3.4.0, and you don't get 3.4.3 until Vivid, 
which is a bit sad - definitely worth quizzing the Ubuntu folks about 
what the plan is there.


Regards

Mark


__
OpenStack Development Mailing 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] Proposing Rossella Sblendido for the Control Plane core team

2015-06-20 Thread Paul Michali 
Congratulations Rossella! Great addition to the team!
On Sat, Jun 20, 2015 at 12:13 PM Miguel Lavalle  wrote:

> Complimenti per il nuovo lavoro!
>
> On Fri, Jun 19, 2015 at 5:50 PM, Kevin Benton  wrote:
>
>> It's been a week with no negative feedback. Welcome to the team Rossella!
>>
>> On Mon, Jun 15, 2015 at 2:53 AM, Oleg Bondarev 
>> wrote:
>>
>>> +1
>>>
>>> On Mon, Jun 15, 2015 at 12:14 PM, Ihar Hrachyshka 
>>> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 No doubt +1.

 On 06/12/2015 09:44 PM, Kevin Benton wrote:
 > Hello!
 >
 > As the Lieutenant of the built-in control plane[1], I would like
 > Rossella Sblendido to be a member of the control plane core
 > reviewer team.
 >
 > Her review stats are in line with other cores[2] and her feedback
 > on patches related to the agents has been great. Additionally, she
 > has been working quite a bit on the blueprint to restructure the L2
 > agent code so she is very familiar with the agent code and the APIs
 > it leverages.
 >
 > Existing cores that have spent time working on the reference
 > implementation (agents and AMQP code), please vote +1/-1 for her
 > addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl
 > and Oleg; you have all been reviewing things in these areas
 > recently so I would like to hear from you specifically.
 >
 > 1.
 >
 http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht
 ml#core-review-hierarchy
 
 >
 >
 2. http://stackalytics.com/report/contribution/neutron-group/30
 >
 > Cheers -- 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
 >
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVfpdmAAoJEC5aWaUY1u574skIAOm15mNKujH3X3XSpwtmy+V4
 cWNvjYZy0lCG2lbyAwGwgQD0Ybs88/RKOZPPpu9gugAuWcFQRHMSMcsahaTLcH5B
 6imK0tEUUn2HdCd9522kEWtf7Hkpux6p5TLQQo2tucvIBQohJuU42EidfKs9Peat
 ed/2kiXm+TGRSnZHAYwzJIrttux3ntTLQeTvElo+4vUQEQJNwm8eguXiAPENEjr9
 7Ou3TgnYeLXsfVopHXNV+jtkHDr92giB4joODqwc8RNDKE2+dhaqDxCrXq6ksYq7
 RFiyVy1qve394ebP0Ta0dq6LKmAYZCnRC9i928GSK5RvQBvcnJRiyFGIgtn4Qu0=
 =59av
 -END PGP SIGNATURE-


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

>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
>>
> __
> OpenStack Development Mailing 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] Question regarding openstack heat

2015-06-20 Thread Swaroop Jayanthi 
Hi All,

I am understanding HEAT architecture, I have few basic questions in this
regard.

1) Who provides the templates to Cloud Admin?

2) Template will be defined by the customer or end user?

3) How will be the overall flow of template request by end user happens?


Can you please let me know your thoughts...
-- 
Thanks and Regards,

--Swaroop Jayanthi
__
OpenStack Development Mailing 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] Question regarding openstack heat

2015-06-20 Thread Nandavar, Divakar Padiyar 
You need to use https://ask.openstack.org/en/questions/ to post such queries

Thanks
Divakar

On 21 Jun 2015 12:11, Swaroop Jayanthi  wrote:
Hi All,

I am understanding HEAT architecture, I have few basic questions in this regard.

1) Who provides the templates to Cloud Admin?

2) Template will be defined by the customer or end user?

3) How will be the overall flow of template request by end user happens?


Can you please let me know your thoughts...
--
Thanks and Regards,

--Swaroop Jayanthi

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