----- 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev