Re: [openstack-dev] [Global Requirements] Adding apscheduler to global requirements

[BORTMAN, Limor (Limor)]

Hi all
can anybody please take a look on my PR[1]?

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

Thanks Limor

-Original Message-
From: BORTMAN, Limor (Limor) [mailto:limor.bort...@alcatel-lucent.com] 
Sent: Wednesday, June 03, 2015 2:28 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Global Requirements] Adding apscheduler to global 
requirements

From: Renat Akhmerov 
Subject: Re: [openstack-dev] [Global Requirements] Adding apscheduler to global 
requirements
Date: 3 Jun 2015 16:48:08 GMT+6
To: "OpenStack Development Mailing List (not for usage questions)" 


Thanks Doug, got it.

>Limor, can you please explain why exactly do you need this library?
This is the only "live" library I found that enable creating scheduled job in 
seconds granularity.
I am planning on using : BackgroundScheduler 
(apscheduler.schedulers.background).
Doug, Does Oslo have this ability?

Renat Akhmerov
@ Mirantis Inc.



On 02 Jun 2015, at 18:45, Doug Hellmann  wrote:

Excerpts from Renat Akhmerov's message of 2015-06-02 18:26:40 +0600:

Any comments from TC on that? What is the typical procedure of accepting new 
libs into global requirements?

There is a requirements management team, and usually we would want a patch to 
the list in openstack/requirements, with some description of the need for the 
package, especially which projects are going to use it and why no existing 
package with similar functionality is suitable. There are more details about 
the evaluation criteria in 
http://git.openstack.org/cgit/openstack/requirements/tree/README.rst

Doug



Thanks

Renat Akhmerov
@ Mirantis Inc.


On 02 Jun 2015, at 18:11, BORTMAN, Limor (Limor) 
 wrote:

Hi all,
As part as a BP in mistral (Add seconds granularity in cron-trigger execute[1]) 
I would like to add apscheduler (Advanced Python Scheduler[2]) to the openstack 
Global Requirements.

Any objections?

[1] 
https://blueprints.launchpad.net/mistral/+spec/cron-trigger-seconds-granularity
[2] https://apscheduler.readthedocs.org/en/latest/


Thanks Stotland Limor 

__
OpenStack Development Mailing 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-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

[Thomas Goirand]

Hi,

The current maintainer of suds in Debian sent bug reports against all
packages depending on it. We would like to get rid of suds completely.

See:

https://bugs.debian.org/788080
https://bugs.debian.org/788081
https://bugs.debian.org/788083
https://bugs.debian.org/788085
https://bugs.debian.org/788088

Affected projects are: cinder, nova, trove, ironic, and finally oslo.vmware.

So, are we moving to suds-jurko? Or anything else?

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [oslo] Adopt mox3

[Jordan Pittier]

Hi,
Shouldn't we move to use mock instead ? If mox3 is supported and active,
why would we recommend to use mock ?

Jordan

On Wed, Jun 10, 2015 at 10:17 PM, Davanum Srinivas 
wrote:

> Oslo folks, everyone,
>
> mox3 needs to be maintained since some of our projects use it and we
> have it in our global requirements.
>
> Here's the proposal from Doug - https://review.openstack.org/#/c/190330/
>
> Any objections? Please chime in here or on the review.
>
> thanks,
> dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Abandoning old specs for Nova

[Michael Still]

I've just done another run of abandons as a pre-cursor to the spec
review day this Friday. I'd suggest if you have a spec which has been
sitting with unresolved review comments for a fair while taking a look
at those before Friday would be a good idea.

Cheers,
Michael

On Fri, May 22, 2015 at 3:10 AM, Michael Still  wrote:
> I just did an abandon run for specs that meet this criteria and
> haven't been touched since March. Once again, this isn't a kiss of
> death, just an attempt at review backlog hygiene.
>
> Cheers,
> Michael
>
> On Tue, May 5, 2015 at 1:26 AM, John Garbutt  wrote:
>> On Monday, May 4, 2015, Michael Still  wrote:
>>>
>>> Hi,
>>>
>>> I just wanted to let people know that I am going through abandoning
>>> old specs for Nova at the moment. The criteria I am using is:
>>>
>>>  - spec targets kilo
>>>  - no review comments or other activity since January or February
>>>
>>> I think its worth reinforcing that an abandon isn't a -2... An upload
>>> of a new version of the spec will re-open reviews on it. Here's the
>>> message I've been using while abandoning:
>>>
>>> "Please update this spec for Liberty if you're still interested in
>>> pursuing it."
>>>
>>
>> Thanks, I already did the ones not touched this year. Makes sense to take
>> that a bit further.
>>
>> We should probably automate this to get parity with code patches, or
>> something similar at least?
>>
>> Thanks,
>> John
>>
>>>
>>> --
>>> 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 Development Mailing 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



-- 
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] [Openstack-operators] [ops][tags][packaging] ops:packaging tag - a little common sense, please

[Thierry Carrez]

Jay Pipes wrote:
> [...]
> = Packaging tags should be release-specific, or they will be wrong =
> 
> For these packaging tags, the release must be part of the tag itself,
> otherwise the information it denotes would be indeterminate.
> 
> As an example, suppose you have a tag that looks like this:
> 
>  ops:packaged:centos:good
> 
> And in the tag definition you say that the tag is applied to projects
> that have CentOS RPM packages available "within the last 6 months".
> Well, as you all know, packages are published for a *particular release
> of OpenStack*. So, if Nova is tagged with ops:packaged:centos:good in,
> say, August 2015, the tag would ostensibly be saying that packages exist
> for Nova in Kilo. However, once November rolls around, and packages for
> Liberty don't (yet) exist, are you going to remove this
> "ops:packaged:centos:good" tag from Nova or (worse) change it to
> "ops:pacakged:centos:no"?
> 
> Instead, have the tag be specific to a release of OpenStack:
> 
> packaged:centos:kilo

There is a provision in the tag framework for (secondary) attributes. So
far we only used it to track the "since when" information on the
"integrated-release" legacy tag.

If packaging basically carries over, the only interesting bit of
information is "what is the first release cycle the packaging appeared
in", so you could actually have:

- repo: openstack/nova
  tags:
- name: packaged:centos
  since: diablo

I think it's easier and simpler to maintain.

-- 
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] Getting rid of suds, which is unmaintained, and which we want out of Debian

[Duncan Thomas]

There's only one cinder driver using it (nimble storage), and it seems to
be using only very basic features. There are half a dozen suds forks on
pipi, or there's pisimplesoap that the debian maintainer recommends. None
of the above are currently packaged for Ubuntu that I can see, so can
anybody in-the-know make a reaasoned recommendation as to what to move to?

On 11 June 2015 at 10:26, Thomas Goirand  wrote:

> Hi,
>
> The current maintainer of suds in Debian sent bug reports against all
> packages depending on it. We would like to get rid of suds completely.
>
> See:
>
> https://bugs.debian.org/788080
> https://bugs.debian.org/788081
> https://bugs.debian.org/788083
> https://bugs.debian.org/788085
> https://bugs.debian.org/788088
>
> Affected projects are: cinder, nova, trove, ironic, and finally
> oslo.vmware.
>
> So, are we moving to suds-jurko? Or anything else?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [oslo] Adopt mox3

[Victor Stinner]

Hi,

Le 10/06/2015 22:17, Davanum Srinivas a écrit :

Oslo folks, everyone,

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

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


Why not only creating a project on Github? Do we need all OpenStack 
tools for mox3? I don't expect much enhancements in the library. For me, 
OpenStack looks more restrictive than a classic Github project, it's 
more heavy to contribute (sign a CLA, use review.openstack.org, etc.).


I prefer mock over mox, the API is very different. mock is now part of 
Python stdlib (unittest.mock since Python 3.3). In the past, I ported 
some mox tests to mock, but it takes a lot of time :-(


https://docs.python.org/dev/library/unittest.mock.html

Did anyone try to contact original mox authors? smiddlek is the last 
active contributor.


I see changes in 2012 in the Subversion repository of mox, whereas the 
latest mox release was in 2010 (mox 0.5.3).


It would be nice to merge back enhancements of mox3 (Python 3 support) 
into mox. It's annoying to have a specific project to get Python 3 support.


mox is hosted on code.google.com which is closing!

Victor

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

Re: [openstack-dev] [nova] vif type libvirt-network

[Daniel P. Berrange]

On Wed, Jun 10, 2015 at 04:47:41PM +0200, Andreas Scheuring wrote:
> Hi Daniel, Neil and others, 
> 
> I was thinking about introducing libvirt-network as a new vif type to
> nova. It can be used when Neutron prepares a libvirt network for
> attaching guests.
> 
> Would you see any general concerns with such an approach? Anything that
> I need to consider with libvirt networks in addition? Maybe I should
> mention one thing due to the discussion this morning: No plug/unplug
> behavior would required.
> 
> Any feedback is welcome!
> 
> 
> I added a blueprint and wrote a spec with more details [1]. This
> blueprint would make the macvtap-vif blueprint [2] dispensable.

It seems the main reason for your new proposal is to deal with
the fact that on migration, you need to specify a different
NIC name in the XML. This is not particularly difficult - Nova
already has code for dealing with pdating the XML - the _update_xml
method in nova.virt.libvirt.driver just needs extending to cover
that.

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

Who / what will actally be talking to libvirt to create/update the
network XML setup. Will that be part of the vif driver too.

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] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

[Xu, Hejie]

Salvatore, thanks for the info, will try to review as soon as possible. Hope we 
get consistent implementation.

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Wednesday, June 10, 2015 4:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion 
guideline in API-WG

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

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

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

Salvatore

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

On 10 June 2015 at 06:28, Xu, Hejie 
mailto:hejie...@intel.com>> wrote:
I updated the Microversion specification in API-WG 
https://review.openstack.org/187112

The new patchset adds min/max version headers as Ironic used:
X-Openstack-[PROJECT]-API-Minimum-Version
X-Openstack-[PROJECT]-API-Maximum-Version

And new response body for invalid version request.

  {
"versionFault": {
  "max_version": "5.2",
  "min_version": "2.1",
  "description": "Version 5.3 is not supported by the API. \
  Minimum is 2.1 and maximum is 5.2."
}
  }

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

  {
"versionFault": {
  "max_version": "5.2",
  "min_version": "2.1",
  "description": "Version 5.3 is not supported by the API. \
  Minimum is 2.1 and maximum is 5.2."
},
"computeFault": {
  "message": "Version 5.3 is not supported by the API. \
  Minimum is 2.1 and maximum is 5.2.",
  "code": 406
}
  }

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

And the “experimental” flag in the X-OpenStack-Nova-API-Version header was 
deleted. It mentioned in the nova-spec but
It didn’t implement. And I didn’t saw the same thing in the ironic. For current 
all the things satisfied all the cases. If we
“experimental” flag still usefull, we can propose separately.

Thanks
Alex

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



On Jun 5, 2015 4:36 AM, "Sean Dague" mailto:s...@dague.net>> 
wrote:
>
> On 06/05/2015 01:28 AM, Adrian Otto wrote:
> >
> >> On Jun 4, 2015, at 11:03 AM, Devananda van der Veen
> >> mailto:devananda@gmail.com> 
> >> >> wrote:
> >>
> >>
> >> On Jun 4, 2015 12:00 AM, "Xu, Hejie" 
> >> mailto:hejie...@intel.com>
> >> >> wrote:
> >> >
> >> > Hi, guys,
> >> >
> >> > I’m working on adding Microversion into the API-WG’s guideline which
> >> make sure we have consistent Microversion behavior in the API for user.
> >> > The Nova and Ironic already have Microversion implementation, and as
> >> I know Magnum https://review.openstack.org/#/c/184975/ is going to
> >> implement Microversion also.
> >> >
> >> > Hope all the projects which support( or plan to) Microversion can
> >> join the review of guideline.
> >> >
> >> > The Mircoversion specification(this almost copy from nova-specs):
> >> https://review.openstack.org/#/c/187112
> >> > And another guideline for when we should bump Mircoversion
> >> https://review.openstack.org/#/c/187896/
> >> >
> >> > As I know, there already have a little different between Nova and
> >> Ironic’s implementation. Ironic return min/max version when the requested
> >> > version doesn’t support in server by http-headers. There isn’t such
> >> thing in nova. But that is something for version negotiation we need
> >> for nova also.
> >> > Sean have pointed out we should use response body instead of http
> >> headers, the body can includes error message. Really hope ironic team
> >> can take a
> >> > look at if you guys have compelling reason for using http headers.
> >> >
> >> > And if we think return body instead of http headers, we probably
> >> need think about back-compatible also. Because Microversion itself
> >> isn’t versioned.
> >> > So I think we should keep those header for a while, does make sense?
> >> >
> >> > Hope we have good guideline for Microversion, because we only can
> >> change Mircoversion itself by back-compatible way.
> >>
> >> Ironic returns the min/max/current API 

Re: [openstack-dev] [nova] Availability of device names for operations with volumes and BDM and other features.

[Nikola Đipanov]

On 06/02/2015 01:39 PM, Alexandre Levine wrote:
> Thank you Nikola.
> 
> We'll be adding the required tickets and will follow your reviews,
> however the person working primarily on this subject (Feodor Tersin) is
> out for his vacation for a couple of weeks so some of our responses
> might be delayed until then. Still we'll try to do whatever can be done
> without him at the time being.
> 
> Best regards,
>   Alex Levine
> 

Hi guys - I have some fixes posted [1]

As said below - reviews, and especially testing would be greatly
appreciated (even before they are merged).

NB: there is still some work needed to fix [2] on your side even if we
decide that my proposed approach is something we want to go with. See
comments on the bug and the related proposed patch for more information.

Thanks,
N.

[1]
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1370250,n,z
[2] https://bugs.launchpad.net/nova/+bug/1370250

> 
> On 5/29/15 11:32 PM, Nikola Đipanov wrote:
>> On 05/29/2015 12:55 AM, Feodor Tersin wrote:
>>> Nicola, i would add some words to Alexandre repsonse.
>>>
>>> We (standalone ec2api project guys) have filed some bugs (the main is
>>> [1]), but we don't know how to fix them since the way Nova's device
>>> names are moved on is unclear for us. Neither BP, nor wiki you've
>>> mentioned above don't explain what was happened with device names in
>>> images.
>>> Other bug which we filed by results of bdm v2 implementation [2] was
>>> resolved, but the fix returns only two devices (even if more than two
>>> volumes are defined in the image) instead of to write device names to
>>> the image and to return full bdm.
>>>
>>> I hope you will clarify this question (Alexandre referred to the patch
>>> with explicit elimination of device names for images).
>>>
>>> Also you mentioned that we can still use bdm v1. We do it now for
>>> instance launch, but we would like to switch to v2 to use new features
>>> like blank volumes which are provided by AWS as well. However v2 based
>>> launch has a suspicious feature which i asked about in ML [3], but no
>>> one answered me. It would be great if you clarify that question too.
>>>
>>> [1] https://bugs.launchpad.net/nova/+bug/1370177
>>> [2] https://bugs.launchpad.net/nova/+bug/1370265
>>> [3]
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-May/063769.html
>>>
>> Hey Feodor and Alexandre - Thanks for the detailed information!
>>
>> I have already commented on some of the bugs above and provided a small
>> patch that I think fixes one bit of it. As described on the bug - device
>> names might be a bit trickier, but I hope to have something posted next
>> week.
>>
>> Help with testing (while patches are in review) would be hugely
>> appreciated!
>>
>> On 05/28/2015 02:24 PM, Alexandre Levine wrote:
>>> 1. RunInstance. Change parameters of devices during instance booting
>>> from image. In Grizzly it worked so we could specify changed BDM in
>>> parameters, it overwrote in nova DB the one coming from image and then
>>> started the instance with new parameters. The only key for addressing
>>> devices in this use case is the very device name. And now we don't have
>>> it for the volumes in BDM coming from the image, because nova stopped
>>> putting this information into the image.
>>>
>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
>>
>>> 2. Devices names for Xen-backed instances to work fully. We should be
>>> able to specify required device names during initial instance creation,
>>> they should be stored into an image when the instance is shapshotted, we
>>> can fetch info and change parameters of such volume during subsequent
>>> operations, and the device names inside the instance should be named
>>> exactly.
>>>
>>> 3. DescribeInstances and DescribeInstanceAttributes to return BDM with
>>> device names ideally corresponding to actual device naming in instance.
>>>
>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html
>>
>>>
>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceAttribute.html
>>
>>>
>>> 4. DescribeImages and DescribeImageAttributes to return BDM with device
>>> names ideally corresponding to the ones in instance before snapshotting.
>>>
>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html
>>
>>>
>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImageAttribute.html
>>
>> I think all of the above is pretty much covered by
>> https://bugs.launchpad.net/nova/+bug/1370177
>>
>>> 5. AttachVolume with the specified device name.
>>>
>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AttachVolume.html
>>
>>> 6. ModifyInstanceAttribute with BDM as parameter.
>>>
>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html
>>
>>>
>>> 7. ModifyImageAttribute with BDM as parameter.
>>>
>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Mod

Re: [openstack-dev] [nova] vif type libvirt-network

[Andreas Scheuring]

Ian, Neil, thanks for your input!

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

Well, that's a good point where I based my design on wrong assumptions.
I had a clear picture of separation in my mind, letting neutron serve
all the base network (bridge or libvirt network) while nova will use
this as base for plugging. But that's obviously not true - also for
linuxbridge agent there is some plug code ensuring that the bridge is
there. 
--> So plug is definitively required to work around potential timing
issues!

Another idea I just verified is, letting nova create the libvirt
network, but without any interface definitions for it. Neutron then
would add the corresponding interface asyncronously. Unfortunately this
does not work too, as an instance can not be spawned on a libvirt
network without any interface defined...

So for my case this might be a showstopper. My original problem which I
tried to solve with the network approach is, that nova does not need to
know about the physical eth interface name used as source for a macvtap
but rather just use the generic network name. So for it would be the
same problem like with directly defining macvtap as interface type


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

Neil, sorry no. Haven't played around with that, yet. But from reading
the libvirt man, it looks good. It's saying "Guest network traffic will
be forwarded to the physical network via the host's IP routing stack" -
so I would assume this is L3. Maybe you should give it a quick try to
figure out... 

-- 
Andreas 
(irc: scheuran)


