Re: [openstack-dev] [Neutron][Nova] API design and usability

On 2014-08-08 8:54 AM, Andrew Laski wrote: On 08/07/2014 07:57 AM, Mathieu Gagné wrote: IMO, moving the burden of such orchestration (and garbage collection) to the end users would be a mistake. It's not a good UX at all. I could say that removing auto-creation is like having to create your

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

On 2014-08-11 5:13 PM, Sandy Walsh wrote: Right, I'm not suggesting to remove the storage abstraction layer. I'm just curious what gnocchi does better/different than InfluxDB? I was at the OpenStack Design Summit when Gnocchi was presented. Soon after the basic goals and technical details of

Re: [openstack-dev] Help with sql upgrade and downgrade

On 2014-08-20 6:42 PM, Murali Balcha wrote: I can successfully add string column parent_id without any problem. However adding a boolean column is vexing. Adding a boolean column adds a check constraint on the table but when I remove the column in the downgrade, the check constraint for

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 2014-09-07 8:14 PM, Monty Taylor wrote: If I were king ... 1. Caring about end user experience at all If I don't do anything at all next cycle, I will see the above fixed. Because it's embarrassing. Seriously. Try to use OpenStack from python some time. I dare you. [...] Between 2 and

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

On 2014-09-16 7:03 PM, Walter A. Boring IV wrote: The upside to brick not making it in Nova is that it has given us some time to rethink things a bit. What I would actually like to see happen now is to create a new cinder/storage agent instead of just a brick library. The agent would run on

Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object

On 2014-06-11, 7:52 PM, Sean Dague wrote: Honestly, I really like [nova] better than [clients_nova] And as we're going to have to live with this for a while, I'd rather use the more clear version of this in keystone instead of the Heat stanzas. What about [novaclient] or [nova_client] ?

Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object

On 2014-06-12, 7:18 AM, Sean Dague wrote: On 06/11/2014 08:12 PM, Mathieu Gagné wrote: On 2014-06-11, 7:52 PM, Sean Dague wrote: I'm concerned about the [nova] section being (one day) overloaded with options unrelated to the actual nova client configuration. Although my concern could be wrong

Re: [openstack-dev] [OpenStack-Infra] Nomination for python-jenkins

On 2014-06-23 4:42 AM, Antoine Musso wrote: Hello, The python-jenkins module is a thin wrapper to interact with Jenkins. It has been migrated from Launchpad to Stackforge a couple months ago to attract more developers and easily upstream work down being done in over OpenStack projects (such as

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

On 2014-06-22 10:23 PM, Lingxian Kong wrote: So, for the functionality parity between nova-network and neutron and for our use case, I registered a blueprint[2] about default security group rules in Neutron days ago and related neutron spec[3], and I want it to be involved in Juno, so we can

Re: [openstack-dev] [hacking] rules for removal

On 2014-06-23 1:28 PM, Clint Byrum wrote: We've had this discussion already, but just remember that not everybody reading those commit messages will be a native English speaker. The more incorrect the grammar and punctuation is, the more confusing it will be to somebody who is already

Re: [openstack-dev] Using tmux instead of screen in devstack

On 2014-07-02 2:10 PM, Yuriy Taraday wrote: One problem that comes to mind is that screen tries to reopen your terminal when you attach to existing session or run a new one. So if you have one user you log in to a test server (ubuntu? root?) and another user that runs screen session (stack), you

Re: [openstack-dev] [Neutron][Nova] API design and usability

On 2014-08-06 7:58 PM, Robert Collins wrote: I'm astounded by this proposal - it doesn't remove the garbage collection complexity at all - it transfers it from our code - Nova - onto end users. So rather than one tested and consolidated implementation, we'll have one implementation in

Re: [openstack-dev] [Nova] Automatic evacuate

On 2014-10-14 2:49 PM, Tim Bell wrote: Nova is also not the right place to do the generic solution as many other parts could be involved... neutron and cinder come to mind. Nova needs to provide the basic functions but it needs something outside to make it all happen transparently. I would

Re: [openstack-dev] [Nova] Cells conversation starter

On 2014-10-20 2:00 PM, Andrew Laski wrote: One of the big goals for the Kilo cycle by users and developers of the cells functionality within Nova is to get it to a point where it can be considered a first class citizen of Nova. [...] Shortcomings: Flavor syncing This needs to be

Re: [openstack-dev] [Glance][Cinder] The sorry state of cinder's driver in Glance

On 2014-10-22 10:05 AM, John Griffith wrote: Ideas started spreading from there to Using a Read Only Cinder Volume per image, to A Glance owned Cinder Volume that would behave pretty much the current local disk/file-system model (Create a Cinder Volume for Glance, attach it to the Glance

Re: [openstack-dev] [api] Networking API Create network missing Request parameters

On 2014-10-23 7:00 PM, Danny Choi (dannchoi) wrote: In neutron, user with “admin” role can specify the provider network parameters when creating a network. —provider:network_type —provider:physical_network —provider:segmentation_id localadmin@qa4:~/devstack$ neutron net-create test-network

Re: [openstack-dev] Travels tips for the Paris summit

On 2014-10-14 11:35 AM, Adrien Cunin wrote: Hi everyone, Inspired by the travels tips published for the HK summit, the French OpenStack user group wrote a similar wiki page for Paris: https://wiki.openstack.org/wiki/Summit/Kilo/Travel_Tips Can someone add information about pre-paid

Re: [openstack-dev] [all] fix latency on requirements breakage

Sean Dague, thanks for bringing up the subject. This is highly relevant to my interests. =) On 2014-11-17 7:10 PM, Robert Collins wrote: Most production systems I know don't run with open ended dependencies. One of our contributing issues IMO is that we have the requirements duplicated

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

On 2014-12-11 8:43 AM, Jay Pipes wrote: I'm generally in favor of making name attributes opaque, utf-8 strings that are entirely user-defined and have no constraints on them. I consider the name to be just a tag that the user places on some resource. It is the resource's ID that is unique. I

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

On 2014-12-12 4:40 PM, Sean Dague wrote: While there is a good case for the UX of unique names - it also makes orchestration via tools like puppet a heck of a lot simpler - the fact is that most OpenStack resources do not require unique names. That being the case, why would we want security

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

On 2014-12-16 12:07 AM, Christopher Yeoh wrote: So I think this is something we really should get agreement on across the open stack API first before flipping back and forth on a case by case basis. Personally I think we should be using uuids for uniqueness and leave any extra restrictions to a

Re: [openstack-dev] [neutron][fwaas] neutron/agent/firewall.py

On 2014-12-19 5:16 PM, Paul Michali (pcm) wrote: This has a FirewallDriver and NoopFirewallDriver. Should this be moved into the neutron_fwaas repo? AFAIK, FirewallDriver is used to implement SecurityGroup: See: -

[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

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

On 2015-02-05 9:36 PM, Angus Lees wrote: On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes g...@greghaynes.net 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

Re: [openstack-dev] problems with instance consoles and novnc

On 2015-02-02 11:36 AM, Chris Friesen wrote: On 01/30/2015 06:26 AM, Jesse Pretorius wrote: Have you tried manually updating the NoVNC and websockify files to later versions from source? We were already using a fairly recent version of websockify, but it turns out that we needed to upversion

Re: [openstack-dev] problems with instance consoles and novnc

On 2015-01-28 11:13 PM, Chris Friesen wrote: Anyone have any suggestions on where to start digging? We have a similar issue which has yet to be properly diagnosed on our side. One workaround which looks to be working for us is enabling the private mode in the browser. If it doesn't work,

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

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

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

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

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

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

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

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

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

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] 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] 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?

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

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

  1   2   >