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

On 06/01/2015 07:16 PM, Jeremy Stanley wrote: > On 2015-06-01 14:55:06 +0200 (+0200), Thomas Goirand wrote: > [...] >> So, should I start writing a script to build an image for package >> building (ie: an image with sbuild, git-buildpackage, and so on...)? > [...] > > Probably what we'd want to do

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

Thanks Adrian, imho making name as required can bring more convenient to end users because UUID is difficult to use. Without name, the end user need to retrieve the UUID of the bay/baymodel first before he did some operations for the bay/baymodel, its really time consuming. We can discuss more in t

Re: [openstack-dev] [Neutron] virtual machine can not get DHCP lease due packet has no checksum

The fix should work fine. It is technically a workaround for the way checksums work in virtualised systems, and the unfortunate fact that some DHCP clients check checksums on packets where the hardware has checksum offload enabled. (This doesn't work due to an optimisation in the way QEMU treats

Re: [openstack-dev] [Murano] Nominating Filip Blaha for murano-core

+1 Welcome! On Tue, Jun 2, 2015 at 9:25 AM, Serg Melikyan wrote: > Folks, I'd like to propose Filip Blaha to core members of Murano team. > > Filip is active member of our community and he maintains a good score > as contributor: > http://stackalytics.com/report/users/filip-blaha > > Existing M

Re: [openstack-dev] [Murano] Nominating Kirill Zaitsev for murano-core

+1 Regards, Kate. On Tue, Jun 2, 2015 at 9:32 AM, Serg Melikyan wrote: > I'd like to propose Kirill Zaitsev to core members of Murano team. > > Kirill Zaitsev is active member of our community, he implemented > several blueprint in > Kilo and f

Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers

VIF plugging, but not precisely libvirt VIF plugging, so I'll tout this to a hopefully interested audience. At the summit, we wrote up a spec we were thinking of doing at [1]. It actually proposes two things, which is a little naughty really, but hey. Firstly we propose that we turn binding into

[openstack-dev] [Murano] Help needed with TOSCA support in Murano

I would like to ask community for the help to implement support for TOSCA in Murano: https://blueprints.launchpad.net/murano/+spec/support-tosca-format I was driving this feature and during OpenStack Summit in Paris we spent good amount of time discussing how we can implement support for TOSCA wit

Re: [openstack-dev] [Neutron] virtual machine can not get DHCP lease due packet has no checksum

The backport seems reasonable IMO. Is this tested in a multihost environment?. I ask, because given the Ian explanation (which probably I got wrong), the issue is in the NET->NIC->VM path while the patch fixes the path in the network node (this is ran in the dhcp agent). dhcp->NIC->NET. Bes

[openstack-dev] [Cinder] [Taskflow]Review help to cinder bp:Implement function to manage/unmanage snapshots

Hi, folks, There is a cinder bp:Implement function to manage/unmanage snapshots( https://review.openstack.org/#/c/144590/), that we use taskflow to implement this feature. So I need your guys' help(cinder & taskflow) to push this forward. Thanks. -- Best Wishes For You!

[openstack-dev] [keystone]Why not common definition about normal HTTP status code like 2xx and 3xx?

There is keystone/exception.py which contains Exceptions defined and used inside keystone provide 4xx and 5xx status code. And we can use it like: exception.Forbidden.code, exception.forbiddent.title exception.NotFound.code, exception.NotFound.title This makes the code looks pretty and avo

Re: [openstack-dev] [Cinder] [Taskflow]Review help to cinder bp:Implement function to manage/unmanage snapshots

Right now we’re working on refactoring current TaskFlow implementations in Cinder to make them more readable and clean. Then we’ll be able to decide if we want to get more TaskFlow into Cinder or step back from using it. Deadline for refactoring work is around 1 of July. Here’s related patch fo

Re: [openstack-dev] [keystone]Why not common definition about normal HTTP status code like 2xx and 3xx?

On Tuesday 02 June 2015 09:32:45 Chenhong Liu wrote: > There is keystone/exception.py which contains Exceptions defined and used > inside keystone provide 4xx and 5xx status code. And we can use it like: > exception.Forbidden.code, exception.forbiddent.title > exception.NotFound.code, excep

[openstack-dev] About the volume status exposure during migration

Hi Avishay, I really appreciate your comments on the spec I submitted for volume migration improvement.(https://review.openstack.org/#/c/186327/) I truly understand your concerns about exposing the migrating status to the end user(not admin). However, there is something I get confused: when we

Re: [openstack-dev] [nova] I think nova behaves poorly when booting multiple instances

Andrew Laski said on Mon, Jun 01, 2015 at 09:26:33AM -0400: > However what these parameters give users, versus orchestrating > outside of Nova, is the ability to have the instances all scheduled > as a single block. We should seek to provide this via persistent claims. IE add to the API something

Re: [openstack-dev] [nova] I think nova behaves poorly when booting multiple instances

Alexis Lee said on Tue, Jun 02, 2015 at 11:28:03AM +0100: > Paul Murray tells me there was a blueprint for this some time ago, but > I can't find a spec for it. I'm interested in pushing this, I'll put up > a spec at some point unless someone beats me to it. Oops, found it, thanks Paul: https:

Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers

Hi Ian, I like your proposal. It sounds very reasonable and makes separation of concerns between neutron and nova very clear. I think with vif plug script support [1]. it will help to decouple neutron from nova dependency. Thank you for sharing this, Irena [1] https://review.openstack.org/#/c/16246

Re: [openstack-dev] [keystone]Why not common definition about normal HTTP status code like 2xx and 3xx?

On Tue, Jun 2, 2015 at 5:46 PM Boris Bobrov wrote: > On Tuesday 02 June 2015 09:32:45 Chenhong Liu wrote: > > There is keystone/exception.py which contains Exceptions defined and used > > inside keystone provide 4xx and 5xx status code. And we can use it like: > > exception.Forbidden.code, ex

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

Ed Leafe said on Mon, Jun 01, 2015 at 07:40:17AM -0500: > We need to update our concept of a resource internally in Nova, both > in the DB and in code, and stop thinking that every request should > have a flavor. If you allocate all the memory of a box to high-mem instances, you may not be billing

Re: [openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot

Deepak, "transfer-*" is not suitable in this particular case. Usage of share networks causes creation of resources, when "transfer" does not. Also in this topic we have "creation" of new share based on some snapshot. Valeriy On Sun, May 31, 2015 at 4:23 PM, Deepak Shetty wrote: > > On Thu, May

Re: [openstack-dev] [keystone]Why not common definition about normal HTTP status code like 2xx and 3xx?

Hi Chenhong Liu, encapsulated into the WSGI application, Keystone is architecturally organized as follows: Application <-> Router <-> Controller <-> Manager <-> Driver The Router connects called URLs with the code in the Controller, which delegates actions to Manager, which manages the busin

Re: [openstack-dev] [keystone]Why not common definition about normal HTTP status code like 2xx and 3xx?

Hi Chenhong Liu, In addition, I think creating a common file to place non-error HTTP status code is a good idea and can be discussed with the Keystone cores. Feel free to add a point to our weekly meeting, Tuesdays 18:00 UTC. [1] Sincerely, Samuel [1] https://wiki.openstack.org/wiki/Meetings

Re: [openstack-dev] [Neutron] virtual machine can not get DHCP lease due packet has no checksum

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/2015 10:10 AM, Miguel Ángel Ajo wrote: > The backport seems reasonable IMO. > > Is this tested in a multihost environment?. > > I ask, because given the Ian explanation (which probably I got > wrong), the issue is in the NET->NIC->VM path

Re: [openstack-dev] [Neutron] virtual machine can not get DHCP lease due packet has no checksum

Ooook, fully understood now. Thanks Ihar & Ian for the clarification :) Miguel Ángel Ajo On Tuesday, 2 de June de 2015 at 13:33, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/02/2015 10:10 AM, Miguel Ángel Ajo wrote: > > The backport seems reasonable IM

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

Kennan, Agree on no requirement for unique name. Regards -steve From: Kai Qiang Wu mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]>> Date: Monday, June 1, 2015 at 6:11 PM To: "OpenStack Development Maili

Re: [openstack-dev] [keystone]Why not common definition about normal HTTP status code like 2xx and 3xx?

On Tue, Jun 2, 2015 at 7:24 PM samuel wrote: > Hi Chenhong Liu, > > In addition, I think creating a common file to place non-error HTTP > status code > is a good idea and can be discussed with the Keystone cores. > > Feel free to add a point to our weekly meeting, Tuesdays 18:00 UTC. [1] > > Than

[openstack-dev] [murano] python versions

It seems that python-muranoclient is the last project from murano-official group, that still supports python2.6. Other projects do not have a 2.6 testing job (correct me if I’m wrong). Personally I think it’s time to drop support for 2.6 completely, and add (at least non-voting) jobs with pytho

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

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] ht

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

Any comments from TC on that? What is the typical procedure of accepting new libs into global requirements? 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 >

Re: [openstack-dev] [murano] python versions

Hi Kirill, Client libraries usually have wider range of python requirements, as they may be run on various kinds of legacy environments, including the ones with python 2.6. only. Murano is definitely not the only project in Openstack which still maintains py26 compatibility for its client: nova, g

Re: [openstack-dev] [murano] oslo namespace changes and murano-dashboard

Excerpts from Serg Melikyan's message of 2015-06-02 07:16:58 +0300: > Hi Doug, > > sorry for the late response, I was traveling a little bit after the > summit. I've released python-muranoclient 0.6.0 with requirements > changes made by you. Thanks! > We use new release policy for libraries, so

Re: [openstack-dev] [murano] oslo namespace changes and murano-dashboard

Excerpts from Georgy Okrokvertskhov's message of 2015-05-29 12:00:07 -0700: > Hi, > > We do monitor both IRC and openstack-dev. #murano is our IRC channel. Most > of the time there are someone who can respond quickly. Mirantis and > Telefonica guys are located in Europe so they will respond durin

Re: [openstack-dev] [tempest][qa][cinder] How to configure tempest with to test volume migration?

Yes, I put them in the cinder-spec. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Open Standards and Open Source Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: [email protected]

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

On 2015-06-02 09:02:42 +0200 (+0200), Thomas Goirand wrote: [...] > That will be the little bit more tricky part. Some libraries are very > small, and probably caching will not be useful (too much work when > building the VM image). However, for big projects (nova, neutron, > cinder...), then we'll

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

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 do

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

Excerpts from BORTMAN, Limor (Limor)'s message of 2015-06-02 12:11:12 +: > 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?

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

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, wi

Re: [openstack-dev] [murano] python versions

Hi Kirill, I agree with Alexander that we should not remove support for python 2.6 in python-muranoclient. Regarding adding python-3 jobs - great idea! But we need to migrate python-muranoclient to yaql 1.0 first and then add python-3 jobs, because previous versions of yaql are not compatible wit

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

On 2015-06-02 12:39:30 + (+), Jeremy Stanley wrote: > Well, my point is those repos are already cached on every worker in > /opt/git (e.g., /opt/git/openstack/nova) and you can git clone, cp > or rsync those into your package build chroot. Then git remote > set-url, update and reset --hard

Re: [openstack-dev] [cinder] Consider using Explicit type casts on filters

Done Regards, Vasco Rodrigues On 02-06-2015 03:02, Huang Zhiteng wrote: > Not a DB expert but looks like a valid bug. Do you mind file a bug on > this? > > On Mon, Jun 1, 2015 at 5:43 PM, Vasco Rodrigues > wrote: > > Running Cinder on postgresql, i get the following er

[openstack-dev] [Neutron] Python 3 and hacking rules.

Hello, At the end of this cycle, Neutron should support Python 3.4 (https://blueprints.launchpad.net/neutron/+spec/neutron-python3). In order to do this, some hacking checks will be added, so that non python3-compliant code cannot be added. This might break code in neutron-*aas and other proj

Re: [openstack-dev] [Neutron] Python 3 and hacking rules.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/2015 03:27 PM, Cyril Roelandt wrote: > Hello, > > At the end of this cycle, Neutron should support Python 3.4 > (https://blueprints.launchpad.net/neutron/+spec/neutron-python3). > In order to do this, some hacking checks will be added, so

Re: [openstack-dev] [Nova] Liberty mid-cycle meetup

On 5/11/2015 9:48 AM, Michael Still wrote: Ok, given we've had a whole bunch people sign up already and no complaints here, I think this is a done deal. So, you can now assume that the dates are final. I will email people currently registered to let them know as well. I have added the mid-cycl

[openstack-dev] [release][oslo] debtcollector release 0.5.0

We are happy to announce the release of: debtcollector 0.5.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. With source available at: http://git.openstack.org/cgit/openstack/debtcollector For more details,

Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers

Hi, At the summit this was discussed in the nova sessions and there were a number of concerns regarding security etc. Thanks Gary From: Irena Berezovsky mailto:[email protected]>> Reply-To: OpenStack List mailto:[email protected]>> Date: Tuesday, June 2, 2015 at 1:44 PM To: Op

[openstack-dev] Cross-Project meeting, Tue Jun 2nd, 21:00 UTC

Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting today at 21:00 UTC, with the following agenda: * Horizontal teams announcements * Update the API WG merge process for Liberty [1] * Vertical teams announcements * Open discussion [1] https://review.o

[openstack-dev] [nova] RequestSpec object and Instance model

Hi, Currently working on implementing the RequestSpec object BP [1], I had some cool comments on my change here : https://review.openstack.org/#/c/145528/12/nova/objects/request_spec.py,cm Since we didn't discussed on how to persist that RequestSpec object, I think the comment is valuable.

[openstack-dev] [new][mercador] Announcing Mercador, a project to federate OpenStack cloud services.

Hello, I'm pleased to announce the development of a new project called Mercador (Portuguese for “merchant”). Mercador will provide a mechanism for integrating OpenStack cloud services from one cloud service provider (CSP) into the set of services published by a second CSP. The mechanism is int

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

I can see both points of view. Principle of least surprise applies here. A list of bays without names would be surprising for a tenant imo :) I don’t particularly have a strong opinion, but my inclination is to lean towards non-unique names as a requirement for creating bays. Again I am not

Re: [openstack-dev] [Murano] Nominating Filip Blaha for murano-core

+1 Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Tue, Jun 2, 2015 at 9:25 AM, Serg Melikyan wrote: > Folks, I'd like to propose Filip Blaha to core members of Murano team. > > Filip is active member of our community and he maintains a good score > as contributor: > htt

[openstack-dev] [release][oslo] oslo.concurrency release 1.10.0 (liberty)

We are stoked to announce the release of: oslo.concurrency 1.10.0: Oslo Concurrency library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.concurrency For more details, please see the git log history below and:

Re: [openstack-dev] [Murano] Nominating Kirill Zaitsev for murano-core

+1 without any doubt Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Tue, Jun 2, 2015 at 10:43 AM, Ekaterina Chernova wrote: > +1 > > Regards, > Kate. > > On Tue, Jun 2, 2015 at 9:32 AM, Serg Melikyan > wrote: > >> I'd like to propose Kirill Zaitsev to core members of M

[openstack-dev] [keystone][reseller] New way to get a project scoped token by name

Hi folks, In Reseller[1], we’ll have the domains concept merged into projects, that means that we will have projects that will behave as domains. Therefore, it will be possible to have two projects with the same name in a hierarchy, one being a domain and another being a regular project. For insta

[openstack-dev] [openstackclient] Image create-or-update

Hi, I have a question related to openstack image create command v1 from python-openstackclient. It behaves like create-or-update (if image with *name* specified for create already existed, it is updated). Actually it looks, that it is in collision with glance, which allows create multiple im

Re: [openstack-dev] [puppet] [ceph] Managing a ceph cluster's lifecycle with puppet

Thanks David, this helped out quite a bit for my phase 1 work. How do you handle the journal partition when replacing a failed drive? Bryan On 5/31/15, 3:06 PM, "David Moreau Simard" wrote: >Hey Bryan, > >The configuration is done through a provider - you can use it in your >composition layer,

Re: [openstack-dev] [Neutron] Python 3 and hacking rules.

On 06/02/2015 03:49 PM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/2015 03:27 PM, Cyril Roelandt wrote: Hello, At the end of this cycle, Neutron should support Python 3.4 (https://blueprints.launchpad.net/neutron/+spec/neutron-python3). In order to do this,

[openstack-dev] [release][oslo] oslo.config release 1.12.0 (liberty)

We are satisfied to announce the release of: oslo.config 1.12.0: Oslo Configuration API This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.config For more details, please see the git log history below and: http://

[openstack-dev] [release][oslo] oslo.log release 1.3.0 (liberty)

We are jazzed to announce the release of: oslo.log 1.3.0: oslo.log library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.log For more details, please see the git log history below and: http://launchpad.net/os

[openstack-dev] [release][oslo] oslo.rootwrap release 1.8.0 (liberty)

We are eager to announce the release of: oslo.rootwrap 1.8.0: Oslo Rootwrap This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.rootwrap For more details, please see the git log history below and: http://launchpad.

[openstack-dev] [release][oslo] oslo.serialization release 1.6.0 (liberty)

We are gleeful to announce the release of: oslo.serialization 1.6.0: Oslo Serialization library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.serialization For more details, please see the git log history below an

[openstack-dev] [release][oslo] oslo.policy release 0.5.0 (liberty)

We are jazzed to announce the release of: oslo.policy 0.5.0: Oslo Policy library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.policy For more details, please see the git log history below and: http://launchp

[openstack-dev] [release][oslo] oslo.context release 0.4.0 (liberty)

We are happy to announce the release of: oslo.context 0.4.0: Oslo Context library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.context For more details, please see the git log history below and: http://launc

[openstack-dev] [release][oslo] oslo.i18n release 1.7.0 (liberty)

We are pleased to announce the release of: oslo.i18n 1.7.0: Oslo i18n library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.i18n For more details, please see the git log history below and: http://launchpad.ne

[openstack-dev] [release][oslo] oslo.messaging release 1.12.0 (liberty)

We are tickled pink to announce the release of: oslo.messaging 1.12.0: Oslo Messaging API This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging For more details, please see the git log history below and: ht

[openstack-dev] [release][oslo] oslo.versionedobjects release 0.3.0 (liberty)

We are thrilled to announce the release of: oslo.versionedobjects 0.3.0: Oslo Versioned Objects library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.versionedobjects For more details, please see the git log histo

[openstack-dev] [release][oslo] oslo.utils release 1.6.0 (liberty)

We are stoked to announce the release of: oslo.utils 1.6.0: Oslo Utility library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.utils For more details, please see the git log history below and: http://launchpa

[openstack-dev] [release][oslo] oslo.db release 1.10.0 (liberty)

We are pumped to announce the release of: oslo.db 1.10.0: Oslo Database library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.db For more details, please see the git log history below and: http://launchpad.ne

[openstack-dev] [release][keystone] pycadf release 1.0.0 (liberty)

We are glad to announce the release of: pycadf 1.0.0: CADF Library This release is part of the liberty release series. With source available at: https://git.openstack.org/cgit/openstack/pycadf For more details, please see the git log history below and: https://launchpad.net/pycadf/+mi

Re: [openstack-dev] [Murano] Nominating Kirill Zaitsev for murano-core

Kirill, welcome! On Tue, Jun 2, 2015 at 5:32 PM, Stan Lagun wrote: > +1 without any doubt > > Sincerely yours, > Stan Lagun > Principal Software Engineer @ Mirantis > > > > On Tue, Jun 2, 2015 at 10:43 AM, Ekaterina Chernova < > [email protected]> wrote: > >> +1 >> >> Regards, >> Kate. >>

Re: [openstack-dev] [Murano] Nominating Filip Blaha for murano-core

Filip, my congratulations! Welcome! On Tue, Jun 2, 2015 at 5:34 PM, Stan Lagun wrote: > +1 > > Sincerely yours, > Stan Lagun > Principal Software Engineer @ Mirantis > > > > On Tue, Jun 2, 2015 at 9:25 AM, Serg Melikyan > wrote: > >> Folks, I'd like to propose Filip Blaha to core members of Mu

[openstack-dev] [puppet] RabbitMQ deprecation

I've spent some time trying to eliminate the number of deprecation warnings we have in preparation for our upgrade to Kilo. One of the ones that I got stuck on is the nova::rabbitmq::rabbitmq_class parameter. If this parameter is specified, and it is by default, then the class will include the ra

[openstack-dev] Hyper-V Meeting

Hi All, Some of us are still returning from post summit activities. We will resume meetings next week. p Peter J. Pouliot CISSP Microsoft Enterprise Cloud Solutions C:\OpenStack New England Research & Development Center 1 Memorial Drive Cambridge, MA 02142 P: 1.(857).4536436 E: ppoul...@micros

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

On 06/02/2015 02:39 PM, Jeremy Stanley wrote: > On 2015-06-02 09:02:42 +0200 (+0200), Thomas Goirand wrote: > [...] >> That will be the little bit more tricky part. Some libraries are very >> small, and probably caching will not be useful (too much work when >> building the VM image). However, for

[openstack-dev] GSLB API and backend support IRC meting

Hi All, Does anyone know on which IRC channel the GSLB API meeting is happening? Thanks, Evg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubs

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

Names can make writing generic orchestration templates that would go in the applications catalog easier. Humans are much better at inputting a name rather then a uuid. You can even default a name in the text box and if they don't change any of the defaults, it will just work. You can't do that w

[openstack-dev] Interconnecting projects

Hi, Trying to understand if somebody has come across the following scenario: I have a two projects: Project 1 and Project 2 I have a neutron private network in Project 1, that I want to connect that private network to a neutron port in Project 2. This does not seem to be possible without using adm

Re: [openstack-dev] [keystone]Why not common definition about normal HTTP status code like 2xx and 3xx?

On 6/2/15, 04:45, "Boris Bobrov" wrote: >On Tuesday 02 June 2015 09:32:45 Chenhong Liu wrote: >> There is keystone/exception.py which contains Exceptions defined and >>used >> inside keystone provide 4xx and 5xx status code. And we can use it like: >> exception.Forbidden.code, exception.for

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

+1. Most of the other openstack api's allow for non unique names. The api's that take in a name just break in that case. Its up to the user to decide if they want uniqueness and api's to work by name, or non-uniqueness and have to use uuids. Thanks, Kevin From:

Re: [openstack-dev] Interconnecting projects

Check out: http://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html Kevin is trying to solve exactly this problem. We're really hoping to land it in time for Liberty. - Original Message - > Hi, > > Trying to understand if somebody has come across the following

[openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

Nova has a very large API, and during the last release cycle a lot of work was done to move all the API checking properly into policy, and not do admin context checks at the database level. The result is a very large policy file - https://github.com/openstack/nova/blob/master/etc/nova/policy.json

Re: [openstack-dev] Interconnecting projects

On Tue, Jun 2, 2015 at 9:14 PM, Assaf Muller wrote: > Check out: > > http://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html If I understand correctly, what Anik is probably asking for is way to connect two OpenStack projects together from a network point of view, whe

Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/2015 06:22 PM, Sean Dague wrote: > Nova has a very large API, and during the last release cycle a lot > of work was done to move all the API checking properly into policy, > and not do admin context checks at the database level. The result >

Re: [openstack-dev] [Neutron] virtual machine can not get DHCP lease due packet has no checksum

On 06/02/2015 12:32 AM, Ian Wells wrote: The fix should work fine. It is technically a workaround for the way checksums work in virtualised systems, and the unfortunate fact that some DHCP clients check checksums on packets where the hardware has checksum offload enabled. (This doesn't work due

[openstack-dev] [puppet] openstacklib::db::sync proposal

Hello list, In order to standardize the way sync_db is done across modules, I would like to offer a suite of patch[1] that enforces a common pattern. Pattern is : if $sync_db { include COMPONENT::db::sync } class COMPONENT::db::sync { openstacklib::db::sync { [

Re: [openstack-dev] Interconnecting projects

That's exactly what I was asking for. Thanks Fawad. Regards, Anik 201-245-1569 From: Fawad Khaliq To: OpenStack Development Mailing List (not for usage questions) Cc: Anik Sent: Tuesday, June 2, 2015 9:29 AM Subject: Re: [openstack-dev] Interconnecting projects On Tue, Jun 2, 20

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

Hi all, The initial meeting logs can be found at http://eavesdrop.openstack.org/meetings/gslb/2015/ , and we will be having another meeting next week, same time, same channel. Thanks, doug > On May 31, 2015, at 1:27 AM, Samuel Bercovici wrote: > > Good for me - Tuesday at 1600UTC > > > --

Re: [openstack-dev] [chef] OpenStack-Chef client-cookbook hacking

> On Jun 1, 2015, at 12:32 PM, JJ Asghar wrote: > > Please answer select the best time for you asap, and tomorrow at 1600UTC i’ll > send out the time that has been decided. Ok, so it seems we’re going to have the hack session 1900UTC Wednesday. I’ll see y’all in the IRC channel! -J _

[openstack-dev] [Glance][Keystone] Glance and trusts

Hello! I think it's a good time to discuss implementation of trusts in Glance v2 and v3 api. Currently we have two different situations during image creation where our token may expire, which leads to unsuccessful operation. First is connection between glance-api and glance-registry. In this case

Re: [openstack-dev] Interconnecting projects

Great! A correction here: RBAC proposal does address some of the use cases on interconnecting tenants. Fawad Khaliq On Tue, Jun 2, 2015 at 9:41 PM, Anik wrote: > That's exactly what I was asking for. Thanks Fawad. > > Regards, > Anik > 201-245-1569 > > -- > *From

Re: [openstack-dev] [puppet] openstacklib::db::sync proposal

On 2015-06-02 12:41 PM, Yanis Guenane wrote: > > The openstacklib::db::sync[2] is currently only a wrapper around an exec > that does the actual db sync, this allow to make any modification to the > exec into a single place. The main advantage IMO is that a contributor > is provided with the same

Re: [openstack-dev] [puppet] Weekly meeting #36

On Mon, Jun 1, 2015 at 12:16 PM, Colleen Murphy wrote: > Hi everyone, > > Here's an initial agenda for our weekly meeting tomorrow at 1500 UTC in > #openstack-meeting-4: > > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150602 > > Please add a

Re: [openstack-dev] GSLB API and backend support IRC meting

On 02/06/15 16:33, Evgeny Fedoruk wrote: > Hi All, > > Does anyone know on which IRC channel the GSLB API meeting is happening? > > Thanks, > > Evg > It was held in #openstack-meeting-4 The logs are here: http://eavesdrop.openstack.org/meetings/gslb/2015/ We are meeting next week, same time, sam

Re: [openstack-dev] [Murano] Nominating Filip Blaha for murano-core

+1 From: Ekaterina Chernova mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]>> Date: Tuesday, June 2, 2015 at 2:42 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:opensta

Re: [openstack-dev] [Murano] Nominating Kirill Zaitsev for murano-core

+1 From: Stan Lagun mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]>> Date: Tuesday, June 2, 2015 at 9:32 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@list

Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team

+1 from me, long overdue! > On May 28, 2015, at 9:42 AM, Kyle Mestery wrote: > > Folks, I'd like to propose Assaf Muller to be a member of the Neutron core > reviewer team. Assaf has been a long time contributor in Neutron, and he's > also recently become my testing Lieutenant. His influence

Re: [openstack-dev] [Cinder] [Taskflow]Review help to cinder bp:Implement function to manage/unmanage snapshots

Hi Michal, Apart from reviewing your changes, few more efforts done from TaskFlow side that I find useful for Cinder's case (and in general). https://review.openstack.org/#/c/186524/ https://review.openstack.org/#/c/184814/ -Vilobh On Tue, Jun 2, 2015 at 2:45 AM, Dulko, Michal wrote: > Righ

Re: [openstack-dev] Interconnecting projects

I suspect a "BaaS" (Bridge-as-a-service) proposal is lurking in this thread. While the idea of yet-another-aas is probably not desirable at this time, it might be worth trying and understand - from an exclusively logical perspective (ie: the API consumer point of view) - what would be the differen

[openstack-dev] [neutron] [fwaas] -IPv6 support in Kilo

Hi, I was browsing the code to understand IPv6 support For FWaaS in Kilo. I don't see a restriction in the db code or in reference fwaas_plugin.py However, from this: https://github.com/openstack/neutron-fwaas/blob/stable/kilo/neutron_fwaas/services/firewall/drivers/vyatta/vyatta_fwaas.py#L126

[openstack-dev] Release naming for M open for nominations

Hey everyone! It's time to pick a name for the M release. If you have a name you'd like us to vote on, please add it here: https://wiki.openstack.org/wiki/Release_Naming/M_Proposals The nominations will be open until 2015-06-07 23:59:59 UTC. If you don't remember the rules, they're here: http

Re: [openstack-dev] [neutron] [fwaas] -IPv6 support in Kilo

> From: Rukhsana Ansari > To: [email protected] > Date: 06/02/2015 01:59 PM > Subject: [openstack-dev] [neutron] [fwaas] -IPv6 support in Kilo > > Hi, > > I was browsing the code to understand IPv6 support For FWaaS in Kilo. > > I don't see a restriction in the db code or in r

Re: [openstack-dev] [Fuel] Call for 7.0 feature design and review

Can we update the vxlan bp to target it to 7.0? The series goal is still set to 6.1.x https://blueprints.launchpad.net/fuel/+spec/neutron-vxlan-support Thanks -- Sean M. Collins __ OpenStack Development Mailing List (not f

  1   2   >