On Wed, 2015-06-10 at 21:20 +0100, Neil Jerram wrote:
> Hi Ian,
> 
> Thanks for your reply!
> 
> On 10/06/15 21:07, Ian Wells wrote:
> > I don't see a problem with this, though I think you do want plug/unplug
> > calls to be passed on to Neutron so that has the opportunity to set up
> > the binding from its side (usage >0) and tear it down when you're done
> > with it (usage <1).
> >
> > There may be a set of races you need to deal with, too - what happens if
> > Nova starts a VM attached to a Neutron network binding that has yet to
> > be set up?  Neutron doesn't (well, technically, shouldn't be expected
> > to) do things instantaneously on a call, even binding, or you get into
> > the realm of distributed system failure case analysis.
> 
> Good point.  Andreas, how do you think the timing of the Nova and 
> Neutron parts will work?
> 
> > Neil, are you trying to route to the host - where this will work,
> > because a libvirt network is L2 - or to the VM - where this won't, for
> > the same reason?
> 
> Consider data that's arriving at a local VM, and has come from a VM on 
> another compute host.
> 
>VM - Host A - Host B - VM
> 10.0.0.1  10.0.0.2
> 
> In Host B's routing table there is a rule like this:
> 
> 10.0.0.2/32 dev tap12345-CD
> 
> where tap12345-CD is the TAP interface towards the VM.  Does that answer 
> your question, and would that be possible with a libvirt network?
> 
> Thanks,
>   Neil
> 
> 
> > --
> > Ian.
> >
> >
> > On 10 June 2015 at 12:16, Neil Jerram  > > wrote:
> >
> > On 10/06/15 15:47, Andreas Scheuring wrote:
> >
> > Hi Daniel, Neil and others,
> >
> > I was thinking about introducing libvirt-network as a new vif
> > type to
> > nova. It can be used when Neutron prepares a libvirt network for
> > attaching guests.
> >
> > Would you see any general concerns with such an approach?
> > Anything that
> > I need to consider with libvirt networks in addition? Maybe I should
> > mention one thing due to the discussion this morning: No plug/unplug
> > behavior would required.
> >
> > Any feedback is welcome!
> >
> >
> > I added a blueprint and wrote a spec with more details [1]. This
> > blueprint would make the macvtap-vif blueprint [2] dispensable.
> >
> > The neutron code exploiting this libvirt network vif type will
> > land on
> > stackforge. It will manage macvtap backed libvirt networks --> offer
> > guest attachments via macvtap. [3]
> >
> >
> >
> > [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
> > [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
> > [3] https://launchpad.net/networking-macvtap
> > (I'm still waiting for the repo to be approved, so for now I
> > only have a
> > launchp

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

[gordon chung]

no worries... can't speak for that Dolph fellow though :)
i think it's good to understand/learn different testing/benchmarking 
strategies. 

cheers,
gord


> Date: Thu, 11 Jun 2015 17:34:57 +1200
> From: robe...@robertcollins.net
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][python3] use of six.iteritems()
> 
> On 11 June 2015 at 17:16, Robert Collins  wrote:
> 
> > This test conflates setup and execution. Better like my example,
> ...
> 
> Just had it pointed out to me that I've let my inner asshole out again
> - sorry. I'm going to step away from the thread for a bit; my personal
> state (daughter just had a routine but painful operation) shouldn't be
> taken out on other folk, however indirectly.
> 
> -Rob
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  __
OpenStack Development Mailing 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] Adding metadata to VM through Horizon

[Srikanth Kumar Lingala]

Hi Stackers,
I know that I can add metadata information (Key - Value parameters) to a VM 
through 'nova boot' command.
But, I didn't find the facility through Harizon pages. Does anybody know 
whether the feature is available through Openstack Dashboard?

Please let me know.

Regards,
Srikanth.
__
OpenStack Development Mailing 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 does instance's tap device mac address generate?

[changzhi]

Hi, all.
I create a vm and it's neutron port's mac address is "fa:16:3e:3f:02:ff". I see 
"fa:16:3e:3f:02:ff" inside vm when I run "ifconfig eth0". Why does vm's tap 
device's mac address is "fe:16:3e:3f:02:ff"? Why different between neutron 
port's mac address and tap device's mac address? Does libvirt create instance 
tap device and its mac address is generated randomly? 


Thx
zhi__
OpenStack Development Mailing 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] Adopt mox3

[Davanum Srinivas]

Yes, that's the official position - "Avoid mox, use mock, worst case
use mox3 for existing"

-- dims

On Thu, Jun 11, 2015 at 3:37 AM, Jordan Pittier
 wrote:
> Hi,
> Shouldn't we move to use mock instead ? If mox3 is supported and active, why
> would we recommend to use mock ?
>
> Jordan
>
> On Wed, Jun 10, 2015 at 10:17 PM, Davanum Srinivas 
> wrote:
>>
>> Oslo folks, everyone,
>>
>> mox3 needs to be maintained since some of our projects use it and we
>> have it in our global requirements.
>>
>> Here's the proposal from Doug - https://review.openstack.org/#/c/190330/
>>
>> Any objections? Please chime in here or on the review.
>>
>> thanks,
>> dims
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

Re: [openstack-dev] [oslo] Adopt mox3

[Davanum Srinivas]

Victor,

Monty had a github repo, that's where we are starting from. The idea
is to rely on our day to day tools here in the openstack ecosystem to
maintain the project. If one of the original authors shows up, we'll
see what we can do. Given that the code is Apache License 2.0, we are
ok to pick this up.

-- dims

On Thu, Jun 11, 2015 at 4:15 AM, Victor Stinner  wrote:
> Hi,
>
> Le 10/06/2015 22:17, Davanum Srinivas a écrit :
>>
>> Oslo folks, everyone,
>>
>> mox3 needs to be maintained since some of our projects use it and we
>> have it in our global requirements.
>>
>> Here's the proposal from Doug - https://review.openstack.org/#/c/190330/
>
>
> Why not only creating a project on Github? Do we need all OpenStack tools
> for mox3? I don't expect much enhancements in the library. For me, OpenStack
> looks more restrictive than a classic Github project, it's more heavy to
> contribute (sign a CLA, use review.openstack.org, etc.).
>
> I prefer mock over mox, the API is very different. mock is now part of
> Python stdlib (unittest.mock since Python 3.3). In the past, I ported some
> mox tests to mock, but it takes a lot of time :-(
>
> https://docs.python.org/dev/library/unittest.mock.html
>
> Did anyone try to contact original mox authors? smiddlek is the last active
> contributor.
>
> I see changes in 2012 in the Subversion repository of mox, whereas the
> latest mox release was in 2010 (mox 0.5.3).
>
> It would be nice to merge back enhancements of mox3 (Python 3 support) into
> mox. It's annoying to have a specific project to get Python 3 support.
>
> mox is hosted on code.google.com which is closing!
>
> Victor
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

[Davanum Srinivas]

Thomas,

oslo.vmware (master) moved to suds-jurko for both python2 and python3.
we deleted references in nova and other places directly to suds and
rely on transitively loading the suds-jurko specified from
oslo.vmware. cinder (master) has a reference to suds-jurko as well.

-- dims

On Thu, Jun 11, 2015 at 3:26 AM, Thomas Goirand  wrote:
> Hi,
>
> The current maintainer of suds in Debian sent bug reports against all
> packages depending on it. We would like to get rid of suds completely.
>
> See:
>
> https://bugs.debian.org/788080
> https://bugs.debian.org/788081
> https://bugs.debian.org/788083
> https://bugs.debian.org/788085
> https://bugs.debian.org/788088
>
> Affected projects are: cinder, nova, trove, ironic, and finally oslo.vmware.
>
> So, are we moving to suds-jurko? Or anything else?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

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

[Gary Kotton]

+1

On 6/10/15, 10:11 PM, "Carl Baldwin"  wrote:

>Folks,
>
>As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
>propose Brian Haley as a member of the Neutron L3 core reviewer team.
>Brian has been a long time contributor in Neutron showing expertise
>particularly in IPv6, iptables, and Linux kernel matters.  His
>knowledge and involvement will be very important especially in this
>area.  Brian has become a trusted member of our community.  His review
>stats [2][3][4] place him comfortably with other Neutron core
>reviewers.  He regularly runs proposed patches himself and gives
>insightful feedback.  He has shown a lot of interest in the success of
>Neutron.
>
>Existing Neutron core reviewers from the L3 area of focus, please vote
>+1/-1 for the addition of Brian to the core reviewer team.
>Specifically, I'm looking for votes from Henry, Assaf, and Mark.
>
>Thanks!
>Carl
>
>[1] 
>http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#a
>dding-or-removing-core-reviewers
>[2] 
>https://review.openstack.org/#/q/reviewer:%22Brian+Haley+%253Cbrian.haley%
>2540hp.com%253E%22,n,z
>[3] 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_repor
>t_contribution_neutron-2Dgroup_90&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw
>-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=EYr3Yah7ycZ
>Qas7q-FniGQk1c2IcuaNRkdgLh28c32c&s=DxJhY-IC3-TXBe_0_as2PqMmpCmdXFG2S-g7pFy
>G8KA&e= 
>[4] 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_-3Fus
>er-5Fid-3Dbrian-2Dhaley-26metric-3Dmarks&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiD
>JAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=EYr3
>Yah7ycZQas7q-FniGQk1c2IcuaNRkdgLh28c32c&s=3qH-V02o3t8eWJvqN9KOqihB97dX7EKx
>szQyRaL458o&e= 
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL

[Sean Dague]

On 06/09/2015 06:42 PM, Jeremy Stanley wrote:
> As discussed in the Liberty Design Summit "Moving apps to Python 3"
> cross-project workshop, the way forward in the near future is to
> switch to the pure-python PyMySQL library as a default.
> 
> https://etherpad.openstack.org/p/liberty-cross-project-python3
> 
> To that end, support has already been implemented and tested in
> DevStack, and when https://review.openstack.org/184493 merges in a
> day or two this will become its default. Any last-minute objections
> or concerns?
> 
> Note that similar work is nearing completion is oslo.db with
> https://review.openstack.org/184392 and there are also a lot of
> similar changes in flight for other repos under the same review
> topic (quite a few of which have already merged).

Ok, we've had 2 days fair warning, I'm pushing the merge button here.
Welcome to the world of pure python mysql.

-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

[openstack-dev] [Nova] Nova's Liberty Priorties Merged

[John Garbutt]

Hi,

We have merged the spec that describes the priorities for the Liberty
release, as discussed at the summit:
http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorities.html

The tracking of spec and code reviews for these is happening in the
usual etherpad:
https://etherpad.openstack.org/p/liberty-nova-priorities-tracking

Thanks,
John

PS
I hope user tags of reviews in gerrit will soon exist and be able to
replace our etherpads of doom, to some extent.

__
OpenStack Development Mailing 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] Follow up actions from the Summit: please help

[John Garbutt]

On 6 June 2015 at 11:16, Kashyap Chamarthy  wrote:
> On Fri, Jun 05, 2015 at 10:47:31AM +0100, John Garbutt wrote:
>> Hi,
>>
>> So in the interests of filling up your inbox yet further...
>>
>> We have lots of etherpads from the summit:
>> https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Nova
>>
>> I have extracted all the action items here:
>> https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items
>
> Just a meta comment. Since the content is not massive, it'd be nice to
> have it exported into plain textand post to the mailing list instead,
> of being lost in a slow, "etherpad of doom" as you yourself put it on
> IRC. :-)
>
> A mailing list thread is faster to load than an etherpad.

So the idea with that list, is people update it when they have
completed their action (strikethrough the item). Also folks can
re-assign the person to a new action.

I just felt it was easier to have an etherpad of doom rather than an
ML thread of doom for that. We could make it a wiki, but etherpad
seemed simpler and faster to use than a wiki, if less version
controlled.

What might work best is trello or some other kanban board, but I was
waiting for someone else to install one for me and make it work with
the regular launchpad login, etc. I may just be out of date on that
conversation, maybe we have one now?

Thanks,
John

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

Re: [openstack-dev] [nova] vif type libvirt-network

[Andreas Scheuring]

On Thu, 2015-06-11 at 09:30 +0100, Daniel P. Berrange wrote:

> It seems the main reason for your new proposal is to deal with
> the fact that on migration, you need to specify a different
> NIC name in the XML. This is not particularly difficult - Nova
> already has code for dealing with pdating the XML - the _update_xml
> method in nova.virt.libvirt.driver just needs extending to cover
> that.

Right, that's why I considered the libvirt network vif type. 

I also considered to use direct macvtap attachments exploiting the
xml-modify feature you just mentioned. My big problem in this case is,
that the domain.xml contains the physical eth interface name which will
be used as source for the macvtap. Only neutron agent knows about that.
It's configured in his interface_mappings. On vif_binding, neutron
serves nova the eth interface name via the vif data. That's working fine
- I already implemented a prototype for that which was working greatly -
as long you not do live Migration.

During pre-livemigration on the target host I would need to figure out
which interface should be used and give this information back to the
source via the pre migration data. But therefore nova needs to talk to
my new neutron agent. I don't think that such a shortcut is a good
approach. I'm not aware of any similar thing from other drivers. 

The poor alternative I see would be to duplicate the interface_mapping
config to nova, but that's also not a proper approach. 

I also had a look at the sriov macvtap live migration blueprint [4] but
the situation there is slightly different, as nova knows about all pci
devices that can be used. No interaction with neutron would be needed. I
also thought on jumping on this boat somehow, but the sriov macvtap
support is too tightly coupled to pci. I want a general purpose macvtap
driver that doesn't care about vendor specifics, but working with any
ethernet device...

Do you have any ideas how to achieve this? 


> > The neutron code exploiting this libvirt network vif type will land on
> > stackforge. It will manage macvtap backed libvirt networks --> offer
> > guest attachments via macvtap. [3]
> 
> Who / what will actally be talking to libvirt to create/update the
> network XML setup. Will that be part of the vif driver too.

The plan was that the new macvtap-neutron agent will talk to libvirt and
set up the network. My plan was not to include such function in the vif
driver. But as I learned from Neil and Ian, this does not work, as
there's no guarantee that neutron has set up the network before nova
defined the instance. So I would need some pluging in the network-vif
use case. And here I have the same problem, that nova needs to know the
eth interface name for setting up the network...

I also played around with just creating the network and adding an
interface later on. But on a libvirt network without interfaces I cannot
start a guest...


Any input is welcome!
Thanks!

[1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
[2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
[3] https://launchpad.net/networking-macvtap
[4] https://blueprints.launchpad.net/nova/+spec/sriov-live-migration


-- 
Andreas 
(irc: scheuran)





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

Re: [openstack-dev] How does instance's tap device mac address generate?

[Neil Jerram]

On 11/06/15 10:47, changzhi wrote:

Hi, all.
I create a vm and it's neutron port's mac address is
"fa:16:3e:3f:02:ff". I see "fa:16:3e:3f:02:ff" inside vm when I run
"ifconfig eth0". Why does vm's tap device's mac address is
"fe:16:3e:3f:02:ff"? Why different between neutron port's mac address
and tap device's mac address? Does libvirt create instance tap device
and its mac address is generated randomly?

Thx
zhi


There are two MAC addresses, one at each end of the link between the 
host and the VM.


---+
 Host  |   +---+
   |   | VM|
tap12345-CD --- eth0   |
 fa:16:3e:56:71:42 |   | fa:16:3e:3f:02:ff |
   |   |   |
   |   +---+
---+

I believe that both of these addresses are randomly generated, although 
I'm not sure exactly which components do that.


Does that help at all?

Thanks,
Neil

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

[openstack-dev] [all] grenade with external plugins for the big tent - how to use

[Sean Dague]

Yesterday we landed the infrastructure for Grenade external plugins -
https://review.openstack.org/#/c/185050/

The first user of this is the Heat project, with a patch that's nearly
ready to land (still sorting out an issue because heat's cli commands
aren't console entry points) - https://review.openstack.org/#/c/188148/.
Much appreciation to the Heat team for patience in getting here, and for
helping sort out all the infrastructure.

For additional projects to work the basic pattern is as follows:

* create a custom grenade job for your project
* write a grenade plugin following the instructions here -
https://github.com/openstack-dev/grenade/blob/master/PLUGINS.rst - put
it in your project tree.
* export the following in your project-config definition

export GRENADE_PLUGINRC "enable_grenade_plugin 
git://git.openstack.org/openstack/"

And... you should be good to go. Additional questions on moving forward,
or clarifications in the documentation, can be handled on this thread or
in the #openstack-qa channel.

-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] How does instance's tap device mac address generate?

[Radek Smigielski]

> On Thursday, 11 June 2015, 12:00:46, Neil Jerram  
> wrote:
> > On 11/06/15 10:47, changzhi wrote:
>>  Hi, all.
>>  I create a vm and it's neutron port's mac address is
>>  "fa:16:3e:3f:02:ff". I see "fa:16:3e:3f:02:ff" inside 
> vm when I run
>>  "ifconfig eth0". Why does vm's tap device's mac address 
> is
>>  "fe:16:3e:3f:02:ff"? Why different between neutron port's mac 
> address
>>  and tap device's mac address? Does libvirt create instance tap device
>>  and its mac address is generated randomly?
>> 
>>  Thx
>>  zhi
> 
> There are two MAC addresses, one at each end of the link between the 
> host and the VM.
> 
> ---+
>   Host  |   +---+
> |   | VM|
>  tap12345-CD --- eth0   |
>   fa:16:3e:56:71:42 |   | fa:16:3e:3f:02:ff |
> |   |   |
> |   +---+
> ---+
> 
> I believe that both of these addresses are randomly generated, although 
> I'm not sure exactly which components do that.
> 
> Does that help at all?
> 
> Thanks,
> Neil



In neutron.conf you've got base_mac option and "fa:16:3e" is the default value.

# Base MAC address. The first 3 octets will remain unchanged. If the
# 4h octet is not 00, it will also be used. The others will be
# randomly generated.
# 3 octet
# base_mac = fa:16:3e:00:00:00
# 4 octet
# base_mac = fa:16:3e:4f:00:00





Cheers,
Radosław Śmigielski

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

Re: [openstack-dev] [puppet] [fuel] more collaboration request

[Sanjay Upadhyay]

+1 for the thread, I would also like to hear from Mirantis on this.

The Fork on fuel/puppet has been actively seen patching and
consolidation.It seems like parallel effort why not merge it.

regards
/sanjay

On Thu, Jun 11, 2015 at 9:12 AM, Emilien Macchi  wrote:

> Hi,
>
> Before reading this e-mail, please keep in mind:
>
> * I have a lot of admiration for Fuel and since I'm working on OpenStack
> Installers (at eNovance and now Red Hat), Fuel is something I always
> consider a good product.
> * This e-mail is about Fuel and Puppet, nothing about Mirantis.
> * I'm writing on behalf of my thoughts, and not on our group.
> * I'm using open mailing-list for open discussion. There is not bad
> spirit in this e-mail and I want to have a productive thread.
>
> I have some concerns I would like to share with you and hopefully find
> some solutions together.
>
> Since I've been working on Puppet OpenStack (2 years now), I see some
> situations that happen - according to me - too often:
>
> * A bug is reported in both Fuel Library and the Puppet module having
> trouble. A patch is provided in Fuel Library (your fork of Puppet
> OpenStack modules) but not in Puppet upstream module. That means you fix
> the bug for Fuel, and not for Puppet OpenStack community. It does not
> happen all the time but quite often.
>
> * A patch is submitted in a Puppet module and quite often does not land
> because there is no activity, no tests or is abandonned later because
> fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library
> though.
>
> * RAW copy/paste between upstream modules code and your forks. In term
> of Licensing, I'm even not sure you have the right to do that (I'm not a
> CLA expert though) but well... in term of authorship and statistics on
> code, I'm not sure it's fair. Using submodules with custom patches would
> have been great to respect the authors who created the original code and
> you could have personalize the manifests.
>
> Note: you can see that I don't give any example because I'm not here to
> blame people or judge anyone.
>
> So the goal of my e-mail is to open the discussion and have a *real*
> collaboration between Fuel team which seems to have a lot of good Puppet
> engineers and Puppet OpenStack team.
>
> We had this kind of discussion at the Summit (in Vancouver and also
> Paris, and even before). Now I would like to officialy know if you are
> interested or not to be more involved.
> I'm also open at any feedback about Puppet OpenStack group and if
> something blocks you to contribute more.
>
> We have the same goals, having Puppet modules better. I think it can be
> win/win: you have less diff with upstream and we have more hands in our
> module maintenance.
> Thank you for reading so far, and I'm looking forward to reading from you.
>
> Best regards,
> --
> Emilien Macchi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [third-party] Weekly Third Party CI Working Group meeting change

[Kurt Taylor]

Following feedback for increasing working group participation from
Vancouver summit[1] and discussions in the weekly meetings[2], we have
decided to move the Wednesday working group meeting times and reduce their
frequency. The Monday Office Hours meetings will remain unchanged.

The options for moving the meeting so that it would no longer conflict with
Neutron and Cinder meetings, and still be in accessible hours for those
that participate, were very few. The proposal is to move the working group
meeting from Wednesday to Tuesday, and to drop the 0400 UTC meeting. For
our APAC friends seeking assistance, there is still the Monday Office Hours
meeting at 0800 UTC.

The proposed time is bi-weekly (every other week) on even weeks, Tuesdays
at 1700 UTC. I have already reserved that time since our options were so
limited.[3] Unless there is major objection, the meetings will start on
Tuesday, June 23rd. Note that this skips next week since we are dropping
the 0400 meeting time. The meetings will continue bi-weekly: June 23rd,
July 7th, July 21st, August 4th...

I will send out reminders to make sure that everyone remembers this
transition.

Thanks!
Kurt Taylor (krtaylor)

[1] https://etherpad.openstack.org/p/liberty-ci-loops-bof
[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[3] https://review.openstack.org/#/c/190221
__
OpenStack Development Mailing 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][L3] L3 routed network segments

[Neil Jerram]

Hi Carl et al.,

I see from [1] that L3 routed network segments are on the Neutron L3 
subteam's roadmap for Liberty, and I wanted to say that I'm very 
interested in this work, and - if there isn't someone else already - 
happy to take the lead on making it happen.


I'm aware already of several parties interested in this work, and 
discussion between those parties has been proceeding at [2].  If there 
is anyone else interested - i.e. in networks that are predominantly L3 
routed, and/or where L2 broadcast is partitioned into subsets of the 
overall network - please do take a look at that bug [2] and add your 
thoughts there, or comment in response to this email.


I'm afraid I've not previously been attending L3 subteam IRC meetings - 
something which I now see was a mistake! - but I plan to do that from 
now on.  For today's meeting, though, I'm afraid I have to leave at the 
half way point.  Therefore, if you (Carl) think it would be useful to 
raise or discuss this during the meeting, I'd appreciate if that could 
be scheduled during the first half hour.


Many thanks,
Neil


[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
[2] https://bugs.launchpad.net/neutron/+bug/1458890

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

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

[Jay Pipes]

On 06/11/2015 01:16 AM, Robert Collins wrote:

But again - where in OpenStack does this matter the slightest?


Precisely. I can't think of a single case where we are iterating over 
anywhere near the number of dictionary items that we would see any 
impact whatsoever.


Best,
-jay

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

[openstack-dev] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

[Flavio Percoco]

Greetings,

I'm reaching out to our puppet community looking for help on creating
Zaqar's puppet manifests. We've started doing lots of work to help the
community adopt Zaqar and it'd be a shame to get at the end of the
road without having OPs friendly deployment tools.

I tried to work on this myself and then Jay Clark helped out a bit.
Here's the code[0], which is unfortunately not complete.

This said, I realize packaging is important and I'm happy to say that
there's a package for fedora/centos and Zigo is working on debian's
(Zigo, I know you're blocked by something I need to do, it's coming
;).

So, can we get some help from the puppet team during Liberty to create
these manifests?

It goes without saying that we're more than happy to help if needed.

[0] https://github.com/jasontclark/puppet-zaqar

Cheers,
Flavio

P.S: Puppet is just a start, in the future it'd be awesome to have
support for other deployment tools.

--
@flaper87
Flavio Percoco


pgpMSjHHaIRwL.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][python3] use of six.iteritems()

[Sean Dague]

On 06/11/2015 09:02 AM, Jay Pipes wrote:
> On 06/11/2015 01:16 AM, Robert Collins wrote:
>> But again - where in OpenStack does this matter the slightest?
> 
> Precisely. I can't think of a single case where we are iterating over
> anywhere near the number of dictionary items that we would see any
> impact whatsoever.
> 
> Best,
> -jay

+1.

This is a massive premature optimization which just makes all the code
gorpy for no real reason.

-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] [all] grenade with external plugins for the big tent - how to use

