<div dir="ltr">I wouldn't like to use foreman for the entire solution because I believe OpenStack is the future and I prefer treating OpenStack as the focal point and foreman as bare metal workaround until TripleO or Ironic will be out for production.<div>
Foreman will also be used for the post install requirements. For example, I just want to reuse the existing client in different setup and update some software version.</div><div><br></div><div>Using only Foreman's API will make it harder to fully integrate with OpenStack lifecycle solution in the future.</div>
<div>Another big advantage of OpenStack is it's python SDK.</div><div><br></div><div>As for the Foreman's discovery process you have mentioned, Do i have to delete them from Foreman or can i just query for facts and send them for new PXE install on demand (by mac or something)?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 31, 2014 at 9:03 PM, Matt Jarvis <span dir="ltr"><<a href="mailto:matt.jarvis@datacentred.co.uk" target="_blank">matt.jarvis@datacentred.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Foreman supports both bare metal and Openstack provisioning, so you could use the Foreman API to achieve all of this. Off the top of my head, for bare metal you'd use the foreman discovery plugin so that non-configured hosts are available as discovered hosts, get a list of hosts available in discovered state, provision and use them for tests, then once you've finished with them, delete them from Foreman and reboot so that they come back into the discovered hosts pool. For Openstack hosts you can do the whole lifecycle management piece through the Foreman API. </div>
<div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On 31 May 2014 14:42, Avi Tal <span dir="ltr"><<a href="mailto:avi3tal@gmail.com" target="_blank">avi3tal@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Alex,<div>First of all, Thanks for the excellent answer. Indeed I'll be participating the event in Israel. It will be cool to meet face-to-face and discuss these scenarios.</div><div><br></div><div>
Thanks</div>
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Sat, May 31, 2014 at 12:40 PM, Alex Glikson <span dir="ltr"><<a href="mailto:GLIKSON@il.ibm.com" target="_blank">GLIKSON@il.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">Hi Avi,</font>
<br>
<br><font face="sans-serif">This is a very interesting use-case.
We have been experimenting internally with similar ideas (dynamic management
of virtualized and bare-metal resources).</font>
<br><font face="sans-serif">In a nutshell, you can use Heat templates
to provision the different environments. For bare-metal, you can configure
Nova to surface bare-metal flavors (with nova-baremetal driver underneath),
mapped to a dedicated host aggregate comprising bare-metal machines. You
can construct bare-metal images with diskimage-buidler from the TripleO
project.</font>
<br><font face="sans-serif">If you don't have non-trivial networking
requirements (e.g., can work with a single flat network), things might
work pretty much out of the box.</font>
<br><font face="sans-serif">Things would get a bit more complicated
if you want to dynamically re-purpose physical nodes between virtualized
and bare-metal workloads. Depending on the nature of your workloads (e.g.,
your ability to predict the desired size of each pool), you may consider
using something like Heat auto-scaling to drive the outer control loop
(but it might require some code changes to work properly in this case).
Alternatively, this logic can be external, invoking Heat for provisioning
(you can also use Heat + nova-baremetal + TripleO tools to provision compute
nodes themselves).</font>
<br><font face="sans-serif">There are many nuances to make it work,
but with certain simplifying assumptions it seems feasible to come up with
a 'native' OpenStack solution, with minimal amount of custom code.</font>
<br>
<br><font face="sans-serif">Regards,</font>
<br><font face="sans-serif">Alex</font>
<br>
<br><font face="sans-serif">P.S. we are going to present some related
work at the OpenStack Israel event on Monday - we can follow-up face-to-face
if you plan to be there too.</font>
<br>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">Avi Tal <<a href="mailto:avi3tal@gmail.com" target="_blank">avi3tal@gmail.com</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif"><a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>,
</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">31/05/2014 11:34 AM</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">[Openstack]
Integration with OpenStack</font>
<br>
<hr noshade><div><div>
<br>
<br>
<br><font size="3">Hi all,</font>
<br><font size="3">I am designing a "Dynamic Resource Allocation"
for my company lab resources. The focal point of this solution should be
OpenStack.</font>
<br>
<br><font size="3"><b>Background:</b></font>
<br><font size="3">The testing and dev environments are built out of multiple
nodes. Servers, clients. Some could be virtual but must support also bare-metal.</font>
<br><font size="3">The goal is to manage the resource pool (both virtual
and physical) dynamically. Let the automated test request for specific
environment by posting the environment details and release it back to pool
at the end of the test.</font>
<br>
<br><font size="3"><b>Example:</b></font>
<br>
<br><font size="3"><b>Request:</b></font>
<br><font size="3">client:</font>
<br><font size="3"> count: 2</font>
<br><font size="3"> type: virtual</font>
<br><font size="3"> os: fedora 20</font>
<br><font size="3"> memory: 2GB</font>
<br><font size="3"> cpu: 4</font>
<br><font size="3"> disk: >200G</font>
<br><font size="3"> packages: ['puppet', 'fio', 'python-2.7']</font>
<br><font size="3">client:</font>
<br><font size="3"> count: 4</font>
<br><font size="3"> type: physical</font>
<br><font size="3"> os: centos-6.5</font>
<br><font size="3"> memory: 2GB</font>
<br><font size="3"> cpu: 4</font>
<br><font size="3"> disk: >100G flash</font>
<br><font size="3"> packages: ['puppet', 'fio', 'python-2.7']</font>
<br><font size="3">server:</font>
<br><font size="3"> count: 2</font>
<br><font size="3"> type: physical</font>
<br><font size="3"> os: centos-6.5</font>
<br><font size="3"> build: 'b10'</font>
<br>
<br><font size="3"><b>Response:</b></font>
<br><font size="3">clients:</font>
<br><font size="3"> </font><a href="http://client1.domain.com/" target="_blank"><font size="3" color="blue"><u>client1.domain.com</u></font></a><font size="3">:</font>
<br><font size="3"> address: 1.1.1.1</font>
<br><font size="3"> user: root</font>
<br><font size="3"> password: 123456</font>
<br><font size="3"> os: fedora-20</font>
<br><font size="3"> </font><a href="http://client2.domain.com/" target="_blank"><font size="3" color="blue"><u>client2.domain.com</u></font></a><font size="3">:</font>
<br><font size="3"> address: 2.2.2.2</font>
<br><font size="3"> user: root</font>
<br><font size="3"> password: 123456</font>
<br><font size="3"> os: fedora-20</font>
<br><font size="3"> </font><a href="http://client3.domain.com/" target="_blank"><font size="3" color="blue"><u>client3.domain.com</u></font></a><font size="3">:</font>
<br><font size="3"> address: 3.3.3.3</font>
<br><font size="3"> user: root</font>
<br><font size="3"> password: 123456</font>
<br><font size="3"> os: centos-6.5</font>
<br><font size="3">...</font>
<br><font size="3">servers:</font>
<br><font size="3"> </font><a href="http://server1.domain.com/" target="_blank"><font size="3" color="blue"><u>server1.domain.com</u></font></a><font size="3">:</font>
<br><font size="3"> address: 10.10.10.10</font>
<br><font size="3"> user: root</font>
<br><font size="3"> password: 123456</font>
<br><font size="3"> </font><a href="http://server2.domain.com/" target="_blank"><font size="3" color="blue"><u>server2.domain.com</u></font></a><font size="3">:</font>
<br><font size="3"> address: 1.1.1.1</font>
<br><font size="3"> user: root</font>
<br><font size="3"> password: 123456</font>
<br>
<br>
<br>
<br>
<br><font size="3"><b>I could think of two solutions:</b></font>
<br><font size="3">1. develop my own layer and use OpenStack just for the
provisioning layer using the API and Foreman for bare-metal, puppet interface,
lab services configuration (dns, dhcp, pxe etc') and searching engine via
facts across entire resources (virtual and physical).</font>
<br><font size="3">2. develop an OpenStack component that integrate with
keystone, nova, horizon and implement my own business layer.</font>
<br>
<br>
<br><font size="3"><b>My questions:</b></font>
<br><font size="3">1. Is there any way of actually implement my second solution?
any documentation for writing new OpenStack component?</font>
<br><font size="3">2. I think that my scenario is common and this solution
could be helping many other companies. Is there any OpenStack project that
solve it?</font>
<br><font size="3">3. How can i offer it to OpenStack as a new component?</font>
<br>
<br><font size="3">I would be thankful for any help and comments</font>
<br>
<br><font size="3">Thanks </font>
<br>
<br>
<br>
<br>
<br>
<br><font size="3">-- </font>
<br></div></div><font size="3" face="sans-serif"><b>Avi Tal</b></font><tt><font>_______________________________________________<br>
Mailing list: </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</font></tt></a><tt><font><br>
Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</font></tt></a><tt><font><br>
</font></tt>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div dir="ltr"><b><font face="'comic sans ms', sans-serif">Avi Tal</font></b></div>
</font></span></div>
<br>_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div dir="ltr">Matt Jarvis<div>Head of Cloud Computing<br>DataCentred</div><div>Office: <a href="tel:%28%2B44%290161%208703985" value="+441618703985" target="_blank">(+44)0161 8703985</a><br>
Mobile: <a href="tel:%28%2B44%2907983%20725372" value="+447983725372" target="_blank">(+44)07983 725372</a></div><div>Email: <a href="mailto:matt.jarvis@datacentred.co.uk" target="_blank">matt.jarvis@datacentred.co.uk</a></div>
<div>Website: <a href="http://www.datacentred.co.uk" target="_blank">http://www.datacentred.co.uk</a></div></div>
</div>
<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">DataCentred Limited registered in England and Wales no. 05611763</span></blockquote></div><br><br clear="all"><div><br></div>
-- <br><div dir="ltr"><b><font face="'comic sans ms', sans-serif">Avi Tal</font></b></div>
</div>