On Thu, 2014-01-16 at 20:59 -0800, Clint Byrum wrote:
Excerpts from Jay Pipes's message of 2014-01-12 11:40:41 -0800:
On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:
So, it's not as simple as it may initially seem :)
Ah, I should have been clearer in my statement - my
Hi Jay,
Awesome. I'll just add quick note inline (and sorry for smaller delay):
On 2014/09/01 18:22, Jay Dobies wrote:
I'm trying to hash out where data will live for Tuskar (both long term
and for its Icehouse deliverables). Based on the expectations for
Icehouse (a combination of the
On 2014/12/01 20:40, Jay Pipes wrote:
On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:
So, it's not as simple as it may initially seem :)
Ah, I should have been clearer in my statement - my understanding is that
we're scrapping concepts like Rack entirely.
That was my understanding as
On Thu, 2014-01-16 at 11:25 +0100, Jaromir Coufal wrote:
On 2014/12/01 20:40, Jay Pipes wrote:
On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:
So, it's not as simple as it may initially seem :)
Ah, I should have been clearer in my statement - my understanding is that
we're
Excerpts from Jay Pipes's message of 2014-01-12 11:40:41 -0800:
On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:
So, it's not as simple as it may initially seem :)
Ah, I should have been clearer in my statement - my understanding is that
we're scrapping concepts like Rack
Excellent write up Jay.
I don't actually know the answer. I'm not 100% bought into the idea that
Tuskar isn't going to store any information about the deployment and
will rely entirely on Heat/Ironic as the data store there. Losing this
extra physical information may be a a strong reason why
On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:
So, it's not as simple as it may initially seem :)
Ah, I should have been clearer in my statement - my understanding is that
we're scrapping concepts like Rack entirely.
That was my understanding as well. The existing Tuskar domain
Thanks Jay, this is a very useful summary! Some comments inline:
On 01/09/2014 06:22 PM, Jay Dobies wrote:
I'm trying to hash out where data will live for Tuskar (both long term
and for its Icehouse deliverables). Based on the expectations for
Icehouse (a combination of the wireframes and
Thanks for the feedback :)
= Stack =
There is a single stack in Tuskar, the overcloud.
A small nit here: in the long term Tuskar will support multiple overclouds.
Yes, absolutely. I should have added For Icehouse like I did in other
places. Good catch.
There's few pieces of concepts
As much as the Tuskar Chassis model is lacking compared to the Tuskar
Rack model, the opposite problem exists for each project's model of
Node. In Tuskar, the Node model is pretty bare and useless, whereas
Ironic's Node model is much richer.
Thanks for looking that deeply into it :)
So, it's
On 01/10/2014 04:27 PM, Jay Dobies wrote:
Thanks for the feedback :)
= Stack =
There is a single stack in Tuskar, the overcloud.
A small nit here: in the long term Tuskar will support multiple
overclouds.
Yes, absolutely. I should have added For Icehouse like I did in other
places. Good
On Fri, Jan 10, 2014 at 10:27 AM, Jay Dobies jason.dob...@redhat.com wrote:
There's few pieces of concepts which I think is missing from the list:
- overclouds: after Heat successfully created the stack, Tuskar needs to
keep track whether it applied the post configuration steps (Keystone
On Fri, Jan 10, 2014 at 11:01 AM, Imre Farkas ifar...@redhat.com wrote:
On 01/10/2014 04:27 PM, Jay Dobies wrote:
There's few pieces of concepts which I think is missing from the list:
- overclouds: after Heat successfully created the stack, Tuskar needs to
keep track whether it applied the
I'm trying to hash out where data will live for Tuskar (both long term
and for its Icehouse deliverables). Based on the expectations for
Icehouse (a combination of the wireframes and what's in Tuskar client's
api.py), we have the following concepts:
= Nodes =
A node is a baremetal machine on
Thanks! This is very informative. From a high-level perspective, this
maps well with my understanding of how Tuskar will interact with various
OpenStack services. A question or two inline:
- Original Message -
I'm trying to hash out where data will live for Tuskar (both long term
and
The UI will also need to be able to look at the Heat resources running
within the overcloud stack and classify them according to a resource
category. How do you envision that working?
There's a way in a Heat template to specify arbitrary metadata on a
resource. We can add flags in there and
I'm glad we are hashing this out as I think there is still some debate
around if Tuskar will need a database at all.
One thing to bear in mind, I think we need to make sure the terminology
matches that described in the previous thread. I think it mostly does
here but I'm not sure the Tuskar
- Original Message -
I'm glad we are hashing this out as I think there is still some debate
around if Tuskar will need a database at all.
One thing to bear in mind, I think we need to make sure the terminology
matches that described in the previous thread. I think it mostly does
On Thu, 2014-01-09 at 16:02 -0500, Tzu-Mainn Chen wrote: There are a
number of other models in the tuskar code[1], do we need to
consider these now too?
[1]:
https://github.com/openstack/tuskar/blob/master/tuskar/db/sqlalchemy/models.py
Nope, these are gone now, in favor of Tuskar
- Original Message -
On Thu, 2014-01-09 at 16:02 -0500, Tzu-Mainn Chen wrote: There are a
number of other models in the tuskar code[1], do we need to
consider these now too?
[1]:
https://github.com/openstack/tuskar/blob/master/tuskar/db/sqlalchemy/models.py
Nope,
- Original Message -
The UI will also need to be able to look at the Heat resources running
within the overcloud stack and classify them according to a resource
category. How do you envision that working?
There's a way in a Heat template to specify arbitrary metadata on a
21 matches
Mail list logo