Open Stack

> Quick note - I want to keep this discussion a bit high-level and not to
> get into big implementation details. For everyone, please, let's agree
> in this thread on the direction and approach and we can start follow-up
> threads with bigger details of how to get those things done.

I'm not sure how the items listed below are implementation details; they seem
like scoping the requirements to me.

> On 2013/13/12 12:04, Tzu-Mainn Chen wrote:
> >> *VERSION 0*
> >> ===========
> >> Enable user to deploy OpenStack with the simpliest TripleO way, no
> >> difference between hardware.
> >>
> >> Target:
> >> - end of icehouse-2
> >
> > My impression was that some of these features required features to be
> > developed in other
> > OpenStack services - if so, should we call those out so that we can see if
> > they'll be
> > available in the icehouse-2 timeframe?
> As for below listed features for v0 - it is the smallest set of what we
> have to have in the UI - if there is some delay in other services, we
> have to put attention there as well. But I don't think there is anything
> blocking us at the moment.
> 
> >> Features we need to get in:
> >> - Enable manual nodes registration (Ironic)
> >> - Get images available for user (Glance)
> >
> > Are we still providing the Heat template?  If so, are there image
> > requirements that we
> > need to take into account?
> I am not aware of any special requirements, but I will let experts to
> answer here...
> 
> >
> >> - Node roles (hardcode): Controller, Compute, Object Storage, Block
> >> Storage
> >> - Design deployment (number of nodes per role)
> >
> > We're only allowing a single deployment, right?
> Correct. For the whole Icehouse. I don't think we can get multiple
> deployments in time, there are much more important features.
> 
> >> - Deploy (Heat + Nova)
> >
> > What parameters are we passing in for deploy?  Is it limited to the # of
> > nodes/role, or
> > are we also passing in the image?
> I think it is # nodes/role and image as well. Though images might be
> hardcoded for the very first iteration. Soon we should be able to let
> user assign images to roles.
> 
> > Do we also need the following?
> >
> > * unregister a node in Ironic
> > * update a deployment (add or destroy instances)
> > * destroy a deployment
> > * view information about management node (instance?)
> > * list nodes/instances by role
> > * view deployment configuration
> > * view status of deployment as it's being deployed
> Some of that is part of above mentioned, some a bit later down the road
> (not far away though). We need all of that, but let's enable user to
> deploy first and we can add next features after we get something working
> then.

Well, these are requirements that I previously pulled from your wireframes
that aren't listed anywhere, so I don't know if they were forgotten, descoped,
or assumed to be part of release 0.  If it's assumed, I think it's important
that we call it out; otherwise, I'm not sure how we can appropriately evaluate
whether the feature list fits into the icehouse-2 timeframe.

I'm also not sure what we consider "needed".  To me, it seems like:

a) NEEDED
   * list nodes/instances by role

b) STANDARD (but possibly not needed?)
   * unregister a node
   * update a deployment
   * destroy a deployment
   * view status of deployment as it's being deployed

c) UNSURE
   * view information about a management node
   * view deployment configuration - I vaguely recall someone saying that it was 
important for the user to view the options being used when creating the overcloud,
even if those options were uneditable defaults.


Regarding the split in features between icehouse-2 and icehouse-3 - I'm not sure it makes sense.
We're re-architecting all of tuskar, and as such, I think it's more important to call out the
features we want for *all* of icehouse.  Otherwise, it's possible that we'll create an architecture
that works for icehouse-2 but which needs to be significantly reworked for icehouse-3.

For that reason, I think it might make more sense to work towards a single deadline within icehouse.


Mainn


> -- Jarda
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>