[openstack-dev] [Neutron] Allow for per-subnet dhcp options

Hi All, I'm hoping to get this blueprint https://blueprints.launchpad.net/neutron/+spec/dhcp-options-per-subnet some love...seems it's been hanging around since January so my assumption is it's not going anywhere. As a private cloud operator I make heavy use of vlan based provider networks to

Re: [openstack-dev] [Nova] Grizzly - Havanna db migration bug/1245502 still biting me?

ah, because the patched version won't work if you've already run the unpatched version, would be nice if that had been captured in the bug but did dig it out of http://lists.openstack.org/pipermail/openstack/2013-October/002481.html On Mon, Dec 30, 2013 at 1:25 PM, Jonathan Proulx j

[openstack-dev] [Nova] os-migrateLive not working with neutron in Havana (or apparently Grizzly)

HI all, Trying to get a little love on bug https://bugs.launchpad.net/nova/+bug/1227836 Short version is the instance migrates, but there's an RPC time out that keeps nova thinking it's still on the old node mid-migration. Informal survey of operators seems to suggest this always happens when

Re: [openstack-dev] [nova] future fate of nova-network?

To add to the screams of others removing features from nova-network to achieve parity with neutron is a non starter, and it rather scares me to hear it suggested. I do try not to rant in public, especially about things I'm not competent to really help fix, but I can't really contain this one any

Re: [openstack-dev] [nova] why are we backporting low priority v3 api fixes to v2?

On Mon, Dec 2, 2013 at 9:27 AM, Joe Gordon joe.gord...@gmail.com wrote: I don't think we should be blocking them per-se as long as they fit the API change guidelines https://wiki.openstack.org/wiki/APIChangeGuidelines. Agreed, possibly not what one would assign developers to do but as an open

[openstack-dev] [Neutron] nova-network as ML2 mechanism?

Hi All, Would making an nova-network mechanism driver for the ml2 plugin be possible? I'm an operator not a developer so apologies if this has been discussed and is either planned or impossible, but a quick web search didn't hit anything. As an operator I would envision this a a transition

Re: [openstack-dev] Fwd: Fwd: Debian people don't like bash8 as a project name (Bug#748383: ITP: bash8 -- bash script style guide checker)

On Wed, Jun 11, 2014 at 2:30 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: On 06/11/2014 02:01 PM, Sean Dague wrote: Honestly, I kind of don't care. :) +1 :-) +1 yep. that about covers it. Ordinarily I'd agree that naming is a bike shed argument, but projectnameinteger strongly

Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default

On Fri, Jul 26, 2013 at 1:01 PM, Jay Pipes jaypi...@gmail.com wrote: On 07/25/2013 08:24 PM, Joshua Harlow wrote: You mean process/forking API right? Honestly I'd sort of think the whole limits.py that is this rate-limiting could also be turned off by default (or a log warn message occurs)

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

On Fri, Nov 06, 2015 at 05:28:13PM +, Mark Baker wrote: :Worth mentioning that OpenStack releases that come out at the same time as :Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka) are :supported for 5 years by Canonical so are already kind of an LTS. Support :in this

Re: [openstack-dev] [Neutron] Allow for per-subnet dhcp options

On Fri, Sep 11, 2015 at 3:43 PM, Kyle Mestery <mest...@mestery.com> wrote: > On Fri, Sep 11, 2015 at 2:04 PM, Jonathan Proulx <j...@jonproulx.com> wrote: >> >> I'm hurt that this blue print has seen no love in 18 months: >> https://blueprints.launchpad.net/neut

[openstack-dev] [Neutron] Allow for per-subnet dhcp options

I'm hurt that this blue print has seen no love in 18 months: https://blueprints.launchpad.net/neutron/+spec/dhcp-options-per-subnet I need different MTUs and different domians on different subnets. It appears there is still no way to do this other than running a network node (or two if I want

Re: [openstack-dev] [all] A proposal to separate the design summit

On Tue, Feb 23, 2016 at 10:14:11PM +0800, Qiming Teng wrote: :My take of this is that we are saving the cost by isolating developers :(contributors) from users/customers. I'm a little concerned about this as well. Though presumably at least the PTLs would still attend the User/Ops conference

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

