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

After discussion in the Large Deployments Team session this morning, we wanted to follow up on the earlier thread [1,2] about overriding endpoint URLs. That topic is exposing an underlying implication about the purpose of the service catalog. The LDT position is that the service catalog should

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

> particularly important for caching popular images close to the > nova-computes. We consider these glance-apis as part of the underlying > cloud infra rather than user-facing, so I think we'd prefer not to see > them in the service-catalog returned to users either

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

he service-catalog returned to users either... is there going > to be a (standard) way to hide them? > > On 28 April 2017 at 09:15, Mike Dorman wrote: >> We make extensive use of the [glance]/api_servers list. We configure that on hypervisors to direct them to Glan

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

We make extensive use of the [glance]/api_servers list. We configure that on hypervisors to direct them to Glance servers which are more “local” network-wise (in order to reduce network traffic across security zones/firewalls/etc.) This way nova-compute can fail over in case one of the Glance

Re: [Openstack-operators] OsOps Reboot

+1! Thanks for driving this. From: Edgar Magana Date: Friday, January 20, 2017 at 1:23 PM To: "m...@mattjarvis.org.uk" , Melvin Hillsman Cc: OpenStack Operators Subject: Re: [Openstack-operators] OsOps Reboot I super second this! Yes, looking forward to amazing contributions there. Edgar

Re: [Openstack-operators] RabbitMQ 3.6.x experience?

6' > 'collect_statistics_interval': 3 > rabbitmq::config_management_variables: > 'rates_mode': 'none' > rabbitmq::file_limit: '65535' > > Finally, if you do upgrade to 3.6.x please report back here with your

[Openstack-operators] RabbitMQ 3.6.x experience?

We are looking at upgrading to the latest RabbitMQ in an effort to ease some cluster failover issues we’ve been seeing. (Currently on 3.4.0) Anyone been running 3.6.x? And what has been your experience? Any gottchas to watch out for? Thanks, Mike

[Openstack-operators] [neutron] neutron-server high CPU and RAM load when updating DHCP ports

We noticed an issue in one of our larger clouds (~700 hypervisors and ovs agents) where (Liberty) neutron-server CPU and RAM load would spike up quite a bit whenever a DHCP agent port was updated. So much load that processes were getting OOM killed on our API servers, and so many queries were g

Re: [Openstack-operators] Question on coding style on osops-tools-contrib repo

There is no standard strategy for this particular repo. Although I do agree with you that the neutron directory is probably not the place for this. I would suggest creating a top level lib/ directory and placing it there. There is already a multi/ directory, but that’s for scripts for non-spec

Re: [Openstack-operators] Ceilometer/oslo.messaging connect to multiple RMQ endpoints

: Thursday, November 3, 2016 at 7:04 PM To: Mike Dorman Cc: OpenStack Operators Subject: Re: [Openstack-operators] Ceilometer/oslo.messaging connect to multiple RMQ endpoints That was me! and yes you can do it when consuming notifications with ceilometer-agent-notification Eg in our

[Openstack-operators] Ceilometer/oslo.messaging connect to multiple RMQ endpoints

I heard third hand from the summit that it’s possible to configure Ceilometer/oslo.messaging with multiple rabbitmq_hosts config entries, which will let you connect to multiple RMQ endpoints at the same time. The scenario here is we use the Ceilometer notification agent the pipe events from Ope

Re: [Openstack-operators] Updating oschecks

Absolutely agree. The osops repos started as (and frankly, still are) mostly dumping grounds for tools folks had built and were running locally. This was meant to be a first step at sharing and collaboration. The kind of improvements you’re talking about is exactly the direction we want to ta

Re: [Openstack-operators] Nova cells patches against Liberty

e tests. >> >> Cheers, >> Sam >> >> >> >>> On 20 May 2016, at 1:25 AM, Mike Dorman wrote: >>> >>> We are struggling a bit with the "Send up AZ and instance_name in system >>> metadata” patch. It works fine under norm

Re: [Openstack-operators] Nova cells patches against Liberty

actice, but it causes some of the tox tests to fail: https://gist.github.com/misterdorm/cc7dfd235ebcc2a23009b9115b58e4d5 Anyways, I’m at a bit of a loss here and curious if anybody might have some better insights. Thanks, Mike From: Sam Morrison Date: Wednesday, May 4, 2016 at 6:23 PM To

