[openstack-dev] [TripleO][Tuskar] Domain Model Locations
tzumainn at redhat.com
Thu Jan 9 22:46:50 UTC 2014
----- 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, do we need to
> > > consider these now too?
> > >
> > > :
> > > 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  to Tuskar's (link above), there are
> some dramatic differences. Notably:
> * No Rack model in Ironic. Closest model seems to be the Chassis model
> , 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.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev