<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 1, 2013 at 12:39 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Excerpts from Alexander Kuznetsov's message of 2013-10-31 10:51:54 -0700:<br>
<div>> Hi Heat, Savanna and Trove teams,<br>
><br>
> All this projects have common part related to software configuration<br>
> management. For creation, an environment user should specify a hardware<br>
> parameter for vms: choose flavor, decide use cinder or not, configure<br>
> networks for virtual machines, choose topology for hole deployment. Next<br>
> step is linking of software parameters with hardware specification. From<br>
> the end user point of view, existence of three different places and three<br>
> different ways (HEAT Hot DSL, Trove clustering API and Savanna Hadoop<br>
> templates) for software configuration is not convenient, especially if user<br>
> want to create an environment simultaneously involving components from<br>
> Savanna, Heat and Trove.<br>
><br>
<br>
</div>I'm having a hard time extracting the problem statement. I _think_ that<br>
the problem is:<br>
<br>
As a user I want to tune my software for my available hardware.<br>
<br>
So what you're saying is, if you select a flavor that has 4GB of RAM<br>
for your application, you want to also tell your application that it<br>
can use 3GB of RAM for an in-memory cache. Likewise, if one has asked<br>
Trove for an 8GB flavor, they will want to tell it to use 6.5GB of RAM<br>
for InnoDB buffer cache.<br>
<br>
What you'd like to see is one general pattern to express these types<br>
of things?<br></blockquote><div>Exactly. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
> I can suggest two approaches to overcome this situations:<br>
><br>
> Common library in oslo. This approach allows a deep domain specific<br>
> customization. The user will still have 3 places with same UI where user<br>
> should perform configuration actions.<br>
><br>
> Heat or some other component for software configuration management. This<br>
> approach is the best for end users. In feature possible will be some<br>
> limitation on deep domain specific customization for configuration<br>
> management.<br>
<br>
</div>Can you maybe be more concrete with your proposed solutions? The lack<br>
of a clear problem statement combined with these vague solutions has<br>
thoroughly confused me.<br>
<div><div><br><br></div></div></blockquote>Sure. I suggest creating a some library or component for standardization of software and hardware configuration. It will contain a validation logic and parameters lists.<br>
<br>Now Trove, Savanna and Heat all have part related to hardware configuration. For end user, VMs description should not depend on component where it will be used.<br><br>Here is an example of VM description which could be common for Savanna and Trove:<br>
<br>{<br> flavor_id: 42,<br> image_id: ”test”,<br> volumes: [{<br> # extra contains a domain specific parameters.<br> # For instance aim for Savanna<br> # could be hdfs-dir or mapreduce-dir.<br> # For trove: journal-dir or db-dir.<br>
extra: {<br> aim: hdfs-dir<br> },<br> size: 10GB,<br> filesystem: ext3<br> },{<br> extra: {<br> aim: mapreduce-dir<br> },<br> size: 5GB,<br> filesystem: ext3<br>
}]<br> networks: [{<br> private-network: some-private-net-id,<br> public-network: some-public-net-id<br> }]<br><br><br>Also, it will be great if this library or component will standardize some software configuration parameters, like a credential for database or LDAP. This greatly simplify integration between different components. For example if user want process data on Hadoop from Cassandra, user should provide a database location and credentials to Hadoop. If we have some standard for both Trove and Savanna, it can be done the same way in both components. An example for Cassandra could look like that:<br>
<br><br>{<br> type: cassandra,<br> host: <a href="http://example.com" target="_blank">example.com</a>,<br> port: 1234,<br> credentials: {<br> user: ”test”,<br> password: ”123”<br> }<br>}<br><br><br>This parameters names and schema should be the same for different components referencing a Cassandra server. <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div>____________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>