<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Mike,<div><br></div><div>You mention "<font size="2" face="sans-serif">We are now extending that example to include storage, and we are also working examples with Hadoop.</font> "</div><div><br></div><div>In the context of your examples / scenarios, do these placement decisions consider storage performance and capacity on a physical node?</div><div><br></div><div>For example: Based on application needs, and IOPS, latency requirements - carving out a SSD storage or a traditional spinning disk block volume? Or say for cost-efficiency reasons using SSD caching on Hadoop name nodes? </div><div><br></div><div>I'm investigating a) Per node PCIe SSD deployment need in Openstack environment / Hadoop environment and ,b) selected node SSD caching, specifically for OpenStack <b>Cinder</b>. Hope this is the right forum to ask this question.</div><div><br></div><div>rgds,</div><div>S</div><div><br></div><div><div><div>On Sep 12, 2013, at 12:29 AM, Mike Spreitzer <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><font size="2" face="sans-serif">Yes, I've seen that material. In
my group we have worked larger and more complex examples. I have
a proposed breakout session at the Hong Kong summit to talk about one,
you might want to vote for it. The URL is </font><a href="http://www.openstack.org/summit/openstack-summit-hong-kong-2013/become-a-speaker/TalkDetails/109"><font size="2" face="sans-serif">http://www.openstack.org/summit/openstack-summit-hong-kong-2013/become-a-speaker/TalkDetails/109</font></a><font size="2" face="sans-serif">
and the title is "Continuous Delivery of Lotus Connections on OpenStack".
We used our own technology to do the scheduling (make placement decisions)
and orchestration, calling Nova and Quantum to carry out the decisions
our software made. Above the OpenStack infrastructure we used two
layers of our own software, one focused on infrastructure and one adding
concerns for the software running on that infrastructure. Each used
its own language for a whole topology AKA pattern AKA application AKA cluster.
For example, our pattern has 16 VMs running the WebSphere application
server, organized into four homogenous groups (members are interchangeable)
of four each. For each group, we asked that it both (a) be spread
across at least two racks, with no more than half the VMs on any one rack
and (b) have no two VMs on the same hypervisor. You can imagine how
this would involve multiple levels of grouping and relationships between
groups (and you will probably be surprised by the particulars). We
also included information on licensed products, so that the placement decision
can optimize license cost (for the IBM "sub-capacity" licenses,
placement of VMs can make a cost difference). Thus, multiple policies
per thing. We are now extending that example to include storage,
and we are also working examples with Hadoop.</font>
<br>
<br><font size="2" face="sans-serif">Regards,</font>
<br><font size="2" face="sans-serif">Mike</font>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">Gary Kotton <<a href="mailto:gkotton@vmware.com">gkotton@vmware.com</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">OpenStack Development
Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, </font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">09/11/2013 06:06 AM</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">Re: [openstack-dev]
[heat] Comments/questions on the instance-group-api-extension blueprint</font>
<br>
<hr noshade="">
<br>
<br>
<br>
<br>
<br><font size="2" face="Calibri"><b>From: </b>Mike Spreitzer <</font><a href="mailto:mspreitz@us.ibm.com"><font size="2" color="blue" face="Calibri"><u>mspreitz@us.ibm.com</u></font></a><font size="2" face="Calibri">><b><br>
Reply-To: </b>OpenStack Development Mailing List <</font><a href="mailto:openstack-dev@lists.openstack.org"><font size="2" color="blue" face="Calibri"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Calibri">><b><br>
Date: </b>Tuesday, September 10, 2013 11:58 PM<b><br>
To: </b>OpenStack Development Mailing List <</font><a href="mailto:openstack-dev@lists.openstack.org"><font size="2" color="blue" face="Calibri"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Calibri">><b><br>
Subject: </b>[openstack-dev] [heat] Comments/questions on the instance-group-api-extension
blueprint</font>
<br>
<br><font size="2" face="sans-serif">First, I'm a newbie here, wondering:
is this the right place for comments/questions on blueprints? Supposing
it is...</font>
<br>
<br><font size="2" face="Calibri">[Gary Kotton] Yeah, as Russel said this
is the correct place</font>
<br><font size="2" face="sans-serif"><br>
I am referring to </font><a href="https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension"><font size="2" color="blue" face="sans-serif"><u>https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension</u></font></a><font size="2" face="Calibri"><br>
</font><font size="2" face="sans-serif"><br>
In my own research group we have experience with a few systems that do
something like that, and more (as, indeed, that blueprint explicitly states
that it is only the start of a longer roadmap). I would like to highlight
a couple of differences that alarm me. One is the general overlap
between groups. I am not saying this is wrong, but as a matter of
natural conservatism we have shied away from unnecessary complexities.
The only overlap we have done so far is hierarchical nesting. As
the instance-group-api-extension explicitly contemplates groups of groups
as a later development, this would cover the overlap that we have needed.
On the other hand, we already have multiple "policies"
attached to a single group. We have policies for a variety of concerns,
so some can combine completely or somewhat independently. We also
have relationships (of various sorts) between groups (as well as between
individuals, and between individuals and groups). The policies and
relationships, in general, are not simply names but also have parameters.</font><font size="2" face="Calibri">
</font>
<br>
<br><font size="2" face="Calibri">[Gary Kotton] The instance groups was meant
to be the first step towards what we had presented in Portland. Please
look at the presentation that we gave an this may highlight what the aims
were: </font><a href="https://docs.google.com/presentation/d/1oDXEab2mjxtY-cvufQ8f4cOHM0vIp4iMyfvZPqg8Ivc/edit?usp=sharing"><font size="2" color="blue" face="Calibri"><u>https://docs.google.com/presentation/d/1oDXEab2mjxtY-cvufQ8f4cOHM0vIp4iMyfvZPqg8Ivc/edit?usp=sharing</u></font></a><font size="2" face="Calibri">.
Sadly for this release we did not manage to get the instance groups through
(it was an issue of timing and bad luck). We will hopefully get this though
in the first stages of the I cycle and then carry on building on it as
it has a huge amount of value for OpenStack. It will be great if you can
also participate in the discussions.</font>
<br><font size="2" face="sans-serif"><br>
Thanks,</font><font size="2" face="Calibri"> </font><font size="2" face="sans-serif"><br>
Mike</font><tt><font size="2">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size="2">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size="2"><br>
</font></tt>
<br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>