Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series

+1 Yes please! -- Mathieu On Wed, Sep 26, 2018 at 2:56 PM Tim Bell wrote: > > > Doug, > > Thanks for raising this. I'd like to highlight the goal "Finish moving legacy > python-*client CLIs to python-openstackclient" from the etherpad and propose > this for a T/U series goal. > > To give it

Re: [openstack-dev] [goals][python3] mixed versions?

On Fri, Sep 14, 2018 at 4:22 PM, Jim Rollenhagen wrote: > On Thu, Sep 13, 2018 at 9:46 PM, Mathieu Gagné wrote: >> >> On Thu, Sep 13, 2018 at 10:14 PM, Doug Hellmann >> wrote: >> > Excerpts from Mathieu Gagné's message of 2018-09-13 20:09:12 -0400: >> >

Re: [openstack-dev] [goals][python3] mixed versions?

On Thu, Sep 13, 2018 at 10:14 PM, Doug Hellmann wrote: > Excerpts from Mathieu Gagné's message of 2018-09-13 20:09:12 -0400: >> On Thu, Sep 13, 2018 at 7:41 PM, Doug Hellmann wrote: >> > Excerpts from Mathieu Gagné's message of 2018-09-13 14:12:56 -0400: >> >> On Wed, Sep 12, 2018 at 2:04 PM,

Re: [openstack-dev] [goals][python3] mixed versions?

On Thu, Sep 13, 2018 at 7:41 PM, Doug Hellmann wrote: > Excerpts from Mathieu Gagné's message of 2018-09-13 14:12:56 -0400: >> On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann wrote: >> > >> > IIRC, we also talked about not supporting multiple versions of >> > python on a given node, so all of the

Re: [openstack-dev] [goals][python3] mixed versions?

On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann wrote: > > IIRC, we also talked about not supporting multiple versions of > python on a given node, so all of the services on a node would need > to be upgraded together. > Will services support both versions at some point for the same OpenStack

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

Hi Julia, Thanks for the follow up on this topic. On Tue, May 29, 2018 at 6:55 AM, Julia Kreger wrote: > > These things are not just frustrating, but also very inhibiting for > part time contributors such as students who may also be time limited. > Or an operator who noticed something that was

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

On Wed, May 2, 2018 at 1:39 PM, Matt Riedemann wrote: > > I know you're just one case, but I don't know how many people are really > running the CachingScheduler with ironic either, so it might be rare. It > would be nice to get other operator input here, like I'm guessing

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

On Wed, May 2, 2018 at 12:49 PM, Matt Riedemann <mriede...@gmail.com> wrote: > On 5/2/2018 11:40 AM, Mathieu Gagné wrote: >> >> What's the state of caching_scheduler which could still be using those >> configs? > > > The CachingScheduler has been dep

Re: [openstack-dev] [nova][ironic] ironic_host_manager and baremetal scheduler options removal

What's the state of caching_scheduler which could still be using those configs? Mathieu On Wed, May 2, 2018 at 12:25 PM, Matt Riedemann wrote: > The baremetal scheduling options were deprecated in Pike [1] and the > ironic_host_manager was deprecated in Queens [2] and is

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

Hi Dave, On Tue, May 1, 2018 at 4:30 AM, Dave Holland <d...@sanger.ac.uk> wrote: > On Mon, Apr 30, 2018 at 12:41:21PM -0400, Mathieu Gagné wrote: >> Weighers for baremetal cells: >> * ReservedHostForTenantWeigher [7] > ... >> [7] Used to favor reserved host over non-

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

On Mon, Apr 30, 2018 at 1:06 PM, Jay Pipes wrote: > Mathieu, > > How do you handle issues where compute nodes are associated with multiple > aggregates and both aggregates have different values for a particular filter > key? > > Is that a human-based validation process to

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

Hi, On Sun, Apr 29, 2018 at 5:29 PM, Ed Leafe wrote: > On Apr 29, 2018, at 1:34 PM, Artom Lifshitz wrote: >> >> Based on that, we can definitely say that SameHostFilter and >> DifferentHostFilter do *not* belong in the defaults. In fact, we got >> our

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

On Tue, Apr 24, 2018 at 3:51 PM, Fox, Kevin M wrote: > I support 12 factor. But 12 factor only works if you can commit to always > deploying on top of 12 factor tools. If OpenStack committed to only ever > deploying api services on k8s then my answer might be different. but

Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal

On Wed, Jan 31, 2018 at 12:16 PM, Lance Bragstad wrote: > Hey folks, > > The tracking tool for the policy-and-docs-in-code goal for Queens [0] > lists a couple projects remaining for the goal [1]. I wanted to start a > discussion with said projects to see how we want to go

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On Tue, Jan 30, 2018 at 10:19 AM, Matt Riedemann wrote: > > Gibi's burndown chart is here to see what's remaining: > > http://burndown.peermore.com/nova-notification/ > > And this is the list of what's already done: > >

Re: [openstack-dev] [nova]Nova rescue inject pasword failed

On Mon, Jan 29, 2018 at 4:57 AM, Matthew Booth wrote: > On 29 January 2018 at 09:27, 李杰 wrote: >> >> Hi,all: >> I want to access to my instance under rescue state using >> temporary password which nova rescue gave me.But this password doesn't

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

On Thu, Jan 25, 2018 at 7:08 PM, James E. Blair <cor...@inaugust.com> wrote: > Mathieu Gagné <mga...@calavera.ca> writes: > >> On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec <openst...@nemebean.com> wrote: >>> >>> >>> I'm curious what this mean

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec wrote: > > > I'm curious what this means as far as best practices for inter-patch > references. In the past my understanding was the the change id was > preferred, both because if gerrit changed its URL format the change id links

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

Hi Chris, On Fri, Jan 19, 2018 at 10:21 AM, Chris Friesen wrote: > > The existing mechanisms to control aggregate membership will still work, so > the remaining issue is how to control the allocation ratios. > > What about implementing a new HTTP API call (as a local

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On Thu, Jan 18, 2018 at 5:19 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On 01/18/2018 03:54 PM, Mathieu Gagné wrote: >> >> Hi, >> >> On Tue, Jan 16, 2018 at 4:24 PM, melanie witt <melwi...@gmail.com> wrote: >>> >>> Hello

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

Hi, On Tue, Jan 16, 2018 at 4:24 PM, melanie witt wrote: > Hello Stackers, > > This is a heads up to any of you using the AggregateCoreFilter, > AggregateRamFilter, and/or AggregateDiskFilter in the filter scheduler. > These filters have effectively allowed operators to set

Re: [openstack-dev] [nova] Boot from volume 's instance of rebuild operation

On Wed, Dec 6, 2017 at 9:13 PM, Jaze Lee wrote: > 2017-12-07 7:12 GMT+08:00 Matt Riedemann : >> On 12/6/2017 2:11 AM, 李杰 wrote: >>> >>> Hi,all >>> >>> Now the boot from volume 's instance of rebuild operation has a >>> problem.For example,after the

Re: [openstack-dev] [nova] Super fun unshelve image_ref bugs

Hi, On Fri, Dec 1, 2017 at 12:24 PM, Matt Riedemann wrote: > > I think we can assert as follows: > > 2. If we're going to point the instance at an image_ref, we shouldn't delete > that image. I don't have a good reason why besides deleting things which > nova has a reference

Re: [openstack-dev] Upstream LTS Releases

Some clarifications below. On Wed, Nov 15, 2017 at 4:52 AM, Bogdan Dobrelya wrote: > Thank you Mathieu for the insights! > >> To add details to what happened: >> * Upgrade was never made a #1 priority. It was a one man show for far >> too long. (myself) > > > I suppose that

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On Tue, Nov 14, 2017 at 6:44 PM, John Dickinson <m...@not.mn> wrote: > > > On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > >> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M <kevin@pnnl.gov> wrote: >>> The pressure for #2 comes from the inability to skip u

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: > The pressure for #2 comes from the inability to skip upgrades and the fact > that upgrades are hugely time consuming still. > > If you want to reduce the push for number #2 and help developers get their > wish of getting

Re: [openstack-dev] [ironic] [Openstack-operators] replace node "tags" with node "traits"

Hi, On Wed, Oct 25, 2017 at 10:17 AM, Loo, Ruby wrote: > Hello ironic'ers, > > A while ago, we approved a spec to add node tag support to ironic [1]. The > feature itself did not land yet (although some of the code has). Now that > the (nova) community has come up with

Re: [openstack-dev] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

> On Fri, Oct 6, 2017 at 2:02 PM, Chris Friesen > <chris.frie...@windriver.com> wrote: >> On 10/06/2017 11:32 AM, Mathieu Gagné wrote: >>> >>> Why not supporting this use case? >> >> >> I don't think anyone is suggesting we support do it, b

Re: [openstack-dev] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

6/2017 11:32 AM, Mathieu Gagné wrote: >> >> Why not supporting this use case? > > > I don't think anyone is suggesting we support do it, but nobody has stepped > up to actually merge a change that implements it. > > I think what Matt is suggesting is that we make it

Re: [openstack-dev] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

Why not supporting this use case? Same reason as before: A user might wish to keep its IP addresses. The use cannot do the following to bypass the limitation: 1) stop instance 2) detach root volume 3) delete root volume 4) create new volume 5) attach as root 6) boot instance Last time I tried,