[Openstack-operators] Nova cells patches against Liberty

I went ahead and pulled out the Nova cells patches we’re running against Liberty so that others can use them if so desired. https://github.com/godaddy/openstack-nova-patches Usual disclaimers apply here, your mileage may vary, these may not work as expected in your environment, etc. We have te

Re: [Openstack-operators] [Large Deployments Team] Meeting tomorrow - 14:00 UTC

1600 UTC tomorrow (Thursday), right? So if Outlook is calculating it right, that’s 1100 US Central, 0900 US Pacific? Thanks, Mike From: Matt Van Winkle mailto:mvanw...@rackspace.com>> Date: Wednesday, April 20, 2016 at 9:38 AM To: OpenStack Operators mailto:openstack-operators@lists.openstac

[Openstack-operators] Ops Summit Call for Lightning Talks!

The time is upon us again to put together some great lightning talks for the Ops summit! We’ll have a single block of 90 minutes this time, so will have time for lots of good content from our community. Details and sign up on the etherpad: https://etherpad.openstack.org/p/AUS-ops-lightning-ta

[Openstack-operators] [operators] updates to osops readme files

I’ve created several reviews in the osops repos to update the README files with more details on how to contribute, etc. Please review: https://review.openstack.org/#/c/274772 https://review.openstack.org/#/c/274773 https://review.openstack.org/#/c/274777

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

We use some custom API policies (as in policy.json) to restrict certain operations to particular roles or requiring some fields on calls (i.e. we require that users give us an availability zone when booting an instance.) When the policy causes the operation to be denied, the only response that g

Re: [Openstack-operators] [openstack-operators][osops] tools-contrib is open for business!

First let me just say that I find nothing more infuriating than “software licensing.” We burn so much effort on this, when all we want to do is share the code to help others. I agree with Joe, I thought the agreement was stuff in “contrib” wouldn’t need license, specific formatting, test, et

Re: [Openstack-operators] [Large Deployments Team] Status update and No LDT meeting today

FYI I also submitted https://review.openstack.org/#/c/247725/ to add our meeting to the consolidated meeting schedule at http://eavesdrop.openstack.org/ Mike On 11/19/15, 11:14 AM, "Mike Dorman" wrote: >Several folks will be unavailable (including me) during the regular m

[Openstack-operators] [Large Deployments Team] Status update and No LDT meeting today

Several folks will be unavailable (including me) during the regular meeting time today, so unless someone else can volunteer to run the meeting, I think we should cancel. Here are some status updates on things since the summit: * Neutron segmented/routed networks * The spec [1] is still being

[Openstack-operators] [Nova] Support for server groups in cells v1

We recently patched Nova for support of server groups under cells v1. It’s pretty rudimentary, but it works. For anyone that’s interested, the patch is here: https://gist.github.com/misterdorm/5e9513bb1211b49e551c and I did a short write-up with some details at http://www.dorm.org/blog/nova-

Re: [Openstack-operators] [openstack-operators][osops] tools-contrib repo review in

Fair enough. Works for me. I didn’t think about the gate stuff. On 11/12/15, 2:46 PM, "JJ Asghar" wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > > > >On 11/12/15 3:36 PM, Mike Dorman wrote: >> I guess I thought we were just going to create c

Re: [Openstack-operators] [openstack-operators][osops] tools-contrib repo review in

I guess I thought we were just going to create contrib/ directories in each of the existing repos, rather than a net new repo. Not necessarily opposed to this approach, but it seems easier to get tools moved into the ‘curated’ area if they were in the same repo in the first place. Mike On

Re: [Openstack-operators] [nova] FYI, local conductor mode is deprecated, pending removal in N

We do have a backlog story to investigate this more deeply, we just have not had the time to do it yet. For us, it’s been easier/faster to add more hardware to conductor to get over the hump temporarily. We kind of have that work earmarked for after the Liberty upgrade, in hopes that maybe it’

Re: [Openstack-operators] Kilo upgrade challenges

We’ve run into this, too, and it’s been a frustration for a while. No way to tell python-requests to use a different cacert file (that I know of), and (at least in the packaging we use), the packaged cacert.pem file isn’t marked as a configuration file, meaning that it gets overwritten any time

Re: [Openstack-operators] [Large Deployments Team] [nova] Cells v1 attach/detach blueprint

/#/c/215459/ [3] https://review.openstack.org/#/c/235485 From: Mike Dorman mailto:mdor...@godaddy.com>> Date: Wednesday, November 4, 2015 at 3:29 PM To: OpenStack Operators mailto:openstack-operators@lists.openstack.org>> Subject: [Openstack-operators] [Large Deployments Team] [no

[Openstack-operators] [Large Deployments Team] [nova] Cells v1 attach/detach blueprint

I reached out to nova today to see what is the best way forward on this patch [1]. mriedem had created a blueprint skeleton for this already [2]. It sounds like it’s unlikely that nova would accept it, because it will require a new CI job [3] and it goes against the philosophy of not adding to

Re: [Openstack-operators] [Large Deployments Team] Summit Meeting Notes & Actions

Sorry, wrong link for [3] below. On 11/4/15, 3:05 PM, "Mike Dorman" wrote: >Thanks to everyone who was able to attend the LDT session in Tokyo! I wanted >to just briefly summarize some of the key points and action items. > >* Neutron segmented/routed networks >

[Openstack-operators] [Large Deployments Team] Summit Meeting Notes & Actions

Thanks to everyone who was able to attend the LDT session in Tokyo! I wanted to just briefly summarize some of the key points and action items. * Neutron segmented/routed networks * Encourage you to follow & provide feedback on the Neutron spec [1] * Cells v1 Patches * Many of the patches w

Re: [Openstack-operators] [Action Required]: Mitaka Operators Policy Changes

A bit late to the party here, but I’ve added all the policy changes for Go Daddy in the etherpad. Happy to talk about any of them in more detail if desired. Thanks, Mike From: Lance Bragstad mailto:lbrags...@gmail.com>> Date: Tuesday, October 27, 2015 at 2:09 AM To: OpenStack Operators mailt

Re: [Openstack-operators] Informal Ops Meetup?

Lower level of the design summit hotel. The larger room where box lunch was held the last few days. On 10/30/15, 10:18 AM, "Kruithof, Piet" wrote: >Feel like I should know thisbut where is the prince room? > >Sent from my Cyanogen phone > >On Oct 30, 2015 10:12 AM, Joe Topjian wrote:

Re: [Openstack-operators] Informal Ops Meetup?

I’ll be there. On 10/29/15, 4:56 PM, "gustavo panizzo (gfa)" wrote: >+1 > >On Thu, Oct 29, 2015 at 07:39:33 +, Kris G. Lindgren wrote: >> Hello all, >> >> I am not sure if you guys have looked at the schedule for Friday… but its >> all working groups. I was talking with a few other op

[Openstack-operators] [summit] Please come early to lightning talks today!

Since we have a lot of people signed up for lightning talks today, we’ll try to start a few minutes early to fit everyone in. Right after lunch, in Ohka (Grand Prince Hotel Takanawa, 2F) If you are speaking, please add a link to your slides in the etherpad for faster switching to the next talk

Re: [Openstack-operators] Ops Lightning Talk schedule

t I feel like Wednesday is already >packed while Tuesday is not. > >On Tuesday I conflict with non-production environments. besides that I'm >ok > >On Tue, Oct 20, 2015 at 07:48:28PM +, Mike Dorman wrote: >> I’ve gone ahead and (somewhat arbitrarily) scheduled out the l

Re: [Openstack-operators] [openstack-operators] OSOps we have a room in Toyko!

Could we get the etherpad link added to the sched page for this please? On 10/20/15, 11:16 AM, "JJ Asghar" wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > > >Hey everyone! > >Thanks to Tom and believing in our project he's given us a room[1] to >get some work done. I've started a

[Openstack-operators] Ops Lightning Talk schedule

I’ve gone ahead and (somewhat arbitrarily) scheduled out the lightning talks between the sessions on Tuesday and Wednesday: https://etherpad.openstack.org/p/TYO-ops-lightning-talks Please confirm your timeslot, or if you need to go on the opposite day, update the etherpad. A few talks have bee

[Openstack-operators] [Large Deployment Team] Action/Work Items Ahead of Summit, please review

During our meeting [1] today we discussed our agenda [2] and action items for the LDT working session [3] at the summit. We’ve compiled a list of a few things folks can be working on before getting to Tokyo to ensure this session is productive: 1. Neutron Segmented/Routed Networks: * Review