[Kyle Mestery]

On Thu, Jun 11, 2015 at 6:11 AM, Sean Dague  wrote:

> Yesterday we landed the infrastructure for Grenade external plugins -
> https://review.openstack.org/#/c/185050/
>
> The first user of this is the Heat project, with a patch that's nearly
> ready to land (still sorting out an issue because heat's cli commands
> aren't console entry points) - https://review.openstack.org/#/c/188148/.
> Much appreciation to the Heat team for patience in getting here, and for
> helping sort out all the infrastructure.
>
> For additional projects to work the basic pattern is as follows:
>
> * create a custom grenade job for your project
> * write a grenade plugin following the instructions here -
> https://github.com/openstack-dev/grenade/blob/master/PLUGINS.rst - put
> it in your project tree.
> * export the following in your project-config definition
>
> export GRENADE_PLUGINRC "enable_grenade_plugin 
> git://git.openstack.org/openstack/"
>
> And... you should be good to go. Additional questions on moving forward,
> or clarifications in the documentation, can be handled on this thread or
> in the #openstack-qa channel.
>
>
This is really pretty awesome! Very excited that this will allow projects
to host their own grenade plugins in their own repositories. Similar to the
devstack plugins, I think this is a huge win! Great work!

Kyle


> -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
>
__
OpenStack Development Mailing 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] [congress] table with named parameters in rule's left side ?

[Pospisil, Radek]

Hello,

Is it possible to have named parameters on rule's left side, for example:


1.   predeploy_modify(eid,oid,"add_property",5, name="image", value=pvalue) 
:-  Glancev2:images(name=pvalue,...)

2.   predeploy_modify(eid,oid,"add_object", 10, type="monitoring", 
port=8190, path="/aa/bb") :- 

My Usecase is following - I want to use Congress to provide me list of 
'actions' that I have to do on Murano environment prior it is deployed - for 
example:

* I want to enforce/use specific image for given component(s) in 
environment, so I set corresponding property (example 1)

* I want to add an object (monitoring) with properties to environment  
(example 2)

Thus generally "I want to query for one rule with variable set/dictionary of 
arguments" - for example using simulation API:
$ openstack congress policy simulate test 'predeploy_modify()' '' action
Result will be
predeploy_modify(,,'add_property', 5, name="image", value="")
predeploy_modify(,,'add_object', 10, type="monitoring", port="...", 
path="...")



The problem is that if I do (as an example):

$  openstack congress policy rule create test "a(o,p,q=4) :- b(o),b(p)"
ERROR: openstack Syntax error for rule::Compiler found errors:Atom a(q=4) uses 
named parameters but the columns for table a have not been declared.
Atom a(q=4) uses named parameters but the columns for table a have not been 
declared. (HTTP 400) (Request-ID: req-b05683e6-766a-4be8-a238-5811eb6f7125)


So is it possible to use named parameters on not-declared tables?
I know that it is possible to do for "execute[ action(...) ] :- ", where 
positional and keyword/named set of parameters is passed to action-executor.


  Regards,

Radek
__
OpenStack Development Mailing 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] How does instance's tap device macaddress generate?

[changzhi]

Hi, I know that neutron port's mac address was generated by neutron.conf and 
default value is "fa:16:3e" which from base_mac configuration. I don't know how 
the tap device's mac address generates and why tap device mac address was 
"fe:16:3e:xxx". I think that tap device mac address was generated by libvirt. 


Thx
changzhi
 
 
-- Original --
From:  "Radek Smigielski";
Date:  Thu, Jun 11, 2015 07:26 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] How does instance's tap device macaddress 
generate?

 
> On Thursday, 11 June 2015, 12:00:46, Neil Jerram  
> wrote:
> > On 11/06/15 10:47, changzhi wrote:
>>  Hi, all.
>>  I create a vm and it's neutron port's mac address is
>>  "fa:16:3e:3f:02:ff". I see "fa:16:3e:3f:02:ff" inside 
> vm when I run
>>  "ifconfig eth0". Why does vm's tap device's mac address 
> is
>>  "fe:16:3e:3f:02:ff"? Why different between neutron port's mac 
> address
>>  and tap device's mac address? Does libvirt create instance tap device
>>  and its mac address is generated randomly?
>> 
>>  Thx
>>  zhi
> 
> There are two MAC addresses, one at each end of the link between the 
> host and the VM.
> 
> ---+
>   Host  |   +---+
> |   | VM|
>  tap12345-CD --- eth0   |
>   fa:16:3e:56:71:42 |   | fa:16:3e:3f:02:ff |
> |   |   |
> |   +---+
> ---+
> 
> I believe that both of these addresses are randomly generated, although 
> I'm not sure exactly which components do that.
> 
> Does that help at all?
> 
> Thanks,
> Neil



In neutron.conf you've got base_mac option and "fa:16:3e" is the default value.

# Base MAC address. The first 3 octets will remain unchanged. If the
# 4h octet is not 00, it will also be used. The others will be
# randomly generated.
# 3 octet
# base_mac = fa:16:3e:00:00:00
# 4 octet
# base_mac = fa:16:3e:4f:00:00





Cheers,
Radosław Śmigielski

__
OpenStack Development Mailing 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] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

[Emilien Macchi]

Hey,

On 06/11/2015 09:29 AM, Flavio Percoco wrote:
> Greetings,
> 
> I'm reaching out to our puppet community looking for help on creating
> Zaqar's puppet manifests. We've started doing lots of work to help the
> community adopt Zaqar and it'd be a shame to get at the end of the
> road without having OPs friendly deployment tools.

+1

> 
> I tried to work on this myself and then Jay Clark helped out a bit.
> Here's the code[0], which is unfortunately not complete.

It's a good start and it will help us to understand how to configure it.

> 
> This said, I realize packaging is important and I'm happy to say that
> there's a package for fedora/centos and Zigo is working on debian's
> (Zigo, I know you're blocked by something I need to do, it's coming
> ;).
> 
> So, can we get some help from the puppet team during Liberty to create
> these manifests?

So we have some folks developping tools [1] to bootstrap Puppet
OpenStack modules with basic bits (we are so lazy) and zaqar could
benefit of this tool. I think we can help you to generate the basic
structure of the module and maybe you could help in porting your bits to
the new compliant module.

On my side, I can take care of 1/ make sure the repo is on Stackforge
(for start, then it will move under OpenStack namespace once done) 2/
help in unit/functional testing (rspec, beaker).


> It goes without saying that we're more than happy to help if needed.
> 
> [0] https://github.com/jasontclark/puppet-zaqar
> 
> Cheers,
> Flavio
> 
> P.S: Puppet is just a start, in the future it'd be awesome to have
> support for other deployment tools.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

[1] https://github.com/enovance/puppet-openstack-cookiecutter (now
eNovance but moving to Stackforge:
https://review.openstack.org/#/c/188929/ )
-- 
Emilien Macchi



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

Re: [openstack-dev] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

[Richard Raseley]

Flavio Percoco wrote:

Greetings,

I'm reaching out to our puppet community looking for help on creating
Zaqar's puppet manifests. We've started doing lots of work to help the
community adopt Zaqar and it'd be a shame to get at the end of the
road without having OPs friendly deployment tools.

I tried to work on this myself and then Jay Clark helped out a bit.
Here's the code[0], which is unfortunately not complete.

This said, I realize packaging is important and I'm happy to say that
there's a package for fedora/centos and Zigo is working on debian's
(Zigo, I know you're blocked by something I need to do, it's coming
;).

So, can we get some help from the puppet team during Liberty to create
these manifests?

It goes without saying that we're more than happy to help if needed.

[0] https://github.com/jasontclark/puppet-zaqar

Cheers,
Flavio

P.S: Puppet is just a start, in the future it'd be awesome to have
support for other deployment tools.

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


Flavio,

Apologies for not yet replying to your email dated June 4th.

I have time set aside tomorrow (Friday from 1PM - 4PM) to begin review 
of the work that's already done and start enumerating what the next 
steps are. Look for some updated information from me either tomorrow 
afternoon or over the weekend (which I'll share here for visibility).


What TZ are you in (in case I need to poke you with some questions)?

Regards,

Richard

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

Re: [openstack-dev] [nova] vif type libvirt-network

[Daniel P. Berrange]

On Thu, Jun 11, 2015 at 12:54:54PM +0200, Andreas Scheuring wrote:
> On Thu, 2015-06-11 at 09:30 +0100, Daniel P. Berrange wrote:
> 
> > It seems the main reason for your new proposal is to deal with
> > the fact that on migration, you need to specify a different
> > NIC name in the XML. This is not particularly difficult - Nova
> > already has code for dealing with pdating the XML - the _update_xml
> > method in nova.virt.libvirt.driver just needs extending to cover
> > that.
> 
> Right, that's why I considered the libvirt network vif type. 
> 
> I also considered to use direct macvtap attachments exploiting the
> xml-modify feature you just mentioned. My big problem in this case is,
> that the domain.xml contains the physical eth interface name which will
> be used as source for the macvtap. Only neutron agent knows about that.
> It's configured in his interface_mappings. On vif_binding, neutron
> serves nova the eth interface name via the vif data. That's working fine
> - I already implemented a prototype for that which was working greatly -
> as long you not do live Migration.
> 
> During pre-livemigration on the target host I would need to figure out
> which interface should be used and give this information back to the
> source via the pre migration data. But therefore nova needs to talk to
> my new neutron agent. I don't think that such a shortcut is a good
> approach. I'm not aware of any similar thing from other drivers. 
> 
> The poor alternative I see would be to duplicate the interface_mapping
> config to nova, but that's also not a proper approach. 
> 
> I also had a look at the sriov macvtap live migration blueprint [4] but
> the situation there is slightly different, as nova knows about all pci
> devices that can be used. No interaction with neutron would be needed. I
> also thought on jumping on this boat somehow, but the sriov macvtap
> support is too tightly coupled to pci. I want a general purpose macvtap
> driver that doesn't care about vendor specifics, but working with any
> ethernet device...
> 
> Do you have any ideas how to achieve this?

I could have sworn I've previously reviewed patches which dealt with
NIC device naming changes across migration, but I can't find them
now. Did you ever submit patches which tried to fix this, or am I
perhaps thinking of someone elses.

I understand the difficulty in getting the information across to
the right place, but I thought I remembered seeing a solution ot
that. Failing that though, the other option is to rename the ethernet
devices when assigning them to a guest, so they have a stable name
across hosts.


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

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

Re: [openstack-dev] [all] grenade with external plugins for the big tent - how to use

[Zane Bitter]

On 11/06/15 09:38, Kyle Mestery wrote:

On Thu, Jun 11, 2015 at 6:11 AM, Sean Dague mailto:s...@dague.net>> wrote:

Yesterday we landed the infrastructure for Grenade external plugins -
https://review.openstack.org/#/c/185050/

The first user of this is the Heat project, with a patch that's nearly
ready to land (still sorting out an issue because heat's cli commands
aren't console entry points) - https://review.openstack.org/#/c/188148/.
Much appreciation to the Heat team for patience in getting here, and for
helping sort out all the infrastructure.

For additional projects to work the basic pattern is as follows:

* create a custom grenade job for your project
* write a grenade plugin following the instructions here -
https://github.com/openstack-dev/grenade/blob/master/PLUGINS.rst - put
it in your project tree.
* export the following in your project-config definition

export GRENADE_PLUGINRC "enable_grenade_plugin 
git://git.openstack.org/openstack/
"

And... you should be good to go. Additional questions on moving forward,
or clarifications in the documentation, can be handled on this thread or
in the #openstack-qa channel.


This is really pretty awesome! Very excited that this will allow
projects to host their own grenade plugins in their own repositories.
Similar to the devstack plugins, I think this is a huge win! Great work!


+1, I know this big tent transition is creating a lot of work for the 
cross-project teams in the short term, but I think this will pay huge 
dividends in the future in increasing the capacity of our community to 
innovate across the board. Many thanks to Sean and everyone else 
involved in making this a reality :)


cheers,
Zane.


__
OpenStack Development Mailing 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][reseller] New way to get a project scoped token by name

[Raildo Mascena]

Hi Folks,

As we have discussed in the last Keystone meeting, we created an etherpad
with the alternatives to solve this problem:
https://etherpad.openstack.org/p/reseller-project-token
We have also decided to take a vote to choose the best option in the next
Keystone Meeting (#openstack-meeting - June 16th - 18:00 UTC).

It would be great if you could take a look before the meeting, so we could
discuss and improve this document before the vote.

Best regards,


On Tue, Jun 9, 2015 at 12:12 PM Dolph Mathews 
wrote:

> On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox 
> wrote:
>
>>
>>
>> - Original Message -
>> > From: "David Chadwick" 
>> > To: openstack-dev@lists.openstack.org
>> > Sent: Saturday, 6 June, 2015 6:01:10 PM
>> > Subject: Re: [openstack-dev] [keystone][reseller] New way to get a
>> project scoped token by name
>> >
>> >
>> >
>> > On 06/06/2015 00:24, Adam Young wrote:
>> > > On 06/05/2015 01:15 PM, Henry Nash wrote:
>> > >> I am sure I have missed something along the way, but can someone
>> > >> explain to me why we need this at all.  Project names are unique
>> > >> within a domain, with the exception of the project that is acting as
>> > >> its domain (i.e. they can only every be two names clashing in a
>> > >> hierarchy at the domain level and below).  So why isn’t specifying
>> > >> “is_domain=True/False” sufficient in an auth scope along with the
>> > >> project name?
>> > >
>> > > The limitation of " Project names are unique within a domain" is
>> > > artificial and somethi8ng we should not be enforcing.  Names should
>> only
>> > > be unique within parent project.
>> >
>> > +++1
>>
>> I said the exact same thing as Henry in the other thread that seems to be
>> on the same topic. You're correct the limitation of "Project names are
>> unique within a domain" is completely artificial, but it's a constraint
>> that allows us to maintain the auth systems we currently have and will not
>> harm the reseller model (because they would be creating new domains).
>>
>> It's also a constraint that we can relax later when multitenancy is a bit
>> more established and someone has a real issue with the limitation - it's
>> not something we can ever claw back again if we allow some looking up
>> projects by name with delimiters.
>>
>> I think for the time being it's an artificial constraint we should
>> maintain.
>>
>
> +1
>
>
>>
>>
>>
>> > >
>> > > This whole thing started by trying to distinguish a domain from a
>> > > project within that domain that both have the same name. We can
>> special
>> > > case that, but it is not a great solution.
>> > >
>> > >
>> > >
>> > >>
>> > >> Henry
>> > >>
>> > >>> On 5 Jun 2015, at 18:02, Adam Young > > >>> > wrote:
>> > >>>
>> > >>> On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
>> >  Hi David,
>> > 
>> >  There needs to be some form of global hierarchy delimiter - well
>> >  more to the point there should be a common one across OpenStack
>> >  installations to ensure we are providing a good and consistent (and
>> >  more to the point inter-operable) experience to our users. I'm
>> >  worried a custom defined delimiter (even at the domain level) is
>> >  going to make it difficult to consume this data outside of the
>> >  context of OpenStack (there are applications that are written to
>> use
>> >  the APIs directly).
>> > >>> We have one already.  We are working JSON, and so instead of project
>> > >>> name being a string, it can be an array.
>> > >>>
>> > >>> Nothing else is backwards compatible.  Nothing else will ensure we
>> > >>> don;t break exisiting deployments.
>> > >>>
>> > >>> Moving forward, we should support DNS notation, but it has to be an
>> > >>> opt in
>> > >>>
>> > 
>> >  The alternative is to explicitly list the delimiter in the project
>> (
>> >  e.g. {"hierarchy": {"delim": ".", "domain.project.project2"}} ).
>> The
>> >  additional need to look up the delimiter / set the delimiter when
>> >  creating a domain is likely to make for a worse user experience
>> than
>> >  selecting one that is not different across installations.
>> > 
>> >  --Morgan
>> > 
>> >  On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
>> >  mailto:d.w.chadw...@kent.ac.uk>> wrote:
>> > 
>> > 
>> > 
>> >  On 03/06/2015 14:54, Henrique Truta wrote:
>> >  > Hi David,
>> >  >
>> >  > You mean creating some kind of "delimiter" attribute in the
>> domain
>> >  > entity? That seems like a good idea, although it does not
>> >  solve the
>> >  > problem Morgan's mentioned that is the global hierarchy
>> delimiter.
>> > 
>> >  There would be no global hierarchy delimiter. Each domain would
>> >  define
>> >  its own and this would be carried in the JSON as a separate
>> >  parameter so
>> >  that the recipient can tell how to parse hierarchical names
>> > >>>

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

[Mike Bayer]

On 6/10/15 11:48 PM, Dolph Mathews wrote:
tl;dr *.iteritems() is faster and more memory efficient than .items() 
in python2*



Using xrange() in python2 instead of range() because it's more memory 
efficient and consistent between python 2 and 3...


# xrange() + .items()
python -m timeit -n 20 for\ i\ in\ 
dict(enumerate(xrange(100))).items():\ pass

20 loops, best of 3: 729 msec per loop
peak memory usage: 203 megabytes

# xrange() + .iteritems()
python -m timeit -n 20 for\ i\ in\ 
dict(enumerate(xrange(100))).iteritems():\ pass

20 loops, best of 3: 644 msec per loop
peak memory usage: 176 megabytes

# python 3
python3 -m timeit -n 20 for\ i\ in\ 
dict(enumerate(range(100))).items():\ pass

20 loops, best of 3: 826 msec per loop
peak memory usage: 198 megabytes
it is just me, or are these differences pretty negligible considering 
this is the "1 million item dictionary", which in itself is a unicorn in 
openstack code or really most code anywhere?


as was stated before, if we have million-item dictionaries floating 
around, that code has problems.   I already have to wait full seconds 
for responses to come back when I play around with Neutron + Horizon in 
a devstack VM, and that's with no data at all.  100ms extra for a 
hypothetical million item structure would be long after the whole app 
has fallen over from having just ten thousand of anything, much less a 
million.


My only concern with items() is that it is semantically different in 
Py2k / Py3k.  Code that would otherwise have a "dictionary changed size" 
issue under iteritems() / py3k items() would succeed under py2k 
items().   If such a coding mistake is not covered by tests (as this is 
a data-dependent error condition), it would manifest as a sudden error 
condition on Py3k only.







And if you really want to see the results with range() in python2...

# range() + .items()
python -m timeit -n 20 for\ i\ in\ 
dict(enumerate(range(100))).items():\ pass

20 loops, best of 3: 851 msec per loop
peak memory usage: 254 megabytes

# range() + .iteritems()
python -m timeit -n 20 for\ i\ in\ 
dict(enumerate(range(100))).iteritems():\ pass

20 loops, best of 3: 919 msec per loop
peak memory usage: 184 megabytes


To benchmark memory consumption, I used the following on bare metal:

$ valgrind --tool=massif --pages-as-heap=yes 
-massif-out-file=massif.out $COMMAND_FROM_ABOVE

$ cat massif.out | grep mem_heap_B | sort -u

$ python2 --version
Python 2.7.9

$ python3 --version
Python 3.4.3


On Wed, Jun 10, 2015 at 8:36 PM, gordon chung > wrote:


> Date: Wed, 10 Jun 2015 21:33:44 +1200
> From: robe...@robertcollins.net 
> To: openstack-dev@lists.openstack.org

> Subject: Re: [openstack-dev] [all][python3] use of six.iteritems()
>
> On 10 June 2015 at 17:22, gordon chung mailto:g...@live.ca>> wrote:
> > maybe the suggestion should be "don't blindly apply
six.iteritems or items" rather than don't apply iteritems at all.
admittedly, it's a massive eyesore, but it's a very real use case
that some projects deal with large data results and to enforce the
latter policy can have negative effects[1]. one "million item
dictionary" might be negligible but in a multi-user, multi-*
environment that can have a significant impact on the amount
memory required to store everything.
>
> > [1] disclaimer: i have no real world results but i assume
memory management was the reason for the switch in logic from py2
to py3
>
> I wouldn't make that assumption.
>
> And no, memory isn't an issue. If you have a million item dict,
> ignoring the internal overheads, the dict needs 1 million object
> pointers. The size of a list with those pointers in it is 1M
(pointer
> size in bytes). E.g. 4M or 8M. Nothing to worry about given the
> footprint of such a program :)