Re: [openstack-dev] [nova][docs] Concerns with docs migration

On Wed, Aug 2, 2017 at 12:28 PM, Clark Boylan wrote: > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote: >> Now that Stephen Finucane is back from enjoying his youth and >> gallivanting all over Europe, and we talked about a few things in IRC >> this morning on the

Re: [openstack-dev] [keystone] office hours report 2017-7-7

Resending... I found out that Gmail messed up my message with its HTML format... Hopefully this time it will be more readable on the online archive interface. On Tue, Jul 11, 2017 at 10:28 PM, Mathieu Gagné <mga...@calavera.ca> wrote: > Hi, > > So this email is relevant

Re: [openstack-dev] [keystone] office hours report 2017-7-7

Hi, So this email is relevant to my interests as an operator. =) On Tue, Jul 11, 2017 at 9:35 PM, Lance Bragstad wrote: > *The future of the templated catalog backend* > > Some issues were uncovered, or just resurfaced, with the templated catalog > backend. The net of the

Re: [openstack-dev] Documenting config drive - what do you want to see?

On Wed, May 24, 2017 at 10:39 AM, Matt Riedemann wrote: > > Rocky tipped me off to a request to document config drive which came up at the Boston Forum, and I tracked that down to Clark's wishlist etherpad [1] (L195) which states: > > "Document the config drive. The only way

Re: [openstack-dev] [nova] Multiple default routes in instance

On Wed, May 17, 2017 at 10:03 AM, Mathieu Gagné <mga...@calavera.ca> wrote: > Hi, > > When you attach multiple networks/interfaces to an instance and at > least 2 subnets have a default route, you end up with 2 default routes > in network_data.json. > > If cloud-init

[openstack-dev] [nova] Multiple default routes in instance

Hi, When you attach multiple networks/interfaces to an instance and at least 2 subnets have a default route, you end up with 2 default routes in network_data.json. If cloud-init or any other in-guest agent is used to configure the network, you could end up with 2 default routes and to an extend,

Re: [openstack-dev] [nova][glance][keystone] Philosophy of the service catalog (was: Who needs multiple api_servers?)

I didn't attend the LDT session but agree with the needs and conclusions mentioned here by Mike Dorman. It's important for us to be able to control the data path of our internal servers and overriding the URLs is the method we are currently using. You could do split view DNS but we prefer being

Re: [openstack-dev] [nova] Usability question for the server migrations API

