<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Sylvain,<br>
<br>
We are currently working on design docs. We'll be adding some
architecture diagrams and description to our documentation soon.<br>
<br>
To answer your question re: provisioning and images.<br>
<br>
In our currently implementation (which is very early days), we
took images that were built from by Triple O, namely the overcloud
non-compute and compute images and we use these directly. in the
demo environment you seen in the video, we used Triple O CI to set
up the machine, register the relevant overcloud images with glance
and so on.<br>
<br>
In Tuskar, we lifted from TripleO a copy of the triple-o overcloud
heat template and made some modifications. We split out the
non-compute and compute sections, this allows us to add multiple
entries of each of the non-compute and compute sections (based on
what is registered in Tuskar) we then add a section to enforce
deployment of the particular images onto particular bare metal
machines. (This allows us to match hardware to OpenStack
services). We do this by using the force_hosts capability in the
nova bare metal driver:
<a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/nova/+spec/baremetal-force-node">https://blueprints.launchpad.net/nova/+spec/baremetal-force-node</a>.<br>
<br>
We also add some extra commands to the Heat template to registers
flavors and associates the flavors, host aggregates and baremetal
nodes in the overcloud nova control instance. This allows us to
tell the nova scheduler to match any instance requests with
flavors that were registered with a resource class in Tuskar with
particular hardware that has also been added to that resource
class.<br>
<br>
As Tomas mentioned, our initial release is really just a Proof of
Concept. We'll be working to add more complex features and
probably rework much of our "short cuts". Our aim though is to
contribute as much as possible (or as much that makes sense) of
Tuskar upstream into TripleO or any other component that we
utilize and extend and have Tuskar really concentrate on how to
utilize existing components to manage and deploy an OpenStack at
large scale.<br>
<br>
Regards<br>
Martyn<br>
<br>
<br>
On 21/08/13 16:15, Sylvain Bauza wrote:<br>
</div>
<blockquote cite="mid:5214D996.3020306@bull.net" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div class="moz-cite-prefix">Hi Tomas,<br>
<br>
Are there any design docs which could explain how you provision
the baremetal hosts ?<br>
As far as I can see, it seeems you're relying on TripleO heat
templates, right ?<br>
<br>
Are you then using disk-image-builder ?<br>
<br>
Thanks,<br>
-Sylvain<br>
<br>
PS : I just looked at the Youtube demo <a
moz-do-not-send="true"
href="https://www.youtube.com/watch?v=VEY035-Lyzo">https://www.youtube.com/watch?v=VEY035-Lyzo</a><br>
<br>
<br>
Le 21/08/2013 14:32, Tomas Sedovic a écrit :<br>
</div>
<blockquote cite="mid:5214B34D.2090203@redhat.com" type="cite">Hi
everyone, <br>
<br>
We would like to announce Tuskar, an OpenStack management
service. <br>
<br>
Our goal is to provide an API and UI to install and manage
OpenStack at larger scale: where you deal with racks, different
hardware classes for different purposes (storage, memory vs.
cpu-intensive compute), the burn-in process, monitoring the HW
utilisation, etc. <br>
<br>
Some of this will overlap with TripleO, Ceilometer and possibly
other projects. In that case, we will work with the projects to
figure out the best place to fix rather than duplicating effort
and playing in our own sandbox. <br>
<br>
<br>
Current status: <br>
<br>
There's a saying that if you're not embarrassed by your first
release, you've shipped too late. <br>
<br>
I'm happy to say, we are quite embarrassed :-) <br>
<br>
We've got a prototype that allows us to define different
hardware classes and provision the racks with the appropriate
images, then add new racks and have them provisioned. <br>
<br>
We've got a Horizon dashboard plugin that shows the general
direction we want to follow and we're looking into integrating
Ceilometer metrics and alarms. <br>
<br>
However, we're still tossing around different ideas and things
are very likely to change. <br>
<br>
Our repositories are on Stackforge: <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/stackforge/tuskar">https://github.com/stackforge/tuskar</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/stackforge/python-tuskarclient">https://github.com/stackforge/python-tuskarclient</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/stackforge/tuskar-ui">https://github.com/stackforge/tuskar-ui</a>
<br>
<br>
And we're using Launchpad to manage our bugs and blueprints: <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://launchpad.net/tuskar">https://launchpad.net/tuskar</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://launchpad.net/tuskar-ui">https://launchpad.net/tuskar-ui</a>
<br>
<br>
If you want to talk to us, pop in the #tuskar IRC channel on
Freenode or send an email to <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openstack-dev@lists.launchpad.net">openstack-dev@lists.launchpad.net</a>
with "[Tuskar]" in the subject. <br>
<br>
<br>
PTL: <br>
<br>
Talking to OpenStack developers, we were advised to elect the
PTL early. <br>
<br>
Since we're nearing the end of the Havana cycle, we'll elect the
PTL for a slightly longer term -- the rest of Havana and
throughout Icehouse. The next election will coincide with those
of the official OpenStack projects. <br>
<br>
If you are a Tuskar developer and want to nominate yourself,
please send an email to <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openstack-dev@lists.launchpad.net">openstack-dev@lists.launchpad.net</a>
with subject "Tuskar PTL candidacy". <br>
<br>
The self-nomination period will end on Monday, 26th August 2013,
23:59 UTC. <br>
<br>
<br>
-- <br>
Tomas Sedovic <br>
<br>
_______________________________________________ <br>
OpenStack-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>