On Wed, Mar 02, 2016 at 11:36:17AM -0800, Gregory Haynes wrote: :Clearly, some operators and users disagree with the opinion that 'by :default security groups should closed off' given that we have several :large public providers who have changed these defaults (despite there :being no documented

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

On Wed, Mar 02, 2016 at 02:05:40PM -0600, Monty Taylor wrote: :(try writing an idempotent ansible playbook that tries to make your :security group look exactly like you want it not knowing in advance :what security group rules this provider happens to want to give you :that you didn't think to

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

On Wed, Mar 02, 2016 at 10:19:50PM +, James Denton wrote: :My opinion is that the current stance of ‘deny all’ is probably the safest bet for all parties (including users) at this point. It’s been that way for years now, and is a substantial change that may result in little benefit. After

Re: [openstack-dev] [oslo.config] Encrypt the sensitive options

On Mon, May 02, 2016 at 11:41:58AM -0700, Morgan Fainberg wrote: :On Mon, May 2, 2016 at 11:32 AM, Adam Young wrote: :> Kerberos would work, too, for deployments that prefer that form of :> Authentication. We can document this, but do not need to implement. :> :> :Never hurts

Re: [openstack-dev] [All] IRC Mishaps

Well the worst thing I've done is type and send my password...that was on an internal work channel not an OpenStack one, but I think that only made it more embarrassing! -Jon On Wed, Feb 08, 2017 at 08:36:16PM +, Kendall Nelson wrote: :Hello All! : :So I am sure we've all seen it: people

Re: [openstack-dev] [osa] [docs] OpenStack-Ansible deploy guide live!

On Wed, Nov 30, 2016 at 09:24:19AM -0600, Major Hayden wrote: :On 11/30/2016 09:03 AM, Alexandra Settle wrote: :> I am really pleased to announce that the OpenStack-Ansible Deployment Guide is now available on the docs.o.o website! You can view it in all its glory here:

Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

On Fri, May 05, 2017 at 02:04:43PM -0600, John Griffith wrote: :On Fri, May 5, 2017 at 11:24 AM, Chris Friesen :> Cinder theoretically supports LVM/iSCSI, but if you actually try to use it :> for anything stressful it falls over. :> : :​Oh really?​ : :​I'd love some

Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

On Thu, May 04, 2017 at 04:14:07PM +0200, Thierry Carrez wrote: :Chris Dent wrote: :> On Wed, 3 May 2017, Drew Fisher wrote: :>> "Most large customers move slowly and thus are running older versions, :>> which are EOL upstream sometimes before they even deploy them." :> :> Can someone with more

Re: [openstack-dev] [ptg] Simplification in OpenStack

On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote: :OpenStack is big. Big enough that a user will likely be fine with learning :a new set of tools to manage it. New users in the startup sense of new, probably. People with entrenched environments, I doubt it. But OpenStack is big. Big

Re: [openstack-dev] [ptg] Simplification in OpenStack

tions" or use-cases. If, instead of in Kolla, do :these in cross-community manner (and just host kolla-specific things :in kolla), I think that would partially address what you're asking for :here. Yeas, that sounds like a great idea. -Jon :On 26 September 2017 at 13:01, Jonathan

Re: [openstack-dev] Supporting SSH host certificates

Giuseppe , I'm pretty sure this is the project you want ot look into: http://git.openstack.org/cgit/openstack/barbican/ "Barbican is a ReST API designed for the secure storage, provisioning and management of secrets, including in OpenStack environments." -Jon On Fri, Sep 29, 2017 at

Re: [openstack-dev] [Openstack-operators] Ops Meetups team minutes + main topics

:On Tue, Nov 21, 2017 at 9:15 AM, Chris Morgan wrote: :> The big topic of debate, however, was whether subsequent meetups should be :> co-located with OpenStack PTG. This is a question for the wider OpenStack :> operators community. For people who attend both I thnik this

Re: [openstack-dev] [Openstack-operators] Ops Meetups team minutes + main topics

AM, Jonathan Proulx <j...@csail.mit.edu> wrote: : :> :On Tue, Nov 21, 2017 at 9:15 AM, Chris Morgan <mihali...@gmail.com> :> wrote: :> :> :> The big topic of debate, however, was whether subsequent meetups should :> be :> :> co-located with OpenStack PTG. This is a

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

On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote: :> >> maybe we're all saying the same thing here? :> > Yeah, I feel like we're all essentially in agreement that nits (of the :> > English mistake of typo type) do need to get fixed, but sometimes :> > (often?) putting the burden of

Re: [openstack-dev] [Openstack-operators] OpenStack "S" Release Naming Preliminary Results

On Wed, Mar 21, 2018 at 08:32:38PM -0400, Paul Belanger wrote: :6. Spandau loses to Solar by 195–88, loses to Springer by 125–118 Given this is at #6 and formal vetting is yet to come it's probably not much of an issue, but "Spandau's" first association for many will be Nazi war criminals via