Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 16 June 2015 at 22:36, Sam Morrison wrote: > > On 17 Jun 2015, at 10:56 am, Armando M. wrote: > > > > On 16 June 2015 at 17:31, Sam Morrison wrote: > >> We at NeCTAR are starting the transition to neutron from nova-net and >> neutron almost does what we want. >> >> We have 10 “public" networ

[openstack-dev] [opensatck-dev][trove]redis replication

Hello, Right now we can create one replication once, but it is not suitable for redis. What we will do for this? And if time permit can the assigner of redis replication tell about the process for redis replication? Thanks a lot.

Re: [openstack-dev] [taskflow] Returning information from reverted flow

> -Original Message- > From: Joshua Harlow [mailto:[email protected]] > Sent: Tuesday, June 16, 2015 4:52 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [taskflow] Returning information from reverted > flow > > Dulko, Michal wrote:

Re: [openstack-dev] [Ironic] ironic-lib library

Seems to me like we can keep ironic-lib git repository as a git submodule of the ironic and ironic-python-agent repositories. Any commit in Ironic or Ironic-python-agent can change ironic-lib independently. Also, looks like our CI system supports it by automatically pushing commits in the subscri

Re: [openstack-dev] [Neutron] Quota enforcement

Ok. So if I understand it correctly, every update operation we do could result in a deadlock then? Or is it just ones with "where" criteria that became invalid. On Tue, Jun 16, 2015 at 8:58 PM, Carl Baldwin wrote: > On Tue, Jun 16, 2015 at 5:17 PM, Kevin Benton wrote: > > There seems to be conf

Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC

1600 is late for me as it is. The earlier the better is my vote. I would make 1630 work, 1700 is too late. Sam Yaple 864-901-0012 On Tue, Jun 16, 2015 at 2:09 PM, Harm Weites wrote: > I'm ok with moving to 16:30 UTC instead of staying at 16:00. > > I actually prefer it in my evening schedule :)

Re: [openstack-dev] [Security] the need about implementing a MAC security hook framework for OpenStack

Hi Yang, This is an interesting idea. Most operators running production OpenStack deployments will be using OS-level Mandatory Access Controls already (likely AppArmour or SELinux). I can see where there might be some application on a per-service basis, introducing more security for Swift, Nov

Re: [openstack-dev] [Magnum] TLS Support in Magnum

I think this is an interesting if somewhat difficult to follow thread. It’s worth keeping in mind that there are more ways to handle certificates in OpenStack than just Barbican, though there are often good reasons to use it. Is there a blueprint or scheduled IRC meeting to discuss the options?

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

On 06/15/2015 10:43 PM, Paul Belanger wrote: > On 06/15/2015 03:03 PM, Allison Randal wrote: >> On 06/15/2015 11:48 AM, Thomas Goirand wrote: >>> On 06/15/2015 04:55 PM, James Page wrote: The problem of managing delta and allowing a good level of distribution independence is still going t

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