[Openstack-operators] Nova DB archiving script

I posted a patch against one of the Nova DB archiving scripts in the osops-tools-generic repo a few days ago to support additional tables: https://review.openstack.org/#/c/229013/2 We’d like a few more folks to review to make sure it looks good. Please take a few minutes and take a look. Than

Re: [Openstack-operators] how to deal with always-growing notifications.info queue?

Yep. If you don’t have ceilometer or something consuming those notifications, you can probably just turn off the feature so the messages aren’t sent in the first place. Generally I think you should be able to disable it by setting [DEFAULT]/notification_driver to blank in each of the service c

Re: [Openstack-operators] Neutron DHCP failover bug

We also run DHCP as active-active on both nodes and don’t do any failover at all. Worst case, both DHCP agents respond to a client, but the lease info is the same from both, anyway. From: Clayton O'Neill Date: Wednesday, September 30, 2015 at 5:48 AM To: Sam Morrison Cc: OpenStack Operators Su

Re: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August18, 19)

7:56 AM To: Mike Dorman Cc: OpenStack Operators Subject: Re: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August18, 19) Sorry, folks – late to the party here. I'm fine with keeping the Neutron bits as the first part of the LDT meeting. Looks like Mike has a mechanism set up fo

[Openstack-operators] PAO lightning talks

Hi all, If you plan on giving a lightning talk at the ops meetup next week, please confirm your contact details on the etherpad: https://etherpad.openstack.org/p/PAO-ops-lightning-talks I’ll reach out to everybody off list once we get a little closer to coordinate the schedule. We have 60 mi

Re: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August18, 19)

Yep! I have you on the list to add to the Hangout when I set it up (probably next week.) From: Kevin Benton Date: Thursday, August 6, 2015 at 8:29 PM To: Ryan Moats Cc: "mord...@inaugust.com", OpenStack Operators Subject: Re: [Openstack-operators] Draft Agenda for PA

Re: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August18, 19)

Not opposed to splitting like this. I know our other big agenda item is around cells, so maybe we could do a 1/3 split for each topic (still keeping Neutron first.) Plus we’ve got the lunch time immediately before, so we could use that time for something. Matt VW, any thoughts? From: Ryan M

Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

what videoconference tool to us? Absent any opinions, I’ll just do a Google Hangout. Thanks! Mike From: Kyle Mestery Date: Tuesday, August 4, 2015 at 8:09 AM To: Ryan Moats Cc: Mike Dorman, "OpenStack Development Mailing List (not for usage questions)", OpenStack Operators Subject:

Re: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August 18, 19)

Looks great, Tom, thanks. Coupling breakouts with lunch is a good plan. From: Tom Fifield Date: Monday, August 3, 2015 at 4:48 AM To: OpenStack Operators Subject: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August 18, 19) Hi all, Registrations are going well for our meetup in Palo A

Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

I hope we can move this idea moving forward. I was disappointed to see the spec abandoned. Some of us from the large deployers group will be at the Ops Meetup. Will there be any representation from Neutron there that we could discuss with more? Thanks, Mike On 8/3/15, 12:27 PM, "Carl Ba

Re: [Openstack-operators] [puppet] module dependencies and different openstack versions

We use the OpenStack modules, but glue everything together with a monolithic composition module (our own.) We do want to get to a place where we can upgrade/apply config/etc. each OpenStack component separately, but have’t tackled it yet. I think it will be possible, but will take some work.

[Openstack-operators] [Neutron] [Large Deployments Team] Discussion around routed networks

I wanted to bring this to the attention of anybody who may have missed it on openstack-dev. Particularly the LDT team folks who have been talking about the routed networks/disparate L2 domains stuff [1] [2]. http://lists.openstack.org/pipermail/openstack-dev/2015-July/thread.html#70 028 This i

Re: [Openstack-operators] Nova cells v2 and operational impacts

Seems reasonable. For us already running v1, will we be creating another new cell database for v2? Or will our existing v1 cell database become that second database under v2? Somewhat beyond the scope of this thread, but my main concern is the acrobatics going from v1 in Kilo to the hybrid v1

Re: [Openstack-operators] [puppet] OpenStack Puppet Modules Usage Questions

