Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Certainly the aim is to support upgrades between LTS releases. Getting a meaningful keynote slot at an OpenStack summit is more of a challenge. On 6 Nov 2015 9:27 pm, "Jonathan Proulx" wrote: > > On Fri, Nov 06, 2015 at 05:28:13PM +, Mark Baker wrote: > :Worth mentioning

[openstack-dev] [Neutron] Reminder: Team meeting on Monday at 2100 UTC

A kind reminder for next week's meeting. Please add agenda items to the meeting here [1]. Cheers, Armando [1] https://wiki.openstack.org/wiki/Network/Meetings __ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [searchlight] Mitaka Priorities discussion mapped to launchpad

Hello Searchlighters, I just wanted to let everybody know that I’ve captured the results of our priorities discussion on the Searchlight launchpad blueprints page. In some cases, this meant creating a new blueprint (sometimes with only a little information). Next week, it would be great if

Re: [openstack-dev] [openstack-ansible][security] Next steps: openstack-ansible-security

On Friday, 6 November 2015, Major Hayden wrote: > > At this moment, openstack-ansible-security[1] is feature complete and all > of the Ansible tasks and documentation for the STIGs are merged. Exciting! Excellent work, thank you! > I've done lots of work to ensure that the

Re: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes

One thing I forgot to mention in my original email was the discussion about when we would have this themes conversation for the N cycle. I had originally hoped we would discuss the themes online before the summit, and that those would inform decisions about summit sessions. Several other folks in

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

Congress allows users to write a policy that executes an action under certain conditions. The conditions can be based on any data Congress has access to, which includes nova servers, neutron networks, cinder storage, keystone users, etc. We also have some Ceilometer statistics; I'm not sure

Re: [openstack-dev] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?

On Friday, 6 November 2015, Major Hayden wrote: > > I found a CA role[1] for Ansible on Galaxy, but it appears to be GPLv3 > code. :/ Considering that the role would not be imported into the OpenStack-Ansible code tree, the license for this role would not be an issue I don't

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

Replies inline. On Fri, Nov 6, 2015 at 1:48 PM, Salvatore Orlando wrote: > More comments inline. > I shall stop trying being ironic (pun intended) in my posts. > :( > > Salvatore > > On 5 November 2015 at 18:37, Kyle Mestery wrote: > >> On Thu,

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

+1 Good work indeed. >From: EXT John Garbutt [mailto:j...@johngarbutt.com] >Sent: Friday, November 06, 2015 5:32 PM >To: OpenStack Development Mailing List >Subject: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core > >Hi, > >I propose we add Alex Xu[1] to nova-core. > >Over the last

Re: [openstack-dev] [kuryr] mutihost networking with nova vm as docker host

+1 for "container-in-vm" On Fri, Nov 6, 2015 at 10:48 PM, Antoni Segura Puimedon < toni+openstac...@midokura.com> wrote: > > > On Fri, Nov 6, 2015 at 1:20 PM, Baohua Yang wrote: > >> It does cause confusing by calling container-inside-vm as nested >> container. >> >> The

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

+1, Alex worked on Nova project for a long time, and push lot of API feature in last few cycles, And spend lots of time doing reviewing, I am glad to add my +1 to him. BR, Eli(Li Yong)Qiao -Original Message- From: Ed Leafe [mailto:e...@leafe.com] Sent: Saturday, November 07, 2015 2:34

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

Excerpts from Tony Breeds's message of 2015-11-05 22:08:59 -0800: > Hello all, > I came across [1] which is notionally an ironic bug in that horizon > presents > VM operations (like suspend) to users. Clearly these options don't make sense > to ironic which can be confusing. > > There is a

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

Le 06/11/2015 07:08, Tony Breeds a écrit : Hello all, I came across [1] which is notionally an ironic bug in that horizon presents VM operations (like suspend) to users. Clearly these options don't make sense to ironic which can be confusing. There is a horizon fix that just disables

Re: [openstack-dev] [Fuel] Change VIP address via API

Hi, Mike, that's exactly how you can use this VIPs allocation functionality. Nailgun will save that VIP so it's not going to be auto-assigned to any node and serialize it into astute.yaml (vip_name: IP). After that you can get your VIP via Hiera and use it in your deployment scripts. Guys, could

Re: [openstack-dev] [Fuel] Change VIP address via API

+1 to Mike It would be awesome to get an API handler that allows one to actually add an ip address to IP_addrs table. As well as an IP range to ip_ranges table. On Fri, Nov 6, 2015 at 6:15 AM, Mike Scherbakov wrote: > Is there a way to make it more generic, not "VIP"

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote: > Hello all, > I came across [1] which is notionally an ironic bug in that horizon > presents > VM operations (like suspend) to users. Clearly these options don't make sense > to ironic which can be confusing. > > There is a

Re: [openstack-dev] [stable][neutron] Kilo is 'security-supported'. What does it imply?

Carl Baldwin wrote: >> - StableBranch page though requires that we don’t merge non-critical bug >> fixes there: "Only critical bugfixes and security patches are acceptable” > > Seems a little premature for Kilo. It is little more than 6 months old. > >> Some projects may want to continue

[openstack-dev] [deb-packaging] [infra] I need help to move forward with the build CI: building a sbuild Debian image

Hi, As the first package source got approved a week before the Tokyo summit (ie: openstack/deb-openstack-pkg-tools), in the Tokyo design summit, we had a 2 sessions to discuss packaging within OpenStack upstream infra. Here's the Etherpad: https://etherpad.openstack.org/p/mitaka-deb-packaging I

Re: [openstack-dev] [Neutron][dns]What the meaning of "dns_assignment" and "dns_name"?

Hi Miguel, I’ve just been looking at this, and have deduced the following summary of the new dns_name and dns_assignment fields: - dns_name is a simple name, like 'vm17'. It is a writable port field, and gets combined with a dns_domain that is specified elsewhere. - dns_assignment is a

[openstack-dev] [Fuel] Master node upgrade

Dear colleagues, At the moment I'm working on deprecating Fuel upgrade tarball. Currently, it includes the following: * RPM repository (upstream + mos) * DEB repository (mos) * openstack.yaml * version.yaml * upgrade script itself (+ virtualenv) Apart from upgrading docker containers this

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

Quoting Clint Byrum (2015-11-06 09:07:20) > Whether they are VMs or real machines, our tools > should strive to be about the user and their workload, and not about the > operator and their technology. +1 This should be in a poster in every office. Ghe Rivero

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Javeria, In your case, I think it's easier to generate config on the target node, using puppet for example, since the information which you may need is placed in /etc/astute.yaml file. Also it may be a problem to retrieve all required information about the cluster, since API is protected with

Re: [openstack-dev] [Nova] Migration state machine proposal.

+1 on Chris comments on implementation and API. Migrate, if all is ideal, should take the initial launch flavor. -Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: Thursday, November 05, 2015 8:46 PM To: openstack-dev@lists.openstack.org Subject: Re:

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Thank Evgeniy. I came to the same conclusion. -- Javeria On Fri, Nov 6, 2015 at 1:41 PM, Evgeniy L wrote: > Javeria, > > In your case, I think it's easier to generate config on the target node, > using puppet for example, since the information which you may need > is

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Sounds great. -- Javeria On Fri, Nov 6, 2015 at 2:31 PM, Evgeniy L wrote: > Great, let us know, if you have any problems. > > Also for the future we have some ideas/plans to provide a way for > a plugin to retrieve any information from API. > > Thanks, > > On Fri, Nov 6,

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

> -Original Message- > From: Tony Breeds [mailto:t...@bakeyournoodle.com] > Sent: Friday, November 06, 2015 6:15 AM > To: OpenStack Development Mailing List > Cc: openstack-operat...@lists.openstack.org > Subject: [openstack-dev] [stable][all] Keeping Juno "alive" for longer. > > Hello

Re: [openstack-dev] [Nova] Migration state machine proposal.

On 11/06/2015 12:45 PM, Chris Friesen wrote: On 11/05/2015 08:33 AM, Andrew Laski wrote: On 11/05/15 at 01:28pm, Murray, Paul (HP Cloud) wrote: Or more specifically, the migrate and resize API actions both call the resize function in the compute api. As Ed said, they are basically the same

Re: [openstack-dev] [Neutron][kuryr] network control plane (libkv role)

@Taku, Ideally libnetwork should not be able to sync network state with driver capability as "local". If that is the case, what is the purpose of having "capability" feature. How drivers(those having their own control plane) will be able to "mute" libnetwork. This will result in two "source of

Re: [openstack-dev] [nova][api]

It makes sense to have a single point were response pagination is made in API processing, rather than scattering pagination across Nova REST controllers; unfortunately if I am not really able to comment how feasible that would be in Nova's WSGI framework. However, I'd just like to add that there

Re: [openstack-dev] [Neutron][kuryr] network control plane (libkv role)

Hi Vikas, > Ideally libnetwork should not be able to sync network state with driver capability as "local". If that is the case, what is the purpose of having "capability" feature. How drivers(those having their own control plane) will be able to "mute" libnetwork. This will result in two "source

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Great, let us know, if you have any problems. Also for the future we have some ideas/plans to provide a way for a plugin to retrieve any information from API. Thanks, On Fri, Nov 6, 2015 at 12:16 PM, Javeria Khan wrote: > Thank Evgeniy. I came to the same conclusion. >

[openstack-dev] [Fuel][Plugins] apt segfaults when too many repositories are configured

Hello, While testing LMA with MOS 7.0, we got apt-get crashing and failing the deployment. The details are in the LP bug [0], the TL;DR version is that when more repositories are added (hence more packages), there is a risk that apt-get commands fail badly when trying to remap memory. The core

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

Tony Breeds wrote: > [...] > 1) Is it even possible to keep Juno alive (is the impact on the project as >a whole acceptable)? It is *technically* possible, imho. The main cost to keep it is that the branches get regularly broken by various other changes, and those breaks are non-trivial to

Re: [openstack-dev] [Zaqar] OpenStack Tokyo Summit Summary

Sorry typo: it should be 'pre-signed URL' On 07/11/15 01:31, Fei Long Wang wrote: Greetings, Firstly, thank you for everyone joined Zaqar sessions at Tokyo summit. We definitely made some great progress for those working sessions. Here are the high level summary and those are basically our

Re: [openstack-dev] [all][bugs] Developers Guide: Who's mergingthat?

Jeremy Stanley wrote on 11/05/2015 07:11:37 PM: > From: Jeremy Stanley > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 11/05/2015 07:17 PM > Subject: Re: [openstack-dev] [all][bugs]

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

Excerpts from Dolph Mathews's message of 2015-11-05 16:31:28 -0600: > On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann wrote: > > > Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800: > > > Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800: > >

Re: [openstack-dev] [kuryr] mutihost networking with nova vm as docker host

It does cause confusing by calling container-inside-vm as nested container. The "nested" term in container area usually means container-inside-container. we may refer this (container-inside-vm) explicitly as vm-holding container. On Fri, Nov 6, 2015 at 12:13 PM, Vikas Choudhary

Re: [openstack-dev] [Fuel] Master node upgrade

Hi Vladimir, Cannot say anything about 1st option, which is to use official Centos scripts, because I'm not familiar with the procedure, but since our installation is not really Centos, I have doubts that it's going to work correctly. 2nd option looks less risky. Also we should decide when to

Re: [openstack-dev] [kuryr] mutihost networking with nova vm as docker host

On Fri, Nov 6, 2015 at 1:20 PM, Baohua Yang wrote: > It does cause confusing by calling container-inside-vm as nested > container. > > The "nested" term in container area usually means > container-inside-container. > I try to always put it as VM-nested container. But I

Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

> I propose we add Sylvain Bauza[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the Scheduler. > > Please respond with comments, +1s, or objections within one week. +1 for tasty cheese. --Dan

Re: [openstack-dev] [Fuel] Master node upgrade

Just my 2 cents here - let's do docker backup and roll it up onto brand new Fuel 8 node. On Fri, Nov 6, 2015 at 7:54 PM, Oleg Gelbukh wrote: > Matt, > > You are talking about this part of Operations guide [1], or you mean > something else? > > If yes, then we still need

Re: [openstack-dev] [All][Glance Mitaka Priorities

On Fri, Nov 06, 2015 at 06:31:23PM +, Bhandaru, Malini K wrote: > Hello Glance Team/Flavio > > Would you please provide link to Glance priorities at > https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Glance > > [ Malini] Regards > Malini I don't belive there was an etherpad

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Excerpts from Doug Hellmann's message of 2015-11-06 10:28:41 -0800: > Excerpts from Clint Byrum's message of 2015-11-06 10:12:21 -0800: > > Excerpts from Dan Smith's message of 2015-11-06 09:37:44 -0800: > > > > Worth mentioning that OpenStack releases that come out at the same time > > > > as

[openstack-dev] [all] [dlm] Zookeeper and openjdk, mythbusted

I just wanted to bring this up in its own thread as I know it was a concern of (some) folks at the DLM session in tokyo[0] and I'd like to try to bust this myth using hopefully objective people/users of zookeeper (besides myself and yahoo, the company I work for) so that this myth can be put

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Clint Byrum wrote: Excerpts from Doug Hellmann's message of 2015-11-06 10:28:41 -0800: Excerpts from Clint Byrum's message of 2015-11-06 10:12:21 -0800: Excerpts from Dan Smith's message of 2015-11-06 09:37:44 -0800: Worth mentioning that OpenStack releases that come out at the same time as

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

> -Original Message- > From: Clint Byrum [mailto:cl...@fewbar.com] > Sent: Thursday, November 05, 2015 3:19 PM > To: openstack-dev > Subject: Re: [openstack-dev] [all] Outcome of distributed lock manager > discussion @ the summit > > Excerpts from Fox, Kevin M's message of 2015-11-05

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Excerpts from Clint Byrum's message of 2015-11-06 10:50:23 -0800: > Excerpts from Doug Hellmann's message of 2015-11-06 10:28:41 -0800: > > Excerpts from Clint Byrum's message of 2015-11-06 10:12:21 -0800: > > > Excerpts from Dan Smith's message of 2015-11-06 09:37:44 -0800: > > > > > Worth

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Excerpts from Joshua Harlow's message of 2015-11-06 11:11:02 -0800: > Clint Byrum wrote: > > Excerpts from Doug Hellmann's message of 2015-11-06 10:28:41 -0800: > >> Excerpts from Clint Byrum's message of 2015-11-06 10:12:21 -0800: > >>> Excerpts from Dan Smith's message of 2015-11-06 09:37:44

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

On 6 November 2015 at 14:09, Sean Dague wrote: > On 11/06/2015 08:44 AM, Alex Xu wrote: >> >> >> 2015-11-06 20:59 GMT+08:00 Sean Dague > >: >> >> On 11/06/2015 07:28 AM, John Garbutt wrote: >> > On 6 November 2015 at 12:09, Sean

Re: [openstack-dev] [nova] [doc] How to support Microversions and Actions in Swagger Spec

On Thu, Nov 5, 2015 at 9:31 PM, Alex Xu wrote: > Hi, folks > > Nova API sub-team is working on the swagger generation. And there is PoC > https://review.openstack.org/233446 > > But before we are going to next step, I really hope we can get agreement > with how to support

Re: [openstack-dev] [Fuel] Master node upgrade

Hi We should think about separating packages for master node and openstack. I > guess we should use 2 repository: > 1. MOS - repository for OpenStack related nodes > 2. MasterNode - repository for packages that are used for master node only. > > At the moment, this is pretty simple as we only

Re: [openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

On 06/11/15 13:46, Ihar Hrachyshka wrote: > Neil Jerram wrote: > >> Prompted by the thread about maybe allowing subproject teams to do their >> own stable maint, I have some questions about what I should be doing in >> networking-calico; and I guess the answers may

Re: [openstack-dev] [nova][api]

On Nov 6, 2015, at 6:30 AM, John Garbutt > wrote: On 6 November 2015 at 12:11, Sean Dague > wrote: On 11/06/2015 04:13 AM, Salvatore Orlando wrote: It makes sense to have a single point were response

Re: [openstack-dev] [Fuel] Master node upgrade

Evgeniy, On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L wrote: > Also we should decide when to run containers > upgrade + host upgrade? Before or after new CentOS is installed? Probably > it should be done before we run backup, in order to get the latest scripts > for >

Re: [openstack-dev] [Ironic] BIOS Configuration

Mea culpa. I was suggested that New REST API entry will be added to Ironic API and NOT IPA (Ironic Python Agent) as I misunderstood from the beginning. Cheers, Serge Kovaleff http://www.mirantis.com cell: +38 (063) 83-155-70 On Fri, Nov 6, 2015 at 1:33 PM, Serge Kovaleff

Re: [openstack-dev] [nova] [doc] How to support Microversions and Actions in Swagger Spec

2015-11-06 22:22 GMT+08:00 Anne Gentle : > > > On Thu, Nov 5, 2015 at 9:31 PM, Alex Xu wrote: > >> Hi, folks >> >> Nova API sub-team is working on the swagger generation. And there is PoC >> https://review.openstack.org/233446 >> >> But before we

Re: [openstack-dev] [Fuel] Master node upgrade

On Fri, Nov 6, 2015 at 3:32 PM, Alexander Kostrikov wrote: > Hi, Vladimir! > I think that option (2) 'to backup the master node, then reinstall it > from scratch and then apply backup' is a better way for upgrade. > In that way we are concentrating on two problems in

Re: [openstack-dev] [nova] [doc] How to support Microversions and Actions in Swagger Spec

2015-11-06 20:46 GMT+08:00 John Garbutt : > On 6 November 2015 at 03:31, Alex Xu wrote: > > Hi, folks > > > > Nova API sub-team is working on the swagger generation. And there is PoC > > https://review.openstack.org/233446 > > > > But before we are going

Re: [openstack-dev] [nova] [doc] How to support Microversions and Actions in Swagger Spec

On 6 November 2015 at 14:22, Anne Gentle wrote: > I'm pretty sure microversions are hard to document no matter what we do so > we just need to pick a way and move forward. > Here's what is in the spec: > For microversions, we'll need at least 2 copies of the

Re: [openstack-dev] [Fuel] Master node upgrade

Oleg, All the volatile information, including a DB dump, are contained in the small Fuel Master backup. There should be no information lost unless there was manual customization done inside the containers (such as puppet manifest changes). There shouldn't be a need to back up the entire

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

On 11/6/2015 4:43 AM, Thierry Carrez wrote: Tony Breeds wrote: [...] 1) Is it even possible to keep Juno alive (is the impact on the project as a whole acceptable)? It is *technically* possible, imho. The main cost to keep it is that the branches get regularly broken by various other

[openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

Hi, I propose we add Sylvain Bauza[1] to nova-core. Over the last few cycles he has consistently been doing great work, including some quality reviews, particularly around the Scheduler. Please respond with comments, +1s, or objections within one week. Many thanks, John [1]

[openstack-dev] [nova] Proposal to add Alex Xu to nova-core

Hi, I propose we add Alex Xu[1] to nova-core. Over the last few cycles he has consistently been doing great work, including some quality reviews, particularly around the API. Please respond with comments, +1s, or objections within one week. Many thanks, John

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

On 11/6/2015 9:20 AM, Matt Riedemann wrote: On 11/6/2015 4:43 AM, Thierry Carrez wrote: Tony Breeds wrote: [...] 1) Is it even possible to keep Juno alive (is the impact on the project as a whole acceptable)? It is *technically* possible, imho. The main cost to keep it is that the

Re: [openstack-dev] [Fuel] Change VIP address via API

Mike, Vladimir, Yes, 1. We need to add IPs on-the-fly (need to add POST functionality) , otherwise it will be VIP-like way (change network roles in plugin or release). 2. We should allow to leave fields 'network_role', 'node_roles', 'namespace' empty. So, validation should be changed. So, answer

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

Hello, Pavlo Shchelokovskyy said on Tue, Nov 03, 2015 at 09:41:51PM +: For auto-setting driver options on enrollment, I would vote for option 2 with default being fake driver + optional CMDB integration. This would ease managing a homogeneous pool of BMs, but still (using fake driver or

Re: [openstack-dev] [Fuel] shotgun code freeze

Great job! We are much closer to removal of fuel-web repo. On Tue, Oct 27, 2015 at 7:35 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > I am glad to announce that since now shotgun is a separate project. > fuel-web/shotgun directory has been deprecated. There is

Re: [openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

>>> >> All new features must go to master only. Your master should always be >> tested and work with neutron master (meaning, your master should target >> Mitaka, not Liberty). >> >>> We have a very similar situation in networking-infoblox to what Neil was saying about Calico. In our

Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

On Fri, Nov 06, 2015 at 03:32:00PM +, John Garbutt wrote: > Hi, > > I propose we add Sylvain Bauza[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the Scheduler. > > Please respond with comments,

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

On Fri, Nov 06, 2015 at 03:32:04PM +, John Garbutt wrote: > Hi, > > I propose we add Alex Xu[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the API. > > Please respond with comments, +1s, or

[openstack-dev] [Fuel][UI] Fuel UI switched to a new build/module system

Hi, I'd like to inform you that Fuel UI migrated from require.js to webpack. It will give us lots of benefits like significant improvement of developer experience and will allow us to easily separate Fuel UI from Nailgun. For more information please read the spec

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

I like the idea of LTS releases. Speaking to my own deployments, there are many new features we are not interested in, and wouldn't be, until we can get organizational (cultural) change in place, or see stability and scalability. We can't rely on, or expect, that orgs will move to the CI/CD

Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

+1 On 11/06/2015 10:32 AM, John Garbutt wrote: Hi, I propose we add Sylvain Bauza[1] to nova-core. Over the last few cycles he has consistently been doing great work, including some quality reviews, particularly around the Scheduler. Please respond with comments, +1s, or objections within

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

+1 On 11/06/2015 10:32 AM, John Garbutt wrote: Hi, I propose we add Alex Xu[1] to nova-core. Over the last few cycles he has consistently been doing great work, including some quality reviews, particularly around the API. Please respond with comments, +1s, or objections within one week.

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

On 11/06/2015 10:32 AM, John Garbutt wrote: > Hi, > > I propose we add Alex Xu[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the API. > > Please respond with comments, +1s, or objections within one

Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

On 11/06/2015 10:32 AM, John Garbutt wrote: > Hi, > > I propose we add Sylvain Bauza[1] to nova-core. > > Over the last few cycles he has consistently been doing great work, > including some quality reviews, particularly around the Scheduler. > > Please respond with comments, +1s, or objections

Re: [openstack-dev] [Fuel] Master node upgrade

Matt, You are talking about this part of Operations guide [1], or you mean something else? If yes, then we still need to extract data from backup containers. I'd prefer backup of DB in simple plain text file, since our DBs are not that big. [1]

[openstack-dev] [nova][bugs] Weekly Status Report

Hey folks, below is the first report of bug stats I intend to post weekly. We discussed it shortly during the Mitaka summit that this report could be useful to keep the attention of the open bugs at a certain level. Let me know if you think it's missing something. Stats = New bugs which are

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

+11 Alex, good news for you ! On Sat, Nov 7, 2015 at 12:36 AM, Daniel P. Berrange wrote: > On Fri, Nov 06, 2015 at 03:32:04PM +, John Garbutt wrote: >> Hi, >> >> I propose we add Alex Xu[1] to nova-core. >> >> Over the last few cycles he has consistently

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

+1 for some sort of LTS release system. Telcos and risk-averse organizations working with sensitive data might not be able to upgrade nearly as fast as the releases keep coming out. From the summit in Japan it sounds like companies running some fairly critical public infrastructure on

Re: [openstack-dev] [release] Release countdown for week R-21, Nov 9-13

Excerpts from Neil Jerram's message of 2015-11-06 12:15:54 +: > On 05/11/15 14:22, Doug Hellmann wrote: > > All deliverables should have reno configured before Mitaka 1. See > > http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html > > for details, and follow up on that

Re: [openstack-dev] [nova][api]

On 11/06/2015 04:13 AM, Salvatore Orlando wrote: > It makes sense to have a single point were response pagination is made > in API processing, rather than scattering pagination across Nova REST > controllers; unfortunately if I am not really able to comment how > feasible that would be in Nova's

Re: [openstack-dev] [Fuel] Master node upgrade

Hi, Vladimir! I think that option (2) 'to backup the master node, then reinstall it from scratch and then apply backup' is a better way for upgrade. In that way we are concentrating on two problems in one feature: backups and upgrades. That will ease development, testing and also reduce feature

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

On Fri, Nov 06, 2015 at 07:09:59AM -0500, Sean Dague wrote: > On 11/06/2015 04:49 AM, Daniel P. Berrange wrote: > > > > I think that exposing hypervisor_type is very much the *wrong* approach > > to this problem. The set of allowed actions varies based on much more than > > just the

Re: [openstack-dev] [all][bugs] Developers Guide: Who's mergingthat?

On 6 November 2015 at 13:38, Markus Zoeller wrote: > Jeremy Stanley wrote on 11/05/2015 07:11:37 PM: > >> From: Jeremy Stanley >> To: "OpenStack Development Mailing List (not for usage questions)" >>

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

On 6 November 2015 at 12:09, Sean Dague wrote: > On 11/06/2015 04:49 AM, Daniel P. Berrange wrote: >> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote: >>> Hello all, >>> I came across [1] which is notionally an ironic bug in that horizon >>> presents >>> VM

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

On 11/06/2015 07:28 AM, John Garbutt wrote: > On 6 November 2015 at 12:09, Sean Dague wrote: >> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote: >>> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote: Hello all, I came across [1] which is notionally an

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

On 11/06/2015 07:46 AM, Daniel P. Berrange wrote: > On Fri, Nov 06, 2015 at 07:09:59AM -0500, Sean Dague wrote: >> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote: >>> >>> I think that exposing hypervisor_type is very much the *wrong* approach >>> to this problem. The set of allowed actions

[openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

Prompted by the thread about maybe allowing subproject teams to do their own stable maint, I have some questions about what I should be doing in networking-calico; and I guess the answers may apply generally to subprojects. Let's start from the text at

Re: [openstack-dev] [Ironic] BIOS Configuration

Hi Lucas, I meant if it's possible to access/update BIOS configuration without any agent. Something similar to remote execution engine via Ansible. I am inspired by agent-less "Ansible-deploy-driver" https://review.openstack.org/#/c/241946/ There is definitely benefits of using the agent e.g.

Re: [openstack-dev] [nova][policy] Exposing hypervisor details to users

On 6 November 2015 at 09:49, Daniel P. Berrange wrote: > On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote: >> Hello all, >> I came across [1] which is notionally an ironic bug in that horizon >> presents >> VM operations (like suspend) to users. Clearly these

Re: [openstack-dev] [swift] re-implementation in golang - hummingbird details

There was a talk at the Summit in Tokyo last week which you can find here: https://youtu.be/Jfat_FReZIE Here is a blog post that was pushed about a week before: http://blog.rackspace.com/making-openstack-powered-rackspace-cloud-files-buzz-with-hummingbird/ -- Brian Fat-fingered from a Victrola

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Worth mentioning that OpenStack releases that come out at the same time as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka) are supported for 5 years by Canonical so are already kind of an LTS. Support in this context means patches, updates and commercial support (for a fee).

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

Hello all, I noticed the otherday that in our Openstack install (Kilo) Neutron seems to be the only project that was not logging the username/tenant information on every wsgi request. Nova/Glance/heat all log a username and/or project on each request. Our wsgi logs from neutron look like the

Re: [openstack-dev] DevStack errors...

Thanks for following up with these details. Good news! Neil From: Thales [mailto:thale...@yahoo.com] Sent: 05 November 2015 20:16 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] DevStack errors... Neil

Re: [openstack-dev] [QA][Nova] Tempest Hypervisor Feature Tagging

On 5 November 2015 at 19:31, Rafael Folco wrote: > Is there any way to know what hypervisor features[1] were tested in a > Tempest run? > From what I’ve seen, currently there is no way to tell what tests cover what > features. > Looks like Tempest has UUID and service

Re: [openstack-dev] [nova] [doc] How to support Microversions and Actions in Swagger Spec

On 6 November 2015 at 03:31, Alex Xu wrote: > Hi, folks > > Nova API sub-team is working on the swagger generation. And there is PoC > https://review.openstack.org/233446 > > But before we are going to next step, I really hope we can get agreement > with how to support

Re: [openstack-dev] [nova][bugs] Weekly Status Report

On Fri, Nov 06, 2015 at 05:54:59PM +0100, Markus Zoeller wrote: > Hey folks, > > below is the first report of bug stats I intend to post weekly. > We discussed it shortly during the Mitaka summit that this report > could be useful to keep the attention of the open bugs at a certain > level. Let

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Excerpts from Dan Smith's message of 2015-11-06 09:37:44 -0800: > > Worth mentioning that OpenStack releases that come out at the same time > > as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka) > > are supported for 5 years by Canonical so are already kind of an LTS. > >

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Excerpts from Erik McCormick's message of 2015-11-06 09:36:44 -0800: > On Fri, Nov 6, 2015 at 12:28 PM, Mark Baker wrote: > > Worth mentioning that OpenStack releases that come out at the same time as > > Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 +

  1   2   >