On 06/16/2015 06:41 PM, Allison Randal wrote: > On 06/15/2015 01:43 PM, Paul Belanger wrote: >> While I agree those points are valid, and going to be helpful, moving >> under OpenStack (even Stackforge) does also offer the chance to get more >> test integration upstream (not saying this was the ori

Re: [openstack-dev] [neutron][db] online schema upgrades

Ihar, thanks for bringing this up! This is very interesting and I think it worth trying. I'm +1 on that and want to participate in this work. In fact a lot *not strict* migrations are removed with juno_initial, so I hope it won't be so hard for now to apply stricter rules for migration. But what

[openstack-dev] [puppet][murano] Developing puppet module for Murano

Hi Emilien, I would like to answer your question regarding stackforge/puppet-murano repository asked in different thread: > Someone from Fuel team created first the module in Fuel, 6 months ago > [1] and 3 months later someone from Fuel team created an empty > repository in Stackforge [2]. By th

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On Tue, Jun 16, 2015 at 04:21:16PM -0500, Matt Riedemann wrote: > The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very > similar. > > I want to extract a common base class that abstracts some of the common code > and then let the sub-classes provide overrides where necessary.

Re: [openstack-dev] [fuel] Fuel API settings reference

As this topic is getting some traction, I will register corresponding blueprint in Fuel and try to decompose the work based on what Andrew proposed. -- Best regards, Oleg Gelbukh On Tue, Jun 16, 2015 at 3:54 PM, Oleg Gelbukh wrote: > Andrew, > > I've also noticed that incompatible changes are b

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

Hi, I don't want to have to diverge much from the topic of this thread, I've done this already as pointed out by Sean. But I feel like replying to this. >> Sorry I might be missing something. I don't think one thing justify >> the other, plus the problem seems to be the source of truth. I thought

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Hi Sam, On 17/06/15 01:31, Sam Morrison wrote: We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does what we want. We have 10 “public" networks and 10 “service" networks and depending on which compute node you land on you get attached to one of them. In ne

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

[Sorry - unintentionally dropped -operators below; adding it back in this copy.] On 17/06/15 11:35, Neil Jerram wrote: Hi Sam, On 17/06/15 01:31, Sam Morrison wrote: We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does what we want. We have 10 “public" ne

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Hi Kris, Apologies in advance for questions that are probably really dumb - but there are several points here that I don't understand. On 17/06/15 03:44, Kris G. Lindgren wrote: We are doing pretty much the same thing - but in a slightly different way. We extended the nova scheduler to help

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 17 June 2015 at 00:21, Matt Riedemann wrote: > The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very > similar. > > I want to extract a common base class that abstracts some of the common > code and then let the sub-classes provide overrides where necessary. > > As part of

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Couple more dumb comments here - sorry that I'm processing this thread backwards! On 16/06/15 15:20, Jay Pipes wrote: Adding -dev because of the reference to the Neutron "Get me a network spec". Also adding [nova] and [neutron] subject markers. Comments inline, Kris. On 05/22/2015 09:28 PM, K

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

Why does alternative implementation need to implement all 50 versions? As far as I understand, API side should not support all versions, that is why version info returns min and max versions https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25-L26 On Tu

Re: [openstack-dev] [QA] [openstack-qa] [tempest] UUIDs and names in tempest.conf file

> -Original Message- > From: ext Matthew Treinish [mailto:[email protected]] > Sent: Tuesday, June 16, 2015 4:49 PM > To: [email protected]; All Things QA. > Subject: Re: [openstack-qa] [QA] [tempest] UUIDs and names in tempest.conf > file > > So I need to point out that

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-17 19:46 GMT+08:00 Andrey Kurilin : > Why does alternative implementation need to implement all 50 versions? > As far as I understand, API side should not support all versions, that is > why version info returns min and max versions > https://github.com/openstack/nova/blob/master/doc/api_s

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 06/17/2015 12:21 AM, Matt Riedemann wrote: The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very similar. I want to extract a common base class that abstracts some of the common code and then let the sub-classes provide overrides where necessary. As part of this, I'm won

Re: [openstack-dev] [opensatck-dev][trove]redis replication

Have you checked the blueprint for this at: https://review.openstack.org/#/c/189445/. Hope that helps. Regards, Mariam. From: "李田清" To: "openstack-dev" Date: 06/17/2015 02:06 AM Subject:[openstack-dev] [opensatck-dev][trove]redis replication Hello, Right now we can c

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 06/17/2015 02:14 PM, Duncan Thomas wrote: On 17 June 2015 at 00:21, Matt Riedemann mailto:[email protected]>> wrote: The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very similar. I want to extract a common base class that abstracts some of the c

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

Hi Serg, On 06/17/2015 05:35 AM, Serg Melikyan wrote: > Hi Emilien, > > I would like to answer your question regarding > stackforge/puppet-murano repository asked in different thread: > >> Someone from Fuel team created first the module in Fuel, 6 months ago >> [1] and 3 months later someone fro

[openstack-dev] [GBP][Heat] Group-based Policy plug-in for Heat

Every day I get an email about broken dependencies for the group-based policy Heat plugin in Fedora (openstack-heat-gbp), because the version of Heat it depends on is capped. Two points: 1) Would whoever maintains that package (Bob?) please fix it :) 2) Why was this plugin not submitted to /co

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 08:53 AM, Emilien Macchi wrote: > Hi Serg, > > On 06/17/2015 05:35 AM, Serg Melikyan wrote: >> Hi Emilien, >> >> I would like to answer your question regarding >> stackforge/puppet-murano repository asked in different thread: >> >>>

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On Wed, Jun 17, 2015 at 1:59 AM, Armando M. wrote: > > > On 16 June 2015 at 22:36, Sam Morrison wrote: > >> >> On 17 Jun 2015, at 10:56 am, Armando M. wrote: >> >> >> >> On 16 June 2015 at 17:31, Sam Morrison wrote: >> >>> We at NeCTAR are starting the transition to neutron from nova-net and >

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 17 June 2015 at 15:36, Dmitry Guryanov wrote: > On 06/17/2015 02:14 PM, Duncan Thomas wrote: > >> On 17 June 2015 at 00:21, Matt Riedemann > > wrote: >> >> The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are >> all very similar. >> >>

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

