Re: [Openstack-operators] Flavors

Follow-up thought: > This concept has never been questioned anywhere I can search, so I have a feeling I'm missing something big here. Maybe other ways are too complicated to implement? This topic does get brought up from time to time, but in different areas under different names. Off of the top

Re: [Openstack-operators] Flavors

Another benefit of flavors is that they provide ease of use. While there are users who are confident enough to spec out each instance they launch, I work with a lot of users who would feel overwhelmed if they had to do this. Providing a set of recommended instance specs can go a long way to

Re: [Openstack-operators] Flavors

How would you account for heterogeneous node types? Flavors by convention put the hardware generation in the name as the digit. Sent from my iPad > On Mar 15, 2017, at 11:42 PM, Kris G. Lindgren wrote: > > So how do you bill for someone when you have a 24 core, 256GB

Re: [Openstack-operators] Flavors

So how do you bill for someone when you have a 24 core, 256GB ram, with 3TB of disk machine - and someone creates a 1 core, 512MB ram, 2.9TB disk – flavor? Are you going to charge them same amount as if they created a 24 core, 250GB instances with 1TB of disk? Because both of those flavors

Re: [Openstack-operators] Flavors

Screw the short answer -- that is annoying to read, and it doesn't simplify BILLING from a CapEx/OpEx perspective, so please - wtf? Anyway, Vladimir - I love your question and have always wanted the same thing. On Wed, Mar 15, 2017 at 6:10 PM, Fox, Kevin M wrote: > I think

Re: [Openstack-operators] Flavors

I think it can help add enough predictability and structure to keep costs down as well. If you know the end users will be using 1 of 25 different pre-configured packages, you can somewhat reliably configure hardware sku's around that because often the packages are a fractional size of the

Re: [Openstack-operators] Flavors

On Wed, Mar 15, 2017 at 10:10:00PM +, Fox, Kevin M wrote: > I think the really short answer is something like: It greatly simplifies > scheduling and billing. The real answer is that once you buy hardware, it's in a fixed radio of CPU/Ram/Disk/IOPS, etc. In order to use the hardware

Re: [Openstack-operators] Flavors

I think the really short answer is something like: It greatly simplifies scheduling and billing. From: Vladimir Prokofev [v...@prokofev.me] Sent: Wednesday, March 15, 2017 2:41 PM To: OpenStack Operators Subject: [Openstack-operators] Flavors A question of

[Openstack-operators] Flavors

A question of curiosity - why do we even need flavors? I do realise that we need a way to provide instance configuration, but why use such a rigid construction? Wouldn't it be more flexible to provide instance configuration as a set of parameters(metadata), and if you need some presets - well,

[Openstack-operators] Cinder NFS backend volume attach issue

Hi All, I have deployed Ocata and configured NFS backend for cinder and able to create volumes without any issues. When am trying to attach the volume to instance it is failing with permission denied error on the compute node Added these to cinder.conf still having permission issue

Re: [Openstack-operators] Trove in production

We've run it in a test cloud meant to identify production issues before supporting them on our production cloud. We ran into a few issues that may or may not apply in your situation: There's a security issue with the Trove Rabbitmq. The easiest way around it is to use the feature that lets the

Re: [Openstack-operators] Forthcoming Nova Ocata 15.0.1 patch release - high severity fixes

On 3/14/2017 6:06 PM, Matt Riedemann wrote: I've got a release request up for the Nova Ocata 15.0.1 patch release here [1]. This release contains a few fixes for some high severity regression bugs introduced in the 15.0.0 release. If you have not yet upgraded to Ocata 15.0.0 I'd recommend going

[Openstack-operators] Trove in production

Hi everyone, I'm curious if anybody is using Trove in production: what's your experience? What are the problems you've encountered and how critical are they? Thanks in advance for your responses ___ OpenStack-operators mailing list

[Openstack-operators] [scientific][scientific-wg] Meeting today CANCELLED

Hi All - Today’s Scientific WG meeting is cancelled due to the Milan Ops meetup this week. There’s plenty of relevant action at the ops meetup (see the list of etherpads here[1]). Hopefully there’ll be a good trip report and plenty to discuss at next week’s meeting. Apologies for late