iiuc, items() (in py2) will create a copy of  the dictionary in
memory to be processed. this is useful for cases such as
concurrency where you want to ensure consistency but doing a quick
test i noticed a massive spike in memory usage between items() and
iteritems.

'for i in dict(enumerate(range(100))).items(): pass' consumes
significantly more memory than 'for i in
dict(enumerate(range(100))).iteritems(): pass'. on my system,
the difference in memory consumption was double when using items()
vs iteritems() and the cpu util was significantly more as well...
let me know if there's anything that stands out as inaccurate.

unless there's something wrong with my ignorant testing above, i
think it's something projects should consider when mass applying
any iteritems/items patch.

cheers,
gord

__
OpenStack Development Mailing List (not for us

Re: [openstack-dev] [congress] table with named parameters in rule's left side ?

[Tim Hinrichs]

Hi Radek,

1. You can't use column references on any table except those created by a
datasource, mainly because Congress doesn't know the name of the columns
for those tables.  We've kicked around the idea of letting policy-writers
declare the column names of any table, but it's trickier than it sounds.

2. Even if we solved (1), there's not much point in using column-references
in the head (left-hand-side) of a rule because you always need to include
all of the columns anyway.  That restriction is baked deeply into the
semantics of the language: if you leave out a column in the head the size
of the table is infinite.  The only benefit to column-references in the
head would be enabling you to specify the columns in any order.

3. I've thought about tweaking the semantics of Datalog so that it includes
both tuples and dictionaries.  But that is a major effort.

4. We don't actually allow column-references even within execute[
action(...)] because of (2).

5.  In your example, can you write it without the column references?  I
don't see the predeploy_modify rule to understand why you need column
references in the query.

 predeploy_modify(,,'add_property', 5, name="image”,
value="")

Tim



On Thu, Jun 11, 2015 at 6:44 AM Pospisil, Radek 
wrote:

>  Hello,
>
>
>
> Is it possible to have named parameters on rule’s left side, for example:
>
>
>
> 1.   predeploy_modify(eid,oid,"add_property",5, name=”image”,
> value=pvalue) :- …. Glancev2:images(name=pvalue,…)
>
> 2.   predeploy_modify(eid,oid,"add_object", 10, type=”monitoring”,
> port=8190, path=”/aa/bb”) :- ….
>
>
>
> My Usecase is following – I want to use Congress to provide me list of
> ‘actions’ that I have to do on Murano environment prior it is deployed –
> for example:
>
> · I want to enforce/use specific image for given component(s) in
> environment, so I set corresponding property (example 1)
>
> · I want to add an object (monitoring) with properties to
> environment  (example 2)
>
>
>
> Thus generally “I want to query for one rule with variable set/dictionary
> of arguments” – for example using simulation API:
>
> $ openstack congress policy simulate test 'predeploy_modify()' '' action
>
> Result will be
>
> predeploy_modify(,,'add_property', 5, name="image”,
> value="")
>
> predeploy_modify(,,'add_object', 10, type="monitoring",
> port="…", path="…")
>
>
>
>
>
>
>
> The problem is that if I do (as an example):
>
>
>
> $  openstack congress policy rule create test "a(o,p,q=4) :- b(o),b(p)"
>
> ERROR: openstack Syntax error for rule::Compiler found errors:Atom a(q=4)
> uses named parameters but the columns for table a have not been declared.
>
> Atom a(q=4) uses named parameters but the columns for table a have not
> been declared. (HTTP 400) (Request-ID:
> req-b05683e6-766a-4be8-a238-5811eb6f7125)
>
>
>
>
>
> So is it possible to use named parameters on not-declared tables?
>
> I know that it is possible to do for “execute[ action(…) ] :- “, where
> positional and keyword/named set of parameters is passed to action-executor.
>
>
>
>
>
>   Regards,
>
>
>
> Radek
>
> __
> OpenStack Development Mailing 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] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

[Flavio Percoco]

On 11/06/15 06:53 -0700, Richard Raseley wrote:

Flavio Percoco wrote:

Greetings,

I'm reaching out to our puppet community looking for help on creating
Zaqar's puppet manifests. We've started doing lots of work to help the
community adopt Zaqar and it'd be a shame to get at the end of the
road without having OPs friendly deployment tools.

I tried to work on this myself and then Jay Clark helped out a bit.
Here's the code[0], which is unfortunately not complete.

This said, I realize packaging is important and I'm happy to say that
there's a package for fedora/centos and Zigo is working on debian's
(Zigo, I know you're blocked by something I need to do, it's coming
;).

So, can we get some help from the puppet team during Liberty to create
these manifests?

It goes without saying that we're more than happy to help if needed.

[0] https://github.com/jasontclark/puppet-zaqar

Cheers,
Flavio

P.S: Puppet is just a start, in the future it'd be awesome to have
support for other deployment tools.

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


Flavio,

Apologies for not yet replying to your email dated June 4th.


Oh don't worry at all. I'm sorry if my email sounded like I was
putting preassure on you. I actually was but h (joke).

I have time set aside tomorrow (Friday from 1PM - 4PM) to begin review 
of the work that's already done and start enumerating what the next 
steps are. Look for some updated information from me either tomorrow 
afternoon or over the weekend (which I'll share here for visibility).




This sounds awesome, thanks a lot for your support here!


What TZ are you in (in case I need to poke you with some questions)?


I'm CEST (UTC+2) (#openstack-(dev|zaqar))

Flavio



Regards,

Richard


--
@flaper87
Flavio Percoco


pgpfV7UxorTxL.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][python3] use of six.iteritems()

[gordon chung]

> it is just me, or are these differences pretty negligible considering 
> this is the "1 million item dictionary", which in itself is a unicorn 
> in openstack code or really most code anywhere? 
> 
> as was stated before, if we have million-item dictionaries floating 
> around, that code has problems. I already have to wait full seconds 
> for responses to come back when I play around with Neutron + Horizon in 
> a devstack VM, and that's with no data at all. 100ms extra for a 
> hypothetical million item structure would be long after the whole app 
> has fallen over from having just ten thousand of anything, much less a 
> million. 

my concern isn't the 1million item dictionary -- i think we're all just using 
that as a simple test -- it's the 100 concurrent actions against a 10,000 item 
dictionary or the  1000 concurrent actions against at 1000 item dictionary... 
when tracking htop to see memory consumption, items() consistently doubled the 
memory consumption of iteritems().

again, i just want to reiterate, i'm not saying don't use items(), i just think 
we should not blindly use items() just as we shouldn't blindly use 
iteritems()/viewitems()

> 
> My only concern with items() is that it is semantically different in 
> Py2k / Py3k. Code that would otherwise have a "dictionary changed 
> size" issue under iteritems() / py3k items() would succeed under py2k 
> items(). If such a coding mistake is not covered by tests (as this is 
> a data-dependent error condition), it would manifest as a sudden error 
> condition on Py3k only. 
> 
  
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [fuel] more collaboration request

[Matthew Mosesohn]

Hi Emilien,

I can see why you might be unhappy with Fuel's actions with regards to
the OpenStack Puppet modules. You could make this argument about many
components in Fuel. The heart of the matter is that we bundle the
upstream OpenStack Puppet modules with all the other modules,
developed both upstream and by Fuel's developers in one single git
repository. This decision, along with all the other decisions to put
Fuel's components under its own repositories, was intended to add
stability and granular control to the product. I'm not saying it's the
most community-oriented approach, but Fuel would have never evolved
and matured without it. The attribution in commits is lost because our
directory namespace differs such that it can't just be merged cleanly.
Revisiting submodules is an option, but it led to maintenance problems
in the past.

Secondly, I'd like to point out that Fuel is not so different from
what other teams are doing. At the Summit, I heard from others who all
maintain internal Gerrits and internal forks of the modules. The
difference is that Fuel is being worked on in the open in StackForge.
Anyone is free to contribute to Fuel as he or she wishes, take our
patches, or review changesets.

Starting in October 2014, the Fuel team has adopted a policy that we
cannot merge any patches into the core Puppet OpenStack modules of
Fuel without submitting a patch or at least a bug upstream. Our
reviewers block patches consistently. The truth is that the upstream
modules are quite excellent and we don't need to make changes so
often. Our goal is to work with upstream modules or in the issue where
upstream integration is impossible, we place that config in our own
separate modules.

The point you raised about fixing bugs in Fuel and not in Puppet
OpenStack is definitely valid and something we need to collaborate on.
The first and easiest option when a bug is applicable to both, we
could use Launchpad to assign bugs to both Fuel project and
puppet-$project so it gains visibility. If a bug is discovered in
Puppet OpenStack after it's been reported and/or fixed in Fuel, then
it would be best to ping someone in #fuel-dev on IRC and we can try to
figure out how to get this applied upstream correctly. Our best
results come from fixing upstream and I want to make sure that is
clear.

If you have specific bugs or commits you'd like to discuss, let's work
them out. I believe I can get the Fuel Library team to agree to do a
walk through all the open bugs in Puppet OpenStack and see if we have
any related fixes or bug reports.

Best Regards,
Matthew Mosesohn

On Thu, Jun 11, 2015 at 2:34 PM, Sanjay Upadhyay  wrote:
> +1 for the thread, I would also like to hear from Mirantis on this.
>
> The Fork on fuel/puppet has been actively seen patching and consolidation.It
> seems like parallel effort why not merge it.
>
> regards
> /sanjay
>
> On Thu, Jun 11, 2015 at 9:12 AM, Emilien Macchi  wrote:
>>
>> Hi,
>>
>> Before reading this e-mail, please keep in mind:
>>
>> * I have a lot of admiration for Fuel and since I'm working on OpenStack
>> Installers (at eNovance and now Red Hat), Fuel is something I always
>> consider a good product.
>> * This e-mail is about Fuel and Puppet, nothing about Mirantis.
>> * I'm writing on behalf of my thoughts, and not on our group.
>> * I'm using open mailing-list for open discussion. There is not bad
>> spirit in this e-mail and I want to have a productive thread.
>>
>> I have some concerns I would like to share with you and hopefully find
>> some solutions together.
>>
>> Since I've been working on Puppet OpenStack (2 years now), I see some
>> situations that happen - according to me - too often:
>>
>> * A bug is reported in both Fuel Library and the Puppet module having
>> trouble. A patch is provided in Fuel Library (your fork of Puppet
>> OpenStack modules) but not in Puppet upstream module. That means you fix
>> the bug for Fuel, and not for Puppet OpenStack community. It does not
>> happen all the time but quite often.
>>
>> * A patch is submitted in a Puppet module and quite often does not land
>> because there is no activity, no tests or is abandonned later because
>> fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library
>> though.
>>
>> * RAW copy/paste between upstream modules code and your forks. In term
>> of Licensing, I'm even not sure you have the right to do that (I'm not a
>> CLA expert though) but well... in term of authorship and statistics on
>> code, I'm not sure it's fair. Using submodules with custom patches would
>> have been great to respect the authors who created the original code and
>> you could have personalize the manifests.
>>
>> Note: you can see that I don't give any example because I'm not here to
>> blame people or judge anyone.
>>
>> So the goal of my e-mail is to open the discussion and have a *real*
>> collaboration between Fuel team which seems to have a lot of good Puppet
>> engineers and Puppet OpenStack team.
>>
>> We had this k

[openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API & DB core reviewer team

[Henry Gessau]

As one of the Lieutenants [1] for the API and DB areas under the PTL, I would
like to propose Ann Kamyshnikova as a member of the Neutron API and DB core
reviewer team.

Ann has been a long time contributor in Neutron showing expertise particularly
in database matters. She has also worked with and contributed code to the
oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the
Neutron "database healing" effort that was completed in the Juno cycle.

Her deep knowledge of databases and backends, and her expertise with oslo.db,
sqlalchemy and alembic will be very important in this area. Ann is a trusted
member of our community and her review stats [2][3][4] place her comfortably
with other Neutron core reviewers. She consistently catches database issues
early when patches are submitted for review, and shows dedication to helping
developers understand and perfect their database-related changes.

Existing Neutron core reviewers from the API and DB area of focus, please vote
+1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm
looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl.


[1]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
[2]
https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
[3] http://stackalytics.com/report/contribution/neutron-group/90
[4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks




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

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

[Jeremy Stanley]

On 2015-06-11 07:51:55 +0200 (+0200), Philipp Marek wrote:
[...]
> I still stand by my opinion (as voiced in Vancouver) that for such
> one-off things (that contributors are not likely to repeat over
> and over again) it might make sense to have -infra simply *do*
> them[3].
[...]

To reiterate my response from the summit, it's a neat idea but not
one the Infra team has the bandwidth to entertain at the moment. As
you've noticed we're understaffed and while we're continually trying
to grow the team it takes many months to a year or more of full-time
exposure to our current systems to bring new people up to speed to
help us run it. Also we don't actually have a holistic view of the
underlying tests being run by the jobs... for that you need to
elicit assistance from the QA team who maintain DevStack/Tempest and
did the plugin design for things like out-of-tree driver testing,
and also the project teams for the software at which these drivers
and backends are targeted.

So while I and others are happy to have our CI run jobs to test
OpenStack drivers for other free software backends, don't expect the
actual work and learning curve to necessarily be any less than
building your own CI system from scratch (just different).

> It doesn't make sense to require people to learn about things they
> will never use again - and the amount of time spent answering the
> questions, diagnosing problems and so on is quite a bit higher
> than doing it simply right the first time.

This is, I think, also a common misconception. The people who write
these jobs to run in our CI need to stick around or induct
successors to help maintain them and avoid bitrot as our systems
constantly change and evolve. I know the same goes for the drivers
themselves... if people don't keep them current with the OpenStack
software into which they're integrating, support will quickly be
dropped due to quality control concerns.

> And if it's *that* often needed, why not write a small script
> that, given a name, does the needed changes, so that only a commit
> & review is needed?
[...]

Definitely something that people who have experience writing these
could collaborate on contributing. As I mentioned, the Infra team
doesn't have the complete picture, but the people who have sweated
and bled to get their drivers tested and integrated do, at least to
a greater extent than we do.

This is all to say I understand the frustration, but I don't have a
simple solution for it unfortunately.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Nova] Follow up actions from the Summit: please help

[Matt Riedemann]

On 6/5/2015 4:47 AM, John Garbutt wrote:

Hi,

So in the interests of filling up your inbox yet further...

We have lots of etherpads from the summit:
https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Nova

I have extracted all the action items here:
https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items

Please do add any actions that might be missing.

Matt Riedemann wins the prize[1] for the first[2][3] completed action
item, by releasing python-novaclient with the volume actions
deprecated.


I will take any and all prizes, virtual or not.



Its has been noted that I greedily took most of the actions for
myself. The name is purely the person who gets to make sure the action
happens. If you want to help (please do help!), contact the person
named, who might be able to hand over that task.

Thanks,
John

[1] its a virtual trophy, here you go: >--|
[2] may not have been the first, but whatever
[3] no, there is no prize for the last person

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



--

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] [all][python3] use of six.iteritems()

[Victor Stinner]

Hi,

Le 10/06/2015 02:15, Robert Collins a écrit :

python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
d.items(): pass'
10 loops, best of 3: 76.6 msec per loop



python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
d.iteritems(): pass'
100 loops, best of 3: 22.6 msec per loop


.items() is 3x as slow as .iteritems(). Hum, I don't have the same 
results. Try attached benchmark. I'm using my own wrapper on top of 
timeit, because timeit is bad at calibrating the benchmark :-/ timeit 
gives unreliable results.


Results on with CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz:

[ 10 keys ]
713 ns: iteritems
922 ns (+29%): items

[ 10^3 keys ]
42.1 us: iteritems
59.4 us (+41%): items


[ 10^6 keys (1 million) ]
89.3 ms: iteritems
442 ms (+395%): items

In my benchmark, .items() is 5x as slow as .iteritems(). The code to 
iterate on 1 million items takes almost an half second. IMO adding 300 
ms to each request is not negligible on an application. If this delay is 
added multiple times (multiple loops iterating on 1 million items), we 
may reach up to 1 second on an user request :-/


Anyway, when I write patches to port a project to Python 3, I don't want 
to touch *anything* to Python 2. The API, the performances, the 
behaviour, etc. must not change.


I don't want to be responsible of a slow down, and I don't feel able to 
estimate if replacing dict.iteritems() with dict.items() has a cost on a 
real application.


As Ihar wrote: it must be done in a separated patch, by developers 
knowning well the project.


Currently, most developers writing Python 3 patches are not heavily 
involved in each ported project.


There is also dict.itervalues(), not only dict.iteritems().

"for key in dict.iterkeys()" can simply be written "for key in dict:".

There is also xrange() vs range(), the debate is similar:
https://review.openstack.org/#/c/185418/

For Python 3, I suggest to use "from six.moves import range" to get the 
Python 3 behaviour  on Python 2: range() always create an iterator, it 
doesn't create a temporary list. IMO it makes the code more readable 
because "for i in xrange(n):" becomes "for i in range(n):". six is not 
written outside imports and "range()" is better than "xrange()" for 
developers starting to learn Python.


Victor
"""
Micro-benchmark for the Python operation "key in dict". Run it with:

./python.orig benchmark.py script bench_str.py --file=orig
./python.patched benchmark.py script bench_str.py --file=patched
./python.patched benchmark.py compare_to orig patched

Download benchmark.py from:

https://bitbucket.org/haypo/misc/raw/tip/python/benchmark.py
"""
import gc

def consume_items(dico):
for key, value in dico.items():
pass


def consume_iteritems(dico):
for key, value in dico.iteritems():
pass


def run_benchmark(bench):
for nkeys in (10, 10**3, 10**6):
bench.start_group('%s keys' % nkeys)
dico = {str(index): index for index in range(nkeys)}

bench.compare_functions(
('iteritems', consume_iteritems, dico),
('items', consume_items, dico),
)
dico = None
gc.collect()
gc.collect()

if __name__ == "__main__":
import benchmark
benchmark.main()
__
OpenStack Development Mailing 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] Looking for help getting git-review to work over https

[KARR, DAVID]

I could use some help with setting up git-review in a slightly unfriendly 
firewall situation.

I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the 
non-standard ssh port.  I'm following the instructions at 
http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
 , for configuring git-review to use https on port 443, but this still isn't 
working (times out with "Could not connect to gerrit").  I've confirmed that I 
can reach other external sites on port 443.

Can someone give me a hand with this?

--
David M. Karr | AT&T | Service Standards - Open Platform for Network Function 
Virtualization
(425) 580-4547 work
(206) 909-0664 cell
(425) 892-5432 cell


__
OpenStack Development Mailing 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 Ann Kamyshnikova for the API & DB core reviewer team

[Mike Bayer]

+1 to Ann !


On 6/11/15 10:34 AM, Henry Gessau wrote:

As one of the Lieutenants [1] for the API and DB areas under the PTL, I would
like to propose Ann Kamyshnikova as a member of the Neutron API and DB core
reviewer team.

Ann has been a long time contributor in Neutron showing expertise particularly
in database matters. She has also worked with and contributed code to the
oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the
Neutron "database healing" effort that was completed in the Juno cycle.

Her deep knowledge of databases and backends, and her expertise with oslo.db,
sqlalchemy and alembic will be very important in this area. Ann is a trusted
member of our community and her review stats [2][3][4] place her comfortably
with other Neutron core reviewers. She consistently catches database issues
early when patches are submitted for review, and shows dedication to helping
developers understand and perfect their database-related changes.

Existing Neutron core reviewers from the API and DB area of focus, please vote
+1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm
looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl.


[1]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
[2]
https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
[3] http://stackalytics.com/report/contribution/neutron-group/90
[4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks




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



__
OpenStack Development Mailing 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] Looking for help getting git-review to work over https

[Dulko, Michal]

In our environment we're using SOCKS proxy to bypass firewall. Maybe it's an 
option for you? I just execute tsocks git-review instead of plain git-review 
and it seem to work.

I've just tried solution you've mentioned and it doesn't help in my case.

> -Original Message-
> From: KARR, DAVID [mailto:dk0...@att.com]
> Sent: Thursday, June 11, 2015 5:00 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] Looking for help getting git-review to work over
> https
> 
> I could use some help with setting up git-review in a slightly unfriendly
> firewall situation.
> 
> I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the
> non-standard ssh port.  I'm following the instructions at
> http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-
> over-https , for configuring git-review to use https on port 443, but this 
> still
> isn't working (times out with "Could not connect to gerrit").  I've confirmed
> that I can reach other external sites on port 443.
> 
> Can someone give me a hand with this?
> 
> --
> David M. Karr | AT&T | Service Standards - Open Platform for Network
> Function Virtualization
> (425) 580-4547 work
> (206) 909-0664 cell
> (425) 892-5432 cell
> 
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [oslo] Adopt mox3

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2015-06-11 05:58:44 -0400:
> Victor,
> 
> Monty had a github repo, that's where we are starting from. The idea
> is to rely on our day to day tools here in the openstack ecosystem to
> maintain the project. If one of the original authors shows up, we'll
> see what we can do. Given that the code is Apache License 2.0, we are
> ok to pick this up.

Right, the problem with github is that unless we do some work to enable
multiple users to have access to the repo, we're in the situation we
have now where the owner is traveling or otherwise unavailable and we
can't release the fix we need. Moving the lib into our CI system expands
the number of people who can make changes, and also lets us use our
release automation.

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

[Daniel P. Berrange]

On Thu, Jun 11, 2015 at 03:02:13PM +0100, Daniel P. Berrange wrote:
> On Thu, Jun 11, 2015 at 12:54:54PM +0200, Andreas Scheuring wrote:
> > On Thu, 2015-06-11 at 09:30 +0100, Daniel P. Berrange wrote:
> > 
> > > It seems the main reason for your new proposal is to deal with
> > > the fact that on migration, you need to specify a different
> > > NIC name in the XML. This is not particularly difficult - Nova
> > > already has code for dealing with pdating the XML - the _update_xml
> > > method in nova.virt.libvirt.driver just needs extending to cover
> > > that.
> > 
> > Right, that's why I considered the libvirt network vif type. 
> > 
> > I also considered to use direct macvtap attachments exploiting the
> > xml-modify feature you just mentioned. My big problem in this case is,
> > that the domain.xml contains the physical eth interface name which will
> > be used as source for the macvtap. Only neutron agent knows about that.
> > It's configured in his interface_mappings. On vif_binding, neutron
> > serves nova the eth interface name via the vif data. That's working fine
> > - I already implemented a prototype for that which was working greatly -
> > as long you not do live Migration.
> > 
> > During pre-livemigration on the target host I would need to figure out
> > which interface should be used and give this information back to the
> > source via the pre migration data. But therefore nova needs to talk to
> > my new neutron agent. I don't think that such a shortcut is a good
> > approach. I'm not aware of any similar thing from other drivers. 
> > 
> > The poor alternative I see would be to duplicate the interface_mapping
> > config to nova, but that's also not a proper approach. 
> > 
> > I also had a look at the sriov macvtap live migration blueprint [4] but
> > the situation there is slightly different, as nova knows about all pci
> > devices that can be used. No interaction with neutron would be needed. I
> > also thought on jumping on this boat somehow, but the sriov macvtap
> > support is too tightly coupled to pci. I want a general purpose macvtap
> > driver that doesn't care about vendor specifics, but working with any
> > ethernet device...
> > 
> > Do you have any ideas how to achieve this?
> 
> I could have sworn I've previously reviewed patches which dealt with
> NIC device naming changes across migration, but I can't find them
> now. Did you ever submit patches which tried to fix this, or am I
> perhaps thinking of someone elses.
> 
> I understand the difficulty in getting the information across to
> the right place, but I thought I remembered seeing a solution ot
> that. Failing that though, the other option is to rename the ethernet
> devices when assigning them to a guest, so they have a stable name
> across hosts.

I wasn't imaginging it - this spec about SRIOV live migration deals
with exactly the scenario you describe with macvtap

https://review.openstack.org/#/c/136077/9/specs/liberty/approved/sriov-live-migration.rst


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] [congress] table with named parameters in rule's left side ?

[Pospisil, Radek]

Hi Tim,

Thanks for clarifications.
Ad 4) I saw dictionary for key-name tuples in action-execution API

Ad 5) It is backup plan ☺ to have sufficient number of columns in the 
predeploy_modification table, so it won’t be readable, but it will work. My 
original intention is to use named parameters to give ability to specify more 
than one ‚property‘ in one action (e.g., 
predeploy_modificatino(,..‘add_object‘, type, p1=v1, p2=v2, p3=v3))

  Regards,

Radek

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Thursday, June 11, 2015 4:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [congress] table with named parameters in rule's 
left side ?

Hi Radek,
1. You can't use column references on any table except those created by a 
datasource, mainly because Congress doesn't know the name of the columns for 
those tables.  We've kicked around the idea of letting policy-writers declare 
the column names of any table, but it's trickier than it sounds.

2. Even if we solved (1), there's not much point in using column-references in 
the head (left-hand-side) of a rule because you always need to include all of 
the columns anyway.  That restriction is baked deeply into the semantics of the 
language: if you leave out a column in the head the size of the table is 
infinite.  The only benefit to column-references in the head would be enabling 
you to specify the columns in any order.

3. I've thought about tweaking the semantics of Datalog so that it includes 
both tuples and dictionaries.  But that is a major effort.

4. We don't actually allow column-references even within execute[ action(...)] 
because of (2).

5.  In your example, can you write it without the column references?  I don't 
see the predeploy_modify rule to understand why you need column references in 
the query.

 predeploy_modify(,,'add_property', 5, name="image”, value="")
Tim



On Thu, Jun 11, 2015 at 6:44 AM Pospisil, Radek 
mailto:radek.pospi...@hp.com>> wrote:
Hello,

Is it possible to have named parameters on rule’s left side, for example:


1.   predeploy_modify(eid,oid,"add_property",5, name=”image”, value=pvalue) 
:- …. Glancev2:images(name=pvalue,…)

2.   predeploy_modify(eid,oid,"add_object", 10, type=”monitoring”, 
port=8190, path=”/aa/bb”) :- ….

My Usecase is following – I want to use Congress to provide me list of 
‘actions’ that I have to do on Murano environment prior it is deployed – for 
example:

• I want to enforce/use specific image for given component(s) in 
environment, so I set corresponding property (example 1)

• I want to add an object (monitoring) with properties to environment  
(example 2)

Thus generally “I want to query for one rule with variable set/dictionary of 
arguments” – for example using simulation API:
$ openstack congress policy simulate test 'predeploy_modify()' '' action
Result will be
predeploy_modify(,,'add_property', 5, name="image”, value="")
predeploy_modify(,,'add_object', 10, type="monitoring", port="…", 
path="…")



The problem is that if I do (as an example):

$  openstack congress policy rule create test "a(o,p,q=4) :- b(o),b(p)"
ERROR: openstack Syntax error for rule::Compiler found errors:Atom a(q=4) uses 
named parameters but the columns for table a have not been declared.
Atom a(q=4) uses named parameters but the columns for table a have not been 
declared. (HTTP 400) (Request-ID: req-b05683e6-766a-4be8-a238-5811eb6f7125)


So is it possible to use named parameters on not-declared tables?
I know that it is possible to do for “execute[ action(…) ] :- “, where 
positional and keyword/named set of parameters is passed to action-executor.


  Regards,

Radek
__
OpenStack Development Mailing 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] vif type libvirt-network

[Andreas Scheuring]

Daniel, thanks a lot for your input! Please see my novel below ;)

> I could have sworn I've previously reviewed patches which dealt with
> NIC device naming changes across migration, but I can't find them
> now. Did you ever submit patches which tried to fix this, or am I
> perhaps thinking of someone elses.

> I understand the difficulty in getting the information across to
> the right place, but I thought I remembered seeing a solution ot
> that. Failing that though, the other option is to rename the ethernet
> devices when assigning them to a guest, so they have a stable name
> across hosts.


This was in the spec of sriov-live-migration with macvtap [4]
I already talked to Robert Li who is the main owner of this spec. 
What they are finally doing is to modify the xml with the new source
device name during pre_live_migration. But as it's in the pci context,
they can figure out the target interface name via the nova pci manager -
I would need to talk to neutron.

For Device renaming I would required another unique identifier which can
be used for everlasting configuration on a host, as the device name is
not stable anymore. The only thing that comes to my mind is the mac
address. It could be used as identifier on all distros, regardless of
the network adapter type used. Then on agent start, the neutron agent
could rename the interface along a calculated pattern (e.g.
net_ or whatever)

The disadvantage would be, that the value of the interface_mappings
parameter, that maps and interface to a physical network will look
differently on every hypervisor (as there's another mac on each host).
But that would be a compromise that would be ok I guess (maybe a little
more difficult for chef deployment)

These are the disadvantages Rob pointed out:

"The approach was initially chosen and implemented. One of the issues is
how to revert the interface back to its original interface name once the
interface is freed. In addition, changing the names back and forth is
considered by some people as being a bit complicated."

I will think about these concerns as well, but they seem not to be
unsolvable! Anyhow this will be in the scope of neutron in my case, so
nothing nova should worry about too much.


So for now I see the following approaches: 

1) Use the mac address as identifier in the interface_mappings
configuration and rename the corresponding interface to a openstack
global name (e.g net_). This ensures that the device has
the same name on each hypervisor

2) Document, that for Live Migration the admin has to ensure, that the
eth devices use for a physical network, must have the same name over all
nodes.

3) Duplicate the neutron config with the interface_mappings to nova.conf

4) Have a shortcut between nova and neutron to figure out the target
device name before live migration


In all 4 cases both vif_types would be thinkable:

a) use macvtap vif_type (direct) in domain.xml [2]
--> vif plug/unplug would be required for creating vlan/vxlan devices

b) use libvirt network vif_type in domain.xml [1]
--> vif plug/unplug has to create the libvirt network and vlan/vxlan
devices
--> no additional value add comes with the libvirt network approach



The most promising solutions sound to be 1 a). But I still need to
figure out more details about device renaming and what other side
effects might come with it.

At least it looks like that I can drawback my blueprint for a libvirt
network vif type [1], as it does not bring any additional benefits...

Or do you still see anything that might justify the libvirt-network
type?

Or would you prefer another option, or even have a better one? ;)


Thanks!



[1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
[2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
[3] https://launchpad.net/networking-macvtap
[4] https://blueprints.launchpad.net/nova/+spec/sriov-live-migration

-- 
Andreas 
(irc: scheuran)





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

[openstack-dev] [keystone] [nova] [oslo] [neutron][cross-project] Split Policy rules into two parts.

[Adam Young]

Sean had a really good point when he mentioned that the Developers know 
what need to be enforced, and I think this is why he suggested that the 
base policy implementation be in Python code, not the policy JSON DSL.


The main thrust of the dynamic policy has been to get the role-to-api 
assignment more flexible.  However, there is another side to each policy 
rule; figureing out where the project (nee' tenant) id is in the 
request;  is it part of the URL, part of the request body, or in the 
object returned from the database.  This part really should be handled 
by the developer working on the policy rule, and it should not be changed.


So...what if we say that we split policy into two checks;  a role check, 
and a scope check.  Both checks must pass in order for the user to get 
access to the API.  The Scope check is not going to be dynamic;  once 
set, they will pretty much stay set.   It might be done using the 
policy.json, or done in code, but it will be separate from the role check.



The Neutron policy checks for things like

|"shared": "field:networks:shared=True", "shared_firewalls": 
"field:firewalls:shared=True", "shared_firewall_policies": 
"field:firewall_policies:shared=True", "shared_subnetpools": 
"field:subnetpools:shared=True",


Would be handled by the dev teams later policy check; anything that 
requires actually fetching the object from the database is postponed to 
this stage.

|



The role check will come from the policy.json file.  This will allow the 
operator to fine tune how roles are handled.  Any thing else that can be 
explicitly checked based on the token will be fair game, but not API 
specific values;  no database fetch will be performed at this point.  
The assumption is that this policy check could be generic enough to be 
performed in middleware, and might even be enforced based on the URL 
instead of the pseudo random namespacing we do now.


Does this suggestion work for Nova?  I think it will make the overall 
policy much easier to maintain in the field.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

[James E. Blair]

Emilien Macchi  writes:

> On my side, I can take care of 1/ make sure the repo is on Stackforge
> (for start, then it will move under OpenStack namespace once done) 2/
> help in unit/functional testing (rspec, beaker).

If the PuppetOpenStack project will be adopting this, then we can just
go ahead and start it in openstack/.  You can create the project-config
change that way, and then adjust the list of repos in the governance
repository later (prior TC approval is not needed for trivial repository
additions to existing projects).

-Jim

__
OpenStack Development Mailing 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] [ceilometer] midcycle meetup poll

[gordon chung]

hi,

for those interested, we have a doodle up for possible dates to host a midcycle 
meetup: doodle.com/64b5x9q4kkmxx4eq

some conditions to assume:
- it will be 3-4 days
- possible host sites include but are not limited to: dublin, berlin, paris, or 
montreal

please vote ASAP so we can plan appropriately if there is enough interest. we 
will close voting in a week so tell your friends and family.

cheers,
gord
  
__
OpenStack Development Mailing 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 Ann Kamyshnikova for the API & DB core reviewer team

[Kyle Mestery]

On Thu, Jun 11, 2015 at 9:34 AM, Henry Gessau  wrote:

> As one of the Lieutenants [1] for the API and DB areas under the PTL, I
> would
> like to propose Ann Kamyshnikova as a member of the Neutron API and DB core
> reviewer team.
>
> Ann has been a long time contributor in Neutron showing expertise
> particularly
> in database matters. She has also worked with and contributed code to the
> oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to
> the
> Neutron "database healing" effort that was completed in the Juno cycle.
>
> Her deep knowledge of databases and backends, and her expertise with
> oslo.db,
> sqlalchemy and alembic will be very important in this area. Ann is a
> trusted
> member of our community and her review stats [2][3][4] place her
> comfortably
> with other Neutron core reviewers. She consistently catches database issues
> early when patches are submitted for review, and shows dedication to
> helping
> developers understand and perfect their database-related changes.
>
> Existing Neutron core reviewers from the API and DB area of focus, please
> vote
> +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm
> looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and
> Carl.
>
>
+1

And thanks for expanding the Neutron core reviewer team along the lines of
our new Lieutenant based area of focus direction Henry!

Kyle


> [1]
>
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
> [2]
>
> https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
> [3] http://stackalytics.com/report/contribution/neutron-group/90
> [4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] How does instance's tap device macaddress generate?

[Andreas Scheuring]

Maybe this helps (taken from [1])

"Actually there is one way that the MAC address of the tap device
affects
proper operation of guest networking - if you happen to set the tap
device's MAC identical to the MAC used by the guest, you will get errors
from the kernel similar to this:


  kernel: vnet9: received packet with own address as source address"



[1] http://www.redhat.com/archives/libvir-list/2012-July/msg00984.html
-- 
Andreas 
(irc: scheuran)


On Thu, 2015-06-11 at 21:48 +0800, changzhi wrote:
> Hi, I know that neutron port's mac address was generated by
> neutron.conf and default value is "fa:16:3e" which from base_mac
> configuration. I don't know how the tap device's mac address generates
> and why tap device mac address was "fe:16:3e:xxx". I think that tap
> device mac address was generated by libvirt. 
> 
> 
> Thx
> changzhi
>  
>  
> -- Original --
> From:  "Radek Smigielski";
> Date:  Thu, Jun 11, 2015 07:26 PM
> To:  "OpenStack Development Mailing List (not for usage
> questions)"; 
> 
> Subject:  Re: [openstack-dev] How does instance's tap device
> macaddress generate?
>  
> > On Thursday, 11 June 2015, 12:00:46, Neil Jerram
>  wrote:
> > > On 11/06/15 10:47, changzhi wrote:
> >>  Hi, all.
> >>  I create a vm and it's neutron port's mac address is
> >>  "fa:16:3e:3f:02:ff". I see "fa:16:3e:3f:02:ff" inside 
> > vm when I run
> >>  "ifconfig eth0". Why does vm's tap device's mac address 
> > is
> >>  "fe:16:3e:3f:02:ff"? Why different between neutron port's mac 
> > address
> >>  and tap device's mac address? Does libvirt create instance tap
> device
> >>  and its mac address is generated randomly?
> >> 
> >>  Thx
> >>  zhi
> > 
> > There are two MAC addresses, one at each end of the link between
> the 
> > host and the VM.
> > 
> > ---+
> >   Host  |   +---+
> > |   | VM|
> >  tap12345-CD --- eth0   |
> >   fa:16:3e:56:71:42 |   | fa:16:3e:3f:02:ff |
> > |   |   |
> > |   +---+
> > ---+
> > 
> > I believe that both of these addresses are randomly generated,
> although 
> > I'm not sure exactly which components do that.
> > 
> > Does that help at all?
> > 
> > Thanks,
> > Neil
> 
> 
> 
> In neutron.conf you've got base_mac option and "fa:16:3e" is the
> default value.
> 
> # Base MAC address. The first 3 octets will remain unchanged. If the
> # 4h octet is not 00, it will also be used. The others will be
> # randomly generated.
> # 3 octet
> # base_mac = fa:16:3e:00:00:00
> # 4 octet
> # base_mac = fa:16:3e:4f:00:00
> 
> 
> 
> 
> 
> Cheers,
> Radosław Śmigielski
> 
> __
> OpenStack Development Mailing 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] Looking for help getting git-review to work over https

