Re: [Openstack-operators] Flavors
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!
+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!
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