[Openstack] How to support for multiple external networks?

I want to setup multiple external networks, but I don't know how to make this works. Here's my user requirements: There are two departments want to use my cloud, but as history problem, they wants their VMs to use original IP range. DepA wants to use floating ip in 192.168.66.0/24, DepB wants to

Re: [Openstack] how to allow vlan tagged traffic to be sent from SR-IOV based VM?

Link: https://openstack.nimeyo.com/65515/?show=65788#c65788 From: shahamf Hey Remo, 'ip netns exec qrouter-41f2efea-7066-4dc3-bad7-41fdab130b65 ifconfig' gives me: lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1

Re: [Openstack] How to support for multiple external networks?

I think your gw is wrong your mask is /24 it does not match. Just make sure you do have the right info. Inviato da iPhone > Il giorno 19 nov 2015, alle ore 03:38, José Riguera López > ha scritto: > > > You can, just tell neutron you want to have another external

Re: [Openstack] How to support for multiple external networks?

You can create a router in each project and attach it to the specific external network (via gw) ... but: * With the default policy, the tenant can create another router for the other network. Quick solution: change the policy to not allow creating routers * I think it will be confusing for the

Re: [Openstack] How to support for multiple external networks?

​Thanks, I will have a try.​ Best Regards -- Ray On Thu, Nov 19, 2015 at 7:38 PM, José Riguera López wrote: > > You can, just tell neutron you want to have another external network. Lets > say VLAN=300 is 192.168.66. 0/24 > > # Creating the external

Re: [Openstack] lbaas kilo ha

Later this month I can work on this Remo Inviato da iPhone > Il giorno 19 nov 2015, alle ore 06:24, Yngvi Páll Þorfinnsson > ha scritto: > > Are we waiting for Openstack Octavia ? > (I‘m just guessing) > > Best regards > Yngvi > > From: Tom Verdaat

Re: [Openstack] How to support for multiple external networks?

Hauke, This is interesting, Is there any way to specify tenantA can only use ext-subnet1 and tenantB only use ext-subnet2? Thanks. Best Regards -- Ray On Thu, Nov 19, 2015 at 7:27 PM, Hauke Bruno Wollentin < hauke-bruno.wollen...@innovo-cloud.de> wrote: > Hi Ray, > > in general it is possible

Re: [Openstack] How to support for multiple external networks?

Hi Ray, in general it is possible to use two (or more) subnets in one external network, but all instances then will get IPs from both subnets (if the floating IPs on subnetA are allocated, the next ones will be allocated from subnetB). So you need to create two (non-shared, tenant specific)

Re: [Openstack] How to support for multiple external networks?

You can, just tell neutron you want to have another external network. Lets say VLAN=300 is 192.168.66. 0/24 # Creating the external network type VLAN with VLAND ID == 300 # The name of the provider physical_network "ext" is mapped to a physical # device on the ML2

Re: [Openstack] lbaas kilo ha

Excellent question! It should be in Kilo but documentation seems to be non-existent I'd also be very interested to any and all links to useful deployment documentation (especially for use on ubuntu)! Tom 2015-11-18 13:33 GMT+01:00 Yngvi Páll Þorfinnsson : > Also the

Re: [Openstack] [ovsdb-dev] No IP assigned to Instances

Hi Sam, I'm still trying to assign addresses to the VM. I was reading carefully your slides and I noticed, if I'm not wrong, that br-int should have a tap inerface for the connection to the dhcp agent. Is it true? In my configuration I noticed that: - Without instances in the controller node I

Re: [Openstack] OpenStack Network Configuration Problems

Sure, make sure that you have debug mode enabled (/etc/nova/nova.conf --> debug = True & the same for /etc/neutron/neutron.conf) Restart the following services (if you changed the config): - nova scheduler - nova compute - neutron agent - neutron service Now try to launch an instance again and

Re: [Openstack] lbaas kilo ha

OK, so I‘m not alone wondering about this ☺ ☺ ☺ Cheers Yngvi From: Tom Verdaat [mailto:t...@server.biz] Sent: 19. nóvember 2015 12:00 To: openstack@lists.openstack.org Subject: Re: [Openstack] lbaas kilo ha Excellent question! It should be in Kilo but documentation seems to be non-existent

Re: [Openstack] lbaas kilo ha

Are we waiting for Openstack Octavia ? (I‘m just guessing) Best regards Yngvi From: Tom Verdaat [mailto:t...@server.biz] Sent: 19. nóvember 2015 12:00 To: openstack@lists.openstack.org Subject: Re: [Openstack] lbaas kilo ha Excellent question! It should be in Kilo but documentation seems to be

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

Artur wrote: Mon 15 UTC works for me too. Was there the first meeting on past Monday? Or are we starting on Monday 23rd November? We start next Monday (Nov 23th). Ihar __ OpenStack

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

Tony Breeds wrote: On Wed, Nov 18, 2015 at 05:44:38PM +0100, Ihar Hrachyshka wrote: Hi all, as per [1] I imply that all projects under stable-maint-core team supervision must abide the stable policy [2] which limits the types of backports for N-2 branches (now it’s

Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit

David Pursehouse wrote on 11/12/2015 09:22:50 PM: > From: David Pursehouse > To: OpenStack Development Mailing List > Cc: openstack-in...@lists.openstack.org > Date: 11/12/2015 09:27 PM > Subject: Re:

[openstack-dev] [fuel] Fuel is now an OpenStack project: what's next?

Fuel team, You've heard the good news. After 4 months of hard work on expanding our collaboration with other OpenStack projects and aligning our development and governance processes with the OpenStack project requirements, our proposal to add Fuel to OpenStack projects [0] was approved by the

Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

Hi, Using fake driver means we need a manual step to set it to something > non-fake :) and the current introspection process already has 1 manual step > (enrolling nodes), so I'd like autodiscovery to require 0 of them (at least > for the majority of users). Exactly. I recognize that our purpose

Re: [openstack-dev] [magnum] Issue on history of renamed file/folder

This is a defect with Github and should not affect our ability to fix defects and correct/refactor our code. git is a CLI tool not a GUI tool and should be treated as such. We should not be imposing restrictions on our developers because a 3rd party GUI does not fit our workflows. Tom On

Re: [Openstack-operators] [Scale][Performance] / compute_nodes ratio experience

Dan, sure, I did not mean that we should collect this information without understanding the workloads happening on the cloud, but still this is very interesting information to gather. Cheers, Dina On Thu, Nov 19, 2015 at 1:52 AM, Dan Smith wrote: > > As providing OpenStack

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

Thomas Morin wrote: > The starting point for this post is a specific Neutron sub-project > (networking-bgpvpn) but I believe the issues raised are shared with > other neutron stadium project and possibly relevant beyond Neutron, to > projects tagged release-independent in general. > > In the

Re: [openstack-dev] [openstack][openstack-operators] IRC meeting(s)

JJ Asghar wrote: > I've been seeing some interesting regressions in our community > recently. Our IRC meetings, or at least the ones I've been attending, > are extremely variable in quality. I believe this is a disservice to > our community as a whole, so I've offered to help. > > I've written up

Re: [openstack-dev] How to add a periodic check for typos?

So since requirements usually has an 's' on the end, would you make my cheque for $1.00 payable to the Campaign Against Smog Hazard please? Just use our initials. -- MC __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [nova] release notes with reno and which patches need that?

Le 19/11/2015 18:37, Markus Zoeller a écrit : If you ever had a patch which contained "UpgradeImpact" or "DocImpact", this mail is for you. You may have already heard of "reno" and how it will change the handling of the release notes. If not, [1] is the announcement and [2] is an example. I

[openstack-dev] [Cinder] Mitaka Midcycle Sprint

Cinder Mitaka Midcycle Sprint Dates: January 26-29 (29th will be optional hack day) Location: NetApp Office 7301 Kit Creek Road, Research Triangle Park, NC 27709 https://www.openstreetmap.org/search?query=35.8578%2C-78.8839#map=16/35.8569/-78.8851 Contact: Tom Barron (tbarron) Nearest airport:

[openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)

I want to fix a thing in oslo.messaging but to my surprise I can't run pep8. This is because python-qpid-proton tries to install qpid-proton and it can't get that because the apache site where it's hosted is down. [1] The apache site for qpid has actually been down a lot lately, I

Re: [openstack-dev] [magnum] Mesos Conductor

I’m open to allowing magnum to pass a blob of data (such as a lump of JSON or YAML) to the Bay's native API. That approach strikes a balance that’s appropriate. Adrian On Nov 19, 2015, at 10:01 AM, bharath thiruveedula > wrote: Hi, At

Re: [openstack-dev] [Openstack-operators] [logs] Neutron not logging user information on wsgi requests by default

Sorry, I missed this earlier. I was in no way meaning to suggest running devstack for production. I was asking that operators look at their wsgi logs, and see if they are logging a username/tenant for Neutron requests. If not, providing a way to fix that (which I happened to take from

Re: [openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)

On 11/19/2015 12:22 PM, Matt Riedemann wrote: I want to fix a thing in oslo.messaging but to my surprise I can't run pep8. This is because python-qpid-proton tries to install qpid-proton and it can't get that because the apache site where it's hosted is down. [1] The apache site for qpid has

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Hey guys, Despite the fact I like containers (as deployment unit), we don't use them so. That means I +1 idea to drop containers, just because I believe that would * simplify a lot of things * helps get rid of huge amount of hacks * increase master node deployment * release us from annoying

[Openstack-operators] [Nova] Support for server groups in cells v1

We recently patched Nova for support of server groups under cells v1. It’s pretty rudimentary, but it works. For anyone that’s interested, the patch is here: https://gist.github.com/misterdorm/5e9513bb1211b49e551c and I did a short write-up with some details at

Re: [openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)

yes :) On Thu, Nov 19, 2015 at 1:22 PM, Matt Riedemann wrote: > I want to fix a thing in oslo.messaging but to my surprise I can't run pep8. > This is because python-qpid-proton tries to install qpid-proton and it can't > get that because the apache site where it's

Re: [openstack-dev] [tripleo] When to use parameters vs parameter_defaults

My personal preference is to say: 1. Any templates which are included in the default environment (e.g overcloud-resource-registry-puppet.yaml), must expose their parameters via overcloud-without-mergepy.yaml 2. Any templates which are included in the default environment, but via a "noop"

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo [imm]

> On Nov 19, 2015, at 11:24 AM, Matt Riedemann > wrote: > > > > On 11/19/2015 10:22 AM, Amrith Kumar wrote: >> Just catching up on this thread, have fixes been submitted for this already? >> >> Thanks, >> >> -amrith >> >>> -Original Message- >>> From:

[openstack-announce] [release][stable][ec2-api] ec2-api 0.2.0 release (kilo)

We are released ec2-api 0.2.0 It is designed for kilo release. With source available at: http://git.openstack.org/cgit/openstack/ec2-api With package available at: https://pypi.python.org/pypi/ec2-api Please report issues through launchpad: http://bugs.launchpad.net/ec2-api --

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Folks I guess it should be pretty simple to roll back - install older version and restore the backup with preservation of /var/log directory. On Thu, Nov 19, 2015 at 7:38 PM, Sergii Golovatiuk wrote: > Hi, > > On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

+1 On Thu, Nov 19, 2015 at 9:35 AM, Eichberger, German wrote: > All, > > > > As I said in a previous e-mail I am really excited about the deep talent in > the Octavia sub-project. So it is my pleasure to propose Bertrand Lallau (irc > blallau) as a new core for the

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

On Mon, Nov 9, 2015 at 1:39 PM, Shraddha Pandhe wrote: > Thats great. L3 layer network model is definitely one of our most important > requirements. All our go-forward deployments are going to be L3. So this is > a big deal for us. I think we're on a good path to

[openstack-dev] [Manila] Midcycle meetup survey

If you planning to attend the midcycle in any capacity, please vote your preferences here: https://www.surveymonkey.com/r/BXPLDXT -Ben __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [openstack-dev ] [Heat] how to verify heat resource plugin

Hi Mohan, well, you should have the service you are developing the resource plugin for installed somewhere and run heat against it, creating the stack with the new resource type your plugin is defining, and checking that the thing it creates is working, can be updated and deleted via heat

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

+1 > On Nov 19, 2015, at 11:39 AM, Brandon Logan > wrote: > > +1 > > On Thu, 2015-11-19 at 17:35 +, Eichberger, German wrote: >> All, >> >> >> >> As I said in a previous e-mail I am really excited about the deep talent in >> the Octavia sub-project. So it

Re: [Openstack-operators] How to install magnum?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/3/15 11:48 AM, Mike Perez wrote: > On 18:51 Oct 28, Mike Perez wrote: >> On 12:35 Oct 28, JJ Asghar wrote: >>> On 10/28/15 10:35 AM, Mike Perez wrote: On 14:09 Oct 16, hittang wrote: > Hello,everynoe. Can anybody help me for

