Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

2013-12-16 Thread Imre Farkas

On 12/13/2013 05:22 PM, James Slagle wrote:

On Fri, Dec 13, 2013 at 03:04:09PM +0100, Imre Farkas wrote:


One note to deploy: It's not done only by Heat and Nova. If we
expect a fully functional OpenStack installation as a result, we are
missing a few steps like creating users, initializing and
registering the service endpoints with Keystone. In TripleO this is
done by the init-keystone and setup-endpoints scripts. Check devtest
for more details: 
http://docs.openstack.org/developer/tripleo-incubator/devtest_undercloud.html


Excellent point Imre, as the deployment isn't really useable until those steps
are done.  The link to the overcloud setup steps is actually:
http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html
Very similar to what is done for the undercloud.


You are right, that's the correct link for the overcloud setup. However, 
I intentionally picked the one for the undercloud because I wanted to 
focus on the keystone configuration part and that's the same for the 
both (the init-keystone, setup-endpoints and keystone role-create 
workflow). There are some other stuff going on in the overcloud setup 
(eg. creating a vm for a user) which might distract those who are not 
familiar with devtest from what really is needed to deploy OpenStack. 
But it would have been better from me to note that the link is not for 
the overcloud.




I think most of that logic could be reimplemented to be done via direct calls
to the API using the client libs vs using a CLI.  Not sure about
keystone-manage pki_setup though, would need to look into that.



Yeah, we can put big part of the needed configuration steps into Tuskar 
as most of it just uses CLI client of Keystone which can be replaced by 
using the direct API calls of the same library. The rest might go to 
Heat or os-refresh-config or else.


Imre

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

2013-12-13 Thread Jaromir Coufal

Hey folks,

after a bit longer but very useful discussion about requirements (almost 
60 e-mails so far) I think we need to get to some conclusion what to 
deliver in Icehouse, what are the steps and what we should continue 
discussing to get better understanding for. Time is running mercilessly 
fast.


I think there was general agreement about need for TripleO's approach in 
the UI as well. We should start from simple use cases and add smartness 
and more functionality in time. I believe we all have consensus on this 
part and we should all get our focus here. Giving operator a full 
control over his deployment is under discussion for now - there are some 
fuzzy areas, so I think the solution here is to continue in this 
discussion in the meantime, get more feedback from operators and 
potential users so we get clearer vision of what exactly to get in. But 
it shouldn't block us at the moment.


Based on above mentioned, I propose two following Icehouse milestones:

*VERSION 0*
===
Enable user to deploy OpenStack with the simpliest TripleO way, no 
difference between hardware.


Target:
- end of icehouse-2

Features we need to get in:
- Enable manual nodes registration (Ironic)
- Get images available for user (Glance)
- Node roles (hardcode): Controller, Compute, Object Storage, Block Storage
- Design deployment (number of nodes per role)
- Deploy (Heat + Nova)


*VERSION 1*
===
Enable user to auto-discover his hardware, specify rules for roles and 
get OpenStack deployed based on those rules. Give user ability to 
monitor state of services and Nodes and to track issues easily.


Target:
- end of icehouse-3

Features we need to get in:
- Node-profiles (Nova-scheduler filters)
- Auto-discovery (Ironic)
- Monitoring (Ceilometer)

*VERSION 2*
===
... TBD based on how fast we can get previous mentioned features

I'd like to ask everybody to ACK or NACK proposed milestones and list of 
features, so that we have clear direction and free way to develop our 
solution. In case of NACK, please suggest clear alternative or solution 
since we need to move forward fast. Keep in mind that we have only about 
2 months left.


Fairly soon, I'd like to kick off discussion about future direction and 
next steps. But please, at the moment, let's keep focused on our current 
deliverables.


Thanks
-- Jarda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

2013-12-13 Thread Tzu-Mainn Chen
Nice list!  Questions and comments in-line:

- Original Message -
 Hey folks,
 
 after a bit longer but very useful discussion about requirements (almost
 60 e-mails so far) I think we need to get to some conclusion what to
 deliver in Icehouse, what are the steps and what we should continue
 discussing to get better understanding for. Time is running mercilessly
 fast.
 
 I think there was general agreement about need for TripleO's approach in
 the UI as well. We should start from simple use cases and add smartness
 and more functionality in time. I believe we all have consensus on this
 part and we should all get our focus here. Giving operator a full
 control over his deployment is under discussion for now - there are some
 fuzzy areas, so I think the solution here is to continue in this
 discussion in the meantime, get more feedback from operators and
 potential users so we get clearer vision of what exactly to get in. But
 it shouldn't block us at the moment.
 
 Based on above mentioned, I propose two following Icehouse milestones:
 
 *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?

 
 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?

 - Node roles (hardcode): Controller, Compute, Object Storage, Block Storage
 - Design deployment (number of nodes per role)

We're only allowing a single deployment, right?

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

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

 
 
 *VERSION 1*
 ===
 Enable user to auto-discover his hardware, specify rules for roles and
 get OpenStack deployed based on those rules. Give user ability to
 monitor state of services and Nodes and to track issues easily.
 
 Target:
 - end of icehouse-3
 
 Features we need to get in:
 - Node-profiles (Nova-scheduler filters)
 - Auto-discovery (Ironic)
 - Monitoring (Ceilometer)
 
 *VERSION 2*
 ===
 ... TBD based on how fast we can get previous mentioned features
 
 I'd like to ask everybody to ACK or NACK proposed milestones and list of
 features, so that we have clear direction and free way to develop our
 solution. In case of NACK, please suggest clear alternative or solution
 since we need to move forward fast. Keep in mind that we have only about
 2 months left.
 
 Fairly soon, I'd like to kick off discussion about future direction and
 next steps. But please, at the moment, let's keep focused on our current
 deliverables.
 
 Thanks
 -- Jarda
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