+1, I think we should just go ahead and do this. On 7/1/15, 3:23 PM, "Richard Raseley" wrote: >Matt Fischer wrote: >> We've been discussing this for 3 months now, so my vote is "soon". Can >> we make the Puppet Labs ML have an auto-responder that redirects people? > >Yes we can. I propose th

Re: [Openstack-operators] Scaling the Ops Meetup

I pretty much agree with everyone so far. No vendor booths, distributed “underwriters”, modest registration fee, and sans evening event. Not sure separate regional meetings are a good idea, but would be in favor of alternating North America vs. other region, like the summits. I’ve been lookin

Re: [Openstack-operators] Spec for Neutron Network IP Usage Extension API

were never been allocated and how many are reusable Thanks, Dani On Thu, May 7, 2015 at 4:29 PM, Mike Dorman mailto:mdor...@godaddy.com>> wrote: Hi all, For those of you who were interested in our network IP usage API extensions from the PHL meet up, we have this spec in play for

[Openstack-operators] [Large Deployers Team] neutron ask for network segments

Kris and I along with Belmiro drafted up a description and ask to Neutron about the network segments topic. We just put it at the end of the etherpad, others can review: https://etherpad.openstack.org/p/YVR-ops-large-deployments (In the “Feedback to Neutron team…” section.) __

[Openstack-operators] RabbitMQ ops session summary

Thought I’d post a quick summary/highlights of our RMQ session this morning. Thanks to all who attended and participated! For reference, the etherpad link is at [1]. * A lot fewer people attended this time than at previous summits and ops meet ups. I read that as an indication things are

[Openstack-operators] Risk of opening up spice html5 proxy publicly?