[Yuriy Taraday]

On Thu, Jun 11, 2015, 18:09 KARR, DAVID  wrote:

I could use some help with setting up git-review in a slightly unfriendly
firewall situation.

I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks
the non-standard ssh port.  I'm following the instructions at
http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
, for configuring git-review to use https on port 443, but this still isn't
working (times out with "Could not connect to gerrit").  I've confirmed
that I can reach other external sites on port 443.

Can someone give me a hand with this?



 Hello.


- Can you please post all output from "git review -vs"?

- Do you have "gerrit" remote already configured?

- Do you have access to https://review.openstack.org/ from your browser?

- Can you access it from command line (via "curl -I
https://review.openstack.org/"; for example)?

- Does "git ls-remote https://review.openstack.org/openstack/nova >
/dev/null" produce and error?
__
OpenStack Development Mailing 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] [OpenStack-Infra][cinder] Request for re-integration of Oracle ZFSSA iSCSI Driver

[Diem Tran]

Dear Cinder team,

Sorry if this message appears duplicated to you. I'd like to kindly 
request re-integration of Oracle ZFSSA iSCSI Cinder driver to 2 
branches: master and stable/kilo:

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

The iSCSI CI has been working stably since 6/8, and the patchset is 
ready to be reviewed. The complete reports list can be found here:

https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z

Please let me know if you have any question.

Thanks,
Diem.





__
OpenStack Development Mailing 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] L3 routed network segments

[Carl Baldwin]

Neil,

I'm very glad to here of your interest.  I have been talking with Kyle
Mestery about the rfe you mention [1] since the day he filed it.  It
relates to a blueprint that I have been trying to get traction on [2]
in various forms for a while [*].

The rfe talks about attaching VMs directly to the the L3 routed
network.  This will require some coordination between ip address
assignment and scheduling of the instance to a compatible physical
server.

My blueprint, on the other hand, tries to maintain IP mobility across
the network by relying on the BGP speaker work:  another BP we've been
trying to get traction on for a while.  I also limit the connections
to the L3 routed network to virtual routers for now.

The two have network segments in common.  So, as I proceed on the
implementation of my blueprint [2], I will keep in mind the needs of
the rfe [1] and build network segments in a way which can be utilized
by both.  However, I will leave the coordination of VM scheduling and
IP address assignment to someone else.  Does this all make sense?

Currently, I have my development efforts mostly consumed in the
address scopes blueprint.  However, I would like to find a way to pass
that on soon so that I can turn my attention toward the network
segments work.

Let's find some time to look at what first steps we can get started.
Ping me directly on IRC.

Carl

[1] https://bugs.launchpad.net/neutron/+bug/1458890
[2] https://review.openstack.org/#/c/172244/
[*] You're not the only one having trouble getting traction.
Sometimes it takes a while to realize that we're interested in similar
things and to find the commonalities and then to get people excited
about something.  It has been an uphill battle for me until recently.

On Thu, Jun 11, 2015 at 6:16 AM, Neil Jerram  wrote:
> Hi Carl et al.,
>
> I see from [1] that L3 routed network segments are on the Neutron L3
> subteam's roadmap for Liberty, and I wanted to say that I'm very interested
> in this work, and - if there isn't someone else already - happy to take the
> lead on making it happen.
>
> I'm aware already of several parties interested in this work, and discussion
> between those parties has been proceeding at [2].  If there is anyone else
> interested - i.e. in networks that are predominantly L3 routed, and/or where
> L2 broadcast is partitioned into subsets of the overall network - please do
> take a look at that bug [2] and add your thoughts there, or comment in
> response to this email.
>
> I'm afraid I've not previously been attending L3 subteam IRC meetings -
> something which I now see was a mistake! - but I plan to do that from now
> on.  For today's meeting, though, I'm afraid I have to leave at the half way
> point.  Therefore, if you (Carl) think it would be useful to raise or
> discuss this during the meeting, I'd appreciate if that could be scheduled
> during the first half hour.
>
> Many thanks,
> Neil
>
>
> [1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
> [2] https://bugs.launchpad.net/neutron/+bug/1458890

__
OpenStack Development Mailing 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 Ann Kamyshnikova for the API & DB core reviewer team

[Carl Baldwin]

+1!

On Thu, Jun 11, 2015 at 8:34 AM, Henry Gessau  wrote:
> As one of the Lieutenants [1] for the API and DB areas under the PTL, I would
> like to propose Ann Kamyshnikova as a member of the Neutron API and DB core
> reviewer team.
>
> Ann has been a long time contributor in Neutron showing expertise particularly
> in database matters. She has also worked with and contributed code to the
> oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the
> Neutron "database healing" effort that was completed in the Juno cycle.
>
> Her deep knowledge of databases and backends, and her expertise with oslo.db,
> sqlalchemy and alembic will be very important in this area. Ann is a trusted
> member of our community and her review stats [2][3][4] place her comfortably
> with other Neutron core reviewers. She consistently catches database issues
> early when patches are submitted for review, and shows dedication to helping
> developers understand and perfect their database-related changes.
>
> Existing Neutron core reviewers from the API and DB area of focus, please vote
> +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm
> looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl.
>
>
> [1]
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
> [2]
> https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
> [3] http://stackalytics.com/report/contribution/neutron-group/90
> [4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Adding metadata to VM through Horizon

[Fox, Kevin M]

It is not. :/

Thanks,
Kevin

From: Srikanth Kumar Lingala [srikanth.ling...@freescale.com]
Sent: Thursday, June 11, 2015 2:46 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Adding metadata to VM through Horizon

Hi Stackers,
I know that I can add metadata information (Key – Value parameters) to a VM 
through ‘nova boot’ command.
But, I didn’t find the facility through Harizon pages. Does anybody know 
whether the feature is available through Openstack Dashboard?

Please let me know.

Regards,
Srikanth.
__
OpenStack Development Mailing 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] Looking for help getting git-review to work over https

[KARR, DAVID]

Thanks for replying.

% git review -vs
2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 09:30:38.399021 Running: git remote
2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 09:30:38.402988 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git --all
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not work.
Could not connect to gerrit.
Enter your gerrit username:

This output is interesting, because I followed the instructions to set the 
scheme and port to https and 443, which can be seen from:
% git config --global -l
user.name=David Karr
user.email=dk0...@att.com
gitreview.scheme=https
gitreview.port=443

Concerning the question ‘Do you have "gerrit" remote already configured?’, I 
guess I’d have to say I don’t know. I’ve followed instructions for setting up 
my pub key, but I’m not sure exactly what is entailed in “gerrit remote”.

I can get to https://review.openstack.org/ from my browser and from the command 
line with curl.

The “ls-remote” command returns without error (or any other output).

From: Yuriy Taraday [mailto:yorik@gmail.com]
Sent: Thursday, June 11, 2015 9:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https


On Thu, Jun 11, 2015, 18:09 KARR, DAVID mailto:dk0...@att.com>> 
wrote:

I could use some help with setting up git-review in a slightly unfriendly 
firewall situation.

I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the 
non-standard ssh port.  I'm following the instructions at 
http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
 , for configuring git-review to use https on port 443, but this still isn't 
working (times out with "Could not connect to gerrit").  I've confirmed that I 
can reach other external sites on port 443.

Can someone give me a hand with this?





Hello.



- Can you please post all output from "git review -vs"?

- Do you have "gerrit" remote already configured?

- Do you have access to https://review.openstack.org/ from your browser?

- Can you access it from command line (via "curl -I 
https://review.openstack.org/"; for example)?

- Does "git ls-remote https://review.openstack.org/openstack/nova > /dev/null" 
produce and error?
__
OpenStack Development Mailing 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] service chaining feature development meeting at 10am pacific time June 11

[Mooney, Sean K]

Hi can anyone provide a link to today's irc meeting logs?

Looking at http://eavesdrop.openstack.org/meetings/ I cannot see a 
Neutron_Service_Chaining_meeting directory
Are the logs being stored in 
http://eavesdrop.openstack.org/meetings/service_chaining/2015/ ?
If so the logs for today's meeting seem to be missing.

Regards
sean
From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Thursday, June 11, 2015 1:45 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] service chaining feature development 
meeting at 10am pacific time June 11

Here is the updated agenda for tomorrow's meeting:


1. Update on last meeting's action items

2.   Neutron port chain API for SFC

3.   Unified API and data model for flow classifier that can be used for 
SFC, QoS, Packet forwarding etc.

4. Summary on the SFC Feature project scope: functional module breakdown 
and their architecture relationship, and Module development ownership sign-up

5. Deep dive into technical questions on etherpad if there is time.

Thanks,
Cathy

From: Cathy Zhang
Sent: Wednesday, June 10, 2015 3:23 PM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [Neutron] service chaining feature development 
meeting at 10am pacific time June 11

Add the following item to the agenda:

unified data model for flow classifiers

Thanks,
Cathy

From: Cathy Zhang
Sent: Wednesday, June 10, 2015 3:12 PM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Subject: [openstack-dev] [Neutron] service chaining feature development meeting 
at 10am pacific time June 11

Hello everyone,

Our next weekly IRC meeting for the OpenStack service chain feature development 
is 10am pacific time June 11 (UTC 1700, hope I am doing the correct time 
conversion this time)  Following is the meeting info:

Weekly on Thursday at 1700 
UTC 
in #openstack-meeting-4

You can also find the meeting info at 
http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting

Agenda:

6. Update on last meeting's action items

7. Summary on the SFC Feature project scope: functional module breakdown 
and their architecture relationship as well as their relationship to OpenStack 
Neutron, the types of service functions that will be chained in this feature 
development

8. Module development ownership sign-up

9. Deep dive into technical questions on etherpad if there is time.


Anyone who would like to contribute to this feature development is welcome to 
join the meeting. Hope the time is good for most people.





Thanks,

Cathy



__
OpenStack Development Mailing 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] Voting on the Nova project meeting times

[John Garbutt]

On 5 June 2015 at 10:50, John Garbutt  wrote:
> On 4 June 2015 at 12:54, John Garbutt  wrote:
>> Hi,
>>
>> We have a regular Nova project meeting with alternating times, as
>> described here:
>> https://wiki.openstack.org/wiki/Meetings/Nova
>>
>> I will lean towards no change of the times, given we are used to them.
>> But I want to double check there if there is a group of contributors
>> we are accidentally excluding due to the times we have picked.
>>
>> Please vote here:
>> http://doodle.com/eyzvnawzv86ubtaw
>
> I forgot to mention... the poll closes at the start of the next Nova
> meeting on June 11:
> https://wiki.openstack.org/wiki/Meetings/Nova
>
> That's what I promised in the Nova meeting last week.
>
>> If doodle doesn't work in your country, or whatever, do email me
>> directly and I can add in your vote. I could have used something
>> better, but doodle was easy.
>>
>> Thanks,
>> John

Turns out we already have the best set of times, based on who responded.

Thanks,
John

PS
Only one person said no to both of the current times, but they didn't
leave their name. Apologies to that person.

Moving the 2100UTC one hour later would mean I could attend all the
time, all be it when half asleep, but it would really screw over most
other folks, so lets not do that.

__
OpenStack Development Mailing 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] Nominating Joshua Hesketh for infra-root

[James E. Blair]

The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access).  Read all about it here:

  http://docs.openstack.org/infra/system-config/project.html#teams

Joshua has been a valuable member of infra-core for some time, having a
high degree of familiarity with Zuul and related systems and an
increasing interest in other operational aspects of the project
infrastructure.  His eagerness to contribute is presently tempered by
most of the infra-root team sleeping[1] during large parts of his day.
I look forward to Joshua being able to approve changes with confidence.

Joshua, if you are interested, please propose your SSH key to
system-config, and thanks again for all of your work!

-Jim
[1] contrary to widely-held belief, this does happen

__
OpenStack Development Mailing 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] Service group foundations and features

[Vilobh Meshram]

Few more places which can trigger inconsistent behaviour.

-
https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/services.py#L44

-
https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/hypervisors.py#L98

-
https://github.com/openstack/nova/blob/stable/kilo/nova/availability_zones.py#L130

-
https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/availability_zone.py#L68

-
https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/hosts.py#L88-L89

-
https://github.com/openstack/nova/blob/stable/kilo/nova/compute/api.py#L3399-L3421
.


Blueprint which plans to fix this :
https://blueprints.launchpad.net/nova/+spec/servicegroup-api-control-plane

Related Spec : 1) https://review.openstack.org/#/c/190322/

   2) https://review.openstack.org/#/c/138607/

-Vilobh


On Mon, May 11, 2015 at 8:08 AM, Chris Friesen 
wrote:

> On 05/11/2015 07:13 AM, Attila Fazekas wrote:
>
>> From: "John Garbutt" 
>>>
>>
>  * From the RPC api point of view, do we want to send a cast to
>>> something that we know is dead, maybe we want to? Should we wait for
>>> calls to timeout, or give up quicker?
>>>
>>
>> How to fail sooner:
>> https://bugs.launchpad.net/oslo.messaging/+bug/1437955
>>
>> We do not need a dedicated is_up just for this.
>>
>
> Is that really going to help?  As I understand it if nova-compute dies (or
> is isolated) then the queue remains present on the server but nothing will
> process messages from it.
>
> Chris
>
>
> __
> OpenStack Development Mailing 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] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

[Richard Raseley]

James E. Blair wrote:

If the PuppetOpenStack project will be adopting this, then we can just
go ahead and start it in openstack/.  You can create the project-config
change that way, and then adjust the list of repos in the governance
repository later (prior TC approval is not needed for trivial repository
additions to existing projects).


Jim,

Thanks so much for this information. I spoke to Emilien and will be 
building out the 'cookie cutter' module tomorrow, and hope to push to 
the new repository.


If I have questions at that time, may I reach out to you on IRC?

Regards,

Richard

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

Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API & DB core reviewer team

[Doug Wiegley]

I wasn’t on your list, but I’m thinking positive thoughts, that rhyme with 
“+1”. Ann’s db reviews are always extremely helpful.

doug


