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

2018-09-26 Thread Mathieu Gagné
+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 so

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

2018-09-14 Thread Mathieu Gagné
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?

2018-09-13 Thread Mathieu Gagné
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, Dou

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

2018-09-13 Thread Mathieu Gagné
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?

2018-09-13 Thread Mathieu Gagné
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 rele

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

2018-05-29 Thread Mathieu Gagné
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 c

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

2018-05-02 Thread Mathieu Gagné
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 CERN has > their cells c

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

2018-05-02 Thread Mathieu Gagné
On Wed, May 2, 2018 at 12:49 PM, Matt Riedemann 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 deprecated since Pike [1]. We disc

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

2018-05-02 Thread Mathieu Gagné
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 now being removed > [3].

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

2018-05-01 Thread Mathieu Gagné
Hi Dave, On Tue, May 1, 2018 at 4:30 AM, Dave Holland 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-reserved ones based on pr

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

2018-04-30 Thread Mathieu Gagné
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 ensure you don't have tha

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

2018-04-30 Thread Mathieu Gagné
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 defaults pretty spot on, based on this admit

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

2018-04-24 Thread Mathieu Gagné
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 so far > has been un

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

2018-01-31 Thread Mathieu Gagné
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 about the work in > the

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

2018-01-30 Thread Mathieu Gagné
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: > > https://docs.openstack.org/nova/latest/reference/notifications.html#versioned-

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

2018-01-29 Thread Mathieu Gagné
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 work. >> Can I ask how this password is inj

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

2018-01-25 Thread Mathieu Gagné
On Thu, Jan 25, 2018 at 7:08 PM, James E. Blair wrote: > Mathieu Gagné writes: > >> 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. I

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

2018-01-25 Thread Mathieu Gagné
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 > would be updated appro

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

2018-01-19 Thread Mathieu Gagné
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 private patch) to > set the a

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

2018-01-18 Thread Mathieu Gagné
On Thu, Jan 18, 2018 at 5:19 PM, Jay Pipes wrote: > On 01/18/2018 03:54 PM, Mathieu Gagné wrote: >> >> Hi, >> >> On Tue, Jan 16, 2018 at 4:24 PM, melanie witt wrote: >>> >>> Hello Stackers, >>> >>> This is a heads up to any of yo

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

2018-01-18 Thread Mathieu Gagné
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 overcommit ratios > pe

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

2017-12-06 Thread Mathieu Gagné
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 rebuild operation,the instance 's root di

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

2017-12-01 Thread Mathieu Gagné
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 to in an active insta

Re: [openstack-dev] Upstream LTS Releases

2017-11-15 Thread Mathieu Gagné
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 confirms that upgrades

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

2017-11-14 Thread Mathieu Gagné
On Tue, Nov 14, 2017 at 6:44 PM, John Dickinson wrote: > > > On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > >> 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 upgr

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

2017-11-14 Thread Mathieu Gagné
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 features into users

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

2017-10-25 Thread Mathieu Gagné
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 traits, ironic wants to sup

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

2017-10-06 Thread Mathieu Gagné
> On Fri, Oct 6, 2017 at 2:02 PM, Chris Friesen > 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, but nobody has stepped >>

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

2017-10-06 Thread Mathieu Gagné
I don't think there ever was a technical limitation to add support for it. I have nothing to back my claims but IIRC, it was more philosophical points against adding support for it. -- Mathieu On Fri, Oct 6, 2017 at 2:02 PM, Chris Friesen wrote: > On 10/06/2017 11:32 AM, Mathieu Gag

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

2017-10-06 Thread Mathieu Gagné
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, o

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

2017-08-02 Thread Mathieu Gagné
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 docs migration for Nova, I

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

2017-07-13 Thread Mathieu Gagné
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é wrote: > Hi, > > So this email is relevant to my interests as an operator. =) &

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

2017-07-11 Thread Mathieu Gagné
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 discussion boiled down

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

2017-05-24 Thread Mathieu Gagné
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 I have been able to fi

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

2017-05-17 Thread Mathieu Gagné
On Wed, May 17, 2017 at 10:03 AM, Mathieu Gagné 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 or any other in-guest agent

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

2017-05-17 Thread Mathieu Gagné
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?)

2017-05-10 Thread Mathieu Gagné
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 ex

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

2017-04-14 Thread Mathieu Gagné
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 limi

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

2017-04-12 Thread Mathieu Gagné
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 said this, I see > that C

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

2017-04-12 Thread Mathieu Gagné
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 starts on the cinder sid

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

2017-04-12 Thread Mathieu Gagné
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 user/admin could > figure

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

2017-04-03 Thread Mathieu Gagné
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 implementation. Thank

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

