Re: [Openstack-operators] Flavors

2017-03-20 Thread Blair Bethwaite
Hi Chris,

On 17 Mar. 2017 15:24, "Chris Friesen"  wrote:

On 03/16/2017 07:06 PM, Blair Bethwaite wrote:

Statement: breaks bin packing / have to match flavor dimensions to hardware
> dimensions.
> Comment: neither of these ring true to me given that most operators tend to
> agree that memory is there first constraining resource dimension and it is
> difficult to achieve high CPU utilisation before memory is exhausted. Plus
> virtualisation is inherently about resource sharing and over-provisioning,
>

Ah whoops, that was meant to be: "resource sharing and (optionally)
over-provisioning", where I was broadly including security and convenience
under resource sharing. There are of course many other factors.

unless you have very detailed knowledge of your workloads a priori (or some
> cycle-stealing/back-filling mechanism) you will always have
> under-utilisation
> (possibly quite high on average) in some resource dimensions.
>

I think this would be highly dependent on the workload.  A virtual router
is going to run out of CPU/network bandwidth far before memory is exhausted.


Absolutely, which is why I hinted at today's general IaaS workload and
said, "...unless you have very detailed knowledge of your workloads a
priori". NFV focused clouds would clearly look quite different, and I
suppose with the rise of OpenStack at telcos there would be quite a few
such deployments floating around now.

For similar reasons I'd disagree that virtualization is inherently about
over-provisioning and suggest that (in some cases at least) it's more about
flexibility over time.  Our customers generally care about maximizing
performance and so nothing is over-provisioned...disk, NICs, CPUs, RAM are
generally all exclusively allocated.


Sure, in our three Nova Cells we have a big mix of workload. One Cell is
HPC oriented and so has no over-provisioning. Another is performance
oriented (fast cores, fast network) but still moderately over-provisioned
(cgroups to manage resource share between flavors). The other is general
purpose.

For me an interesting question to know the answer to here would be at what
point you have to stop resource sharing to guarantee your performance
promises/SLAs (disregarding memory over-provisioning). My gut says that
unless you are also doing all the other high-end performance tuning (CPU &
memory pinning​, NUMA topology, hugepages, optimised networking such as
macvtap or SRIOV, plus all the regular host-side system/BIOS and power
settings) you'll see very little benefit, i.e., under-provisioning on its
own is not a performance win.

Cheers,
Blair
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] [User-committee] Boston Forum - Formal Submission Now Open!

2017-03-20 Thread Emilien Macchi
+openstack-dev mailing-list.

On Mon, Mar 20, 2017 at 3:55 PM, Melvin Hillsman  wrote:
> Hey everyone!
>
> We have made it to the next stage of the topic selection process for the
> Forum in Boston.
>
> Starting today, our submission tool is open for you to submit abstracts for
> the most popular sessions that came out of your brainstorming. Please note
> that the etherpads are not being pulled into the submission tool and
> discussion around which sessions to submit are encouraged.
>
> We are asking all session leaders to submit their abstracts at:
>
> http://forumtopics.openstack.org/
>
> before 11:59PM UTC on Sunday April 2nd!
>
> We are looking for a good mix of project-specific, cross-project or
> strategic/whole-of-community discussions, and sessions that emphasize
> collaboration between users and developers are most welcome!
>
> We assume that anything submitted to the system has achieved a good amount
> of discussion and consensus that it is a worthwhile topic. After submissions
> close, a team of representatives from the User Committee, the Technical
> Committee, and Foundation staff will take the sessions proposed by the
> community and fill out the schedule.
>
> You can expect the draft schedule to be released on April 10th.
>
> Further details about the Forum can be found at:
> https://wiki.openstack.org/wiki/Forum
>
> Regards,
>
> OpenStack User Committee
>
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>



-- 
Emilien Macchi

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


[Openstack-operators] Boston Forum - Formal Submission Now Open!

2017-03-20 Thread Melvin Hillsman
Hey everyone!

We have made it to the next stage of the topic selection process for the
Forum in Boston.

Starting today, our submission tool is open for you to submit abstracts for
the most popular sessions that came out of your brainstorming. *Please note
that the etherpads are not being pulled into the submission tool and
discussion around which sessions to submit are encouraged.*

We are asking all session leaders to submit their abstracts at:

http://forumtopics.openstack.org/

*before 11:59PM UTC on Sunday April 2nd!*

We are looking for a good mix of project-specific, cross-project or
strategic/whole-of-community discussions, and *sessions that emphasize
collaboration between users and developers are most welcome!*

We assume that anything submitted to the system has achieved a good amount
of discussion and consensus that it is a worthwhile topic. After
submissions close, a team of representatives from the User Committee, the
Technical Committee, and Foundation staff will take the sessions proposed
by the community and fill out the schedule.

You can expect the draft schedule to be released on April 10th.

Further details about the Forum can be found at: https://wiki.openstack.org/
wiki/Forum

Regards,

OpenStack User Committee
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators