I think we may all be approaching the planning of this project in the wrong way, because of confusions such as:
> Well, I think there is one small misunderstanding. I've never said that > manual way should be primary workflow for us. I agree that we should lean > toward as much automation and smartness as possible. But in the same time, I > am adding that we need manual fallback for user to change that smart > decision. > Primary way would be to let TripleO decide, where the stuff go. I think we > agree here. That's a pretty fundamental requirement that both sides seem to agree upon - but that agreement got lost in the discussions of what feature should come in which release, etc. That seems backwards to me. 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. To make this example more specific: it seems clear that everyone agrees that the current Tuskar design (where nodes must be assigned to racks, which are then used as the primary means of manipulation) is not quite correct. Instead, we'd like to introduce a philosophy where we assume that users don't want to deal with homogeneous nodes individually, instead letting TripleO make decisions for them. When we have a bunch of heterogeneous nodes, we want to be able to break them up into several homogeneous groups, and assign different capabilities to each. But again, within each individual homogeneous group, we don't want users dealing with each individual nodes; instead, we want TripleO to take care of business. 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. 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). In any case, if we can a) detail requirements without talking about releases and b) create a design architecture, I think that it'll be far easier to come up with a set of milestones that make developmental sense. > > Folk that want to manually install openstack on a couple of machines > > > can already do so : we don't change the game for them by replacing a > > > manual system with a manual system. My vision is that we should > > > deliver something significantly better! > > We should! And we can. But I think we shouldn't deliver something, what will > discourage people from using TripleO. Especially at the beginning - see > user, we are doing first steps here, the distribution is not perfect and > what you wanted, but you can do the change you need. You don't have to go > away and come back in 6 months when we try to be smarter and address your > case. Regarding this - I think we may want to clarify what the purpose of our releases are at the moment. Personally, I don't think our current planning is about several individual product releases that we expect to be production-ready and usable by the world; I think it's about milestone releases which build towards a more complete product. >From that perspective, if I were a prospective user, I would be less concerned >with each release containing exactly what I need. Instead, what I would want >most out of the project is: a) frequent stable releases (so I can be comfortable with the pace of development and the quality of code) b) design documentation and wireframes (so I can be comfortable that the architecture will support features I need) c) a roadmap (so I have an idea when my requirements will be met) Mainn
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
