Open Stack

Hi Rob,

thank you very much for such valuable feedback, I really appreciate it. 
Few comments follow inline the text.

On 2013/25/09 03:50, Robert Collins wrote:
> 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.
ad extra attributes:
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)?

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.

> 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?
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:
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.
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.

> 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.
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.

> 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?
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?

> 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.
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?

> Similarly, it's a little weird that racks would have names.
Similar situation as nodes above.

> 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.
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.

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.

> 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.
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.
> HTH,
> Rob
>
> -Rob
I hope the answers helped at least somehow

Cheers,
-- Jarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130925/0fd79b0a/attachment.html>