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[1], 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.
[1]
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
