<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#333333">
Hi Rob,<br>
<br>
thank you very much for such valuable feedback, I really appreciate
it. Few comments follow inline the text.<br>
<br>
<div class="moz-cite-prefix">On 2013/25/09 03:50, Robert Collins
wrote:<br>
</div>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">A few quick notes.
Flavors need their extra attributes to be editable (e.g. architecture,
raid config etc) - particularly in the undercloud, but it's also
relevant for overcloud : If we're creating flavors for deployers, we
need to expose the full capabilities of flavors.
Secondly, if we're creating flavors for deployers, the UI should
reflect that: is it directly editing flavors, or editing the inputs to
the algorithm that creates flavors.</pre>
</blockquote>
ad extra attributes:<br>
Until now for POC we were dealing only with flavor definition values
and no extra attributes. Can you be please a bit more descriptive
about extra attributes or at least point me to some documentation
for it (for undercloud as well as overcloud flavors)?<br>
<br>
Flavors in the Tuskar UI is for deployers and it is a definition for
the algorithm that registers flavors in nova after a machine is
provisioned.<br>
<br>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">We seemed to have consensus @ the sprint in Seattle that Racks aren't
really Racks : that is that Rack as currently defined is more of a
logical construct (and some clouds may have just one), vs the actual
physical 'This is a Rack in a DC' aspect. If there is a physical thing
that the current logical Rack maps too, perhaps we should use that as
the top level UI construct?</pre>
</blockquote>
Well in ideal case we represent physical thing with logical grouping
of nodes. In this case we are able to operate with hardware in the
most efficient way. Of course we might end up that this is not
reality and we need to support it in the UI as well. But I don't
think I follow the idea with rack being the top level UI construct.
I think this depends on the point of view how you are looking at the
deployment. I think there are 2 ways of how deployer wants to see
his deployment:<br>
1) Hardware focus. Deployer is interested if his hardware is running
fine and everything is running correctly. In this case you are right
- the top level should be rack and it is rack in this moment.<br>
2) Service focus. Deployer is interested what service is he
providing, how much capacity he has available, left, in capacity
planning, etc. For this purpose we have resource classes, which are
defining what service you (as deployer) provide to your
customers/users.<br>
<br>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">The related thing is we need to expose the other things that also tend
to map failure domains - shared switches, power bars, A/C - but that
is future work I believe.</pre>
</blockquote>
In general I don't think that it is good idea to replicate other
applications for DC monitoring, which already exist and we would
only put effort to their duplication. I mean if we can get general
information about switches, etc, yes that would be great, but I
would recommend to make distinction between deployment management
and DC monitoring.<br>
<br>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">The 'add rack' thing taking a list of MACs seems odd : a MAC address
isn't enough to deploy even a hardware inventory image to (you need
power management details + CPU arch + one-or-more MACs to configure
TFTP and PXE enough to do a detailed automatic inventory). Long term
I'd like to integrate with the management network switch, so we can
drive the whole thing automatically, but in the short term, I think we
want to drive folk to use the API for mass enrollment. What do you
think?</pre>
</blockquote>
So for the short term we were counting with some sort of
auto-discovery which means with minimal input from user PXE boot
some minimal image, do the introspection of the machine and fill all
the details for user. But you are right, that only MAC address isn't
enough. What I think will be needed are power management credentials
(currently support for IPMI - so the MAC address /or IP/, IPMI
username and IPMI password). I believe all other information can be
introspected (in short term). What do you think?<br>
<br>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">Regardless, the node list will need to deal with nodes having N MAC
addresses and management credentials, not just a management IP.
Lastly, whats node name for? Instances [may] have names, but I don't
see any reason for nodes to have a name.</pre>
</blockquote>
I believe that node name will be mac address by default (in majority
cases). There was idea about having possibility to rename the node
for deployers' needs if they need better recognition. Let's imagine
that we have a rack with mixed hardware, each node running different
services, if we rename those few nodes with for example name of
services they are running (or any purpose they are doing), then for
the first glance, I as deployer have better overview about what my
rack contains and where it is located. Do you see the use case
there?<br>
<br>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">Similarly, it's a little weird that racks would have names.</pre>
</blockquote>
Similar situation as nodes above.<br>
<br>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">CSV uploads stand out to me as an odd thing: JSON is the standard
serialisation format we use, does using CSV really make sense? Tied
into that is the question above - does it make sense to put bulk
enrollment in the web UI at all, or would it be better to just have
prerolled API scripts for that? Having 'upload racks' etc as a UI
element is right in the users face, but will be used quite rarely.</pre>
</blockquote>
I agree. As for CSV file, I am not convinced, JSON might work here.
I think it depends on the end users what format they are used to.<br>
<br>
As for the UI usage, you are completely right, that it it's not the
hottest feature and we shouldn't be focusing on that as top
priority. However, talking about medium deployments, consider
operator who is going to deploy 3 racks each consisted of 16 nodes.
It's 48 machines to which you need to enter details at once.
Thinking about minimal number of 3 text fields which need to be
entered for each node (ipmi mac + user + passw) we have 144 fields
to be filled in total. I believe that bulk enrollment for nodes (not
necessarily racks) will be needed.<br>
<br>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">I don't follow why racks would be bound to classes: class seems to be
an aspect of a specific machine + network capacity configuration, but
Rack is a logical not physical construct, so it's immediately
decoupled from that. Perhaps it's a keep-it-simple thing, which I can
get behind - but in that case, reducing the emphasis on Rack /
renaming Rack becomes more important IMO.</pre>
</blockquote>
As for the classes - in class you are actually defining the service
which you are going to provide. So let's say that I am going to
provide compute service, I need to specify flavors and at least some
SLA. The SLA would be assured with some vCPU performance, network
bandwidth, etc. All of these happens on the level of class. So that
I define for example m1 class, which is providing 5 flavors (tiny,
small, medium, large, x-large), it assures certain vCPU performance
and minimum network throughput. To assure this performance I need to
be sure that the service is running on the correct type of hardware
(which I specify in the class as well). Now I have defined service,
so what I do, I add resources which are going to run this type of
service (assigning racks/nodes to the resource class). At this point
I am able to monitor the whole capacity of compute service which I
am providing. I can see total capacity, current usage, free space,
expectations when I am going out of resources. I can do planning for
the future and if I expand my resources by new hardware, I buy
similar type of hardware and just add it to the class - no need for
additional settings - very smooth way for scaling up. In conclusion
I see lot of advantages in classes, mostly from service point of
view.<br>
<blockquote
cite="mid:CAJ3HoZ2RZfMGw2OMG5TLUpvvg=3zCMY2_muoto4-XfKJXXicGA@mail.gmail.com"
type="cite">
<pre wrap="">HTH,
Rob
-Rob
</pre>
</blockquote>
I hope the answers helped at least somehow<br>
<br>
Cheers,<br>
-- Jarda<br>
</body>
</html>