Re: [Openstack-operators] Operators Mid-cycle Moderator

Melvin, I don't see anywhere on the meetup page defining who has been assigned to moderate what? Is there a document describing this yet? Robert On Sat, Feb 25, 2017 at 9:35 AM, Melvin Hillsman wrote: > Hey everyone, > > Thank you all for signing up to be moderators at

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

Chris, What's the status of this? Is there an eventbrite set up for it? What still needs to be done? Do we have a session catalog established yet? Robert On Wed, Jul 6, 2016 at 1:07 PM, Chris Morgan wrote: > For the purposes of the mid-cycle meeting this august, I can

Re: [Openstack-operators] [openstack-dev] [Neutron][IPAM] Anyone using builtin pluggable IPAM driver?

I didnt' even realize that there was a special "internal" driver. The only time I've set this parameter was to use a non-standard IPAM service ( romana.io SDN specifically), otherwise I'd likely never have even looked for an ipam_driver config parameter. R On Fri, Jun 17, 2016 at 2:03 PM, Sean

Re: [Openstack-operators] Ops Meetup event sizes

I'll second David's comments, and second the fact that the Manchester layout seemed to work well. The facility in Manchester provided a couple secondary rooms plus a few much smaller rooms which I think generally worked well. Having a tertiary area for meals/"networking" type engagements should

Re: [Openstack-operators] Fwd: [openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.

Seems like a great approach. You might want to also include: This bug was probably not triaged due to lack of information to reproduce the issue. Please include as much information about the problem including steps to allow a developer to reproduce the issue in order for your time in reporting

Re: [Openstack-operators] User specified fixed-ips, anyone else doing it?

I don't have cycles to support this development, but I do think that the function is worth while, wether you are using a 3rd party IPAM model or not, there are plenty of developers who expect a specific IP Address (even if it was randomly assigned via some other process, like booting without

Re: [Openstack-operators] Moving from distro packages to containers (or virtualenvs...)

That's effectively my understanding. On Fri, May 13, 2016 at 9:51 AM, Matthew Thode wrote: > On 05/13/2016 01:59 PM, Joshua Harlow wrote: > > Matthew Thode wrote: > >> On 05/13/2016 12:48 PM, Joshua Harlow wrote: > > * Was/is kolla used or looked into? or

Re: [Openstack-operators] Moving from distro packages to containers (or virtualenvs...)

I'm working with a customer to define and manage a transition to what is currently anticipated to be a container based solution for OpenStack services. The focus on containers is to simplify the middleware deployment of both OpenStack services and other services that are deployed to enable the

Re: [Openstack-operators] User Survey usage of QEMU (as opposed to KVM) ?

> They were happy because they could now go down the path. > > The simple answer should have been - get off the bike and pick up the > tacks - instead of finding ways to > over-engineer the problem > > Either show the right thing - or don't show it at all. > > My 0.02

Re: [Openstack-operators] User Survey usage of QEMU (as opposed to KVM) ?

You could just ask for the value of virt_type parameter from a compute host (or the output of something like grep 'virt_type' /etc/nova/nova*) if you are using qemu or kvm. I believe that's how nova figures out what parameters to use when launching an instance. On Wed, May 11, 2016 at 8:39 AM,

Re: [Openstack-operators] Maintenance

Maybe a result of the discussion can be a set of models (let's not go so far as to call them best pracices yet :) for how maintainance can be done at scale, perhaps solidifying the descriptions Jay has above with the user stories Tomi described in his initial note. This seems like an achievable

Re: [Openstack-operators] [puppet][kolla] Multi-node installation

+1 for Kolla (and yes, I realize I just suggested Packstack). It certainly is much easier to _operate_ once you get it up and running. On Wed, Apr 13, 2016 at 1:40 AM, Steven Dake (stdake) wrote: > A suggestion to give Kolla a spin inside… > > From: Rayson Ho

Re: [Openstack-operators] [nova] Removing seeded flavors

I'll add a vote for removal, given how varied private clouds tend to be, the flavors are often "wrong" for any one particular purpose. R On Sat, Apr 2, 2016 at 8:41 PM, Mike Smith wrote: > +1 from me. We always just remove them and add our own. Like Dan said, > it’s

Re: [Openstack-operators] Austin Summit Ops Day - Kuryr and Containers Networking

I add another voice, I have customers who are looking to extend their cloud into the container space, and raised concerns about the multi-SDN approach that seemed to be needed in environments where both VM and Containers are needed. Actually I have one who is curious as to how this maps to Iroinc

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

If fixing a typo in a document is considered a technical contribution, then I think we've already cast the net far and wide. ATC as used has become a name implying you're trying to make OpenStack better, more useable, and more functional for those who would use/deploy (and fix, update, enhance)

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

So when a user manages a discussion across a group of operators, who's input is then fed into the development teams who are developing the software, and in such a way are supporting the development cycle, would those downstream users (I'm not touching the code), not also be ATCs? The discussions

Re: [Openstack-operators] Cloud Upgrade Strategies

I have to agree, unless you start with CI/CD as your deployment model, you're going to be doing full upgrades. And be aware that at least one package model will overwrite your carefully crafted config files if you choose the wrong option. Having tried an upgrade to a system in the middle of an

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

I agree with the list of contributions that should garner value, and I really like TOC, because some folks who meet the other operators requirements may not actually _run_ OpenStack, they may "operate" on top :) On Thu, Mar 3, 2016 at 7:54 AM, Edgar Magana wrote: >

Re: [Openstack-operators] Setting affinity based on instance type