We are looking at opening up the spice html5 proxy service publicly, to support a customer facing product running on our OpenStack private cloud (GoDaddy Cloud Servers, https://cloud.godaddy.com/, for those interested.) This will be the first and only component of OpenStack we’re exposing publi

[Openstack-operators] RabbitMQ Ops session at Vancouver Summit

Hello Operators! Our RabbitMQ Ops summit session is on Tuesday at 11:15am, room 306 [1]. I’ve put together a preliminary agenda of discussion topics [2], but I’d like to gather any other items people want to cover. Please review the etherpad and add any specific outcomes/topics you’d like to s

[Openstack-operators] Spec for Neutron Network IP Usage Extension API

Hi all, For those of you who were interested in our network IP usage API extensions from the PHL meet up, we have this spec in play for it. Please review and comment! As a reminder, the raw code/patch for this is also available at https://github.com/godaddy/openstack-neutron/tree/network-ip-u

Re: [Openstack-operators] expanding to 2nd location

+1 to second site = second region. I would not recommend using cells unless you have a real nova scalability problem. There are a lot of caveats/gotchas. Cells v2 I think should come as an experimental feature in Liberty, and past that point cells will be the default mode of operation. It wi

Re: [Openstack-operators] FYI: Rabbit Heartbeat Patch Landed

We’ve been running the new oslo.messaging under Juno for about the last month, and we’ve seen success with it, too. From: Sam Morrison Date: Thursday, April 30, 2015 at 11:02 PM To: David Medberry Cc: OpenStack Operators Subject: Re: [Openstack-operators] FYI: Rabbit Heartbeat Patch Landed Great

Re: [Openstack-operators] [Neutron]floatingip with security group

Yup, you need to configure an “address pair” for the floating IP. This isn’t specifically a security groups thing, but it will allow traffic to the floating IP to pass into the VM to which it is associated. Under the covers, it’s implemented similarly to security groups, but is not directly a

[Openstack-operators] What to do when a compute node dies?

Hi all, I’m curious about how people deal with failures of compute nodes, as in total failure when the box is gone for good. (Mainly care about KVM HV, but also interested in more general cases as well.) The particular situation we’re looking at: how end users could identify or be notified of

[Openstack-operators] Neutron IP usage API extension

Several folks at the PHL meet up were interested in the API extensions we built for Neutron to report usage statistics on networks. Essentially this gives you a way to report the number of IPs out of the total that are used. We have that patch up in this branch now: https://github.com/godaddy

Re: [Openstack-operators] OpenStack services and ca certificate config entries

I have struggled with this stuff in the past, too. And have had situations where certs come from different CAs, so I can see some value in an ability to override the global defaults for specific services. However, for the small fraction of use cases that would cover, I think the cert concatena

Re: [Openstack-operators] max_age and until_refresh for fixing Nova quotas

ins that figures out what projects >are out of sync and corrects them. >We’ve always been scared of setting these to zero but we probably should. > >Sam > > >> On 15 Mar 2015, at 2:53 pm, Mike Dorman wrote: >> >> Yeah the default is just ‘0’ for both, which disab

Re: [Openstack-operators] max_age and until_refresh for fixing Nova quotas

>> From: Jesse Keating [mailto:j...@bluebox.net] >> Sent: 14 March 2015 16:59 >> To: openstack-operators@lists.openstack.org >> Subject: Re: [Openstack-operators] max_age and until_refresh for fixing >>Nova >> quotas >> >> On 3/14/15 8:11 AM, Mike Dorm

[Openstack-operators] max_age and until_refresh for fixing Nova quotas

For those not following the discussion on https://review.openstack.org/#/c/161782/ around fixing Nova quota usages, there are a couple config options that can help: max_age and until_refresh. I had not known about these before. I deployed them out this week and they seem to do a pretty good j

Re: [Openstack-operators] Ops meetup

On 3/13/15, 3:20 PM, "Jonathan Proulx" wrote: >On Fri, Mar 13, 2015 at 4:56 PM, Subbu Allamaraju wrote: >> Regarding the discussion on tags, here is my take from the discussion on >> Monday. >> >> 1. There is vehement agreement that having an integrated release >>consisting >> of a small “inne

[Openstack-operators] bug for scheduler failures (was FW: [openstack-dev] [nova] readout from Philly Operators Meetup)

For those of you who don’t subscribe to openstack-dev, see below for the nova bug to track better logging of scheduler failures: https://bugs.launchpad.net/nova/+bug/1431291 On 3/12/15, 5:23 AM, "Sean Dague" wrote: >On 03/11/2015 12:53 PM, Sylvain Bauza wrote: >>> Reporting on Scheduler F

[Openstack-operators] Operators Summit: RabbitMQ

I’ll follow the other posts today with some info on the RabbitMQ session for Tuesday morning. I’d like to start by quickly going over the different RMQ architectures that people run, and how you manage and maintain those. Then I think it’ll be helpful to classify the general issues people typic

[Openstack-operators] FW: Change in openstack/nova-specs[master]: Refresh quotas usage

This is an interesting spec around a feature to fix/refresh quotas. Kind of a temporary workaround for the larger problem of quota bugs, but definitely could be useful from an operator’s perspective. Mike On 3/5/15, 10:01 AM, "Romain Hardouin (Code Review)" wrote: >Romain Hardouin has u

Re: [Openstack-operators] [openstack-dev] [nova] The strange case of osapi_compute_unique_server_name_scope

I can report that we do use this option (‘global' setting.) We have to enforce name uniqueness for instances’ integration with some external systems (namely AD and Spacewalk) which require unique naming. However, we also do some external name validation which I think effectively enforces uniqu

Re: [Openstack-operators] Draft agenda for PHL Ops Meetup (9-10 March)

LGTM; +1 I like the working lunch idea! From: Tom Fifield Date: Friday, February 13, 2015 at 12:01 AM To: OpenStack Operators Subject: [Openstack-operators] Draft agenda for PHL Ops Meetup (9-10 March) Hi all, Registrations are going well for our meetup in Philly. If you're on the fence, hope

Re: [Openstack-operators] Monitoring Discussions at the Mid-Cycle Meetup

Absolutely. I think demos and then follow on discussions would be fantastic. On 2/3/15, 7:33 PM, "Hochmuth, Roland M" wrote: >Hi Folks, A number of us involved with the Monasca, >https://wiki.openstack.org/wiki/Monasca, and StackTach, >https://launchpad.net/stacktach projects, were discuss

Re: [Openstack-operators] [Large deployment] Meetings

Awesome, thanks for this update Tim! From: Tim Bell mailto:tim.b...@cern.ch>> Date: Friday, January 30, 2015 at 12:30 AM To: OpenStack Operators mailto:openstack-operators@lists.openstack.org>> Subject: Re: [Openstack-operators] [Large deployment] Meetings The spec for quotas in Nova for hierar