Thank you for sharing link to list of things that new module should satisfy to! It will be really helpful even if list will change over time. At least we have pointers how to start making our module compliant. Regarding figuring out permissions - I don't mind if we will set puppet-core as group re

[openstack-dev] [puppet] New Juno (5.1.0) release

Hi, We are preparing a new Juno sub-release. You can see the status of this work here: https://etherpad.openstack.org/p/puppet-juno-5.1.0-release All modules having stable/juno will be released 5.1.0 both in OpenStack and Puppet forge. Regards, -- Emilien Macchi signature.asc Description: Op

Re: [openstack-dev] [Congress] Mid-cycle sprint

Hi Zhenzan, Yes the oslo.messaging integration task is relevant--oslo.messaging is one way of achieving cross-process, cross-host messaging. So I'll count you as interested for the mid-cycle sprint. Have you looked at the API call that forces a datasource driver to pull immediately? See congre

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

On 06/17/2015 09:50 AM, Serg Melikyan wrote: > Thank you for sharing link to list of things that new module should > satisfy to! It will be really helpful even if list will change over > time. At least we have pointers how to start making our module > compliant. > > Regarding figuring out permis

Re: [openstack-dev] [Ironic] ironic-lib library

Excerpts from Ramakrishnan G's message of 2015-06-17 12:50:25 +0530: > Seems to me like we can keep ironic-lib git repository as a git submodule > of the ironic and ironic-python-agent repositories. Any commit in Ironic > or Ironic-python-agent can change ironic-lib independently. Also, looks > l

Re: [openstack-dev] [nova] [neutron] Re: [Openstack-operators] How do your end users use networking?

On Tue, Jun 16, 2015 at 8:20 AM, Jay Pipes wrote: > Adding -dev because of the reference to the Neutron "Get me a network > spec". Also adding [nova] and [neutron] subject markers. > > Comments inline, Kris. > > On 05/22/2015 09:28 PM, Kris G. Lindgren wrote: > >> During the Openstack summit this

[openstack-dev] Developers in the Bay Area

Hi! I work for an events market research company and am in need of recruiting young developers in the San Francisco Bay Area to answer a short survey to see if they qualify for an in-depth interview regarding an upcoming developer event in San Francisco. Is this something I can post your page o

Re: [openstack-dev] [puppet] New Juno (5.1.0) release

Hey, Thanks for your work guys. What about kilo release? Is it plan as well? Last summit, you mentioned that it could be released for end of june? Cheers, Arnaud. On 17/06/2015 15:57, Emilien Macchi wrote: Hi, We are preparing a new Juno sub-release. You can see the status of this work here

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/17/2015 06:30 AM, Lucas Alvares Gomes wrote: overlap there rather than competition), how crazy does it sound if we say that for OpenStack Nova is the compute API and Ironic the Bare Metal API and so on? Would that be an unacceptable power grab? It's not that it's unacceptable, but I think

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 6/16/2015 5:56 PM, Michael Still wrote: I don't think you need a spec for this (its a refactor). That said, I'd be interested in exploring how you deprecate the old flags. Can you have more than one deprecated name for a single flag? Michael On Wed, Jun 17, 2015 at 7:29 AM, Matt Riedemann

