On Sun Dec 1 00:27:30 2013, Tzu-Mainn Chen wrote:
I think it's far more important that we list out requirements and
create a design document that people agree upon first. Otherwise, we
run the risk of focusing on feature X for release 1 without ensuring
that our architecture supports
On 01/12/13 00:27 -0500, Tzu-Mainn Chen wrote:
I think we may all be approaching the planning of this project in the wrong way, because of confusions such as:
Well, I think there is one small misunderstanding. I've never said that
manual way should be primary workflow for us. I agree that we
I think we may all be approaching the planning of this project in the wrong
way, because of confusions such as:
Well, I think there is one small misunderstanding. I've never said that
manual way should be primary workflow for us. I agree that we should lean
toward as much automation and
On 2013/28/11 06:41, Robert Collins wrote:
Certainly. Do we have Personas for those people? (And have we done any
validation of them?)
We have shorter paragraph to each. But not verified by any survey, so we
don't have very solid basis in this area right now and I believe we all
are trying to
Hello,
just few notes from me:
https://etherpad.openstack.org/p/tripleo-feature-map sounds like a great
idea, we should go through them one by one maybe on meeting.
We should agree on what is doable for I, without violating the Openstack
way in some very ugly way. So do we want to be
Hi Mark,
thanks for your insight, I mostly agree. Just few points below.
On 2013/27/11 21:54, Mark McLoughlin wrote:
Hi Jarda,
...
Yes, I buy this. And I think it's the point worth dwelling on.
It would be quite a bit of work to substantiate the point with hard data
- e.g. doing user
On 2013/27/11 16:37, James Slagle wrote:
On Wed, Nov 27, 2013 at 8:39 AM, Jaromir Coufal jcou...@redhat.com wrote:
V0: basic slick installer - flexibility and control first
- enable user to auto-discover (or manual register) nodes
- let user decide, which node is going to be controller, which
Hi all,
just a few thoughts (subjective opinions) regarding the whole debate:
* I think that having a manually picking images for machines approach
would make TripleO more usable in the beginning. I think it will take a
good deal of time to get our smart solution working with the admin
On 2013/27/11 00:00, Robert Collins wrote:
On 26 November 2013 07:41, Jaromir Coufal jcou...@redhat.com wrote:
Hey Rob,
can we add 'Slick Overcloud deployment through the UI' to the list? There
was no session about that, but we discussed it afterwords and agreed that it
is high priority for
On Wed, Nov 27, 2013 at 8:39 AM, Jaromir Coufal jcou...@redhat.com wrote:
V0: basic slick installer - flexibility and control first
- enable user to auto-discover (or manual register) nodes
- let user decide, which node is going to be controller, which is going to
be compute or storage
-
Hi Jarda,
On Wed, 2013-11-27 at 14:39 +0100, Jaromir Coufal wrote:
I think here is the main point where I disagree and which leads to
different approaches. I don't think, that user of TripleO cares *only*
about deploying infrastructure without any knowledge where the things
go. This is
On 26 November 2013 07:41, Jaromir Coufal jcou...@redhat.com wrote:
Hey Rob,
can we add 'Slick Overcloud deployment through the UI' to the list? There
was no session about that, but we discussed it afterwords and agreed that it
is high priority for Icehouse as well.
I just want to keep it
Hey Rob,
can we add 'Slick Overcloud deployment through the UI' to the list?
There was no session about that, but we discussed it afterwords and
agreed that it is high priority for Icehouse as well.
I just want to keep it on the list, so we are aware of that.
Thanks
-- Jarda
On 2013/25/11
I've now gone through and done the post summit cleanup of blueprints
and migration of design docs into blueprints as appropriate.
We had 50 odd blueprints, many of where were really not effective
blueprints - they described single work items with little coordination
need, were not changelog
14 matches
Mail list logo
