Open Stack

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