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

  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

  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.


Chris Dent tw:@anticdent freenode:cdent

OpenStack-dev mailing list

Reply via email to