The proposal looks reasonable. This could greatly help operation team if a migration no longer vanishes from the API once completed. Can I assume some form of advanced filtering will be proposed to ensure an instance doesn't end up with 1k records? One suggestion would be filtering by date or

Re: [openstack-dev] [nova][cinder] Can all non-Ironic compute drivers handle volume size extension?

On Wed, Apr 12, 2017 at 2:54 PM, Matt Riedemann wrote: > > Correct, I thought about this yesterday too. And this should be a detail in > the Cinder spec for sure, but Cinder should probably have a specific policy > check for attempting to extend an attached volume. Having

Re: [openstack-dev] [nova][cinder] Can all non-Ironic compute drivers handle volume size extension?

Thanks for starting this discussion. There is a lot to cover/answer. On Tue, Apr 11, 2017 at 6:35 PM, Matt Riedemann wrote: > > This is not discoverable at the moment, for the end user or cinder, so I'm > trying to figure out what the failure mode looks like. > > This all

Re: [openstack-dev] [nova][cinder] Can all non-Ironic compute drivers handle volume size extension?

On Wed, Apr 12, 2017 at 12:58 PM, Matt Riedemann wrote: > > I guess we also have the instance action events. So we could avoid putting > the instance into ERROR state but record an instance action event that the > extend volume event failed on the compute, so at least the

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

Hi, On Mon, Apr 3, 2017 at 8:40 PM, Jay S Bryant wrote: > > Thank you for sharing this. Nice to see you have a solution that looks > agreeable to Matt. Do you think you can get a spec pushed up and propose > your code? > I will go ahead, write the spec and contribute the

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On Mon, Apr 3, 2017 at 12:27 PM, Walter Boring wrote: > Actually, this is incorrect. > > The sticking point of this all was doing the coordination and initiation of > workflow from Nova. Cinder already has the ability to call the driver to > do the resize of the volume.

Re: [openstack-dev] [neutron][metadata] Is there HTTP attack issue in metadata proxy functionality offered by reference implementation?

On Wed, Nov 16, 2016 at 11:52 AM, Clint Byrum wrote: > > IMO the HTTP metadata service and the way it works is one of the worst > ideas we borrowed from EC2. Config drive (which I didn't like when I > first saw it, but now that I've operated clouds, I love) is a simpler > system

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

Hi, On Wed, Sep 21, 2016 at 10:49 AM, Matt Riedemann wrote: > Nova has policy defaults in code now and we can generate the sample using > oslopolicy-sample-generator but we'd like to get the default policy sample > in the Nova developer documentation also, like we

Re: [openstack-dev] mod_wsgi: what services are people using with it?

I don't have much experience with mod_wsgi. I just want to let you know that when I tried to run nova-api service in mod_wsgi (with OpenStack Kilo), I had to remove the python-librabbitmq and librabbitmq1 packages from my system or mod_wsgi would throw Segmentation Fault (11) when a user tries to

Re: [openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'

I think there is an implementation error. The spec mentions that link type can be "vif", "phy" or (future) "bond". Nova passes the "raw" Neutron VIF type instead. IMO, "bridge" should be "vif" as per spec. -- Mathieu On Tue, May 24, 2016 at 5:20 PM, Joshua Harlow wrote: >

Re: [openstack-dev] [all] Deprecated options in sample configs?

On Tue, May 17, 2016 at 3:51 PM, Ben Nemec wrote: > > I'm +1 on removing them from sample configs. This feels like release > note information to me, and if someone happens to miss the release note > then they'll get deprecation warnings in their logs. The sample config >

Re: [openstack-dev] Team blogs

On Tue, May 10, 2016 at 8:05 AM, Jeremy Stanley wrote: > On 2016-05-09 19:46:14 -0400 (-0400), Sean Dague wrote: >> Honestly, I'm really liking that more of them are hitting the >> mailing list proper this time around. Discoverability is key. The >> mailing list is a shared

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On Tue, Apr 5, 2016 at 11:24 PM, Monty Taylor wrote: > On 04/05/2016 05:07 PM, Michael Still wrote: > >> self.glance = glance_client.Client('2', endpoint, token=token) > > > There are next to zero cases where the thing you want to do is talk to > glance using a token and an

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

It got renamed a couple of months/year ago to #openstack-stable: https://bugs.launchpad.net/openstack-ci/+bug/1360324 Documentation should have been updated to reflect this change. Channel being invite-only is probably a side-effect of the migration. Mathieu On 2016-03-09 12:48 PM, Matt

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

On 2016-03-03 12:53 PM, Sean M. Collins wrote: > sridhar basam wrote: >> This doesn't sound like a neutron issue but an issue with how the >> conntrack module for GRE changed in the kernel in 3.18. >> >> >> http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/47705 >> >> Sri >

[openstack-dev] [puppet] Stepping down from Puppet Core

Hi, I would like to ask to be removed from the core reviewers team on the Puppet for OpenStack project. My day to day tasks and focus no longer revolve solely around Puppet and I lack dedicated time to contribute to the project. In the past months, I stopped actively reviewing changes compared

Re: [openstack-dev] OpenStack-Announce List

On 2015-11-19 11:00 PM, Tom Fifield wrote: > > Personally, I no longer consider this volume "low traffic" :) > > In addition, I have been recently receiving feedback that users have > been unsubscribing from or deleting without reading the list's posts. > > That isn't good news, given this is

