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