Re: [openstack-dev] [devstack] apache wsgi application support

On Tue, 16 Jun 2015, Sean Dague wrote: > I'd expect nova to be running on http://localhost/compute not > http://localhost:8774 when running under wsgi. That's going to probably > interestingly break a lot of weird assumptions by different projects, > but that's part of the reason for doing this e

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

> On Jun 16, 2015, at 14:56, Thomas Goirand wrote: > > On 06/16/2015 12:06 PM, Thierry Carrez wrote: It also removes the stupid encouragement to use all components from the same date. With everything tagged at the same date, you kinda send the message that those various things sho

Re: [openstack-dev] [Glance] [all] Proposal for Weekly Glance Drivers meeting.

As this Fri Jun 19th did not seem to have weight, I just express my opinion to the mailing list for the records. Personally I think this is bad idea, but as not being Glance Driver I can't say how much need there is for such meeting. The specs should be raised during our weekly meeting and/or d

Re: [openstack-dev] [Neutron] Quota enforcement

On 06/16/2015 11:58 PM, Carl Baldwin wrote: On Tue, Jun 16, 2015 at 5:17 PM, Kevin Benton wrote: There seems to be confusion on what causes deadlocks. Can one of you explain to me how an optimistic locking strategy (a.k.a. compare-and-swap) results in deadlocks? Take the following example whe

[openstack-dev] ★ Openstack Dev, Hachem a laissé un message pour toi

Hachem a laissé un message pour toi Tu peux immédiatement répondre via notre messagerie instantanée. Voir tes messages... http://eu1.badoo.com/0322198318/in/KMLZfBmG1ho/?lang_id=6&g=57-0-4&m=61&mid=55818daf0006004d0591faaf003ada3301a6 D'autres personnes attendent : Les liens ne fonct

Re: [openstack-dev] [puppet] New Juno (5.1.0) release

On 06/17/2015 10:15 AM, Arnaud Morin wrote: > Hey, > > Thanks for your work guys. > What about kilo release? Is it plan as well? Last summit, you mentioned > that it could be released for end of june? And we're working hard on that: https://etherpad.openstack.org/p/puppet-kilo-release It shoul

Re: [openstack-dev] [nova] [neutron] Re: [Openstack-operators] How do your end users use networking?

On Wed, Jun 17, 2015 at 9:08 AM, John Griffith wrote: > > > On Tue, Jun 16, 2015 at 8:20 AM, Jay Pipes wrote: > >> Adding -dev because of the reference to the Neutron "Get me a network >> spec". Also adding [nova] and [neutron] subject markers. >> >> Comments inline, Kris. >> >> On 05/22/2015 09

Re: [openstack-dev] [neutron][L3] L3 routed network segments

Hi Carl, I know you said at the end of your message below to ping you on IRC, but there are details here that I'm not sure about, and some suggestions that I'd like to make, and I think it will be clearer to discuss those in context. I hope that's OK. On 11/06/15 17:26, Carl Baldwin wrote:

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Great! I'll reach out to you in unicast mode on this Kris, thanks! On Wed, Jun 17, 2015 at 10:27 AM, Kris G. Lindgren wrote: > While I didn't know about the Neutron mid-cycle being next week. I do > happen to live in Fort Collins, so I could easy become available if you > want to talk face-to-

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

While I didn't know about the Neutron mid-cycle being next week. I do happen to live in Fort Collins, so I could easy become available if you want to talk face-to-face about https://bugs.launchpad.net/neutron/+bug/1458890. Kris Lindgren Senior Linux

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I tend to agree with Thomas that plan D is not ideal. For one, it prevents changes to the stable branch that span multiple CRs, since a two patch change would generate two tags and there would be no clear indication that the first patch should not b

Re: [openstack-dev] [Nova] [Cinder] [Tempest] Regarding deleting snapshot when instance is OFF

On Tue, Jun 16, 2015 at 3:33 PM, Jordan Pittier wrote: > On Thu, Apr 9, 2015 at 6:10 PM, Eric Blake wrote: > >> On 04/08/2015 11:22 PM, Deepak Shetty wrote: >> > + [Cinder] and [Tempest] in the $subject since this affects them too >> > >> > On Thu, Apr 9, 2015 at 4:22 AM, Eric Blake wrote: >> >

