[openstack-dev] [TripleO][Tuskar] Domain Model Locations

Jay Pipes jaypipes at gmail.com
Thu Jan 9 21:42:14 UTC 2014

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 :)



More information about the OpenStack-dev mailing list