Re: [openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

On 2015-10-21 10:23 AM, Markus Zoeller wrote: > Lingxian Kong wrote on 10/21/2015 06:44:27 AM: > >> From: Lingxian Kong >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> Date: 10/21/2015

Re: [openstack-dev] [puppet] Incompatible default parameters

This change [1] introduced the nova_catalog_info and nova_catalog_admin_info parameters. Martin Mágr also mentioned that default values were wrong but the change got merged anyway. I agree that those default values should be changed to "nova" like initially suggested as the 2nd field is the

Re: [openstack-dev] Fwd: [nova] live migration in Mitaka

Hi Pavel, On 2015-10-08 9:39 AM, Pavel Boldin wrote: > Here you go: https://launchpad.net/~pboldin/+archive/ubuntu/libvirt-python > > Use it, but please keep in mind that this is a draft reupload. > Thank you for your work. I'm sure a lot of people will benefit from it. Live migration is a

Re: [openstack-dev] Fwd: [nova] live migration in Mitaka

On 2015-10-02 4:18 PM, Pavel Boldin wrote: > > You have to pass device names from /dev/, e.g., if a VM has > ephemeral disk > attached at /dev/vdb you need to pass in 'vdb'. Format expected by > migrate_disks is ",...". > > > This is the format expected by the `virsh' utility

Re: [openstack-dev] [nova] live migration in Mitaka

On 2015-10-01 7:26 AM, Kashyap Chamarthy wrote: > On Wed, Sep 30, 2015 at 11:25:12AM +, Murray, Paul (HP Cloud) wrote: >> >>> Please respond to this post if you have an interest in this and what >>> you would like to see done. Include anything you are already >>> getting on with so we get a

Re: [openstack-dev] [Openstack-operators] [cinder] [all] The future of Cinder API v1

On 2015-09-28 11:43 PM, John Griffith wrote: > > > On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker > wrote: > > FWIW, the most popular client libraries in the last user survey[1] > other than OpenStack’s own clients were: libcloud (48

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

On 2015-09-24 11:53 AM, Walter A. Boring IV wrote: > The good thing about the Nova and Cinder clients/APIs is that > anyone can write a quick python script to do the orchestration > themselves, if we want to deprecate this. I'm all for deprecating this. I don't like this kind of reasoning which

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

Hi Matt, On 2015-09-24 1:45 PM, Matt Riedemann wrote: > > > On 9/24/2015 11:50 AM, Mathieu Gagné wrote: >> >> May I suggest the following solutions: >> >> 1) Add ability to disable this whole AZ concept in Cinder so it doesn't >> fail to create v

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

On 2015-09-24 3:04 AM, Duncan Thomas wrote: > > I proposed a session at the Tokyo summit for a discussion of Cinder AZs, > since there was clear confusion about what they are intended for and how > they should be configured. Since then I've reached out to and gotten > good feedback from, a number

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

On 2015-09-23 4:50 PM, Andrew Laski wrote: > On 09/23/15 at 04:30pm, Mathieu Gagné wrote: >> On 2015-09-23 4:12 PM, Andrew Laski wrote: >>> On 09/23/15 at 02:55pm, Matt Riedemann wrote: >>>> >>>> Heh, so when I just asked in the cinder channel if we can

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

On 2015-09-23 4:12 PM, Andrew Laski wrote: > On 09/23/15 at 02:55pm, Matt Riedemann wrote: >> >> Heh, so when I just asked in the cinder channel if we can just >> deprecate nova boot from volume with source=(image|snapshot|blank) >> (which automatically creates the volume and polls for it to be >>

Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services

On 2015-09-22 1:46 PM, Sean Dague wrote: > On 09/22/2015 12:12 PM, Mathieu Gagné wrote: >> On 2015-09-22 7:00 AM, Sean Dague wrote: >>> >>> My feeling on this one is that we've got this thing in OpenStack... the >>> Service Catalog. It definitively tells the

Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services

On 2015-09-22 4:52 PM, Sean Dague wrote: > On 09/22/2015 03:16 PM, Mathieu Gagné wrote: >> >> The oslo_middleware.ssl middleware looks to offer little overhead and >> offer the maximum flexibility. I appreciate the wish to use the Keystone >> catalog but I don't fe

Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services

On 2015-09-22 7:00 AM, Sean Dague wrote: > > My feeling on this one is that we've got this thing in OpenStack... the > Service Catalog. It definitively tells the world what the service > addresses are. > > We should use that in the services themselves to reflect back their > canonical addresses.

[openstack-dev] [all] Consistent support for SSL termination proxies across all API services

Hi, While debugging LP bug #1491579 [1], we identified [2] an issue where an API sitting being a proxy performing SSL termination would not generate the right redirection. The protocol ends up being the wrong one (http instead of https) and this could hang your request indefinitely if tcp/80 is

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

Hi Kevin, On 2015-09-15 8:33 PM, Fox, Kevin M wrote: > I am not a neutron developer, but an operator and a writer of cloud apps. So far, I'm only an operator and heavy cloud apps user (if you can call Vagrant an app). =) > Yes, it is sort of a philosophical issue, and I have stated my side >

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 2015-09-15 7:44 PM, Armando M. wrote: > > > On 15 September 2015 at 15:11, Mathieu Gagné <mga...@internap.com > <mailto:mga...@internap.com>> wrote: > > On 2015-09-15 2:00 PM, Fox, Kevin M wrote: > > We run several clouds where there are multiple

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 2015-09-15 6:49 PM, Doug Wiegley wrote: > > >> On Sep 15, 2015, at 4:11 PM, Mathieu Gagné <mga...@internap.com> wrote: >> >>> On 2015-09-15 2:00 PM, Fox, Kevin M wrote: >>> We run several clouds where there are multiple external networks. the

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 2015-09-15 8:06 PM, Doug Wiegley wrote: > > “Neutron doesn’t get it and never will.” > > I’m not sure how all ‘yes’ above keeps translating to this old saw, but > is there any tiny chance we can stop living in the past and instead > focus on the use cases that we want to solve? > I

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 2015-09-15 2:00 PM, Fox, Kevin M wrote: > We run several clouds where there are multiple external networks. the "just > run it in on THE public network" doesn't work. :/ > > I also strongly recommend to users to put vms on a private network and use > floating ip's/load balancers. For many

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

On 2015-09-04 12:50 PM, Monty Taylor wrote: > On 09/04/2015 10:55 AM, Morgan Fainberg wrote: >> >> Obviously the translation of errors >> would be more difficult if the enforcer is generating messages. > > The type: "PolicyNotAuthorized" is a good general key. Also - even > though the command I

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

On 2015-09-04 2:41 PM, Monty Taylor wrote: > On 09/04/2015 01:42 PM, John Griffith wrote: >> >> ​Is no good? You would like to see "less" in the output; like just the >> command name itself and "Policy doesn't allow"? >> >> To Mathieu's point, fair statement WRT the visibility of the policy name.

Re: [openstack-dev] --detailed-description for OpenStack items

On 2015-08-27 1:23 PM, Tim Bell wrote: Some project such as cinder include a detailed description option where you can include an arbitrary string with a volume to remind the admins what the volume is used for. Has anyone looked at doing something similar for Nova for instances and Glance

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

+1 On 2015-07-27 3:06 PM, Emilien Macchi wrote: Puppet group, Yanis has been working in our group for a while now. He has been involved in a lot of tasks, let me highlight some of them: * Many times, involved in improving consistency across our modules. * Strong focus on data binding,

Re: [openstack-dev] [nova] [ironic] Exposing provider networks in network_data.json

at 01:23:29PM PDT, Mathieu Gagné wrote: So it looks like there is a missing part in this feature. There should be a way to hide this information if the instance does not require to configure vlan interfaces to make network functional. I just commented on the review, but the provider network API

[openstack-dev] [horizon] Unified interface for all regions

Hi, As anyone wondered if it could be possible/feasible to have an unified interface where all instances (or resources) are listed in one single page for all regions available in the catalog? What would be the challenges to make it happen? (so you don't have to toggle between regions) --

[openstack-dev] [nova] Exposing provider networks in network_data.json

Hi, I stubble on this review [1] which proposes adding info about provider networks in network_data.json. Concerns were raised by Kevin Benton about how those information shouldn't be exposed to virtual instances for various reasons you can read in the review and I totally agree with those

Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?

On 2015-07-03 10:31 AM, Silvan Kaiser wrote: Hello! I just found the following commit in the cinder log: commit a3f4eed52efce50c2eb1176725bc578272949d7b Merge: 6939b4a e896ae2 Author: Jenkins jenk...@review.openstack.org mailto:jenk...@review.openstack.org Date: Thu Jul 2 23:14:39 2015

Re: [openstack-dev] [packaging] [puppet] how to deal with the rename of config files in neutron on upgrade?

Adding [puppet] tag to subject. On 2015-07-02 11:35 AM, Matt Riedemann wrote: This change in neutron [1] renames the linuxbridge and openvswitch plugin config files. I'm familiar with the %config(noreplace) directive in rpm but I'm not sure if there is a special trick with rpm to rename a

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

On 2015-06-08 2:48 AM, Yanis Guenane wrote: If we look at openstacklib::db::postgresql[1] or openstackib::db::mysql[2] they are simple wrapper around puppet resources with no extra logic, but a common resource across all modules. I see a lot of resources, relationships and logic in

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

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

[openstack-dev] [puppet] Renaming the IRC channel to #openstack-puppet

Hi, We recently asked for our IRC channel (#puppet-openstack) to be logged by the infra team. We happen to be the only channel suffixing the word openstack instead of prefixing it. [1] I would like to propose renaming our IRC channnel to #openstack-puppet to better fit the mold (convention)

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

On 2015-05-21 3:13 AM, Daniel P. Berrange wrote: On Thu, May 21, 2015 at 09:34:20PM +1200, Xav Paice wrote: On 21/05/15 21:23, Daniel P. Berrange wrote: On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote: I note that we use instance.name to lookup the libvirt domain a bunch in the

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

On 2015-05-21 3:38 PM, Chris Friesen wrote: On 05/21/2015 03:20 PM, Mathieu Gagné wrote: On 2015-05-21 3:13 AM, Daniel P. Berrange wrote: On Thu, May 21, 2015 at 09:34:20PM +1200, Xav Paice wrote: On 21/05/15 21:23, Daniel P. Berrange wrote: On Wed, May 20, 2015 at 03:01:50PM -0700, Michael

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

On 2015-05-21 4:18 PM, Chris Friesen wrote: I guess it's for the reason I mentioned above: To not break all OpenStack installations on Earth running with default config values. So that's not breaking *upgrades* of all OpenStack installations with default config values, which is a

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

On 2015-05-14 12:34 AM, David Lyle wrote: Horizon only supports authenticating to one keystone endpoint at a time, specifically to one of the entries in AVAILABLE_REGIONS as defined in settings.py. Once you have an authenticated session in Horizon, the region selection support is merely for

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

When using AVAILABLE_REGIONS, you get a dropdown at login time to choose your region which is in fact your keystone endpoint. Once logged in, you get a new dropdown at the top right to switch between the keystone endpoints. This means you can configure an Horizon installation to login to multiple

Re: [openstack-dev] [puppet] Proposal to configure Oslo libraries

On 2015-05-07 4:19 PM, Emilien Macchi wrote: Proposals = #1 Creating puppet-oslo ... and having oslo::messaging::rabbitmq, oslo::messaging::qpid, ..., oslo::logging, etc. This module will be used only to configure actual Oslo libraries when we deploy OpenStack. To me, this

Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?

On 2015-05-05 1:25 AM, Monty Taylor wrote: On 05/04/2015 08:47 PM, Emilien Macchi wrote: On 05/04/2015 10:37 PM, Rich Megginson wrote: On 05/04/2015 07:52 PM, Mathieu Gagné wrote: On 2015-05-04 9:15 PM, Rich Megginson wrote: On 05/04/2015 06:03 PM, Mathieu Gagné wrote: On 2015-05-04 7:35

Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?

On 2015-05-04 9:15 PM, Rich Megginson wrote: On 05/04/2015 06:03 PM, Mathieu Gagné wrote: On 2015-05-04 7:35 PM, Rich Megginson wrote: The way authentication works with the Icehouse branch is that puppet-keystone reads the admin_token and admin_endpoint from /etc/keystone/keystone.conf

Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?

On 2015-05-04 7:35 PM, Rich Megginson wrote: The way authentication works with the Icehouse branch is that puppet-keystone reads the admin_token and admin_endpoint from /etc/keystone/keystone.conf and passes these to the keystone command via the OS_SERVICE_TOKEN env. var. and the

Re: [openstack-dev] [puppet] rabbit/kombu settings deprecations

On 2015-04-16 2:10 PM, Richard Raseley wrote: I am certainly sympathetic to your situation - having the world change beneath your feet is never a good place to be. =] It does seem, however, that there is a disconnect between your expectations (as I understand them) of what the 'master'

Re: [openstack-dev] [puppet] Release management and bug triage

On 2015-03-26 1:08 PM, Sebastien Badia wrote: About lp script, a short search on github (bug mgmt, merged changes): - https://github.com/openstack-infra/release-tools - https://github.com/markmc/openstack-lp-scripts - https://github.com/dolph/launchpad But we wait the publishing of

Re: [openstack-dev] [puppet] Release management and bug triage

On 2015-03-17 3:22 PM, Emilien Macchi wrote: A first question that comes in my mind is: should we continue to manage every Puppet module in a different Launchpad project? Or should we migrate all modules to a single project. I prefer multiple Launchpad projects due to the fact that each

Re: [openstack-dev] [puppet] Release management and bug triage

On 2015-03-18 12:26 PM, Emilien Macchi wrote: The challenge is with release management at scale. I have a bunch of tools which I use to create new series, milestones and release them. So it's not that big of a deal. Are you willing to share it? Sure. I'll make it a priority to publish it

[openstack-dev] [nova] Request non-priority feature freeze exception for Add ability to inject routes in interfaces.template

Hi, I am requesting the exception for the feature Add ability to inject routes in interfaces.template. The potential changes in Nova are limited as the feature is opt-in. The default interfaces.template is not changed for the reasons now explained in the new commit message. No comment were

  1   2   >