Re: [openstack-dev] [Horizon] Bug day! Yeah!

Great, I'll be around next Tuesday. -Lin On Thu, Nov 19, 2015 at 12:53 PM, Rob Cresswell (rcresswe) < rcres...@cisco.com> wrote: > As requested, > https://etherpad.openstack.org/p/horizon-bug-day > > Rob > > From: Richard Jones > Reply-To: "OpenStack Development Mailing

Re: [openstack-dev] [openstack][openstack-operators] IRC meeting(s)

++ > -Original Message- > From: Thierry Carrez [mailto:thie...@openstack.org] > Sent: Thursday, November 19, 2015 1:52 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [openstack][openstack-operators] IRC > meeting(s) > > JJ Asghar wrote: > > I've been seeing

Re: [Openstack-operators] [openstack-dev] [all]Can we get some sanity in the Neutron logs please?

Thanks both Armando and Matt! I am cross posting this to the operators' list (as the main post -- operators, simple reply and no spam to dev). The logging tag should be a tag in all projects. I'm glad it's already there in Neutron. And, this sort of feedback is exactly what we need operators

Re: [openstack-dev] [magnum] Mesos Conductor

It's great that we come to some agreement on unifying the client call ;-) As i proposed in previous thread, I think that "magnum app-create" may be better than "magnum create", I want to use "magnum app-create" to distinguish with "magnum container-create". The "app-create" may also not a good

Re: [Openstack-operators] [Scale][Performance] / compute_nodes ratio experience

Sorry this doesn't thread properly, but cut and pasted out of the digest... > As providing OpenStack community with understandable recommendations > and instructions on performant OpenStack cloud deployments is part of > Performance Team mission, I'm kindly asking you to share your >

Re: [openstack-dev] [ironic] Redfish drivers in ironic

Hello, Vladyslav Drok said on Thu, Nov 19, 2015 at 03:59:41PM +0200: Hi list and Bruno, I’m interested in adding virtual media boot interface for redfish ( https://blueprints.launchpad.net/ironic/+spec/redfish-virtual-media-boot). It depends on

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

ceilometer cares. we listen to all notifications and build Measurement and Event data from (some of) them. to be honest, i don't know if changes in nova notifications have/are broken in ceilometer because quite frankly there are far too many notifications to test and track. as a consumer of

Re: [openstack-dev] [all]Can we get some sanity in the Neutron logs please?

Thanks both Armando and Matt! I am cross posting this to the operators' list (as the main post -- operators, simple reply and no spam to dev). The logging tag should be a tag in all projects. I'm glad it's already there in Neutron. And, this sort of feedback is exactly what we need operators

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

On 11/19/2015 5:52 PM, gord chung wrote: ceilometer cares. we listen to all notifications and build Measurement and Event data from (some of) them. to be honest, i don't know if changes in nova notifications have/are broken in ceilometer because quite frankly there are far too many

Re: [openstack-dev] [Openstack-operators] [openstack-ansible] Fedora/CentOS/other Support

On 11/19/2015 09:32 AM, Kevin Carter wrote: > I don't believe we should have a class system in the OS's that we choose > to support. If we're going to bring in a new OS I think we should first > bring it in using non-voting jobs however once all of the bits have been > finalized the supported

Re: [Openstack-operators] [Nova] Question about starting nova as service versus directly

Hi Adam, I've seen this happen due to permission issues. Regardless of running with sudo, upstart is dropping to the "nova" user. I usually debug this by setting a shell on the nova user, sudoing/su'ing to nova, then running nova-compute from there. It should die with an error message of the

Re: [openstack-dev] [Horizon] Bug day! Yeah!

Thanks Rob, next Tuesday is fine with me. -Zhenguo Sent from my iPhone > On Nov 19, 2015, at 19:19, Rob Cresswell (rcresswe) > wrote: > > Hey folks, > > Our bug list is… rather large. We’ve discussed having a bug day, where as a > community we all dedicate some time to

[openstack-dev] [release][stable] OpenStack 2014.2.4 (juno)

Again, my plea to leave the Juno repository on git.openstack.org, but locked down to enable at least grenade testing for Juno->Kilo upgrades. For upgrade testing purposes, python2.6 is not needed as any cloud would have to upgrade python before upgrading to kilo. The testing could/should be

[openstack-dev] [security][sahara] creating a threat analysis to aid operators

hello all, during the security midcycle meetup we had a session about creating threat analysis for openstack projects. the folks at HPE were kind enough to offer their documentation and examples as an aid to creating these analysis. after talking with the sahara team, i am confident that we

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

On 11/19/2015 03:59 PM, Vladimir Kozhukalov wrote: > Anyway, the idea is to get > rid of Docker containers on the master node and switch to plane package > based approach that we used before. +1 __ OpenStack Development

Re: [openstack-dev] [infra][glance] How do we fix the glance_store git > glance-store LP mapping?

When I originally wanted to create the naming for glance_store to be consistent across platforms, we already had the library glance_store out (actually it first called glance.store but due to the anxiety of namespace conflicts it was quickly renamed to glance_store in git/gerrit etc.). Creating a

Re: [openstack-dev] [magnum] Mesos Conductor

+1, I found that 'kubectl create -f FILENAME’ (https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md) works very well for different type of objects and I think we should try to use it. but I think we should support two use-cases - 'magnum

Re: [openstack-dev] [magnum] Mesos Conductor

Hi, At the present scenario, we can have mesos conductor with existing attributes[1]. Or we can add extra options like 'portMappings', 'instances', 'uris'[2]. And the other options is to take json file as input to 'magnum container-create' and dispatch it to corresponding conductor. And the

Re: [openstack-dev] [Manila] Mitaka deadlines

On 11/19/2015 12:24 PM, Ben Swartzlander wrote: Based on discussions going back to the Liberty feature freeze, we have decided to add some additional deadlines for Mitaka, to avoid having fire drills at the end of the release, and to focus core reviewer attention on the right things. As always,

[openstack-dev] [nova] What things do we want to get into a python-novaclient 3.0 release?

We've been talking about doing a 3.0 release for novaclient for awhile so we can make some backward incompatible changes, like: 1. Removing the novaclient.v1_1 module 2. Dropping py26 support (if there is any explicit py26 support in there) What else are people aware of? Monty was talking

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

+1 On Thu, 2015-11-19 at 17:35 +, Eichberger, German wrote: > All, > > > > As I said in a previous e-mail I am really excited about the deep talent in > the Octavia sub-project. So it is my pleasure to propose Bertrand Lallau (irc > blallau) as a new core for the OpenStack Neutron

Re: [openstack-dev] [infra][glance] How do we fix the glance_store git > glance-store LP mapping?

Yes, that is why I have suggested you either update the mapping so it is correct or you use glance which is what the mapping currently says you want to use. On Thu, Nov 19, 2015, at 12:08 PM, Nikhil Komawar wrote: > When I originally wanted to create the naming for glance_store to be > consistent

Re: [openstack-dev] [Horizon] Bug day! Yeah!

Let's do it. I'd like to suggest we use an etherpad to keep track of what people have done. If it's not created when I start my day, I'll make one. Richard On 19 November 2015 at 22:19, Rob Cresswell (rcresswe) wrote: > Hey folks, > > Our bug list is… rather large.

Re: [openstack-dev] [Horizon] Bug day! Yeah!

As requested, https://etherpad.openstack.org/p/horizon-bug-day Rob From: Richard Jones > Reply-To: "OpenStack Development Mailing List (not for usage questions)" >

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

On Thu, 19 Nov 2015, Julien Danjou wrote: It would be good to support that as being *normal*, not "potentially incorrect and random"! Yes. The underlying issue in this thread is the dominance of the six month cycle and the way this is perceived to be (any may actually be) a benefit for

Re: [openstack-dev] [infra][glance] How do we fix the glance_store git > glance-store LP mapping?

On 11/19/2015 11:38 AM, Clark Boylan wrote: On Thu, Nov 19, 2015, at 08:00 AM, Matt Riedemann wrote: Patches in Gerrit aren't syncing status to the glance-store project in launchpad b/c the project in launchpad is called glance-store and in git it's glance_store. Looking at the project

Re: [openstack-dev] [nova] release notes with reno and which patches need that?

Le 19/11/2015 20:46, Sylvain Bauza a écrit : Le 19/11/2015 18:37, Markus Zoeller a écrit : If you ever had a patch which contained "UpgradeImpact" or "DocImpact", this mail is for you. You may have already heard of "reno" and how it will change the handling of the release notes. If not, [1]

Re: [openstack-dev] [ironic] weekly subteam status report

On 17 November 2015 at 01:34, Naohiro Tamura wrote: > Ruby, > > Thanks for taking care of our weekly status report. > I'd like to just let you know that the iRMC part is somehow consolidated > with old statuses which I reported two and three weeks ago. > If this

[openstack-dev] [nova] Versioned notifications... who cares about the version?

Reading through [1] I started getting worries in the back of my head about versioning these notifications. The main concern being how can the consumer know about the versions and what's different between them? Because these versioned notification payloads hold live nova objects, there can be a

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

The high value of the bug here reflects that the error message is wrong. >From a UX side we could maybe even justify this as Critical. The error message must reflect the correct quantity of addresses required. On Tue, Nov 17, 2015 at 1:31 PM Roman Prykhodchenko wrote: > Folks,

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

On 19 November 2015 at 09:25, Brad P. Crochet wrote: > I have pushed up a draft of the spec. Let's move comments there. > > I tried to incorporate as much as I could from the discussion here. > There was a lot of disjointed suggestions and was a bit difficult to > follow. So

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

On Tue, Nov 17, 2015 at 12:35 AM, Jim Rollenhagen wrote: > > > My preference is 4) no mid-cycle -- and try to work more effectively with > > people in different locations and time zones. > > ++ that was part of my thought process when I proposed not having an > official

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

> > Another idea I floated last week was to do a virtual midcycle of sorts. > > Treat it like a normal midcycle in that everyone tells their management > > "I'm out for 3-4 days for the midcycle", but they don't travel anywhere. > > We come up with an agenda, see if there's any planning/syncing

Re: [openstack-dev] [puppet] weekly meeting #59

Clayton O'Neill wrote: > On Tue, Nov 17, 2015 at 4:38 PM, Cody Herriges > wrote: > > Now that the standard is $::os_service_default does it mean that current > changes up for review with parameters set to the string ' DEFAULT>' should

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

On 11/19/2015 4:05 PM, Ryan Rossiter wrote: Reading through [1] I started getting worries in the back of my head about versioning these notifications. The main concern being how can the consumer know about the versions and what's different between them? Because these versioned notification

Re: [openstack-dev] How to add a periodic check for typos?

On 11/18/2015 8:00 PM, Gareth wrote: Hi stacker, We could use some 3rd tools like topy: pip install topy topy -a git commit & git review Here is an example: https://review.openstack.org/#/c/247261/ Could we have a periodic job like Jenkins users updating our requirement.txt?

[Openstack-operators] [Nova] Question about starting nova as service versus directly

So I can start Nova on Ubuntu/Icehouse via *$ sudo python /usr/bin/nova-compute* and it runs fine and stays online but it does not run/stay online if I use *$ sudo service nova-compute start/restart*. I guessed it might have been related to rootwrap but I ran out of time to troubleshoot so I

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

Erno wrote: Typo fixes are not good idea for stable branches. As it might be bit annoying or amusing for the English user fixing typos in kilo will mean that it breaks translation for all the rest and I haven't seen any translation patches being proposed to older stable

[OpenStack-Infra] Request to add group member into the new Openstack project

Hi openstack-infra team, Kindly please add > to the following Gerrit ACL groups: -- https://review.openstack.org/#/admin/groups/1186,members

Re: [openstack-dev] [ironic][security] what is OK to put in DEBUG logs?

Hi, > Also keep in mind that DEBUG logging, while still should have some masking > of data, since it is explicitly called out (or should be) as not safe for > production, can contain some " sensitive" data. Credentials should still be > scrubbed, but I would say the swift temp URL is something

Re: [openstack-dev] [puppet] review the core-reviewer members

So here is a status: * François Charlier told me he's not working anymore on Puppet OpenStack, and wants to be dropped from core-reviewer list. I would like to personally thank him, he was the guy who showed me what is Puppet and how to write Puppet code. Thanks a lot for your work in our

Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

What Yuiko has described makes a lot of sense, and from that perspective perhaps instead of us defining what driver a node should and shouldn't be using a config file, we should just provide a guide to using the inspector rules for this and maybe some prewritten rules that can set the driver

Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic

Regarding tunnel for that. How do you ensure packet timestamps and ordering? Endre Karlson 19. nov. 2015 4.55 a.m. skrev "Li Ma" : > It is suggested that you can issue a RFE request for it. [1] We can > discuss with it and track the progress in the launchpad. > > By the

Re: [openstack-dev] [fuel] Fuel is now an OpenStack project: what's next?

Dima, A very huge +1 to the initiatives, especially Diversity, you have listed here and a big congratulations to everyone. Thanks, Dims On Thu, Nov 19, 2015 at 3:04 AM, Dmitry Borodaenko wrote: > Fuel team, > > You've heard the good news. After 4 months of hard work

Re: [openstack-dev] [Monasca][vitrage] Vitrage project

Hi Roland, Thanks for your feedback. The questions you raised below are helping us in clarifying and enhancing our design. We will also be happy to see your comments on our blueprints. Your input will be very helpful. The integration with Monasca should include two parts: 1. Query

Re: [openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

On 11/19/2015 11:57 AM, Sam Betts (sambetts) wrote: What Yuiko has described makes a lot of sense, and from that perspective perhaps instead of us defining what driver a node should and shouldn’t be using a config file, we should just provide a guide to using the inspector rules for this and

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

> -Original Message- > From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] > Sent: Thursday, November 19, 2015 10:43 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [stable][neutron] How we handle Kilo > backports > > Tony Breeds

[openstack-dev] [Horizon] Bug day! Yeah!

Hey folks, Our bug list is… rather large. We’ve discussed having a bug day, where as a community we all dedicate some time to triaging bugs and discussing in the IRC channel as we go. First off, see the docs about bug triage: https://wiki.openstack.org/wiki/BugTriage Secondly, lets pick a

[openstack-dev] [nova] Today, November 19 is Nova Spec Review Day

Hi all, A (late) reminder that today is Spec Review day: https://wiki.openstack.org/wiki/Nova/Mitaka_Release_Schedule I encourage everyone to help review the specs we still have up for review. Any questions, as normal, chat in #openstack-nova in IRC. If you are busy today, or today as already

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

Hi, > I sent a new idea to openstack-dev, and nobody has opinions? :P > > I'd like to get consensus on this soon, please do reply if you have > thoughts on this. > Sorry for the delay... Yeah, I've no problem giving this virtual midcycle idea a go, so +1

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

Me too :) +1 for trying a virtual midcycle On Thu, Nov 19, 2015 at 8:55 AM, Lucas Alvares Gomes wrote: > Hi, > > > I sent a new idea to openstack-dev, and nobody has opinions? :P > > > > I'd like to get consensus on this soon, please do reply if you have > > thoughts on

[openstack-dev] [openstack-dev ] [Heat] how to verify heat resource plugin

Hi team, Currently working on adding heat resource plugin for neutron extension "networking-sfc" , similar to firewall implementation " https://github.com/openstack/heat/blob/master/heat/engine resources/openstack/neutron/firewall.py

Re: [Openstack-operators] [openstack-dev] [openstack-ansible] Fedora/CentOS/other Support

On 11/18/2015 04:19 AM, Jesse Pretorius wrote: > The current community has done some research into appropriate patterns to use > and has a general idea of how to do it - but in order to actually execute > there need to be enough people who commit to actually maintaining the work > once it's

Re: [openstack-dev] [Ironic] Do we need to have a mid-cycle?

Seems good to me too. On Thu, Nov 19, 2015 at 5:07 PM, John Villalovos wrote: > Me too :) > > +1 for trying a virtual midcycle > > On Thu, Nov 19, 2015 at 8:55 AM, Lucas Alvares Gomes < > lucasago...@gmail.com> wrote: > >> Hi, >> >> > I sent a new idea to

Re: [openstack-dev] [openstack-ansible] Fedora/CentOS/other Support

On 11/18/2015 04:19 AM, Jesse Pretorius wrote: > The current community has done some research into appropriate patterns to use > and has a general idea of how to do it - but in order to actually execute > there need to be enough people who commit to actually maintaining the work > once it's

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

> On Nov 19, 2015, at 4:43 AM, Thierry Carrez wrote: > > Thomas Morin wrote: >> The starting point for this post is a specific Neutron sub-project >> (networking-bgpvpn) but I believe the issues raised are shared with >> other neutron stadium project and possibly relevant

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

> On Nov 19, 2015, at 9:28 AM, Thomas Morin wrote: > > Hi Thierry, > > Thanks for you answers, more below. > > Thierry Carrez : >> Thomas Morin wrote: >>> The starting point for this post is a specific Neutron sub-project >>> (networking-bgpvpn) but I believe the

  1   2   >