> On Jun 11, 2015, at 10:27 AM, Carl Baldwin  wrote:
> 
> +1!
> 
> On Thu, Jun 11, 2015 at 8:34 AM, Henry Gessau  wrote:
>> As one of the Lieutenants [1] for the API and DB areas under the PTL, I would
>> like to propose Ann Kamyshnikova as a member of the Neutron API and DB core
>> reviewer team.
>> 
>> Ann has been a long time contributor in Neutron showing expertise 
>> particularly
>> in database matters. She has also worked with and contributed code to the
>> oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to 
>> the
>> Neutron "database healing" effort that was completed in the Juno cycle.
>> 
>> Her deep knowledge of databases and backends, and her expertise with oslo.db,
>> sqlalchemy and alembic will be very important in this area. Ann is a trusted
>> member of our community and her review stats [2][3][4] place her comfortably
>> with other Neutron core reviewers. She consistently catches database issues
>> early when patches are submitted for review, and shows dedication to helping
>> developers understand and perfect their database-related changes.
>> 
>> Existing Neutron core reviewers from the API and DB area of focus, please 
>> vote
>> +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm
>> looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl.
>> 
>> 
>> [1]
>> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
>> [2]
>> https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
>> [3] http://stackalytics.com/report/contribution/neutron-group/90
>> [4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks
>> 
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing 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 Ann Kamyshnikova for the API & DB core reviewer team

[Armando M.]

+1

On 11 June 2015 at 09:27, Carl Baldwin  wrote:

> +1!
>
> On Thu, Jun 11, 2015 at 8:34 AM, Henry Gessau  wrote:
> > As one of the Lieutenants [1] for the API and DB areas under the PTL, I
> would
> > like to propose Ann Kamyshnikova as a member of the Neutron API and DB
> core
> > reviewer team.
> >
> > Ann has been a long time contributor in Neutron showing expertise
> particularly
> > in database matters. She has also worked with and contributed code to the
> > oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor
> to the
> > Neutron "database healing" effort that was completed in the Juno cycle.
> >
> > Her deep knowledge of databases and backends, and her expertise with
> oslo.db,
> > sqlalchemy and alembic will be very important in this area. Ann is a
> trusted
> > member of our community and her review stats [2][3][4] place her
> comfortably
> > with other Neutron core reviewers. She consistently catches database
> issues
> > early when patches are submitted for review, and shows dedication to
> helping
> > developers understand and perfect their database-related changes.
> >
> > Existing Neutron core reviewers from the API and DB area of focus,
> please vote
> > +1/-1 for the addition of Ann to the core reviewer team. Specifically,
> I'm
> > looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and
> Carl.
> >
> >
> > [1]
> >
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
> > [2]
> >
> https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
> > [3] http://stackalytics.com/report/contribution/neutron-group/90
> > [4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] Add table to Nova DB

[Jay Pipes]

Replying to openstack-dev ML, which is where this question belongs.

On 06/11/2015 11:10 AM, Silvia Fichera wrote:

Hi all,
I have to add a table to Nova DB (I will populated it statically by now).
I found this post:
http://stackoverflow.com/questions/19424901/how-to-add-a-table-in-nova-database-openstack
But since it is a little bit "old" I need to know if there are any
changes and if it is the right way to follow.
In this table I want to report network stats information (latency,
badwidth, etc.). By now I want to insert manually those data.


I know this is going to sound harsh, but you should not be extending 
Nova's database in any way outside of submissions to the upstream Nova 
codebase.


What it sounds like you want to do is to publish network statistics 
(bandwidth/IO in and out of VMs) about your instances. If that is 
correct, you should probably look to the Ceilometer project to meet your 
needs.


Best,
-jay

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

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

[Dolph Mathews]

On Thu, Jun 11, 2015 at 12:34 AM, Robert Collins 
wrote:

> On 11 June 2015 at 17:16, Robert Collins 
> wrote:
>
> > This test conflates setup and execution. Better like my example,
> ...
>
> Just had it pointed out to me that I've let my inner asshole out again
> - sorry. I'm going to step away from the thread for a bit; my personal
> state (daughter just had a routine but painful operation) shouldn't be
> taken out on other folk, however indirectly.
>

Ha, no worries. You are completely correct about conflating setup and
execution. As far as I can tell though, even if I isolate the dict setup
from the benchmark, I get the same relative differences in results.
iteritems() was introduced for a reason!

If you don't need to go back to .items()'s copy behavior in py2, then
six.iteritems() seems to be the best general purpose choice.

I think Gordon said it best elsewhere in this thread:

> again, i just want to reiterate, i'm not saying don't use items(), i just
think we should not blindly use items() just as we shouldn't blindly use
iteritems()/viewitems()


>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Looking for help getting git-review to work over https

[Kevin L. Mitchell]

On Thu, 2015-06-11 at 16:42 +, KARR, DAVID wrote:
> Concerning the question ‘Do you have "gerrit" remote already
> configured?’, I guess I’d have to say I don’t know. I’ve followed
> instructions for setting up my pub key, but I’m not sure exactly what
> is entailed in “gerrit remote”.

The "git review" command does its magic, in part, through configuring a
"git remote" on the repository.  Go to the repository and do a "git
remote -v" and look for any lines beginning with "gerrit"; they probably
have the SSH URL instead of the https URL.  You should be able to use
"git remote remove gerrit" and re-run the "git review -s" to get that
all fixed up.  (Could also use "git remote set-url", FYI, but I figured
starting from scratch may be easier for you…)
-- 
Kevin L. Mitchell 
Rackspace


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

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

[Mike Bayer]

On 6/11/15 1:39 PM, Dolph Mathews wrote:


On Thu, Jun 11, 2015 at 12:34 AM, Robert Collins 
mailto:robe...@robertcollins.net>> wrote:


On 11 June 2015 at 17:16, Robert Collins
mailto:robe...@robertcollins.net>> wrote:

> This test conflates setup and execution. Better like my example,
...

Just had it pointed out to me that I've let my inner asshole out again
- sorry. I'm going to step away from the thread for a bit; my personal
state (daughter just had a routine but painful operation) shouldn't be
taken out on other folk, however indirectly.


Ha, no worries. You are completely correct about conflating setup and 
execution. As far as I can tell though, even if I isolate the dict 
setup from the benchmark, I get the same relative differences in 
results. iteritems() was introduced for a reason!


If you don't need to go back to .items()'s copy behavior in py2, then 
six.iteritems() seems to be the best general purpose choice.
I am firmly in the "let's use items()" camp.  A 100 ms difference for a 
totally not-real-world case of a dictionary 1M items in size is no kind 
of rationale for the Openstack project - if someone has a dictionary 
that's 1M objects in size, or even 100K, that's a bug in and of itself.


the real benchmarks we should be using, if we are to even bother at all 
(which we shouldn't), is to observe if items() vs. iteritems() has *any* 
difference that is at all measurable in terms of the overall execution 
of real-world openstack use cases.   These nano-differences in speed are 
immediately dwarfed by all those operations surrounding them long before 
we even get to the level of RPC overhead.






I think Gordon said it best elsewhere in this thread:

> again, i just want to reiterate, i'm not saying don't use items(), i 
just think we should not blindly use items() just as we shouldn't 
blindly use iteritems()/viewitems()
If a demonstrable difference can be established in terms of real-world 
use cases for code that is using iteritems() vs. items(), then you can 
justify this difference.  Otherwise, not worth it.







-Rob

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

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

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




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


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

Re: [openstack-dev] [Openstack] Add table to Nova DB

[Andrew Laski]

On 06/11/15 at 01:17pm, Jay Pipes wrote:

Replying to openstack-dev ML, which is where this question belongs.

On 06/11/2015 11:10 AM, Silvia Fichera wrote:

Hi all,
I have to add a table to Nova DB (I will populated it statically by now).
I found this post:
http://stackoverflow.com/questions/19424901/how-to-add-a-table-in-nova-database-openstack
But since it is a little bit "old" I need to know if there are any
changes and if it is the right way to follow.
In this table I want to report network stats information (latency,
badwidth, etc.). By now I want to insert manually those data.


I know this is going to sound harsh, but you should not be extending 
Nova's database in any way outside of submissions to the upstream 
Nova codebase.


+1.  If a future Nova database change would happen to conflict with a 
local database change you are not going to enjoy resolving that.


In the Nova deployment I help manage we have made a lot of local 
modifications to the code for our business purposes, but we have never 
and will never touch the database outside of upstream for that reason.




What it sounds like you want to do is to publish network statistics 
(bandwidth/IO in and out of VMs) about your instances. If that is 
correct, you should probably look to the Ceilometer project to meet 
your needs.


Best,
-jay

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


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

[openstack-dev] [release][oslo] automaton release 0.2.0 (liberty)

[Doug Hellmann]

We are excited to announce the release of:

automaton 0.2.0: Friendly state machines for python.

This release is part of the liberty release series.

With source available at:

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

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

http://launchpad.net/automaton/+milestone/0.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/automaton

Changes in automaton 0.1..0.2.0
---

bcb61f0 Split the state machine runners off into own file
33c7e82 Use debtcollector removals function instead of warnings.warn
d71b6cf Revamp repo to match openstack repos
468a992 Allow the hierarchical machine to provide back the nested machines
230ade3 Retain & deprecate default_start_state via constructor
931de8b Amend the unittest due to more on_exit being triggered
dd34f04 Have the start state 'on_exit' be called when exit occurs
01a92f9 Use a property setter instead of a method
b0abceb Require using set_default_start_state to set the default
93f1f4e Add more checks on setting a alternative start state default
daacc95 Rename start_state to default_start_state
ba0214a Use type(self) instead of self.__class__
00b59ec Correctly copy derived classes
6f1be9d Allow initialize to take an alternative start_state
eb169da Update message when processing event and not initialized
8c897cf Add pre and post event processing methods
4de3914 Share the same not found template between machines
3f748c2 Avoid having a _generate_runner method when inheritance is ok
a81d49a Allow frozen to be set/unset
01f2201 Add testrepository to testing requirements
46f3c4b Fixup the classifiers
6f51cb8 Fix the tox to install the right requirements
7acc45a Just use _generate_runner to generate the different runner types
ceaf7a1 Use quoting in the machine code documentation
1c5ae77 Adjust pformat() + add examples
b87aefc Remove version caps
a84405e Split the requirements file into py2/py3 variations
cf14590 Move process event to be a static method
114e68f Add a HierarchicalFiniteMachine + Runner
b08d6ab Use a helper classmethod to create machines
878a6ef Rename _Runner -> _FiniteRunner
4b9bb19 Move to top level machines module, seems cleaner this way
0c122a9 Fix the pformat() example
fe402eb Move the fsm -> machines/finite.py and split off the running methods
61fdedc Allow copies to be unfrozen (if the parent is frozen)
22edd49 Make frozen a non-settable attribute and copy it correctly
a4197ee Allow machines to be shallow or deep copied
f0c4fb2 Three is the number for alpha
3c964ef Change beta to alpha (for now)

Diffstat (except docs and test files)
-

.gitreview  |   4 +
.testr.conf |   8 +
.travis.yml |  14 --
CONTRIBUTING.rst|  17 ++
HACKING.rst |   5 +
MANIFEST.in |   6 +
README.rst  |   9 +-
automaton/fsm.py| 336 -
automaton/machines.py   | 394 
automaton/runners.py| 169 +++
babel.cfg   |   2 +
openstack-common.conf   |   6 +
requirements.txt|  13 +-
setup.cfg   |  32 ++--
setup.py|   2 +-
test-requirements.txt   |  16 +-
tox.ini |  20 ++-
25 files changed, 1171 insertions(+), 590 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index ba45ab7..87a6d7c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,2 +1,6 @@
-# Build sanity
-pbr>=0.6,!=0.7,<1.0
+# The order of packages is significant, because pip processes them in the order
+# of appearance. Changing the order has an impact on the overall integration
+# process, which may cause wedges in the gate later.
+
+# See: https://bugs.launchpad.net/pbr/+bug/1384919 for why this is here...
+pbr>=0.11,<2.0
@@ -5 +9,4 @@ pbr>=0.6,!=0.7,<1.0
-six>=1.7.0
+six>=1.9.0
+
+# For deprecation of things
+debtcollector>=0.3.0  # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 6107f0d..031650a 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -1,2 +1,14 @@
-hacking>=0.9.2,<0.10
-nose
+# The order of packages is significant, because pip processes them in the order
+# of appearance. Changing the order has an impact on the overall integration
+# process, which may cause wedges in the gate later.
+
+hacking<0.11,>=0.10.0
+
+coverage>=3.6
+discover
+python-subunit>=0.0.18
+sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0
+testrepository>=0.0.18
+testscenarios>=0.4



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

Re: [openstack-dev] Looking for help getting git-review to work over https

[Paul Michali]

Do you know if you have SSH access to the outside world through the
firewall?

Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing,
created a .ssh/config file with:

Host review.openstack.org
ProxyCommand corkscrew  80 %h %p

The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew
tunnels the SSH through to port 80.

HTHs,

PCM


On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID  wrote:

>   Thanks for replying.
>
>
>
> % git review -vs
>
> 2015-06-11 09:30:38.396076 Running: git log --color=never --oneline
> HEAD^1..HEAD
>
> 2015-06-11 09:30:38.399021 Running: git remote
>
> 2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
>
> No remote set, testing ssh://
> dk0...@review.openstack.org:29418/openstack/horizon.git
>
> 2015-06-11 09:30:38.402988 Running: git push --dry-run ssh://
> dk0...@review.openstack.org:29418/openstack/horizon.git --all
>
> ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not
> work.
>
> Could not connect to gerrit.
>
> Enter your gerrit username:
>
>
>
> This output is interesting, because I followed the instructions to set the
> scheme and port to https and 443, which can be seen from:
>
> % git config --global -l
>
> user.name=David Karr
>
> user.email=dk0...@att.com
>
> gitreview.scheme=https
>
> gitreview.port=443
>
>
>
> Concerning the question ‘Do you have "gerrit" remote already configured?’,
> I guess I’d have to say I don’t know. I’ve followed instructions for
> setting up my pub key, but I’m not sure exactly what is entailed in “gerrit
> remote”.
>
>
>
> I can get to https://review.openstack.org/ from my browser and from the
> command line with curl.
>
>
>
> The “ls-remote” command returns without error (or any other output).
>
>
>
> *From:* Yuriy Taraday [mailto:yorik@gmail.com]
> *Sent:* Thursday, June 11, 2015 9:19 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] Looking for help getting git-review to
> work over https
>
>
>
> On Thu, Jun 11, 2015, 18:09 KARR, DAVID  wrote:
>
> I could use some help with setting up git-review in a slightly unfriendly
> firewall situation.
>
> I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks
> the non-standard ssh port.  I'm following the instructions at
> http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
> , for configuring git-review to use https on port 443, but this still isn't
> working (times out with "Could not connect to gerrit").  I've confirmed
> that I can reach other external sites on port 443.
>
> Can someone give me a hand with this?
>
>
>
>
>
> Hello.
>
>
>
> - Can you please post all output from "git review -vs"?
>
> - Do you have "gerrit" remote already configured?
>
> - Do you have access to https://review.openstack.org/ from your browser?
>
> - Can you access it from command line (via "curl -I
> https://review.openstack.org/"; for example)?
>
> - Does "git ls-remote https://review.openstack.org/openstack/nova >
> /dev/null" produce and error?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Nikhil Komawar]

+1 : .items()

Why can't we just add six.iteritems calls case by case basis (if that
happens)? Regex substitutions for a library call don't make sense to me
on such a massive scale.

On 6/11/15 11:00 AM, Victor Stinner wrote:
> Hi,
>
> Le 10/06/2015 02:15, Robert Collins a écrit :
>> python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
>> d.items(): pass'
>> 10 loops, best of 3: 76.6 msec per loop
>
>> python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
>> d.iteritems(): pass'
>> 100 loops, best of 3: 22.6 msec per loop
>
> .items() is 3x as slow as .iteritems(). Hum, I don't have the same
> results. Try attached benchmark. I'm using my own wrapper on top of
> timeit, because timeit is bad at calibrating the benchmark :-/ timeit
> gives unreliable results.
>
> Results on with CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz:
>
> [ 10 keys ]
> 713 ns: iteritems
> 922 ns (+29%): items
>
> [ 10^3 keys ]
> 42.1 us: iteritems
> 59.4 us (+41%): items
>
>
> [ 10^6 keys (1 million) ]
> 89.3 ms: iteritems
> 442 ms (+395%): items
>
> In my benchmark, .items() is 5x as slow as .iteritems(). The code to
> iterate on 1 million items takes almost an half second. IMO adding 300
> ms to each request is not negligible on an application. If this delay
> is added multiple times (multiple loops iterating on 1 million items),
> we may reach up to 1 second on an user request :-/
>
> Anyway, when I write patches to port a project to Python 3, I don't
> want to touch *anything* to Python 2. The API, the performances, the
> behaviour, etc. must not change.
>
> I don't want to be responsible of a slow down, and I don't feel able
> to estimate if replacing dict.iteritems() with dict.items() has a cost
> on a real application.
>
> As Ihar wrote: it must be done in a separated patch, by developers
> knowning well the project.
>
> Currently, most developers writing Python 3 patches are not heavily
> involved in each ported project.
>
> There is also dict.itervalues(), not only dict.iteritems().
>
> "for key in dict.iterkeys()" can simply be written "for key in dict:".
>
> There is also xrange() vs range(), the debate is similar:
> https://review.openstack.org/#/c/185418/
>
> For Python 3, I suggest to use "from six.moves import range" to get
> the Python 3 behaviour  on Python 2: range() always create an
> iterator, it doesn't create a temporary list. IMO it makes the code
> more readable because "for i in xrange(n):" becomes "for i in
> range(n):". six is not written outside imports and "range()" is better
> than "xrange()" for developers starting to learn Python.
>
> Victor
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [Neutron] service chaining feature development meeting at 10am pacific time June 11

[Henry Fourie]

Sean,
   See
http://eavesdrop.openstack.org/meetings/sfc_project/2015/sfc_project.2015-06-11-17.01.log.html


-  Louis

From: Mooney, Sean K [mailto:sean.k.moo...@intel.com]
Sent: Thursday, June 11, 2015 9:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] service chaining feature development 
meeting at 10am pacific time June 11

Hi can anyone provide a link to today's irc meeting logs?

Looking at http://eavesdrop.openstack.org/meetings/ I cannot see a 
Neutron_Service_Chaining_meeting directory
Are the logs being stored in 
http://eavesdrop.openstack.org/meetings/service_chaining/2015/ ?
If so the logs for today's meeting seem to be missing.

Regards
sean
From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Thursday, June 11, 2015 1:45 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] service chaining feature development 
meeting at 10am pacific time June 11

Here is the updated agenda for tomorrow's meeting:


1. Update on last meeting's action items

2.   Neutron port chain API for SFC

3.   Unified API and data model for flow classifier that can be used for 
SFC, QoS, Packet forwarding etc.

4. Summary on the SFC Feature project scope: functional module breakdown 
and their architecture relationship, and Module development ownership sign-up

5. Deep dive into technical questions on etherpad if there is time.

Thanks,
Cathy

From: Cathy Zhang
Sent: Wednesday, June 10, 2015 3:23 PM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [Neutron] service chaining feature development 
meeting at 10am pacific time June 11

Add the following item to the agenda:

unified data model for flow classifiers

Thanks,
Cathy

From: Cathy Zhang
Sent: Wednesday, June 10, 2015 3:12 PM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Subject: [openstack-dev] [Neutron] service chaining feature development meeting 
at 10am pacific time June 11

Hello everyone,

Our next weekly IRC meeting for the OpenStack service chain feature development 
is 10am pacific time June 11 (UTC 1700, hope I am doing the correct time 
conversion this time)  Following is the meeting info:

Weekly on Thursday at 1700 
UTC 
in #openstack-meeting-4

You can also find the meeting info at 
http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting

Agenda:

6. Update on last meeting's action items

7. Summary on the SFC Feature project scope: functional module breakdown 
and their architecture relationship as well as their relationship to OpenStack 
Neutron, the types of service functions that will be chained in this feature 
development

8. Module development ownership sign-up

9. Deep dive into technical questions on etherpad if there is time.


Anyone who would like to contribute to this feature development is welcome to 
join the meeting. Hope the time is good for most people.





Thanks,

Cathy



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

[Kevin Benton]

Hello all!

As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
Takashi to be a member of the control plane core reviewer team.

He has been extensively reviewing the entire codebase[2] and his feedback
on patches related to the reference implementation has been very useful.
This includes everything ranging from the AMPQ API to OVS flows.

Existing cores that have spent time working on the reference implementation
(agents and AMQP code), please vote +1/-1 for his 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.html#core-review-hierarchy
2. http://stackalytics.com/report/contribution/neutron-group/90


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

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

[Assaf Muller]

+1

- Original Message -
> Hello all!
> 
> As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
> Takashi to be a member of the control plane core reviewer team.
> 
> He has been extensively reviewing the entire codebase[2] and his feedback on
> patches related to the reference implementation has been very useful. This
> includes everything ranging from the AMPQ API to OVS flows.
> 
> Existing cores that have spent time working on the reference implementation
> (agents and AMQP code), please vote +1/-1 for his 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.html#core-review-hierarchy
> 2. http://stackalytics.com/report/contribution/neutron-group/90
> 
> 
> 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
> 

__
OpenStack Development Mailing 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 YAMAMOTO Takashi for the Control Plane core team

[Kyle Mestery]

+1

On Thu, Jun 11, 2015 at 1:34 PM, Assaf Muller  wrote:

> +1
>
> - Original Message -
> > Hello all!
> >
> > As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
> > Takashi to be a member of the control plane core reviewer team.
> >
> > He has been extensively reviewing the entire codebase[2] and his
> feedback on
> > patches related to the reference implementation has been very useful.
> This
> > includes everything ranging from the AMPQ API to OVS flows.
> >
> > Existing cores that have spent time working on the reference
> implementation
> > (agents and AMQP code), please vote +1/-1 for his 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.html#core-review-hierarchy
> > 2. http://stackalytics.com/report/contribution/neutron-group/90
> >
> >
> > 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
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Dennis]

On 06/11/2015 01:46 PM, Mike Bayer wrote:
I am firmly in the "let's use items()" camp.  A 100 ms difference for 
a totally not-real-world case of a dictionary 1M items in size is no 
kind of rationale for the Openstack project - if someone has a 
dictionary that's 1M objects in size, or even 100K, that's a bug in 
and of itself.