2013-12-13 Thread Tzu-Mainn Chen
Nice list!  Questions and comments in-line:

- Original Message -
 Hey folks,
 
 after a bit longer but very useful discussion about requirements (almost
 60 e-mails so far) I think we need to get to some conclusion what to
 deliver in Icehouse, what are the steps and what we should continue
 discussing to get better understanding for. Time is running mercilessly
 fast.
 
 I think there was general agreement about need for TripleO's approach in
 the UI as well. We should start from simple use cases and add smartness
 and more functionality in time. I believe we all have consensus on this
 part and we should all get our focus here. Giving operator a full
 control over his deployment is under discussion for now - there are some
 fuzzy areas, so I think the solution here is to continue in this
 discussion in the meantime, get more feedback from operators and
 potential users so we get clearer vision of what exactly to get in. But
 it shouldn't block us at the moment.
 
 Based on above mentioned, I propose two following Icehouse milestones:
 
 *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?

 
 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?

 - Node roles (hardcode): Controller, Compute, Object Storage, Block Storage
 - Design deployment (number of nodes per role)

We're only allowing a single deployment, right?

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

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

 
 
 *VERSION 1*
 ===
 Enable user to auto-discover his hardware, specify rules for roles and
 get OpenStack deployed based on those rules. Give user ability to
 monitor state of services and Nodes and to track issues easily.
 
 Target:
 - end of icehouse-3
 
 Features we need to get in:
 - Node-profiles (Nova-scheduler filters)
 - Auto-discovery (Ironic)
 - Monitoring (Ceilometer)
 
 *VERSION 2*
 ===
 ... TBD based on how fast we can get previous mentioned features
 
 I'd like to ask everybody to ACK or NACK proposed milestones and list of
 features, so that we have clear direction and free way to develop our
 solution. In case of NACK, please suggest clear alternative or solution
 since we need to move forward fast. Keep in mind that we have only about
 2 months left.
 
 Fairly soon, I'd like to kick off discussion about future direction and
 next steps. But please, at the moment, let's keep focused on our current
 deliverables.
 
 Thanks
 -- Jarda
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

2013-12-13 Thread Jaromir Coufal
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.


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.


-- Jarda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

2013-12-13 Thread Imre Farkas

On 12/13/2013 11:36 AM, Jaromir Coufal wrote:


*VERSION 0*
===
Enable user to deploy OpenStack with the simpliest TripleO way, no
difference between hardware.

Target:
- end of icehouse-2

Features we need to get in:
- Enable manual nodes registration (Ironic)
- Get images available for user (Glance)
- Node roles (hardcode): Controller, Compute, Object Storage, Block Storage
- Design deployment (number of nodes per role)
- Deploy (Heat + Nova)


One note to deploy: It's not done only by Heat and Nova. If we expect a 
fully functional OpenStack installation as a result, we are missing a 
few steps like creating users, initializing and registering the service 
endpoints with Keystone. In TripleO this is done by the init-keystone 
and setup-endpoints scripts. Check devtest for more details: 
http://docs.openstack.org/developer/tripleo-incubator/devtest_undercloud.html


Imre

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

2013-12-13 Thread James Slagle
On Fri, Dec 13, 2013 at 03:04:09PM +0100, Imre Farkas wrote:
 On 12/13/2013 11:36 AM, Jaromir Coufal wrote:
 
 *VERSION 0*
 ===
 Enable user to deploy OpenStack with the simpliest TripleO way, no
 difference between hardware.
 
 Target:
 - end of icehouse-2
 
 Features we need to get in:
 - Enable manual nodes registration (Ironic)
 - Get images available for user (Glance)
 - Node roles (hardcode): Controller, Compute, Object Storage, Block Storage
 - Design deployment (number of nodes per role)
 - Deploy (Heat + Nova)
 
 One note to deploy: It's not done only by Heat and Nova. If we
 expect a fully functional OpenStack installation as a result, we are
 missing a few steps like creating users, initializing and
 registering the service endpoints with Keystone. In TripleO this is
 done by the init-keystone and setup-endpoints scripts. Check devtest
 for more details: 
 http://docs.openstack.org/developer/tripleo-incubator/devtest_undercloud.html

Excellent point Imre, as the deployment isn't really useable until those steps
are done.  The link to the overcloud setup steps is actually:
http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html
Very similar to what is done for the undercloud.

I think most of that logic could be reimplemented to be done via direct calls
to the API using the client libs vs using a CLI.  Not sure about
keystone-manage pki_setup though, would need to look into that.

--
-- James Slagle
--

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

2013-12-13 Thread Jordan OMara

On 13/12/13 11:36 +0100, Jaromir Coufal wrote:

*VERSION 0*
===
Enable user to deploy OpenStack with the simpliest TripleO way, no  
difference between hardware.


Target:
- end of icehouse-2

Features we need to get in:
- Enable manual nodes registration (Ironic)
- Get images available for user (Glance)
- Node roles (hardcode): Controller, Compute, Object Storage, Block Storage
- Design deployment (number of nodes per role)
- Deploy (Heat + Nova)


Thanks for summarizing this Jarda!

I noticed one thing missing from the V0 list that we had talked about
earlier that seemed important. Copied below from an earlier doc:

retrieve node lists (Ironic + Nova + Heat?)
   management node(s) (awareness of the node)
   resource nodes, broken down by role
   unallocated nodes

This seems also important to include in v0.
--
Jordan O'Mara jomara at redhat.com
Red Hat Engineering, Raleigh 


pgpgJlPGEy1Tc.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev