Open Stack

----- 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, these are gone now, in favor of Tuskar interacting directly with
> > Ironic, Heat, etc.
> 
> Hmm, not quite.
> 
> If compare the models in Ironic [1] to Tuskar's (link above), there are
> some dramatic differences. Notably:
> 
> * No Rack model in Ironic. Closest model seems to be the Chassis model
> [2], but the Ironic Chassis model doesn't have nearly the entity
> specificity that Tuskar's Rack model has. For example, the following
> (important) attributes are missing from Ironic's Chassis model:
>  - slots (how does Ironic know how many RU are in a chassis?)
>  - location (very important for integration with operations inventory
> management systems, trust me)
>  - subnet (based on my experience, I've seen deployers use a
> rack-by-rack or paired-rack control and data plane network static IP
> assignment. While Tuskar's single subnet attribute is not really
> adequate for describing production deployments that typically have 3+
> management, data and overlay network routing rules for each rack, at
> least Tuskar has the concept of networking rules in its Rack model,
> while Ironic does not)
>  - state (how does Ironic know whether a rack is provisioned fully or
> not? Must it query each each Node's powr_state field that has a
> chassis_id matching the Chassis' id field?)
>  -
> * The Tuskar Rack model has a field "chassis_id". I have no idea what
> this is... or its relation to the Ironic Chassis model.
> 
> 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.
> 
> 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.

Mainn

> Best,
> -jay
> 
> [1]
> https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/models.py
> [2]
> https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/models.py#L83
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>