Open Stack

On Sun Dec  1 00:27:30 2013, Tzu-Mainn Chen wrote:

> I think it's far more important that we list out requirements and
> create a design document that people agree upon first.  Otherwise, we
> run the risk of focusing on feature X for release 1 without ensuring
> that our architecture supports feature Y for release 2.

+1 to this.

I think that lifeless'
https://etherpad.openstack.org/p/tripleo-feature-map pad might be a good
way to get moving in that direction.


> The point of disagreement here - which actually seems quite minor to
> me - is how far we want to go in defining heterogeneity.  Are existing
> node attributes such as cpu and memory enough?  Or do we need to go
> further?  To take examples from this thread, some additional
> possibilities include: rack, network connectivity, etc.  Presumably,
> such attributes will be user defined and managed within TripleO itself.

I took the point of disagreement more about the allowance of manual
control. Should a user be able to override the list of what gets
provisioned, where?

And I don't think you always want heterogeneity. For example, if we
treat 'rack' as one of those attributes, a system administrator might
specifically want things to NOT share a rack, e.g. for redundancy.

That said, I suspect that many of us (myself included) have never
designed a data center, so I worry that some of our examples might be a
bit contrived. Not necessarily just for this conversation, but I think
it'd be handy to have real-world stories here. I'm sure no two are
identical, but it'd help make sure we're focused on real-world scenarios.


>
> If that understanding is correct, it seems to me that the requirements
> are broadly in agreement, and that "TripleO defined node attributes"
> is a feature that can easily be slotted into this sort of
> architecture.  Whether it needs to come first. . . should be a
> different discussion (my gut feel is that it shouldn't come first, as
> it depends on everything else working, but maybe I'm wrong).

So to me, that question -- what should come first? -- is exactly what
started this discussion. It didn't start out as a question of whether we
should allow users to override the schedule, but as a question of where
we should start building. Should we start off just letting Nova
scheduler do all the hard work for us and let overrides maybe come in
later? Or should we we start off requiring that everything is manual and
later transition to using Nova? (I don't have a strong opinion either
way, but I hope we land one way or the other soon.)

-- 
Matt Wagner
Software Engineer, Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 600 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131202/099ea4f1/attachment.pgp>