There was work done on enabling much more dynamic scheduling, including cross project scheduling (e.g. get additional placement hints from Neutron or Cinder), and I believe the framework is even in place to make use of this, but I don't believe anyone has written a scheduling component to make use

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

Ha, now that's a truth :) On Fri, Feb 26, 2016 at 7:34 AM, Matt Jarvis <matt.jar...@datacentred.co.uk> wrote: > Agreed, although I've learned over the years that second guessing what > actions customers may or may not take is usually a losing battle ;) > > On 26 February 201

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

For a user that's gone and deleted their network services, then wouldn't they perhaps be savvy enough to deploy a network/subnet pair. If they don't want to pay for the router then this is what they'd be working towards (by deleting their initially provisioned service). As it stands today, if

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

cool, then option 2 makes sense. On Thu, Feb 25, 2016 at 9:41 PM, Kevin Benton <ke...@benton.pub> wrote: > The router is automatically created as well and is attached to the tenants > network and an external network with the flag 'is_default' set to true. > On Feb 24, 2016 6

Re: [Openstack-operators] Nova-network -> Neutron Migration

It still probably fits in OSOps, at least in contrib, as the idea is to capture scripts and code that _may_ help someone, rather than necessarily being 100% fit for any production environment. Of course, any/all documentation available would also be useful. Robert On Wed, Feb 17, 2016 at 8:42

Re: [Openstack-operators] European Operators Meetup

+1 Really a well put together event. Robert On Wed, Feb 17, 2016 at 10:21 AM, Edgar Magana wrote: > Thank you Matt! > > Great organization and a very good job putting all this together. Yes, see > you in Austin. > > Edgar > > From: Matt Jarvis

Re: [Openstack-operators] [kolla] Question about how Operators deploy

+1 on two VIPs On Fri, Feb 12, 2016 at 6:04 AM, Steven Dake (stdake) wrote: > Hi folks, > > Unfortunately I won't be able to make it to the Operator midcycle because > of budget constraints or I would find the answer to this question there. > The Kolla upstream is busy sorting

Re: [Openstack-operators] RAID / stripe block storage volumes

purpose / best effort compute > and storage, what methods are available to help the user be resilient to > block storage failures? > > Joe > > On Mon, Feb 8, 2016 at 12:09 PM, Robert Starmer <rob...@kumul.us> wrote: > >> I've always recommended providing multiple under

Re: [Openstack-operators] RAID / stripe block storage volumes

I've always recommended providing multiple underlying storage services to provide this rather than adding the overhead to the VM. So, not in any of my systems or any I've worked with. R On Fri, Feb 5, 2016 at 5:56 PM, Joe Topjian wrote: > Hello, > > Does anyone have users

Re: [Openstack-operators] RAID / stripe block storage volumes

nstack.org/wiki/CinderSupportMatrix > 2: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html > > > On Mon, Feb 8, 2016 at 4:10 PM, Robert Starmer <rob...@kumul.us> wrote: > >> I'm not against Ceph, but even 2 machines (and really 2 machines with >>

Re: [Openstack-operators] RAID / stripe block storage volumes

corrupt them all... Hence my comment about having some form of object storage (SWIFT is perhaps even a good example of this architeccture, the proxy replicates, checks MD5, etc. to verify good data, rather than just replicating blocks of data). On Mon, Feb 8, 2016 at 7:15 PM, Robert Starmer

Re: [Openstack-operators] OpenStack Consult Opp (Network/Horizon/VNC)

I thought this got stuck in the "do we need another list" and "well, what is our alternative" discussion. So, no I don't recall any progress. I still think it'd be useful to have a list. for this class of discussion. Robert On Wed, Feb 3, 2016 at 6:01 PM, Adam Lawson wrote:

Re: [Openstack-operators] Draft Agenda for MAN Ops Meetup (Feb 15, 16)

I' m also open to moderating just about any session, but I'll volunteer for Keystone Federation. On Mon, Feb 1, 2016 at 10:22 AM, Edgar Magana wrote: > I can help moderating any session about Operations and Networking. > > Edgar > > From: Matt Jarvis

Re: [Openstack-operators] DVR and public IP consumption

conflicting but it would still allow the > existing code to function the way it always has, greatly simplifying > implementation? > > Thanks, > Kevin > > -- > *From:* Robert Starmer [rob...@kumul.us] > *Sent:* Wednesday, January 27, 2016 8:34 PM

Re: [Openstack-operators] DVR and public IP consumption

how it should be" on top. Robert On Wed, Jan 27, 2016 at 3:33 PM, Fox, Kevin M <kevin@pnnl.gov> wrote: > But there already is a second external address, the fip address that's > nating. Is there a double nat? I'm a little confused. > > Thanks, > Kevin >

Re: [Openstack-operators] User Committee Changes

Congratulations Edgar! Robert On Wed, Jan 27, 2016 at 9:28 AM, Edgar Magana wrote: > Hello All, > > Thank you so much Shilla and Jon for the support and confidence I am > really looking forward to working with you as well. > > This is a great opportunity and I am very

Re: [Openstack-operators] Storage backend for glance

Glusterfs backend works great for shared glance, and can be configured for a bit of redundancy at the disk level (rather than non distributed NFS, which needs the NFS server to be present), much like the Ceph model Kevin suggests. Is your database also resiliant (e.g. some form of mysql

Re: [Openstack-operators] Better error messages for API policy enforcements

I can't think of a case where better error response and log messages are not useful/desired. Robert On Wed, Dec 2, 2015 at 2:39 PM, Mike Dorman wrote: > We use some custom API policies (as in policy.json) to restrict certain > operations to particular roles or requiring