On Wed, 3 Sep 2014, Joe Gordon wrote:
Have anyone interested (especially TC members) come up with a list of what they think the project wide Kilo cycle goals should be and post them on this thread by end of day Wednesday, September 10th. After which time we can begin discussing the results.
I think this is a good idea, but the timing (right at the end of j-3) might be a problematic. I'll jump in, despite being a newb; perhaps that perspective is useful. I'm sure these represent the biases of my limited experience, so apply salt as required and please be aware that I'm not entirely ignorant of the fact that there are diverse forces of history that lead to the present. Things I'd like to help address in Kilo: * Notifications as a contract, better yet as events, with events taking primacy over projects. The main thrust of this topic has been the development of standards that allow endpoints to have some confidence that what is sent or received is the right thing. This is a good thing, but I think misses a larger issue with the notification environment. One of my first BPs was to make Ceilometer capable of hearing notifications from Ironic that contain metrics generated from IPMI readings. I was shocked to discover that _code_ was required to make this happen; my newbie naivety thought it ought to just be a configuration change: a dict on the wire transformed into a data store. I was further shocked to discover that the message bus was being modeled as RPC. I had assumed that at the scale OpenStack is expected to operate most activity on the bus would be modeled as events and swarms of semi-autonomous agents would process them. In both cases my surprise was driven by what I perceived to be a bad ordering of priority between project and events in the discussion of "making things happen". In this specific case the idea was presented as _Ironic_ needs to send some information to _Ceilometer_. Would it not be better to say: "there is hardware health information that happens and various things can process"? With that prioritization lots of different tools can produce and access the information. * Testing is slow and insufficiently reliable. Despite everyone's valiant effort this is true, we see evidence all over this list of trouble at the level of integration testing and testing during the development processing. My own experience has been that the tests (that is the way they are written and run) are relatively okay at preventing regression but not great at enabling TDD nor at being a pathway to understanding the code. This is probably because I think OO unittests are wack so just haven't developed the skill to read them well, but still: Tests are hard and that makes it harder to make good code. We can and should make it better. Facile testing makes it a lot easier to do tech debt cleanup that everyone(?) says we need. I reckon the efforts to library-ize tempest and things like Monty's dox will be useful tools. * Containers are a good idea, let's have more of them. There's a few different ways in which this matters: * "Skate to where the puck will be, not where it is" or "ZOMG VMs are like so last decade". * dox, as above * Containerization of OpenStack services for easy deployment and development. Perhaps `dock_it` instead of `screen_it` in devstack. * Focus on user experience. This one is the most important. The size and number of projects that assemble to become OpenStack inevitably leads to difficulty seeing the big picture when focusing on the individual features within each project. OpenStack is big, hard to deploy and manage, and challenging to understand and use effectively. I _really_ like Sean Dague's idea (sorry, I've lost the ref) that OpenStack needs to be usable and useful to small universities that want to run relatively small clouds. I think this needs to be true _without_ the value-adds that our corporate benefactors package around the core to ease deployment and management. Or to put all this another way: As we are evaluating what we want to do and how we want to do it we need to think less about the projects and technologies that are involved and more about the actions and results that our efforts hope to allow and enable.  http://lists.openstack.org/pipermail/openstack-dev/2014-September/044748.html -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev