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 h

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 mi

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" specific? Let's say I > wan

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 keys

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 tru

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: [openst

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 placed in /etc/astute.yam

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 i

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 o

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. > > > -- > Javeria > > On

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, 2015 at 12:16 PM, Jave

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 all

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] [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 horizo

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 backpor

[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 w

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 server

[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 upgrad

[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 is

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 fix

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

Hi folks! Can anyone share status of porting muranoclient to Python 3? On Tue, Jun 16, 2015 at 4:54 PM, Serg Melikyan wrote: > Stan, +100500 > > On Fri, Jun 12, 2015 at 3:13 PM, Stan Lagun wrote: > > > > I'd rather go with Heat approach (job first) because it makes easier to > track what is lef

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. He

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

Hi, On Fri, Nov 6, 2015 at 11:29 AM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > At the moment I'm working on deprecating Fuel upgrade tarball. Currently, > it includes the following: > > * RPM repository (upstream + mos) > We should think about separating packa

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 Jerram wrote: "When you say 'on Ubu

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

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 operations (like suspend) to users. Clearly these options don't make >> sens

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 WS

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 options don't make >

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

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 thread with questions. I guess that 'deliverables' do not include projects

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 wrote: > @Gal,

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 run

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 operations (like suspen

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

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 pagination is made >> in API processing, rather than scattering pagination across Nova REST >> controllers; unfortunately if I am not really able

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

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 Mitaka priorities. I may miss something so please feel free to comment/reply this ma

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 cre

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 M

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 tagging, but no reference to

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 Microversions and Actions. T

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 hypervisor_typ

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 ironic bug in that ho

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 varies

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 -

[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 http://docs.openstack.org/developer/neutron/d

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

On 11/06/2015 03:47 AM, Tang Chen wrote: On 11/06/2015 12:45 PM, Chris Friesen wrote: To me, the external API would make more sense as: 1) resize 2) migrate (with option of cold or live, and with option to specify a destination, and with option to override the scheduler if the specified des

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] Developers Guide: Who's merging that? > > On 2015-11-05 16:23:56 +0100 (+0100),

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

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 apply generally to subprojects. Let's start from the text at http://docs.openstack.

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

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 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 ac

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

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 Dague > wrote: > >> On 11/06/2015 04:49 AM, Daniel P. Berran

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)" >> >> Date: 11/05/2015 07:17 PM >> Subject: Re: [openstack-dev] [all][bugs] Developers Guide: Who'

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 Dague > > w

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 Microversions and Action

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 supp

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 apply generally to >> subproject

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

On Nov 6, 2015, at 6:30 AM, John Garbutt mailto:j...@johngarbutt.com>> wrote: On 6 November 2015 at 12:11, Sean Dague mailto:s...@dague.net>> wrote: 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 t

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 > backup/restore actions. > We'

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 wrote: > Hi Lucas, > >

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 are going to next step, I really hope we can get a

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 one feature: > backups and up

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 to next step, I really hope we can get agr

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 previous reference > info (enable a dro

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 containers

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 cha

[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] http://stackalytics

[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 [1]http://stackalytics.com/?module=

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 bra

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 data

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

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 objec

[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 m

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 one

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. Many

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 w

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] https://docs.mirantis.com/openstack/fuel/fuel-7.0/o

[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 been doing great work

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 Openstack

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 t

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: > > > > Excerpts from Adam Y

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 probably slipped in some m

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 to extract data from back

[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] [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). F

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 me

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

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

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 + Mitaka) are > supported for 5 years by Canonical so are already kind of an LTS. Support in > this context

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

On 11/06/15 at 09:18am, Dan Smith wrote: 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

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

Fixes to below: logging_context_format_string is the correct config option name. The exact link that I wanted for [1] below is actually: https://review.openstack.org/#/c/172508/2/lib/neutron-legacy ___ Kris Lindgren Senior Linux Sy

[openstack-dev] [swift] Tokyo summit recap

Below are some high-level notes from the topics discussed at the summit by the Swift community. encryption We're continuing the data-at-rest encryption work. For our first deliverable, we'll have a feature that allows operators to set an encryption key for the cluster and all encryption w

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. > > Supp

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 + Mitaka) are > > supported for 5

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

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 Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka) > > > are

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

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 __ OpenStack Development Mailing List (not for us

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

On Nov 6, 2015, at 9:32 AM, John Garbutt wrote: > 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

  1   2   >