the real benchmarks we should be using, if we are to even bother at 
all (which we shouldn't), is to observe if items() vs. iteritems() has 
*any* difference that is at all measurable in terms of the overall 
execution of real-world openstack use cases.   These nano-differences 
in speed are immediately dwarfed by all those operations surrounding 
them long before we even get to the level of RPC overhead.


Lessons learned in the trenches:

* The best code is the simplest [1] and easiest to read.

* Code is write-once, read-many; clarity is a vital part of the read-many.

* Do not optimize until functionality is complete.

* Optimize only after profiling real world use cases.

* Prior assumptions about what needs optimization are almost always 
proven wrong by a profiler.


* I/O latency vastly overwhelms most code optimization making obtuse 
optimization pointless and detrimental to long term robustness.


* The amount of optimization needed is usually minimal, restricted to 
just a few code locations and 80% of the speed increases occur in just 
the first few tweaks after analyzing profile data.


[1] Compilers can optimize simple code best, simple code is easy to 
write and easier to read while at the same time giving the tool chain 
the best chance of turning your simple code into efficient code. (Not 
sure how much this applies to Python, but it's certainly true of other 
compiled languages.)


John

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

Re: [openstack-dev] [nova] Should we add instance action event to live migration?

[Jay Pipes]

On 06/03/2015 04:39 AM, Rui Chen wrote:

Hi all:
 We have the instance action and action event for most of the
instance operations,

exclude: live-migration. In the current master code, when we do
live-migration, the

instance action is recorded, but the action event for live-migration is
lost. I'm not sure that

it's a bug or design behavior, so I want to get more feedback in mail list.


Seems like that would be a bug.


 I found the patch https://review.openstack.org/#/c/95440/

 It's add the live migration action, but no event. It looks weird.

 I think there are two improvement we can do

 [1]: add the live migration event, keep consistence with other
instance operations.


++


 [2]: remove the live migration action in order to make the
operation transparent to end-users, like Andrew say in the patch comments.


I guess I'm confused why we would want to make the operation transparent 
to end-users? Andrew, what was your thought on that?


Best,
-jay

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

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

[Clint Byrum]

Top posting as this is more a response to the whole thread.

My take aways from the most excellent discussion:

* There is some benefit to iteritems in python2 when you need it.
* OpenStack does not seem to need it
  - Except in places that are operating on tens of thousands of large
objects concurrently such as the nova scheduler.
* six.anything is more code, and more code is more burden in general.

>From this I believe we should distill some clear developer
and reviewer recommendations which should go in our developer docs:

* Do not use six.iteritems in new patches without a clear reason
  stated and attached.
  - Reasons should clearly state why .items() would be a large enough
burden, such as "this list will be large and stay resident in
memory for the duration of the program. Each concurrent request
will have similar lists."
* -1 patches using six.iteritems in flight now with "Please remove or
  justify six.iteritems usage."
* Patches touching code sections which uses six.iteritems should be
  allowed to remove its usage without justification.

I've gone ahead and added this suggestion in a patch to the
infra-manual:

https://review.openstack.org/190757

This looks quite a bit like a hacking rule definition. How strongly do
we feel about this, do we want to require a tag of some kind on lines
that use six.iteritems(), or are we comfortable with this just being in
our python3 porting documentation?

Excerpts from Robert Collins's message of 2015-06-09 17:15:33 -0700:
> I'm very glad folk are working on Python3 ports.
> 
> I'd like to call attention to one little wart in that process: I get
> the feeling that folk are applying a massive regex to find things like
> d.iteritems() and convert that to six.iteritems(d).
> 
> I'd very much prefer that such a regex approach move things to
> d.items(), which is much easier to read.
> 
> Here's why. Firstly, very very very few of our dict iterations are
> going to be performance sensitive in the way that iteritems() matters.
> Secondly, no really - unless you're doing HUGE dicts, it doesn't
> matter. Thirdly. Really, it doesn't.
> 
> At 1 million items the overhead is 54ms[1]. If we're doing inner loops
> on million item dictionaries anywhere in OpenStack today, we have a
> problem. We might want to in e.g. the scheduler... if it held
> in-memory state on a million hypervisors at once, because I don't
> really to to imagine it pulling a million rows from a DB on every
> action. But then, we'd be looking at a whole 54ms. I think we could
> survive, if we did that (which we don't).
> 
> So - please, no six.iteritems().
> 
> Thanks,
> Rob
> 
> 
> [1]
> python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
> d.items(): pass'
> 10 loops, best of 3: 76.6 msec per loop
> python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
> d.iteritems(): pass'
> 100 loops, best of 3: 22.6 msec per loop
> python3.4 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
> d.items(): pass'
> 10 loops, best of 3: 18.9 msec per loop
> pypy2.3 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
> d.items(): pass'
> 10 loops, best of 3: 65.8 msec per loop
> # and out of interest, assuming that that hadn't triggered the JIT
> but it had.
>  pypy -m timeit -n 1000 -s 'd=dict(enumerate(range(100)))' 'for i
> in d.items(): pass'
> 1000 loops, best of 3: 64.3 msec per loop
> 

__
OpenStack Development Mailing 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] Regarding Flow classifiers existing proposals

[Cathy Zhang]

Hi Yuji,

This is very similar to the flow classifier which has been proposed in 
https://review.openstack.org/#/c/177946. 
Since quite some people have reviewed and given comments on 
https://review.openstack.org/#/c/177946 and the latest version has incorporated 
those comments, I would suggest that you incorporate your input to 
https://review.openstack.org/#/c/177946 and work with LouisF and Vikram on 
driving and developing a unified flow classifier API and model. 

Thanks,
Cathy

-Original Message-
From: Yuji Azama [mailto:yuj-az...@rc.jp.nec.com] 
Sent: Wednesday, June 10, 2015 9:24 PM
To: Cathy Zhang; Henry Fourie; mangel...@redhat.com; Vikram Choudhary
Cc: arma...@gmail.com; Dongfeng (C); mest...@mestery.com; 
openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi
Subject: RE: [neutron] Regarding Flow classifiers existing proposals

Hello everyone,

I want to join to IRC meeting. But I cannot join to the meeting because there 
is time difference.
I tried to write my idea in spec of common classifier resource.
( https://review.openstack.org/#/c/190463 )


Thanks,

Yuji

 -Original Message-
 From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
 Sent: Saturday, June 06, 2015 3:36 AM
 To: Henry Fourie; Miguel Angel Ajo; Vikram Choudhary
 Cc: Azama Yuji(安座間 勇二); arma...@gmail.com; Dongfeng (C); Kyle
 Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar
 Asangi
 Subject: RE: [neutron] Regarding Flow classifiers existing proposals
 
 Sure. I will add this item to the next IRC meeting agenda.
 
 
 
 Thanks,
 
 Cathy
 
 
 
 From: Henry Fourie
 Sent: Friday, June 05, 2015 11:27 AM
 To: Miguel Angel Ajo; Vikram Choudhary
 Cc: azama-y...@mxe.nes.nec.co.jp; Cathy Zhang; arma...@gmail.com;
 Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv
 Dhody; Kalyankumar Asangi
 Subject: RE: [neutron] Regarding Flow classifiers existing proposals
 
 
 
 Miguel,
 
I agree, we can probably use the service-chaining meeting to discuss
 this.
 
 We can have it as an agenda item for the next meeting:
 
 http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting
 
 
 
 -  Louis
 
 
 
 
 
 From: Miguel Angel Ajo [mailto:mangel...@redhat.com]
 Sent: Friday, June 05, 2015 1:42 AM
 To: Vikram Choudhary
 Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang;
 arma...@gmail.com; Dongfeng (C); Kyle Mestery;
 openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi
 Subject: [neutron] Regarding Flow classifiers existing proposals
 
 
 
 
 
 
 
 Added openstack-dev, where I believe this conversation must live.
 
 
 
 I totally agree on this, thank you for bringing up this conversation. This
 is not something we want to do for QoS this cycle, but probably next cycle.
 
 
 
 Anyway, an unified data model and API to create/update classifiers will
 not only be beneficial from the code duplication point of view, but will
 also provide a better user experience.
 
 
 
 I’m all for it.
 
 
 
 Best regards,
 
 Miguel Ángel Ajo
 
 
 
 On Friday 5 June 2015 at 09:57, Vikram Choudhary wrote:
 
Dear All,
 
 
 
There are multiple proposal floating around flow classifier rules
 for Liberty [1], [2] and [3].
 
I feel we all should work together and try to address all our use
 case having a unified framework rather than working separately achieving
 the same  goal.
 
 
 
Moreover, I can find the proposal for flow classifier as defined
 by the existing SFC [2] proposal is too generic and could address all the
 use cases by minor extension’s.
 
 
 
In this regard, I would like all to come forward, exchange their
 thoughts, work together and make it happen good the first go rather doing
 the same effort separately and end up in duplicating code & effort L.
 
I always feel less code will make our life happy in the long run ;)
 
 
 
Please let me know about your views.
 
 
 
[1] Add Neutron API extensions for packet forwarding
 
  https://review.openstack.org/#/c/186663/
 
 
 
 
[2] Neutron API for Service Chaining [Flow Filter resource]
 
 
 https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-fo
 r-service-chaining.rst
 
 
 
 
[3] QoS API Extension [Defines classifier rule in QoSRule.
 Classifier rule can really grow big in the long run]:
 
 
 https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-extens
 ion.rst
 
 
 
 
Thanks
 
Vikram
 
 

__
OpenStack Development Mailing 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] [Networking] Support for multiple gateways in neutron/nova-net subnets for provider networks

[Shraddha Pandhe]

Hi,
Currently, the Subnets in Neutron and Nova-Network only support one gateway. 
For provider networks in large data centers, quite often, the architecture is 
such a way that multiple gateways are configured per subnet. These multiple 
gateways are typically spread across backplanes so that the production traffic 
can be load-balanced between backplanes.This is just my use case for supporting 
multiple gateways, but other folks might have more use cases as well and also 
want to take the community's opinion about this feature. Is this something 
that's going to help a lot of users?I want to open up a discussion on this 
topic and figure out the best way to handle this.
1. Should this be done in a same way as dns-nameserver, with a separate table 
with two columns: gateway_ip, subnet_id.2. Should Gateway field be converted to 
a List instead of String?

__
OpenStack Development Mailing 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] Should we add instance action event to live migration?

[Andrew Laski]

On 06/11/15 at 02:47pm, Jay Pipes wrote:

On 06/03/2015 04:39 AM, Rui Chen wrote:

Hi all:
We have the instance action and action event for most of the
instance operations,

exclude: live-migration. In the current master code, when we do
live-migration, the

instance action is recorded, but the action event for live-migration is
lost. I'm not sure that

it's a bug or design behavior, so I want to get more feedback in mail list.


Seems like that would be a bug.


I found the patch https://review.openstack.org/#/c/95440/

It's add the live migration action, but no event. It looks weird.

I think there are two improvement we can do

[1]: add the live migration event, keep consistence with other
instance operations.


++


[2]: remove the live migration action in order to make the
operation transparent to end-users, like Andrew say in the patch comments.


I guess I'm confused why we would want to make the operation 
transparent to end-users? Andrew, what was your thought on that?


Just that it's something the user shouldn't need to care about.  A 
live-migration is not a user initiated event, though I suppose it could 
be in some deployments, and the end result is that the instance is 
running on another host with no other appreciable change.


There are many reasons a deployer may want to live-migrate instances 
around: capacity planning, security patching, noisy neighbors, host 
maintenance, etc... and I just don't think the user needs to know or 
care that it has taken place.


I'm not against exposing it, but I do think that some operators will 
want the option to live-migrate without informing their users.




Best,
-jay

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


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

[openstack-dev] [Networking] Support for multiple gateways in neutron/nova-net subnets for provider networks

[Shraddha Pandhe]

Hi,
Currently, the Subnets in Neutron and Nova-Network only support one
gateway. For provider networks in large data centers, quite often, the
architecture is such a way that multiple gateways are configured per
subnet. These multiple gateways are typically spread across backplanes so
that the production traffic can be load-balanced between backplanes.
This is just my use case for supporting multiple gateways, but other folks
might have more use cases as well and also want to take the community's
opinion about this feature. Is this something that's going to help a lot of
users?
I want to open up a discussion on this topic and figure out the best way to
handle this.
1. Should this be done in a same way as dns-nameserver, with a separate
table with two columns: gateway_ip, subnet_id.
2. Should Gateway field be converted to a List instead of String?
I have also opened a bug  for Neutron here:
https://bugs.launchpad.net/neutron/+bug/1464361
__
OpenStack Development Mailing 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] Service group foundations and features

[Sylvain Bauza]

Le 11/06/2015 18:52, Vilobh Meshram a écrit :

Few more places which can trigger inconsistent behaviour.

- 
https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/services.py#L44


- 
https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/hypervisors.py#L98


- 
https://github.com/openstack/nova/blob/stable/kilo/nova/availability_zones.py#L130


- 
https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/availability_zone.py#L68


- 
https://github.com/openstack/nova/blob/stable/kilo/nova/api/openstack/compute/contrib/hosts.py#L88-L89


- 
https://github.com/openstack/nova/blob/stable/kilo/nova/compute/api.py#L3399-L3421.



Blueprint which plans to fix this : 
https://blueprints.launchpad.net/nova/+spec/servicegroup-api-control-plane


Related Spec : 1) https://review.openstack.org/#/c/190322/

 2) https://review.openstack.org/#/c/138607/

-Vilobh




tl,dr: checking a Service (is_up) should only be for making sure we can 
send a message to it, but not for checking if the related hypervisor(s) 
is/are up. Having a reference in the services table mapping 1:1 to a 
reference in a separate datastore is fine by me.



So, I'm going to review the specs above and leave my comments there.
That said, I want to also point out some humble opinion about what 
should be the relationship between a Service and what could be called 
the "ServiceGroup API" (badly named IMHO since it only checks a service, 
not a group ;-) )


From my perspective, the Service object is related to the AMQP service 
tied to the queue and... that's it.
That has nothing to do related to an hypervisor (since hypervisors can 
be distributed for a single service). That only represents the single 
point of failure for messages sent to a nova-compute service (and not a 
compute node, remember the distributed stuff) and since this is the only 
way to communicate with the related hypervisor(s), we have to know its 
status.


Again, that doesn't necessarly imply that if the service (who listens to 
the AMQP queue) is up, the hypervisors will be up as well, but that's 
enough strong to say that if it's down, we are sure that the 
hypervisor(s) won't receive messages.
Whether if the hypervisor is still continuing to work while the service 
is down is a corner case that the service status should not provide IMHO.


That's exactly why we need to consider that the service is a reference 
which can be used as it is for any relationship with a list of 
hypervisors (call that ComputeNode now) and checking its state (using 
any driver for it) should just be used for knowing if the message can be 
sent to it - *and not for checking if the related hypervisor(s) are 
running or not*


Given that disclaimer (which implies that we need to be very clear about 
when to wonder if is_up(service) ), I'm fine with considering the 
reference stored in DB (ie. the services table) as only a list of 
references pointing to a separate object which can be stored in any 
datastore (DB/Memcache/ZK/pick your favorite)


The only thing we need to make sure is that there is a 1:1 mapping 
between the 2 objects (eg. the DB "service" item and the "datastored" 
object) which can only be done logically.


My 2 cts,
-Sylvain




On Mon, May 11, 2015 at 8:08 AM, Chris Friesen 
mailto:chris.frie...@windriver.com>> wrote:


On 05/11/2015 07:13 AM, Attila Fazekas wrote:

From: "John Garbutt" mailto:j...@johngarbutt.com>>


* From the RPC api point of view, do we want to send a cast to
something that we know is dead, maybe we want to? Should
we wait for
calls to timeout, or give up quicker?


How to fail sooner:
https://bugs.launchpad.net/oslo.messaging/+bug/1437955

We do not need a dedicated is_up just for this.


Is that really going to help?  As I understand it if nova-compute
dies (or is isolated) then the queue remains present on the server
but nothing will process messages from it.

Chris


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

[openstack-dev] [puppet] beaker jobs voting

[Emilien Macchi]

Hi,

We introduced functional testing a few time ago with rspec-beaker.
All of our modules have tests and are supposed to work today.

As we don't want regression and maintain our modules stability and
testability, we might want to make vote beaker jobs:
https://review.openstack.org/#/c/190778/

It will avoid merging patch when beaker is red and nobody noticed that.

Please use this patch for further discussion,

Best regards,
-- 
Emilien Macchi



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

Re: [openstack-dev] [nova] Should we add instance action event to live migration?

[Richard Raseley]

Andrew Laski wrote:

There are many reasons a deployer may want to live-migrate instances
around: capacity planning, security patching, noisy neighbors, host
maintenance, etc... and I just don't think the user needs to know or
care that it has taken place.


They might care, insofar as live migrations will often cause performance 
degradation from a users perspective.


Having this information easily available might reduce the mean time to 
diagnose a performance issue caused by such a migration.


Regards,

Richard

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

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

[Carl Baldwin]

+1

On Thu, Jun 11, 2015 at 12:15 PM, Kevin Benton  wrote:
> Hello all!
>
> As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
> Takashi to be a member of the control plane core reviewer team.
>
> He has been extensively reviewing the entire codebase[2] and his feedback on
> patches related to the reference implementation has been very useful. This
> includes everything ranging from the AMPQ API to OVS flows.
>
> Existing cores that have spent time working on the reference implementation
> (agents and AMQP code), please vote +1/-1 for his 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.html#core-review-hierarchy
> 2. http://stackalytics.com/report/contribution/neutron-group/90
>
>
> 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
>

__
OpenStack Development Mailing 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] Looking for help getting git-review to work over https

[KARR, DAVID]

> -Original Message-
> From: Kevin L. Mitchell [mailto:kevin.mitch...@rackspace.com]
> Sent: Thursday, June 11, 2015 10:46 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Looking for help getting git-review to
> work over https
> 
> On Thu, 2015-06-11 at 16:42 +, KARR, DAVID wrote:
> > Concerning the question ‘Do you have "gerrit" remote already
> > configured?’, I guess I’d have to say I don’t know. I’ve followed
> > instructions for setting up my pub key, but I’m not sure exactly
> what
> > is entailed in “gerrit remote”.
> 
> The "git review" command does its magic, in part, through
> configuring a
> "git remote" on the repository.  Go to the repository and do a "git
> remote -v" and look for any lines beginning with "gerrit"; they
> probably
> have the SSH URL instead of the https URL.  You should be able to
> use
> "git remote remove gerrit" and re-run the "git review -s" to get
> that
> all fixed up.  (Could also use "git remote set-url", FYI, but I
> figured
> starting from scratch may be easier for you…)

Ok, the output from "git remote -v" is this:
--
origin  https://github.com/openstack/horizon.git (fetch)
origin  https://github.com/openstack/horizon.git (push)
---

So there's obviously nothing to remove.  As usual, running "git review -sv" 
times out on the ssh:29418 request.  Are the "gitreview.scheme" and 
"gitreview.port" properties completely ignored here?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Nikhil Komawar]

On 6/11/15 2:45 PM, John Dennis wrote:
> On 06/11/2015 01:46 PM, Mike Bayer wrote:
>> I am firmly in the "let's use items()" camp.  A 100 ms difference for
>> a totally not-real-world case of a dictionary 1M items in size is no
>> kind of rationale for the Openstack project - if someone has a
>> dictionary that's 1M objects in size, or even 100K, that's a bug in
>> and of itself.  
>>
>> the real benchmarks we should be using, if we are to even bother at
>> all (which we shouldn't), is to observe if items() vs. iteritems()
>> has *any* difference that is at all measurable in terms of the
>> overall execution of real-world openstack use cases.   These
>> nano-differences in speed are immediately dwarfed by all those
>> operations surrounding them long before we even get to the level of
>> RPC overhead.
>
> Lessons learned in the trenches:
>
> * The best code is the simplest [1] and easiest to read.
>
> * Code is write-once, read-many; clarity is a vital part of the read-many.
>

+1

> * Do not optimize until functionality is complete.
>

+1

> * Optimize only after profiling real world use cases.
>

+2!

> * Prior assumptions about what needs optimization are almost always
> proven wrong by a profiler.
>

+2!

> * I/O latency vastly overwhelms most code optimization making obtuse
> optimization pointless and detrimental to long term robustness.
>

Couldn't agree more

> * The amount of optimization needed is usually minimal, restricted to
> just a few code locations and 80% of the speed increases occur in just
> the first few tweaks after analyzing profile data.
>
> [1] Compilers can optimize simple code best, simple code is easy to
> write and easier to read while at the same time giving the tool chain
> the best chance of turning your simple code into efficient code. (Not
> sure how much this applies to Python, but it's certainly true of other
> compiled languages.)
>
> 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

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] Looking for help getting git-review to work over https

[KARR, DAVID]

I don’t know if ssh is general is blocked.  I’ve been hearing about Corkscrew.  
I guess I’ll try installing it on my CentOS7 VM.  Does anyone know if this page 
is accurate: http://www.confignotes.com/2013/10/corkscrew/ ?

From: Paul Michali [mailto:p...@michali.net]
Sent: Thursday, June 11, 2015 11:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Do you know if you have SSH access to the outside world through the firewall?

Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, 
created a .ssh/config file with:

Host review.openstack.org
ProxyCommand corkscrew  80 %h %p

The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew 
tunnels the SSH through to port 80.

HTHs,

PCM

On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID 
mailto:dk0...@att.com>> wrote:
Thanks for replying.

% git review -vs
2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 09:30:38.399021 Running: git remote
2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 09:30:38.402988 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:

This output is interesting, because I followed the instructions to set the 
scheme and port to https and 443, which can be seen from:
% git config --global -l
user.name=David Karr
user.email=dk0...@att.com
gitreview.scheme=https
gitreview.port=443

Concerning the question ‘Do you have "gerrit" remote already configured?’, I 
guess I’d have to say I don’t know. I’ve followed instructions for setting up 
my pub key, but I’m not sure exactly what is entailed in “gerrit remote”.

I can get to https://review.openstack.org/ from my browser and from the command 
line with curl.

The “ls-remote” command returns without error (or any other output).

From: Yuriy Taraday [mailto:yorik@gmail.com]
Sent: Thursday, June 11, 2015 9:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https


On Thu, Jun 11, 2015, 18:09 KARR, DAVID mailto:dk0...@att.com>> 
wrote:

I could use some help with setting up git-review in a slightly unfriendly 
firewall situation.

I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the 
non-standard ssh port.  I'm following the instructions at 
http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
 , for configuring git-review to use https on port 443, but this still isn't 
working (times out with "Could not connect to gerrit").  I've confirmed that I 
can reach other external sites on port 443.

Can someone give me a hand with this?





Hello.



- Can you please post all output from "git review -vs"?

- Do you have "gerrit" remote already configured?

- Do you have access to https://review.openstack.org/ from your browser?

- Can you access it from command line (via "curl -I 
https://review.openstack.org/"; for example)?

- Does "git ls-remote https://review.openstack.org/openstack/nova > /dev/null" 
produce and error?
__
OpenStack Development Mailing 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] Looking for help getting git-review to work over https

[Jeremy Stanley]

On 2015-06-11 19:53:25 + (+), KARR, DAVID wrote:
> Ok, the output from "git remote -v" is this:
> --
> originhttps://github.com/openstack/horizon.git (fetch)
> originhttps://github.com/openstack/horizon.git (push)
> ---
> 
> So there's obviously nothing to remove.  As usual, running "git
> review -sv" times out on the ssh:29418 request.  Are the
> "gitreview.scheme" and "gitreview.port" properties completely
> ignored here?

I don't recall seeing what git-review version you're running, but
keep in mind that HTTPS Gerrit support only really showed up in
git-review 1.24 (the latest release on pypi.python.org) so if you're
running an older version that that it's probably not going to do
what you want here regardless. There are also I think some further
improvements for it in the master Git branch since the last release
(we're long overdue to tag another one) so you might consider giving
that a try too.
-- 
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