[openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
Jaromir Coufal
jcoufal at redhat.com
Wed Sep 25 13:02:52 UTC 2013
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>
More information about the OpenStack-dev
mailing list