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] Setting affinity based on instance type

Mathieu, Blame it on my scattered brain but I'm now curious. How would this be approached practically speaking? I.e. how would ram_weight_multiplier enable the scenario I mentioned in my earliest post ? //adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware

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

- Original Message - > From: "Adam Lawson" > To: "Silence Dogood" > > Mathieu, > > Blame it on my scattered brain but I'm now curious. How would this be > approached practically speaking? I.e. how would ram_weight_multiplier > enable the

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

Cern actually did a pretty good write up of this: http://openstack-in-production.blogspot.com/2014/07/openstack-plays-tetris-stacking-and.html ___ Kris Lindgren Senior Linux Systems Engineer GoDaddy From: Adam Lawson

Re: [Openstack-operators] libvirt cpu type per instance?

On Thu, Mar 03, 2016 at 03:52:49PM -0500, Jonathan Proulx wrote: > > I have a user who wants to specify their libvirt CPU type to restrict > performance because they're modeling embeded systems. > > I seem to vaguely recall there is/was a way to specify this either in > the instance type or

Re: [Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

On 03/03/16 19:00, Sean M. Collins wrote: > Kilo is in the security supported stage of the lifecycle. > > http://releases.openstack.org/ > > So, unless it is a security bug, I do not believe that this will be > able to be backported. > In this case, it was already merged. But yes, thank you

[Openstack-operators] [ceilometer] Is it possible to set how often a ceilometer alarm fires when continuous alarm is true?

We are using Ceilometer to tell us when it’s time to expand a server cluster based on cpu utilization. When I turn on repeat-actions (continuous alarming), it alerts about every 20 seconds. Is there any way to specify how often the continuous alarm fires? I like the idea of continuous alarm

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

Hello Folks, I have to admit that I really like these two: TOC / Technical Ops Contributor IRO / I Run OpenStack Edgar From: Pierre Freund > Date: Thursday, March 3, 2016 at 6:57 AM To: Edgar Magana

Re: [Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

The backport is pretty easy. You click on Cherry pick and if there's no conflict it just works. Like so: https://review.openstack.org/#/c/287928/ It still needs to go through the review process so you will need to ping some horizon developers in IRC. Getting that packaged may take longer. On

Re: [Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

Thanks Matt ! I logged in and now I see the cherry-pick button. I should use the web interface always logged in :) Thank you Saverio 2016-03-03 16:51 GMT+01:00 Matt Fischer : > The backport is pretty easy. You click on Cherry pick and if there's no > conflict it just works.

[Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

Hello there, in Manchester we had this interesting discussion about asking to backport bugfixes in order to avoid to build own packages. https://etherpad.openstack.org/p/MAN-ops-Upgrade-patches-packaging We run Openstack with Ubuntu and we use the Ubuntu Cloud Archive. We are upgrading our

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

+1 for TOC or AOC On 3 March 2016 at 15:54, Edgar Magana wrote: > Hello Folks, > > I have to admit that I really like these two: > > TOC / Technical Ops Contributor > IRO / I Run OpenStack > > Edgar > > From: Pierre Freund > Date: Thursday,

Re: [Openstack-operators] Configuration tool for Openstack

Hello Edgar; I'd be happy to. Not sure which part of the repo to put it in. This should become a mature tool, so perhaps genetic? Not quite sure. Let me know Chris - Christopher T. Hull 333 Orchard Ave, Sunnyvale CA. 94085 (415) 385 4865 chrishul...@gmail.com http://chrishull.com On

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] Setting affinity based on instance type

On 03/03/2016 08:57 AM, Robert Starmer wrote: 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

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

On Thu, Mar 03, 2016 at 03:57:22PM +0100, Pierre Freund wrote: :> :> *This needs a catchy name.* :> Yes, yes it does. Suggestions? :> :​​ :Some suggestions, but I'm not a native english speaker, it might sounds not :natural. As a native (american) english speaker all these suggestions sound

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

On Wed, Mar 02, 2016 at 09:35:07PM -0500, Mathieu Gagné wrote: :What would prevent the next user from having workloadB collocated with :an other user's workloadA if that's the only capacity available? : :Unless aggregates are used, it will be hard to guaranty that workloadA :and workloadB (from

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] [openstack-community] Recognising Ops contributions

How about just OPS : {$Verified_Count} Physical Nodes =D On Thu, Mar 3, 2016 at 12:08 PM, Robert Starmer wrote: > I setup an etherpad to try to capture this discussion: > > https://etherpad.openstack.org/p/OperatorRecognition > > R > > On Thu, Mar 3, 2016 at 9:04 AM, Robert

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

> > *This needs a catchy name.* > Yes, yes it does. Suggestions? > ​​ Some suggestions, but I'm not a native english speaker, it might sounds not natural. AOC / Active Ops Contributor ACC / Active Community Contributor TOC / Technical Ops Contributor Proud Ops POP / Proudly Operating in

[Openstack-operators] [app-catalog] App Catalog IRC meeting minutes - 3/3/2016

During our meeting this morning we touched on some of the excellent stuff markvan is doing with Horizon integration testing (thanks!) We also talked some more about transition/implementation details around using GLARE as the backend for the app catalog. kzaitsev_mb is making some excellent

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

We did some early affinity work and discovered some interesting problems with affinity and scheduling. =/ by default openstack used to ( may still ) deploy nodes across hosts evenly. Personally, I think this is a bad approach. Most cloud providers stack across a couple racks at a time filling

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

From: Matt Joyce > Date: Thursday 3 March 2016 at 18:35 To: Robert Starmer > Cc: openstack-operators >,

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

cool! On Thu, Mar 3, 2016 at 1:39 PM, Mathieu Gagné wrote: > On 2016-03-03 12:50 PM, Silence Dogood wrote: > > We did some early affinity work and discovered some interesting problems > > with affinity and scheduling. =/ by default openstack used to ( may > > still )

Re: [Openstack-operators] Configuration tool for Openstack

Yes, I think that the Generic repo will be the best for now.: https://github.com/openstack/osops-tools-generic Please, add me as reviewer of your commit. Cheers, Edgar From: Christopher Hull > Date: Thursday, March 3, 2016 at 8:31 AM To:

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

On 2016-03-03 12:50 PM, Silence Dogood wrote: > We did some early affinity work and discovered some interesting problems > with affinity and scheduling. =/ by default openstack used to ( may > still ) deploy nodes across hosts evenly. > > Personally, I think this is a bad approach. Most cloud

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

​What about 3 different groups, with every combination possible. ACC / Active Community Contributor I contribute with non-technical tasks (tasks not producing code). Example : Meetups, Summits, Ask moderation, participating in a user commitee, etc. TOC / Technical Ops Contributor I contribute to

Re: [Openstack-operators] Horizon bug fixed in Liberty, how should we ask a backport to Kilo ?

Kilo is in the security supported stage of the lifecycle. http://releases.openstack.org/ So, unless it is a security bug, I do not believe that this will be able to be backported. -- Sean M. Collins ___ OpenStack-operators mailing list

[Openstack-operators] libvirt cpu type per instance?

I have a user who wants to specify their libvirt CPU type to restrict performance because they're modeling embeded systems. I seem to vaguely recall there is/was a way to specify this either in the instance type or maybe even in the image metadata, but I can't seem to find it. Am I delusional

Re: [Openstack-operators] libvirt cpu type per instance?

I would be curious if specifing the cpu type would actually restrict performance. As far as I know, this only restricts the cpu features presented to a vm. You can present a vm that has the cpu instruction sets of a Pentium 3 – but runs and is as performant as a single core on a 2.8ghz

Re: [Openstack-operators] libvirt cpu type per instance?

Jonathan - There are some nova settings (at least for KVM that you are probably thinking of, such as: cpu_mode cpu_model http://docs.openstack.org/liberty/config-reference/content/kvm.html Mike Smith Lead Cloud Systems Architect Overstock.com On Mar 3, 2016, at 1:52

Re: [Openstack-operators] libvirt cpu type per instance?

On 03/03/2016 03:20 PM, Kris G. Lindgren wrote: I would be curious if specifing the cpu type would actually restrict performance. As far as I know, this only restricts the cpu features presented to a vm. You can present a vm that has the cpu instruction sets of a Pentium 3 – but runs and is as