2017-04-03 Thread Mathieu Gagné
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. Cinder just prevents thi

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

2016-11-16 Thread Mathieu Gagné
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 and does not prese

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

2016-09-21 Thread Mathieu Gagné
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 have for nova.conf.sample. > > I

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

2016-08-17 Thread Mathieu Gagné
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'

2016-05-24 Thread Mathieu Gagné
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: > Hi there all, > > I am

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

2016-05-17 Thread Mathieu Gagné
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 > entries are redundant an

Re: [openstack-dev] Team blogs

2016-05-10 Thread Mathieu Gagné
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 medium, archived foreve

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

2016-04-06 Thread Mathieu Gagné
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 endpoint. I used to ha

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

2016-03-09 Thread Mathieu Gagné
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 Riedema

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

2016-03-03 Thread Mathieu Gagné
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

2016-01-27 Thread Mathieu Gagné
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 t

Re: [openstack-dev] OpenStack-Announce List

2015-11-19 Thread Mathieu Gagné
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 sup

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

2015-10-22 Thread Mathieu Gagné
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 06:44 AM >> Subject: Re: [openstack-dev] [nova-compute][nova][libvirt] Extending

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

2015-10-21 Thread Mathieu Gagné
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 servi

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

2015-10-08 Thread Mathieu Gagné
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 majo

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

2015-10-02 Thread Mathieu Gagné
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 and

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

2015-10-01 Thread Mathieu Gagné
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 cl

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

2015-09-29 Thread Mathieu Gagné
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 respondents), > jCloud

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

2015-09-24 Thread Mathieu Gagné
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 vo

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

2015-09-24 Thread Mathieu Gagné
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?

2015-09-24 Thread Mathieu Gagné
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 c

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

2015-09-23 Thread Mathieu Gagné
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?

2015-09-23 Thread Mathieu Gagné
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

2015-09-22 Thread Mathieu Gagné
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'

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

2015-09-22 Thread Mathieu Gagné
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

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

2015-09-22 Thread Mathieu Gagné
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

2015-09-17 Thread Mathieu Gagné
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 no

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

2015-09-15 Thread Mathieu Gagné
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 > of

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

2015-09-15 Thread Mathieu Gagné
On 2015-09-15 6:49 PM, Doug Wiegley wrote: > > >> On Sep 15, 2015, at 4:11 PM, Mathieu Gagné wrote: >> >>> 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

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

2015-09-15 Thread Mathieu Gagné
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 apologize

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

2015-09-15 Thread Mathieu Gagné
On 2015-09-15 7:44 PM, Armando M. wrote: > > > On 15 September 2015 at 15:11, Mathieu Gagné <mailto: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

2015-09-15 Thread Mathieu Gagné
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 rea

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

2015-09-04 Thread Mathieu Gagné
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] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Mathieu Gagné
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 se

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

2015-08-27 Thread Mathieu Gagné
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 >

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

2015-07-28 Thread Mathieu Gagné
+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 bindi

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

2015-07-17 Thread Mathieu Gagné
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) -- Mathie

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

2015-07-17 Thread Mathieu Gagné
t;> On Thu, Jul 16, 2015 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 int

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

2015-07-16 Thread Mathieu Gagné
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 concer

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

2015-07-03 Thread Mathieu Gagné
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 > > Date: Thu Jul 2 23:14:39 2015 + > > Merge

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

2015-07-02 Thread Mathieu Gagné
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

2015-06-09 Thread Mathieu Gagné
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 open

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

2015-06-02 Thread Mathieu Gagné
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

2015-05-29 Thread Mathieu Gagné
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) a

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

2015-05-21 Thread Mathieu Gagné
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,

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

2015-05-21 Thread Mathieu Gagné
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: >>&g

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

2015-05-21 Thread Mathieu Gagné
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

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

2015-05-14 Thread Mathieu Gagné
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

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

2015-05-13 Thread Mathieu Gagné
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 mul

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

2015-05-08 Thread Mathieu Gagné
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, th

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

2015-05-04 Thread Mathieu Gagné
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: >>>&

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

2015-05-04 Thread Mathieu Gagné
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_endp

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

2015-05-04 Thread Mathieu Gagné
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 --os-en

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

2015-04-16 Thread Mathieu Gagné
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

2015-03-31 Thread Mathieu Gagné
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 publishi

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

2015-03-18 Thread Mathieu Gagné
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

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

2015-03-18 Thread Mathieu Gagné
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 p

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Mathieu Gagné
On 2015-02-05 9:36 PM, Angus Lees wrote: On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes mailto:g...@greghaynes.net>> wrote: Along those lines and in an effort to be a bit less doom-and-gloom, I spent my lunch break trying to find non-marketing documentation on the Galera replication protocol a

  1   2   >