Re: [openstack-dev] [Magnum] TLS Support in Magnum

Do consider another use case, that of a private docker cluster... I may want to use magnum to deploy a docker cluster in a private neutron network for a mid/backend tier as a component of a larger scalable cloud application. Floating ip's would not be used in this case since the machines that w

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Excerpts from Doug Hellmann's message of 2015-06-16 15:55:04 -0400: > Excerpts from Thierry Carrez's message of 2015-06-16 11:45:51 +0200: > > Doug Hellmann wrote: > > > [...] > > > I put together a little script [1] to try to count the previous > > > releases for projects, to use that as the basis

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 05:40 PM, Douglas Mendizábal wrote: > I tend to agree with Thomas that plan D is not ideal. For one, it > prevents changes to the stable branch that span multiple CRs, since > a two patch change would generate two tags and there would

[openstack-dev] [nova][ceilometer] proposal to send bulk hypervisor stats data in periodic notifications

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

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

Emilien, Thank you for your proposal, I completely agree with it: > * Move the module under the big tent Proposed change in infra [1] and corresponding change in governance [2] > * Adding Puppet OpenStack group part of core permissions I've added puppet-manager-core to puppet-murano-core > * Ke

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

The biggest issue we have run into with multiple public networks is restricting which users can use which networks. We have the same issue, where we may have an internal public network for the datacenter, but also, say, a DMZ network we want to put some vm's on, but can't currently extend that n

Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic‏

Hey there! Yes, we are duplicating effort. I've spent quite a bit of effort over the past few months landing features inside openstack that will make it possible for a JavaScript client to be imported to horizon as a dependency. This includes CORS, configuration, caching, infra tooling, etc, with

[openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities

Hello everyone: I would like to test the waters on some new functionality we think is needed to protect OpenStack deployments from some overload situations due to an excessive user or DDOS scenario. We wrote this up in the style of an RFE. Please let us know your thoughts and we can pr

Re: [openstack-dev] [nova][ceilometer] proposal to send bulk hypervisor stats data in periodic notifications

I was involved in the IRC discussion, but to reiterate here this would be a wonderful thing to get done. The current polling can be terribly inefficient, and the ceilo team is already looking into other ways to reduce the impact of it. I'm looking forward to helping with this. Cheers, Jason On W

Re: [openstack-dev] Developers in the Bay Area

Lisette Sheehan wrote: > I work for an events market research company and am in need of > recruiting young developers in the San Francisco Bay Area to answer a > short survey to see if they qualify for an in-depth interview regarding > an upcoming developer event in San Francisco. Is this something

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

Ihar Hrachyshka wrote: > On 06/17/2015 05:40 PM, Douglas Mendizábal wrote: >> I tend to agree with Thomas that plan D is not ideal. For one, it >> prevents changes to the stable branch that span multiple CRs, since >> a two patch change would generate two tags and there would be no >> clear indic

Re: [openstack-dev] [Ironic] ironic-lib library

On 2015-06-17 10:10:22 -0400 (-0400), Doug Hellmann wrote: > Excerpts from Ramakrishnan G's message of 2015-06-17 12:50:25 +0530: > > Seems to me like we can keep ironic-lib git repository as a git submodule > > of the ironic and ironic-python-agent repositories. Any commit in Ironic > > or Ironic

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 6/17/2015 8:14 AM, Duncan Thomas wrote: On 17 June 2015 at 15:36, Dmitry Guryanov mailto:[email protected]>> wrote: On 06/17/2015 02:14 PM, Duncan Thomas wrote: On 17 June 2015 at 00:21, Matt Riedemann mailto:[email protected]>

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 6/17/2015 7:36 AM, Dmitry Guryanov wrote: On 06/17/2015 12:21 AM, Matt Riedemann wrote: The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very similar. I want to extract a common base class that abstracts some of the common code and then let the sub-classes provide over

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 17 June 2015 at 17:19, Thierry Carrez wrote: > Ihar Hrachyshka wrote: >> On 06/17/2015 05:40 PM, Douglas Mendizábal wrote: >>> I tend to agree with Thomas that plan D is not ideal. For one, it >>> prevents changes to the stable branch that span multiple CRs, since >>> a two patch change would

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On 6/17/2015 4:46 AM, Daniel P. Berrange wrote: On Tue, Jun 16, 2015 at 04:21:16PM -0500, Matt Riedemann wrote: The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very similar. I want to extract a common base class that abstracts some of the common code and then let the sub

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

I agree with Rob in terms of tooling and with Travis on rules.Any linting tool is fine with me as long as it does not break the rules we currently have set in Horizon. I believe the rules right now are general enough, so switching to eslint might not be an issue, but its something to look into. And

Re: [openstack-dev] [neutron][db] online schema upgrades

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote: > Ihar, thanks for bringing this up! > > This is very interesting and I think it worth trying. I'm +1 on > that and want to participate in this work. > Awesome. > In fact a lot *not strict* migrati

Re: [openstack-dev] [neutron][db] online schema upgrades

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/16/2015 05:58 PM, Mike Bayer wrote: > > > On 6/16/15 11:41 AM, Ihar Hrachyshka wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> - - instead of migrating data with alembic rules, migrate it in >> runtime. There should be a abst

[openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

Hello Solum Developers, When we were designing the operator languagepack feature for Solum, we wanted to make use of public urls to download operator LPs, such as those available for CDN backed swift containers we have at Rackspace, or any publicly accessible url. This would mean that when a us

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 05:55 PM, Fox, Kevin M wrote: > The biggest issue we have run into with multiple public networks is > restricting which users can use which networks. We have the same > issue, where we may have an internal public network for the > datac

Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities

Hi John, We were trying to push a very similar spec to enhance the security group API, we covered both DDoS case and another use case for brute force prevention (We did a research to identify common protocols login behaviour in order to identify brute force attacks using iptables) and even some UI

[openstack-dev] [cross-project] RBAC Policy Basics

Policy is supposed to allow access control to work across multiple services and endpoints. However, each service has specified policy differently. Here are some of the basic working assumptions for policy enforcement we can use to work towards consistent enforcement. 1) A policy rule shoul

Re: [openstack-dev] [Ceilometer][Gnocchi] question on integration with time-series databases

On Tue, 16 Jun 2015, Simon Pasquier wrote: I'm still struggling to see how these optimizations would be implemented since the current Gnocchi design has separate backends for indexing and storage which means that datapoints (id + timestamp + value) and metric metadata (tenant_id, instance_id, se

[openstack-dev] [Solum] Roadmap additions

Hi Adrian, As an FYI, I took a shot at updating the OpenStack wiki view of the Roadmap for Solum per IRC and developer collaboration, where good progress has been made over the last cycle delivering on features that make Solum usable in a production OpenStack system environment. This is, of co

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 17/06/15 16:17, Kris G. Lindgren wrote: See inline. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 6/17/15, 5:12 AM, "Neil Jerram" wrote: Hi Kris, Apologies in advance for questions that are probably really dumb - but there a

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

Hi guys! > * Do not merge a patch without at least one review from both groups > * Collaborate to make the module compliant I'm strongly agree with it, because it'll help to avoid some mistakes. Also, someone from puppet-manager-core may to prompt what are we doing wrong or better way for elaborat

[openstack-dev] [Tacker][Telco][NFV]: Reminder - weekly IRC meeting tomorrow Jun 18th

Meeting on #openstack-meeting @ 1600UTC (9am PDT) Agenda can be found here: https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_June_18.2C_2015 Feel free to update the agenda if needed. thanks, Sridhar __ OpenStack Devel

Re: [openstack-dev] [puppet][murano] Developing puppet module for Murano

I am planning on looking into Murano later this year so I'd be interested in helping review this code. I'm puppet-core so feel free to add me to reviews and I can look as time permits. On Wed, Jun 17, 2015 at 9:49 AM, Serg Melikyan wrote: > Emilien, > > Thank you for your proposal, I completely

Re: [openstack-dev] Developers in the Bay Area

Lisette, what is this about? http://it.linkedin.com/in/fsoppelsa On 06/17/2015 07:10 AM, Lisette Sheehan wrote: Hi! I work for an events market research company and am in need of recruiting young developers in the San Francisco Bay Area to answer a short survey to see if they qualify for an

Re: [openstack-dev] [neutron][db] online schema upgrades

On 6/17/15 12:40 PM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote: Ihar, thanks for bringing this up! This is very interesting and I think it worth trying. I'm +1 on that and want to participate in this work. Awesome

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: > On 06/16/2015 12:49 PM, Clint Byrum wrote: > > Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: > >> FYI, > >> > >> One of the things that came out of the summit for Devstack plans going > >> forward is to trim it ba

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Awesome! Thanks. :) Kevin From: Ihar Hrachyshka [[email protected]] Sent: Wednesday, June 17, 2015 9:41 AM To: [email protected] Subject: Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Re: [openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

On Wed, Jun 17, 2015 at 11:37:04AM -0500, Matt Riedemann wrote: > > > On 6/17/2015 4:46 AM, Daniel P. Berrange wrote: > >On Tue, Jun 16, 2015 at 04:21:16PM -0500, Matt Riedemann wrote: > >>The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all very > >>similar. > >> > >>I want to e

[openstack-dev] [QA] Meeting Thursday June 18th at 17:00 UTC

Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, June 18th at 17:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to a

[openstack-dev] [tc] adding magnum-ui to the openstack git namespace

Hey TCers, In this thread, the Magnum community made a commitment to tackle horizon support for our software: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066701.html We would like to add magnum-ui to the list of repos in the openstack namespace. The governance review change: h

Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

On 06/17/2015 01:29 PM, Clint Byrum wrote: > Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: >> On 06/16/2015 12:49 PM, Clint Byrum wrote: >>> Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: FYI, One of the things that came out of the summit for Devs

Re: [openstack-dev] [tc] adding magnum-ui to the openstack git namespace

TC, I authorized the addition of the new repo in the ML thread, and have recorded my approval on each of the reviews. Thanks, Adrian Otto — OpenStack Magnum PTL On Jun 17, 2015, at 10:57 AM, Steven Dake (stdake) mailto:[email protected]>> wrote: Hey TCers, In this thread, the Magnum communit

Re: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: [openstack-dev] [S

Re: [openstack-dev] [devstack] apache wsgi application support

On 06/16/2015 05:25 PM, Chris Dent wrote: > On Tue, 16 Jun 2015, Sean Dague wrote: > >> I was just looking at the patches that put Nova under apache wsgi for >> the API, and there are a few things that I think are going in the wrong >> direction. Largely I think because they were copied from the >

Re: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, a

[openstack-dev] [Solum] Update on current status

Hi team, With the recent application from our team to be included in the big tent (https://review.openstack.org/190949), I wanted to give a quick update on the state of our project. Before I do that, here is a quick overview of the current capabilities of Solum and a very high-level view o

Re: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that;

[openstack-dev] [all] setup.py executable bit

An unintended side effect of the requirements refactoring was that we changed from preserving the 'x' bit on setup.py, to discarding it. This happened when we started writing the file atomically rather than in-place - a good robustness improvement. Previously the requirements sync, which enforces

[openstack-dev] [Ironic] [Nova] How to pass additional information from Flavor to an Ironic driver

Hi everyone, we are developing an Ironic driver for OneView [1], an Infrastructure Management System (IMS) by HP and, in order to deploy the node correctly, the driver needs to know some specific information about the configuration of the physical hardware. In OneView, there is the concept o

Re: [openstack-dev] [all] setup.py executable bit

Excerpts from Robert Collins's message of 2015-06-18 06:40:33 +1200: > An unintended side effect of the requirements refactoring was that we > changed from preserving the 'x' bit on setup.py, to discarding it. > This happened when we started writing the file atomically rather than > in-place - a go

[openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

Hi all, We are scheduled to publish 2014.1.5, last Icehouse point release, on Thurs June 18th for Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova and Trove. The list of issues fixed can be seen here: https://launchpad.net/ceilometer/+milestone/2014.1.5 https://launchpad.ne

  1   2   >