subject:"\"Re\\\: \\\[openstack\\\-dev\\\] Kilo Cycle Goals Exercise\""

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-11 Thread Kenichi Oomichi


> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Tuesday, September 09, 2014 4:29 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Kilo Cycle Goals Exercise
> 
> > 3. Another long-term topic is standardizing our APIs so that we use
> > consistent terminology and formatting (I think we have at least 3 forms
> > of errors returned now?). I’m not sure we have anyone ready to drive
> > this, yet, so I don’t think it’s something to consider for Kilo.
> 
> +10
> 
> Frankly, I believe this should be our #1 priority from a cross-project
> perspective.
> 
> The inconsistencies in the current APIs (even within the same project's
> APIs!) is just poor form and since our REST APIs are the very first
> impression that we give to the outside developer community, it really is
> incumbent on us to make sure they are explicit, free of side-effects,
> well-documented, consistent, easy-to-use, and hide implementation
> details thoroughly.

+1

The REST API consistency is important for whole OpenStack projects,
The list for it in my mind is that
 * API URL/Attribute naming
 * HTTP status code on success
 * Behavior against wrong input (HTTP status code, message in a response)
It is difficult to apply them to all projects, but it would be worth
for improving the quality from the viewpoint of the outside world.

Thanks
Ken'ichi Ohmichi


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-11 Thread Jeremy Stanley

On 2014-09-11 01:27:23 -0400 (-0400), Russell Bryant wrote:
[...]
> But seriously, we should probably put out a more official notice about
> this once Kilo opens up.

It's probably worth carrying in the release notes for all Juno
servers... "This is the last release of OpenStack with official
support for Python 2.6-based platforms."

Of course we're still supporting it on the Juno stable branch for
its lifetime (probably something like a year depending on what the
stable branch managers feel they can provide), and in all involved
clients and libraries until Juno reaches end of support. So don't
get all excited that 2.6 is "going away entirely" in a couple
months.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-11 Thread David Kranz


On 09/11/2014 07:32 AM, Eoghan Glynn wrote:



As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].

To that end, I would like to propose an exercise as discussed in the TC
meeting yesterday [1]:
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 ...

Here's my list of high-level cycle goals, for consideration ...


1. Address our usability debts

With some justification, we've been saddled with the perception
of not caring enough about the plight of users and operators. The
frustrating thing is that much of this is very fixable, *if* we take
time out from the headlong rush to add features. Achievable things
like documentation completeness, API consistency, CLI intuitiveness,
logging standardization, would all go a long way here.

These things are of course all not beyond the wit of man, but we
need to take the time out to actually do them. This may involve
a milestone, or even longer, where we accept that the rate of
feature addition will be deliberately slowed down.


2. Address the drags on our development velocity

Despite the Trojan efforts of the QA team, the periodic brownouts
in the gate are having a serious impact on our velocity. Over the
past few cycles, we've seen the turnaround time for patch check/
verification spike up unacceptably long multiple times, mostly
around the milestones.

Whatever we can do to smoothen out these spikes, whether it be
moving much of the Tempest coverage into the project trees, or
switching focus onto post-merge verification as suggested by
Sean on this thread, or even considering some more left-field
approaches such as staggered milestones, we need to grasp this
nettle as a matter of urgency.

Further back in the pipeline, the effort required to actually get
something shepherded through review is steadily growing. To the
point that we need to consider some radical approaches that
retain the best of our self-organizing model, while setting more
reasonable & reliable expectations for patch authors, and making
it more likely that narrow domain expertise is available to review
their contributions in timely way. For the larger projects, this
is likely to mean something different (along the lines of splits
or sub-domains) than it does for the smaller projects.


3. Address the long-running "what's in and what's out" questions

The way some of the discussions about integration and incubation
played out this cycle have made me sad. Not all of these discussions
have been fully supported by the facts on the ground IMO. And not
all of the issues that have been held up as justifications for
whatever course of exclusion or inclusion would IMO actually be
solved in that way.

I think we need to move the discussion around a new concept of
layering, or redefining what it means to be "in the tent", to a
more constructive and collaborative place than heretofore.


4. Address the fuzziness in cross-service interactions

In a semi-organic way, we've gone and built ourselves a big ol'
service-oriented architecture. But without necessarily always
following the strong contracts, loose coupling, discoverability,
and autonomy that a SOA approach implies.

We need to take the time to go back and pay down some of the debt
that has accreted over multiple cycles around these these
cross-service interactions. The most pressing of these would
include finally biting the bullet on the oft-proposed but never
delivered-upon notion of stabilizing notifications behind a
well-defined contract. Also, the more recently advocated notions
of moving away from coarse-grained versioning of the inter-service
APIs, and supporting better introspection and discovery of
capabilities.

+1
IMO, almost all of the other ills discussed recently derive from this 
single failure.


 -David

by end of day Wednesday, September 10th.

Oh, yeah, and impose fewer arbitrary deadlines ;)

Cheers,
Eoghan


After which time we can
begin discussing the results.
The goal of this exercise is to help us see if our individual world views
align with the greater community, and to get the ball rolling on a larger
discussion of where as a project we should be focusing more time.


best,
Joe Gordon

[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
[1]
http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-11 Thread Eoghan Glynn



> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
> 
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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 ...

Here's my list of high-level cycle goals, for consideration ...


1. Address our usability debts

With some justification, we've been saddled with the perception
of not caring enough about the plight of users and operators. The
frustrating thing is that much of this is very fixable, *if* we take
time out from the headlong rush to add features. Achievable things
like documentation completeness, API consistency, CLI intuitiveness,
logging standardization, would all go a long way here.

These things are of course all not beyond the wit of man, but we
need to take the time out to actually do them. This may involve
a milestone, or even longer, where we accept that the rate of
feature addition will be deliberately slowed down. 


2. Address the drags on our development velocity

Despite the Trojan efforts of the QA team, the periodic brownouts
in the gate are having a serious impact on our velocity. Over the
past few cycles, we've seen the turnaround time for patch check/
verification spike up unacceptably long multiple times, mostly
around the milestones.

Whatever we can do to smoothen out these spikes, whether it be
moving much of the Tempest coverage into the project trees, or
switching focus onto post-merge verification as suggested by
Sean on this thread, or even considering some more left-field
approaches such as staggered milestones, we need to grasp this
nettle as a matter of urgency.

Further back in the pipeline, the effort required to actually get
something shepherded through review is steadily growing. To the
point that we need to consider some radical approaches that
retain the best of our self-organizing model, while setting more
reasonable & reliable expectations for patch authors, and making
it more likely that narrow domain expertise is available to review
their contributions in timely way. For the larger projects, this
is likely to mean something different (along the lines of splits
or sub-domains) than it does for the smaller projects.


3. Address the long-running "what's in and what's out" questions

The way some of the discussions about integration and incubation 
played out this cycle have made me sad. Not all of these discussions
have been fully supported by the facts on the ground IMO. And not
all of the issues that have been held up as justifications for
whatever course of exclusion or inclusion would IMO actually be
solved in that way.

I think we need to move the discussion around a new concept of
layering, or redefining what it means to be "in the tent", to a
more constructive and collaborative place than heretofore.


4. Address the fuzziness in cross-service interactions

In a semi-organic way, we've gone and built ourselves a big ol'
service-oriented architecture. But without necessarily always
following the strong contracts, loose coupling, discoverability,
and autonomy that a SOA approach implies.

We need to take the time to go back and pay down some of the debt
that has accreted over multiple cycles around these these
cross-service interactions. The most pressing of these would
include finally biting the bullet on the oft-proposed but never
delivered-upon notion of stabilizing notifications behind a
well-defined contract. Also, the more recently advocated notions
of moving away from coarse-grained versioning of the inter-service
APIs, and supporting better introspection and discovery of
capabilities.

> by end of day Wednesday, September 10th.

Oh, yeah, and impose fewer arbitrary deadlines ;)

Cheers,
Eoghan

> After which time we can
> begin discussing the results.
> The goal of this exercise is to help us see if our individual world views
> align with the greater community, and to get the ball rolling on a larger
> discussion of where as a project we should be focusing more time.
> 
> 
> best,
> Joe Gordon
> 
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-10 Thread Russell Bryant

On 09/11/2014 12:52 AM, Angus Lees wrote:
> So easy/obvious it probably isn't even worth mentioning:
> 
> Drop support for python2.6

Yeah, that's been the plan.  We discussed this at the Juno summit and
representatives from most (all?) distributions carrying OpenStack were
there.  Dropping in Kilo seemed like a reasonable time frame at the time.

https://etherpad.openstack.org/p/juno-cross-project-future-of-python

And obviously tweeting about it makes it official, right?

https://twitter.com/russellbryant/status/466241078472228864

But seriously, we should probably put out a more official notice about
this once Kilo opens up.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-10 Thread Angus Lees

So easy/obvious it probably isn't even worth mentioning:

Drop support for python2.6

-- 
 - Gus

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-10 Thread Jay Pipes


On 09/03/2014 11:37 AM, Joe Gordon wrote:

As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].

To that end, I would like to propose an exercise as discussed in the TC
meeting yesterday [1]:
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.
The goal of this exercise is to help us see if our individual world
views align with the greater community, and to get the ball rolling on a
larger discussion of where as a project we should be focusing more time.


Again, thanks for bringing up this important topic. Here's my take on 
the cross-project, larger problem domains that I believe we should focus 
as a community on in Kilo:


1) Apply Drano to the current blockage in our governance policies and 
program pipeline


I'm finalizing a blog post about the community and governance policy 
issues that I see, but the Cliff's Notes version is that I think we should:


 a) get rid of the official incubated status
 b) adopt strictly the OpenStack Layers taxonomy for classification of 
projects (and get rid of Programs entirely)
 c) loosen the restrictions on projects living in the openstack/ code 
namespace
 d) replace the official integrated project status with finer-grained 
information that is actually useful to deployers


2) Apply LiquidPlumber to the current testing infrastructure gate

I think it's clear that there is significant pain currently felt by 
contributors across the board, and a large amount of pain experience by 
folks setting up and maintaining external CI systems. We need to focus 
on how to make our gating systems as efficient as possible, with as few 
false failures and as few non-relevant test runs as possible.


I believe Dan Berrange's proposal to split out the virt drivers in Nova 
(all of them) into separate repositories will be a huge win here in 
terms of reducing false positives and avoiding running external CI 
systems for drivers that are not related to a patch in another driver. I 
think Neutron and Cinder would be able to alleviate some gate pain by 
doing a similar effort.


I think pulling functional tests into the individual projects will also 
help to give the gate a bit of unclogging, since functional tests can be 
removed from the lengthier devstack-gate-based Tempest integration tests.


We need to continue making progress in documenting our upstream CI 
systems, how the gate works, how to diagnose and debug gate issues, how 
to bootstrap a developer environment, and how to set up external CI systems.


Finally, I believe there are significant things that can be done to 
reduce both unit and functional test run time. Personally, I'm almost 
finished with a branch in Nova that replaces the functional tests in 
/nova/tests/integrated/api_samples/ with a separate runner that only 
does environment setup once instead of on each test method setUp(). The 
runtime for testing api_samples goes from >5 minutes to <30 seconds on 
my machines. Similar things can and should be looked at for other 
projects to give our gate something of an enema.


3) Apply Mr. Clean to the crufty interfaces that litter our projects

Folks have discussed this at length, and I'm also finishing up another 
longish etherpad and ML discussion about refactoring in Nova's 
api->conductor->scheduler internal interfaces, but the bottom line is 
that there are a significant number of internal interfaces that need to 
be cleaned up, versioned, and "objectified" before splitting out any of 
the drivers or subsystems can be done easily.


We need to pay down the technical debt that has built up, and 
refactoring crufty interfaces is one good way to do that.


Thanks,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-10 Thread Russell Bryant

On 09/03/2014 11:37 AM, Joe Gordon wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
> 
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world
> views align with the greater community, and to get the ball rolling on a
> larger discussion of where as a project we should be focusing more time.

In OpenStack, we have no shortage of interest and enthusiasm on all
fronts, including development contributors, deployers, and cloud end
users.  When looking at project wide-priorities, we need to make sure
our tools, processes, and resulting technology facilitate turning all of
that interest into real value.  We need to identify which areas have the
most pain, and work to improve them.

A lot of this is certainly about Kilo, but it's longer term, too.  It's
the way we should always be thinking about this.

1) Dev community

We clearly have a lot of growing pains here.  What's quite encouraging
is that we also have a lot of hard work going into several different
proposals to figure out ways to help.

The largest projects (Nova and Neutron) are overwhelmed and approaching
breaking points.  We have to find ways to relieve this pressure.  This
may involve aggressively pursing project splits or other code review
workflow changes.  I think the problems and solutions here are
project-wide issues, as solutions put in place tend to rapidly spread to
the rest of OpenStack.  This is an area I'm especially concerned about
and eager to help look for solutions.  We should evaluate all potential
improvements against how well they help us scale our teams and processes
to remove bottlenecks to productivity in the dev communtiy.

There are several other encouraging proposals related to easing pain in
the dev community:

 - re-working how we do functional testing by making it more project focused

 - discussions like this one to discuss both priorities, but also how we
turn priorities into real action (like the nova projects discussions
around using priorities in development)

 - evolving project leadership (the PTL position) so that we can provide
more guidance around delegation in a way that is reasonably consistent
across projects

 - continued discussion about the contents of the integrated release and
how we can continue to foster growth without sacrificing quality

We are always going to have problems like this, and I hope we continue
to think about, discuss, and improve the way we run our projects every
release cycle to come.

2) End Users

A few others have done a very nice job describing end user experience
problems.  Monty's description of getting an instance with an IP was
painful and embarrassing to read.  We've got to figure out ways to
provide better focus on these sorts of usability issues.  They're
obviously not getting the attention they deserve.

There have also been lots of good points about improving our API
consistency.  I totally agree.  I'd love to see a group of people step
up and emerge as leaders in this area across all projects.  I feel like
that's something we're sorely missing right now.

3) Deployers

OpenStack is still painful to deploy, and even more painful to manage.
  I'm still quite pleased that we have a deployment program working on
this space.  I'd actually really like to see how we can facilitate
better integration and discussion between TripleO and the rest of the
project teams.

I'm also very pleased with the progress we've made in Nova towards the
initial support for live upgrades.  We still have more work to do in
Nova, but I'd also like to see more work done in other projects towards
the same goal.

For both deployers and the dev community, figuring out what went wrong
when OpenStack breaks sucks.  Others provided some good pointers to
several areas we can improve that area (better logs, tooling, ...) and I
hope we can make some real progress in this area in the coming cycle.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-10 Thread Kyle Mestery

On Wed, Sep 10, 2014 at 7:13 AM, Thierry Carrez  wrote:
> Joe Gordon wrote:
>> To that end, I would like to propose an exercise as discussed in the TC
>> meeting yesterday [1]:
>> 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.
>> The goal of this exercise is to help us see if our individual world
>> views align with the greater community, and to get the ball rolling on a
>> larger discussion of where as a project we should be focusing more time.
>
> Thanks again to Joe for starting this important discussion.
>
+100

I was going to propose my own list, but to be honest, Thierry sums it
all up so eloquently below that I'd be hard pressed to come up with a
different list.

> My personal list of Kilo goals goes as follows:
>
> #1: Fix our growth pains
>
> We grew a lot, and our recipes were designed for a smaller group where
> trust happens more naturally. With our community growing to a Dunbar
> order of magnitude above, some of those recipes don't work so great, so
> we need to revisit them... That includes the binary "integrated release"
> (introduce layers?), cross-project functional testing (push it at
> project level?), the "programs" concept, encouraging PTL delegation (the
> czar/liaisons proposal ?), scaling core reviewing in larger projects
> (Nova driver split ?), etc.
>
> We already started the conversation on those important topics, but Kilo
> is the timeframe for us to implement those changes, because I don't see
> our community wait for more than one cycle to see the light at the end
> of the tunnel.
>
> #2: Fix the end user experience
>
> Monty expressed it better than I can. We need consistent and
> better-designed APIs, client SDKs that provide useful primitives and
> actually abstract differences in implementations, etc.
>
> #3: Fix what we have: bugfixes, consistency, scaling up, scaling down,
> upgrading
>
> Rather than adding more features for the mid-size private cloud, let's
> make sure that what we have works well, provides a consistent experience
> across projects, scales up beautifully, can be easily used at smaller
> scale as well (simplicity), and allows seamless upgrades. This is
> another way of looking at "paying our technical debt" that others have
> mentioned as goals -- generally polishing what we have rather than
> building out new things.
>
I agree with all of your goals here Thierry, and as I stated above, my
list matches these one for one. I think we have to continue fixing the
growing pains which are happening at a micro-level in each project,
and at a macro-level overall. There are lots of solid ideas around
this for sure, we just need to execute on the ones which we think will
have the most benefit. To me, this is the biggest issue we have and
the one we should tackle first.

Thanks,
Kyle

>
> Regards,
>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-10 Thread Anne Gentle

tl;dr I'm concerned we're conflating user concerns and contributor
concerns. I'd like to see laser focus on two things that help both: 1)
Define layers in our governance and integration efforts 2) Pay down
technical debt with a focus on supporting users.

Great kick off Joe, thanks. I have been waiting to reply to this thread on
purpose while I try to gather as much info as I can about what both users
and contributors are interested in for our future. I have a pretty specific
curiosity about how we're framing this request: I see a spilt between
contributor concerns and user concerns.

Example contributor concerns:
scope definition
incubation and integration requirements
heavy-handed processes
review pileups
contributor license agreement concerns about preventing contributions and
openness
technical debt weighing a project down

Example user concerns:
how do I know what's tested; what's buggy
how do I trust a part of OpenStack to put it into production and maintain
over time
why isn't there complete driver or hypervisor documentation for

logging
security best practices
high availability across OpenStack
monitoring OpenStack
monitoring apps on my OpenStack infrastructure
my own users have needs; how can I get upstream to care about them

These example concerns are not comprehensive but I worry about conflation
causing us all to burnout and flail. I know we all work in the gray areas
but there's a black-and-white problem due to our current governance.

Since I write docs and work on technical committee concerns, I sit on a
cross-project and cross-concern bridge all the time, advocating,
prioritizing, standardizing, and weighing needs across many project teams.
The user concerns are a higher priority for docs currently, because they're
a support mechanism.

I think the Kilo cycle should be dedicated to:

 - Fulfill the promise of layers for defining OpenStack integration
gradients in governance and integration "taxes" such as consistency across
projects, reviews on projects with many drivers/contributors, infra, docs,
and testing
 - Pay down technical debt by sharply focusing on capabilities rather than
drivers that fulfill them

Two focus areas. Each of those will have a lot of work items. Both find
more common ground for devs and users. Let's do this!

 Anne

On Wed, Sep 3, 2014 at 10:37 AM, Joe Gordon  wrote:

> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
>
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world views
> align with the greater community, and to get the ball rolling on a larger
> discussion of where as a project we should be focusing more time.
>
>
> best,
> Joe Gordon
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-10 Thread Thierry Carrez

Joe Gordon wrote:
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world
> views align with the greater community, and to get the ball rolling on a
> larger discussion of where as a project we should be focusing more time.

Thanks again to Joe for starting this important discussion.

My personal list of Kilo goals goes as follows:

#1: Fix our growth pains

We grew a lot, and our recipes were designed for a smaller group where
trust happens more naturally. With our community growing to a Dunbar
order of magnitude above, some of those recipes don't work so great, so
we need to revisit them... That includes the binary "integrated release"
(introduce layers?), cross-project functional testing (push it at
project level?), the "programs" concept, encouraging PTL delegation (the
czar/liaisons proposal ?), scaling core reviewing in larger projects
(Nova driver split ?), etc.

We already started the conversation on those important topics, but Kilo
is the timeframe for us to implement those changes, because I don't see
our community wait for more than one cycle to see the light at the end
of the tunnel.

#2: Fix the end user experience

Monty expressed it better than I can. We need consistent and
better-designed APIs, client SDKs that provide useful primitives and
actually abstract differences in implementations, etc.

#3: Fix what we have: bugfixes, consistency, scaling up, scaling down,
upgrading

Rather than adding more features for the mid-size private cloud, let's
make sure that what we have works well, provides a consistent experience
across projects, scales up beautifully, can be easily used at smaller
scale as well (simplicity), and allows seamless upgrades. This is
another way of looking at "paying our technical debt" that others have
mentioned as goals -- generally polishing what we have rather than
building out new things.

Regards,

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-09 Thread Adam Lawson

Deleting unnecessary code, introducing a stabilization cycle and/or making
definite steps towards a unified SDK are definitely my votes.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Sep 9, 2014 at 5:09 PM, Joe Gordon  wrote:

>
>
> On Wed, Sep 3, 2014 at 8:37 AM, Joe Gordon  wrote:
>
>> As you all know, there has recently been several very active discussions
>> around how to improve assorted aspects of our development process. One
>> idea
>> that was brought up is to come up with a list of cycle goals/project
>> priorities for Kilo [0].
>>
>> To that end, I would like to propose an exercise as discussed in the TC
>> meeting yesterday [1]:
>> 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.
>> The goal of this exercise is to help us see if our individual world views
>> align with the greater community, and to get the ball rolling on a larger
>> discussion of where as a project we should be focusing more time.
>>
>
>
>
> 1. Strengthen our north bound APIs
>
> * API micro-versioning
> * Improved CLI's and SDKs
> * Better capability discovery
> * Hide usability issues with client side logic
> * Improve reliability
>
> As others have said in this thread trying to use OpenStack as a user is a
> very frustrating experience. For a long time now we have focused on
> southbound APIs such as drivers, configuration options, supported
> architectures etc. But as a project we have not spent nearly enough time on
> the end user experience. If our northbound APIs aren't something developers
> want to use, our southbound API work doesn't matter.
>
> 2. 'Fix' our development process
>
> * openstack-specs. Currently we don't have any good way to work on big
> entire-project efforts, hopefully something like a openstack-specs repo
> (with liasons from each core-team reviewing it) will help make it possible
> for us to tackle these issues.  I see us addressing the API
> micro-versioning and capability  discovery issues here.
> * functional testing and post merge testing. As discussed elsewhere in
> this thread our current testing model isn't meeting our current
> requirements.
>
> 3. Pay down technical debt
>
> This is the one I am actually least sure about, as I can really only speak
> for nova on this one. In our constant push forward we have accumulated a
> lot of technical debt. The debt manifests itself as hard to maintain code,
> bugs (nova had over 1000 open bugs until yesterday), performance/scaling
> issues and missing basic features. I think its time for us to take
> inventory if our technical debt and fix some of the biggest issues.
>
>
>>
>> best,
>> Joe Gordon
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
>> [1]
>> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-09 Thread Joe Gordon

On Wed, Sep 3, 2014 at 8:37 AM, Joe Gordon  wrote:

> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
>
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world views
> align with the greater community, and to get the ball rolling on a larger
> discussion of where as a project we should be focusing more time.
>

1. Strengthen our north bound APIs

* API micro-versioning
* Improved CLI's and SDKs
* Better capability discovery
* Hide usability issues with client side logic
* Improve reliability

As others have said in this thread trying to use OpenStack as a user is a
very frustrating experience. For a long time now we have focused on
southbound APIs such as drivers, configuration options, supported
architectures etc. But as a project we have not spent nearly enough time on
the end user experience. If our northbound APIs aren't something developers
want to use, our southbound API work doesn't matter.

2. 'Fix' our development process

* openstack-specs. Currently we don't have any good way to work on big
entire-project efforts, hopefully something like a openstack-specs repo
(with liasons from each core-team reviewing it) will help make it possible
for us to tackle these issues.  I see us addressing the API
micro-versioning and capability  discovery issues here.
* functional testing and post merge testing. As discussed elsewhere in this
thread our current testing model isn't meeting our current requirements.

3. Pay down technical debt

This is the one I am actually least sure about, as I can really only speak
for nova on this one. In our constant push forward we have accumulated a
lot of technical debt. The debt manifests itself as hard to maintain code,
bugs (nova had over 1000 open bugs until yesterday), performance/scaling
issues and missing basic features. I think its time for us to take
inventory if our technical debt and fix some of the biggest issues.

>
> best,
> Joe Gordon
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-09 Thread Michael Still

I haven't had a chance to read other people's posts, so I am sure
there is duplication here.

What would I have all of OpenStack working on if I was ruler of the
universe? Let's see...

1. Fixing our flakey gate: we're all annoyed by our code failing tests
with transient errors, but most people just recheck. Here's the kicker
though -- those errors sometimes affect production deployments as
well. I don't have a magical solution to incent people to work on
fixing these bugs, but we need to fix these. Now.

2. Pay down our tech debt in general. The most obvious example of this
is bugs. Nova has nearly 1,000 of these, and not enough people working
on them compared with features. This is a horrible user experience for
our users, and we should all be embarrassed by it.

3. Find a way to scale nova and neutron development. Our biggest
projects are suffering, and we need to come up with a consistent way
to solve that problem.

Michael

On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon  wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
>
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world views
> align with the greater community, and to get the ball rolling on a larger
> discussion of where as a project we should be focusing more time.
>
>
> best,
> Joe Gordon
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Mathieu Gagné

On 2014-09-07 8:14 PM, Monty Taylor wrote:

If I were king ...

1. Caring about end user experience at all

If I don't do anything at all next cycle, I will see the above fixed.
Because it's embarrassing. Seriously. Try to use OpenStack from python
some time. I dare you.

>
> [...]

Between 2 and 3, maybe we can make a kilo release that has a net
negative SLOC count. But, honestly, screw 2 and 3 - let's all just work
on 1.

On 2014-09-08 5:07 PM, James E. Blair wrote:
>
> 3) A real SDK
>
> OpenStack is so nearly impossible to use, that we have a substantial
> amount of code in the infrastructure program to do things that,
> frankly, we are a bit surprised that the client libraries don't do.
> Just getting an instance with an IP address is an enormous challenge,
> and something that took us years to get right.  We still have problems
> deleting instances.  We need client libraries (an SDK if you will) and
> command line clients that are easy for users to understand and work
> with, and hide the gory details of how the sausage is made.

I 100% agree with both of you. The user experience is a MAJOR concern 
for us. I'm not a good writer able to articulate my thoughts as good as 
I would like but both Monty and James managed to communicate and 
summarize them.

As a technical person, I often don't see the level of complexity in 
tools I use, I like challenges. I will gladly learn new complex stuff if 
needed. But when I first tried to use OpenStack client libraries, it was 
one of those times where I told myself: wow, it sucks. Especially around 
lack of consistency. Or as Monty said, the number of hoops you have to 
go through just to get a pingable instance. And it was and still is the 
opinion shared by some of my coworkers.

If we could improve this aspect, I would be so happy.

--
Mathieu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread James E. Blair

Thanks for starting this, Joe.

I think that we need to address the operator and user experience by
improving the consistency and stability of OpenStack overall.  Here are
five ways of doing that:

1) Improve log correlation and utility

If we're going to improve the stability of OpenStack, we have to be
able to understand what's going on when it breaks.  That's both true
as developers when we're trying to diagnose a failure in an
integration test, and it's true for operators who are all too often
diagnosing the same failure in a real deployment.  Consistency in
logging across projects as well as a cross-project request token would
go a long way toward this.

2) Improve API consistency

As projects are becoming more integrated (which is happening at least
partially as we move functionality _out_ of previously monolithic
projects), the API between them becomes more important.  We keep
generating APIs with different expectations that behave in very
different ways across projects.  We need to standardize on API
behavior and expectations, for the sake of developers of OpenStack who
are increasingly using them internally, but even moreso for our users
who expect a single API and are bewildered when they get dozens
instead.

3) A real SDK

OpenStack is so nearly impossible to use, that we have a substantial
amount of code in the infrastructure program to do things that,
frankly, we are a bit surprised that the client libraries don't do.
Just getting an instance with an IP address is an enormous challenge,
and something that took us years to get right.  We still have problems
deleting instances.  We need client libraries (an SDK if you will) and
command line clients that are easy for users to understand and work
with, and hide the gory details of how the sausage is made.

In OpenStack, we have chosen to let a thousand flowers bloom and
deployers have a wide array of implementation options available.
However, it's unreasonable to expect all of our users to understand
all of the implications of all of those choices.  Our SDK must help
users deal with that complexity.

4) Reliability

Parts of OpenStack break all the time.  In general, we accept that the
environment a cloud operates in can be unreliable (we design for
failure).  However, that should be the exception, not the norm.  Our
current failure modes and rates are hurting everyone -- developers
merging changes in the gate, operators in continual fire-fighting
mode, and users who have to handle and recover from every kind of
internal error that OpenStack externalizes.  We need to focus on
making OpenStack itself operate reliably.

5) Functional testing

We've hit the limit of what we can reasonably accomplish by putting
all of our testing efforts into cross-project integration testing.
Instead, we need to functionally test individual projects much more
strongly, so that we can reserve integration testing (which is much
more complicated) for catching real "integration" bugs rather than
expecting it to call all functional bugs.  To that end, we should help
projects focus on robust functional testing in the Kilo cycle.

-Jim

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Jay Pipes


On 09/03/2014 12:16 PM, Doug Hellmann wrote:

On Sep 3, 2014, at 11:37 AM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote:


As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One
idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].

To that end, I would like to propose an exercise as discussed in the
TC meeting yesterday [1]:
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.
The goal of this exercise is to help us see if our individual world
views align with the greater community, and to get the ball rolling on
a larger discussion of where as a project we should be focusing more time.


Thanks for starting this discussion, Joe. It’s important for us to start
working on “OpenStack” as a whole, in addition to our individual projects.


Agreed. Thank you, Joe.


1. Sean has done a lot of analysis and started a spec on standardizing
logging guidelines where he is gathering input from developers,
deployers, and operators [1]. Because it is far enough for us to see
real progress, it’s a good place for us to start experimenting with how
to drive cross-project initiatives involving code and policy changes
from outside of a single project. We have a couple of potentially
related specs in Oslo as part of the oslo.log graduation work [2] [3],
but I think most of the work will be within the applications.


No surprise, I'm a huge +1 on this.


2. A longer-term topic is standardizing our notification content and
format. See the thread "Treating notifications as a contract” for
details. We could set a goal for Kilo of establishing the requirements
and proposing a spec, with implementation to begin in L.


+1.


3. Another long-term topic is standardizing our APIs so that we use
consistent terminology and formatting (I think we have at least 3 forms
of errors returned now?). I’m not sure we have anyone ready to drive
this, yet, so I don’t think it’s something to consider for Kilo.


+10

Frankly, I believe this should be our #1 priority from a cross-project 
perspective.


The inconsistencies in the current APIs (even within the same project's 
APIs!) is just poor form and since our REST APIs are the very first 
impression that we give to the outside developer community, it really is 
incumbent on us to make sure they are explicit, free of side-effects, 
well-documented, consistent, easy-to-use, and hide implementation 
details thoroughly.



4. I would also like to see the unified SDK and command line client
projects continued (or resumed, I haven’t been following the SDK work
closely). Both of those projects will eventually make using OpenStack
clouds easier. It would be nice to see some movement towards a “user
tools” program to encompass both of these projects, perhaps with an eye
on incubation at the end of Kilo.


+1


5. And we should also be considering the Python 3 porting work. We’ve
made some progress with the Oslo libraries, with oslo.messaging &
eventlet still our main blocker. We need to put together a more concrete
plan to finish that work and for tackling applications, as well as a
team willing to help projects through their transition. This is very
long term, but does need attention, and I think it’s reasonable to ask
for a plan by the end of Kilo.


+0 (only because I don't consider it a priority compared with the other 
things you've documented here)



 From a practical standpoint, we do need to work out details like where
we make decisions about the plans for these projects once the general
idea is approved. We’ve done some of this in the Oslo project in the
past (log translations, for example) but I don’t think that’s the right
place for projects at this scale. A new openstack-specs repository would
give us a place to work on them, but we need to answer the question of
how to decide what is approved.


An openstack-specs repo might indeed be a nice place to put this 
cross-project, OpenStack-wide type of stuff.


Best,
-jay


Doug




best,
Joe Gordon

[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
[1]
http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/open

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Joshua Harlow

Amen to this!

I've always felt bad that before yahoo tries to include a new feature in its 
openstack cloud/s we have to figure out how much the feature is a land-mine, 
how much of it works, how much of it doesn't and so-on. That type of 
investigation imho shouldn't really be needed and the fact that it is makes me 
want more and more a stability cycle or two (or three).

More and more recently I've be thinking that we have spent way to much on 
drivers and features and not enough on our own 'infrastructure'. 

While of course there is a balance, it just seems like the balance currently 
isn't right (IMHO).

Maybe we should start asking ourselves why it is so much easier to add a driver 
vs. do a cross-project functionality like gantt (or centralized quota 
management or other...) that removes some of those land-mines. When it becomes 
easier to land gantt vs a new driver then I think we might be in a better 
place. After all, our infrastructure is what makes the project a long-term 
success and not adding new drivers.

Just my 2 cents,

Josh

On Sep 7, 2014, at 5:14 PM, Monty Taylor  wrote:

> On 09/03/2014 08:37 AM, Joe Gordon wrote:
>> As you all know, there has recently been several very active discussions
>> around how to improve assorted aspects of our development process. One idea
>> that was brought up is to come up with a list of cycle goals/project
>> priorities for Kilo [0].
>> 
>> To that end, I would like to propose an exercise as discussed in the TC
>> meeting yesterday [1]:
>> 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.
>> The goal of this exercise is to help us see if our individual world views
>> align with the greater community, and to get the ball rolling on a larger
>> discussion of where as a project we should be focusing more time.
> 
> If I were king ...
> 
> 1. Caring about end user experience at all
> 
> It's pretty clear, if you want to do things with OpenStack that are not 
> running your own cloud, that we collectively have not valued the class of 
> user who is "a person who wants to use the cloud". Examples of this are that 
> the other day I had to read a section of the admin guide to find information 
> about how to boot a nova instance with a cinder volume attached all in one 
> go. Spoiler alert, it doesn't work. Another spoiler alert - even though the 
> python client has an option for requesting that a volume that is to be 
> attached on boot be formatted in a particular way, this does not work for 
> cinder volumes, which means it does not work for an end user - EVEN THOUGH 
> this is a very basic thing to want.
> 
> Our client libraries are clearly not written with end users in mind, and this 
> has been the case for quite some time. However, openstacksdk is not yet to 
> the point of being usable for "end users" - although good work is going on 
> there to get it to be a basis for an end user python library.
> 
> We give deployers so much flexibility, that in order to write even a SIMPLE 
> program that uses OpenStack, an end user has to know generally four of five 
> pieces of information to check for that are different ways that a deployer 
> may have decided to do things.
> 
> Example:
> 
> - As a user, I want a compute instance that has an IP address that can do 
> things.
> 
> WELL, now you're screwed, because there is no standard way to do that. You 
> may first want to try booting your instance and then checking to see if nova 
> returns a network labeled "public". You may get no networks. This indicates 
> that your provider decided to deploy neutron, but as part of your account 
> creation did not create default networks. You now need to go create a router, 
> network and port in neutron. Now you can try again. Or, you may get networks 
> back, but neither of them are labeled "public" - instead, you may get a 
> public and a private address back in the network labeled private. Or, you may 
> only get a private network back. This indicates that you may be expected to 
> create a thing called a "floating-ip". First, you need to verify that your 
> provider has installed the floating-ip's extension. If they have, then you 
> can create a floating-ip and attach it to your host. NOW - once you have 
> those things done, you need to connect to your host and verify that its 
> outbound networkin
 g has not been blocked by a thing called security groups, which you also may 
not have been expecting to exist, but I'll stop there, because the above is 
long enough.
> 
> Every. Single. One. Of. Those. Cases. is real and has occurred across only 
> the two public openstack clouds that infra uses. That means that our 
> provisioning code takes every single one of them in to account, and anyone 
> who writes code that wants to get a machine to use must tak

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Tim Bell

The End User working group is being described at 
https://wiki.openstack.org/wiki/End_User_Working_Group. Chris Kemp is 
establishing the structure.

This page covers how to get involved...

Tim

From: Brad Topol [mailto:bto...@us.ibm.com]
Sent: 08 September 2014 19:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Kilo Cycle Goals Exercise

Monty,

+1!!   I fully agree!!  How can I help :-)?  Can we dedicate some design summit 
sessions to this topic?  Ideally,  having some stakeholder driven sessions 
where we can hear about the user experiences issues causing the most pain would 
be a good start to get this to become a focus area.

Thanks,

Brad

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com<mailto:bto...@us.ibm.com>
Assistant: Kendra Witherspoon (919) 254-0680

From:Monty Taylor mailto:mord...@inaugust.com>>
To:"OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>,
Date:09/07/2014 08:15 PM
Subject:    Re: [openstack-dev] Kilo Cycle Goals Exercise

On 09/03/2014 08:37 AM, Joe Gordon wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
>
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world views
> align with the greater community, and to get the ball rolling on a larger
> discussion of where as a project we should be focusing more time.

If I were king ...

1. Caring about end user experience at all

It's pretty clear, if you want to do things with OpenStack that are not
running your own cloud, that we collectively have not valued the class
of user who is "a person who wants to use the cloud". Examples of this
are that the other day I had to read a section of the admin guide to
find information about how to boot a nova instance with a cinder volume
attached all in one go. Spoiler alert, it doesn't work. Another spoiler
alert - even though the python client has an option for requesting that
a volume that is to be attached on boot be formatted in a particular
way, this does not work for cinder volumes, which means it does not work
for an end user - EVEN THOUGH this is a very basic thing to want.

Our client libraries are clearly not written with end users in mind, and
this has been the case for quite some time. However, openstacksdk is not
yet to the point of being usable for "end users" - although good work is
going on there to get it to be a basis for an end user python library.

We give deployers so much flexibility, that in order to write even a
SIMPLE program that uses OpenStack, an end user has to know generally
four of five pieces of information to check for that are different ways
that a deployer may have decided to do things.

Example:

 - As a user, I want a compute instance that has an IP address that can
do things.

WELL, now you're screwed, because there is no standard way to do that.
You may first want to try booting your instance and then checking to see
if nova returns a network labeled "public". You may get no networks.
This indicates that your provider decided to deploy neutron, but as part
of your account creation did not create default networks. You now need
to go create a router, network and port in neutron. Now you can try
again. Or, you may get networks back, but neither of them are labeled
"public" - instead, you may get a public and a private address back in
the network labeled private. Or, you may only get a private network
back. This indicates that you may be expected to create a thing called a
"floating-ip". First, you need to verify that your provider has
installed the floating-ip's extension. If they have, then you can create
a floating-ip and attach it to your host. NOW - once you have those
things done, you need to connect to your host and verify that its
outbound networking has not been blocked by a thing called security
groups, which you also may not have been expecting to exist, but I'll
stop there, because the above is long enough.

Every. Single. One. Of. Those. Cases. is real and has occurred across
only the two public openstack clouds that infra uses. That means that
our provisioning code takes every single one of them in to account, a

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Brad Topol

Monty,

+1!!   I fully agree!!  How can I help :-)?  Can we dedicate some design 
summit sessions to this topic?  Ideally,  having some stakeholder driven 
sessions where we can hear about the user experiences issues causing the 
most pain would be a good start to get this to become a focus area.

Thanks,

Brad

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680

From:   Monty Taylor 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   09/07/2014 08:15 PM
Subject:    Re: [openstack-dev] Kilo Cycle Goals Exercise

On 09/03/2014 08:37 AM, Joe Gordon wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One 
idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
>
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world 
views
> align with the greater community, and to get the ball rolling on a 
larger
> discussion of where as a project we should be focusing more time.

If I were king ...

1. Caring about end user experience at all

It's pretty clear, if you want to do things with OpenStack that are not 
running your own cloud, that we collectively have not valued the class 
of user who is "a person who wants to use the cloud". Examples of this 
are that the other day I had to read a section of the admin guide to 
find information about how to boot a nova instance with a cinder volume 
attached all in one go. Spoiler alert, it doesn't work. Another spoiler 
alert - even though the python client has an option for requesting that 
a volume that is to be attached on boot be formatted in a particular 
way, this does not work for cinder volumes, which means it does not work 
for an end user - EVEN THOUGH this is a very basic thing to want.

Our client libraries are clearly not written with end users in mind, and 
this has been the case for quite some time. However, openstacksdk is not 
yet to the point of being usable for "end users" - although good work is 
going on there to get it to be a basis for an end user python library.

We give deployers so much flexibility, that in order to write even a 
SIMPLE program that uses OpenStack, an end user has to know generally 
four of five pieces of information to check for that are different ways 
that a deployer may have decided to do things.

Example:

  - As a user, I want a compute instance that has an IP address that can 
do things.

WELL, now you're screwed, because there is no standard way to do that. 
You may first want to try booting your instance and then checking to see 
if nova returns a network labeled "public". You may get no networks. 
This indicates that your provider decided to deploy neutron, but as part 
of your account creation did not create default networks. You now need 
to go create a router, network and port in neutron. Now you can try 
again. Or, you may get networks back, but neither of them are labeled 
"public" - instead, you may get a public and a private address back in 
the network labeled private. Or, you may only get a private network 
back. This indicates that you may be expected to create a thing called a 
"floating-ip". First, you need to verify that your provider has 
installed the floating-ip's extension. If they have, then you can create 
a floating-ip and attach it to your host. NOW - once you have those 
things done, you need to connect to your host and verify that its 
outbound networking has not been blocked by a thing called security 
groups, which you also may not have been expecting to exist, but I'll 
stop there, because the above is long enough.

Every. Single. One. Of. Those. Cases. is real and has occurred across 
only the two public openstack clouds that infra uses. That means that 
our provisioning code takes every single one of them in to account, and 
anyone who writes code that wants to get a machine to use must take them 
all in to account or else their code is buggy.

That's RIDICULOUS. So we should fix it. I'd say we should fix it by 
removing 1000% of the choices we've given deployers in this case, but I 
won't win there. So how about let's make at least one client library 
that encodes all of the above logic behind some simple task oriented API 
calls? How about we make that library not something which is just a 
repack

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Anita Kuno

On 09/08/2014 12:00 PM, Mike Bayer wrote:
> 
> On Sep 8, 2014, at 11:30 AM, Anita Kuno  wrote:
> 
>> Wow, we are really taking liberties with my question today.
>>
>> What part of any of my actions current or previous have led you to
>> believe that I want to now or ever have silenced anyone? I am curious
>> what led you to believe that silencing users was the motivation for my
>> question of Angus.
> 
> I was only replying to your single message in isolation of the full 
> conversation; the notion that one would not want to send traffic to a blog 
> because they disagree with it, at face value seems like a bad idea.
Actually the word used was prevent, and if I personally want to prevent
something I don't encourage it by giving it attention.

Not understanding something due to disagreement with it is, I agree, a
perspective which is limiting and which ultimately does the party at the
heart of the discussion the most harm, it is self-defeating, yes.

>  Apparently that isn’t the meaning you wished to convey, so I apologize for 
> missing the larger context.
I appreciate you taking the time to talk to me so that we might
understand each other better. Thank you, Mike, I'm grateful for your
time with this.

Thanks,
Anita.
> 
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Mike Bayer

On Sep 8, 2014, at 11:30 AM, Anita Kuno  wrote:

> Wow, we are really taking liberties with my question today.
> 
> What part of any of my actions current or previous have led you to
> believe that I want to now or ever have silenced anyone? I am curious
> what led you to believe that silencing users was the motivation for my
> question of Angus.

I was only replying to your single message in isolation of the full 
conversation; the notion that one would not want to send traffic to a blog 
because they disagree with it, at face value seems like a bad idea.  Apparently 
that isn’t the meaning you wished to convey, so I apologize for missing the 
larger context.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Mike Bayer

On Sep 7, 2014, at 8:14 PM, Monty Taylor  wrote:

> 
> 
> 2. Less features, more win
> 
> In a perfect world, I'd argue that we should merge exactly zero new features 
> in all of kilo, and instead focus on making the ones we have work well. Some 
> of making the ones we have work well may wind up feeling just like writing 
> features, as I imagine some of our features are probably only half features 
> in the first place.
> 
> 3. Deleting things
> 
> We should delete a bunch of code. Deleting code is fun, and it makes your 
> life better, because it means you have less code. So we should start doing 
> it. In particular, we should look for places where we wrote something as part 
> of OpenStack because the python community did not have a thing already, but 
> now there is one. In those cases, we should delete ours and use theirs. Or we 
> should contribute to theirs if it's not quite good enough yet. Or we should 
> figure out how to make more of the oslo libraries things that can truly 
> target non-OpenStack things.
> 

I have to agree that “Deleting things” is the best, best thing.  Anytime you 
can refactor around things and delete more code, a weight is lifted, your code 
becomes easier to understand, maintain, and expand upon.Simpler code then 
gives way to refactorings that you couldn’t even see earlier, and sometimes you 
can even get a big performance boost once a bunch of supporting code now 
reveals itself to be superfluous.  This is most critical for Openstack as 
Openstack is written in Python, and for as long as we have to stay on the 
cPython interpreter, number of function calls is directly proportional to how 
slow something is.  Function calls are enormously expensive in Python.

Something that helps greatly with the goal of “Deleting things” is to reduce 
dependencies between systems. In SQLAlchemy, the kind of change I’m usually 
striving for is one where we take a module that does one Main Thing, but then 
has a bunch of code spread throughout it to do some Other Thing, that is really 
much less important, but complicates the Main Thing.   What we do is reorganize 
the crap out of it and get the Other Thing out of the core Main Thing, move it 
out to a totally optional “extension” module that bothers noone, and we 
essentially forget about it because nobody ever uses it (examples include 
http://docs.sqlalchemy.org/en/rel_0_9/changelog/migration_08.html#instrumentationmanager-and-alternate-class-instrumentation-is-now-an-extension,

http://docs.sqlalchemy.org/en/rel_0_9/changelog/migration_08.html#mutabletype). 
   When we make these kinds of changes, major performance enhancements come 
right in - the Main Thing no longer has to worry about those switches and left 
turns introduced by the Other Thing, and tons of superfluous logic can be 
thrown away.SQLAlchemy’s architecture gains from these kinds of changes 
with every major release and 1.0 is no exception.

This is not quite the same as “Deleting things” but it has more or less the 
same effect; you isolate code that everyone uses from code that only some 
people occasionally use.   In SQLAlchemy specifically, we have the issue of 
individual database dialects that are still packaged along; e.g. there is 
sqlalchemy.dialects.mysql, sqlalchemy.dialects.postgresql, etc.  However, a few 
years back I went through a lot of effort to modernize the system by which 
users can provide their own database backends; while you can not only provide 
your own custom backend using setuptools entry points, I also made a major 
reorganization of SQLAlchemy’s test suite to produce the “dialect test suite”; 
so that when you write your custom dialect, you can actually run a large, 
pre-fabricated test suite out of SQLAlchemy’s core against your dialect, 
without the need for your dialect to be actually *in* SQLAlchemy.  There 
were many wins from this system, including that it forced me to write lots of 
tests that were very well focused on testing specifically what a dialect needs 
to do, in isolation of anything SQLAlchemy itself needs to do.   It allowed a 
whole batch of new third party dialects like that for Amazon Redshift, 
FoundationDB, MonetDB, and also was a huge boon to IBM’s DB2 driver who I 
helped to get onto the new system.   And since then I’ve been able to go into 
SQLAlchemy and dump out lots of old dialects that are much better off being 
maintained separately, at a different level of velocity and hopefully by 
individual contributors who are interested in them, like MS Access, Informix, 
MaxDB, and Drizzle.   Having all these dialects in one big codebase only served 
as a weight on the project, and theoretically it wouldn’t be a bad idea for 
SQLA to have *all* dialects as separate projects, but we’re not there yet.

The only reason I’m rambling on about a SQLAlchemy’s Core/Dialect dichotomy is 
just that I was very much *reminded* of it by the thread regarding Nova and the 
various “virt” drivers.  I know nothi

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Anita Kuno

On 09/08/2014 11:12 AM, Mike Bayer wrote:
> 
> On Sep 7, 2014, at 9:27 PM, Anita Kuno  wrote:
> 
>> On 09/07/2014 09:12 PM, Angus Salkeld wrote:
>>> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
>>> users happy.
>> I don't understand why you would encourage writers of blog posts you
>> disagree with by sending them traffic.
> 
> silencing users who have issues with your project is a really bad idea.If 
> you want to create something great you absolutely need to be obsessed with 
> your detractors and the weight of what they have to say.  Because unless they 
> are a competitor engaged in outright slander, there will be some truth in it. 
>   Ignore criticism at your peril.Someone who takes the time to write out 
> an even somewhat well reasoned criticism is doing your project a service.
> 
> I found the above blog post very interesting as I’d like to get more data on 
> what the large, perceived issues are.
> 
Wow, we are really taking liberties with my question today.

What part of any of my actions current or previous have led you to
believe that I want to now or ever have silenced anyone? I am curious
what led you to believe that silencing users was the motivation for my
question of Angus.

I now see, through asking Angus for clarity which he did provide (not
silencing him, you will notice), that Angus' motivation was prevention
of poor user experience through better attention.

I am highly aware, particularly in the area in which I work - the third
party space- of the leading nature of behavioural training that takes
place particularly of new contributors and contributors who don't have
English as a first language of anything we ask or expect them to do.
Many times what seems to be a reasonable comment or expectation can be
taken completely out of context by folks who don't have English as a
first language and don't have the cultural context and filters that
English speakers have.

Actually my question was motivated from a user experience point of view,
the third party user, since I am only too aware of what kind of
questions and confusion many comments cause because the commenter
doesn't take the non-English speaker point of view into account.

By clarifying Angus' motivation with Angus, hopefully his meaning -
create better user experiences, and better relationships with users -
has come through.

And I agree with all of your points, which is why I take such pains to
create clarity on the mailing lists and other communication.

Thanks,
Anita.
> 
> 
> 
>>
>> Anita.
>>>
>>> 1) Consistent/easy upgrading.
>>> all projects should follow a consistent model to the way they approach
>>> upgrading.
>>> it should actually work.
>>> - REST versioning
>>> - RPC versioning
>>> - db (data) migrations
>>> - ordering of procedures and clear documentation of it.
>>>[this has been begged for by operators, but not sure how we have
>>> delivered]
>>>
>>> 2) HA
>>>  - ability to continue operations after been restated
>>>  - functional tests to prove the above?
>>>
>>> 3) Make it easier for small business to "give OpenStack a go"
>>>  - produce standard docker images as part of ci with super simple
>>> instructions on running them.
>>>
>>> -Angus
>>>
>>>
>>>
>>> On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon  wrote:
>>>
 As you all know, there has recently been several very active discussions
 around how to improve assorted aspects of our development process. One idea
 that was brought up is to come up with a list of cycle goals/project
 priorities for Kilo [0].

 To that end, I would like to propose an exercise as discussed in the TC
 meeting yesterday [1]:
 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.
 The goal of this exercise is to help us see if our individual world views
 align with the greater community, and to get the ball rolling on a larger
 discussion of where as a project we should be focusing more time.

 best,
 Joe Gordon

 [0]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
 [1]
 http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bi

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Mike Bayer


On Sep 7, 2014, at 9:27 PM, Anita Kuno  wrote:

> On 09/07/2014 09:12 PM, Angus Salkeld wrote:
>> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
>> users happy.
> I don't understand why you would encourage writers of blog posts you
> disagree with by sending them traffic.

silencing users who have issues with your project is a really bad idea.If 
you want to create something great you absolutely need to be obsessed with your 
detractors and the weight of what they have to say.  Because unless they are a 
competitor engaged in outright slander, there will be some truth in it.   
Ignore criticism at your peril.Someone who takes the time to write out an 
even somewhat well reasoned criticism is doing your project a service.

I found the above blog post very interesting as I’d like to get more data on 
what the large, perceived issues are.




> 
> Anita.
>> 
>> 1) Consistent/easy upgrading.
>> all projects should follow a consistent model to the way they approach
>> upgrading.
>> it should actually work.
>> - REST versioning
>> - RPC versioning
>> - db (data) migrations
>> - ordering of procedures and clear documentation of it.
>>[this has been begged for by operators, but not sure how we have
>> delivered]
>> 
>> 2) HA
>>  - ability to continue operations after been restated
>>  - functional tests to prove the above?
>> 
>> 3) Make it easier for small business to "give OpenStack a go"
>>  - produce standard docker images as part of ci with super simple
>> instructions on running them.
>> 
>> -Angus
>> 
>> 
>> 
>> On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon  wrote:
>> 
>>> As you all know, there has recently been several very active discussions
>>> around how to improve assorted aspects of our development process. One idea
>>> that was brought up is to come up with a list of cycle goals/project
>>> priorities for Kilo [0].
>>> 
>>> To that end, I would like to propose an exercise as discussed in the TC
>>> meeting yesterday [1]:
>>> 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.
>>> The goal of this exercise is to help us see if our individual world views
>>> align with the greater community, and to get the ball rolling on a larger
>>> discussion of where as a project we should be focusing more time.
>>> 
>>> 
>>> best,
>>> Joe Gordon
>>> 
>>> [0]
>>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
>>> [1]
>>> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>> 
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Chris Dent


On Sun, 7 Sep 2014, Monty Taylor wrote:


1. Caring about end user experience at all
2. Less features, more win
3. Deleting things


Yes. I'll give away all of my list for any one of these.

--
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

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-07 Thread Anita Kuno

On 09/07/2014 09:37 PM, Angus Salkeld wrote:
> On Mon, Sep 8, 2014 at 11:27 AM, Anita Kuno  wrote:
> 
>> On 09/07/2014 09:12 PM, Angus Salkeld wrote:
>>> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
>>> users happy.
>> I don't understand why you would encourage writers of blog posts you
>> disagree with by sending them traffic.
>>
>>
> I am not disagreeing with the blog, I am saying we need to respond better
> to user/operator
> requests so that they don't feel the need to complain.
> 
> -Angus
Oh I misunderstood your use of the word prevent. Thanks for clarifying.

Anita.
> 
> 
>> Anita.
>>>
>>> 1) Consistent/easy upgrading.
>>>  all projects should follow a consistent model to the way they
>> approach
>>> upgrading.
>>>  it should actually work.
>>>  - REST versioning
>>>  - RPC versioning
>>>  - db (data) migrations
>>>  - ordering of procedures and clear documentation of it.
>>> [this has been begged for by operators, but not sure how we have
>>> delivered]
>>>
>>> 2) HA
>>>   - ability to continue operations after been restated
>>>   - functional tests to prove the above?
>>>
>>> 3) Make it easier for small business to "give OpenStack a go"
>>>   - produce standard docker images as part of ci with super simple
>>> instructions on running them.
>>>
>>> -Angus
>>>
>>>
>>>
>>> On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon 
>> wrote:
>>>
 As you all know, there has recently been several very active discussions
 around how to improve assorted aspects of our development process. One
>> idea
 that was brought up is to come up with a list of cycle goals/project
 priorities for Kilo [0].

 To that end, I would like to propose an exercise as discussed in the TC
 meeting yesterday [1]:
 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.
 The goal of this exercise is to help us see if our individual world
>> views
 align with the greater community, and to get the ball rolling on a
>> larger
 discussion of where as a project we should be focusing more time.


 best,
 Joe Gordon

 [0]

>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
 [1]

>> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


>>>
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-07 Thread Angus Salkeld

On Mon, Sep 8, 2014 at 11:27 AM, Anita Kuno  wrote:

> On 09/07/2014 09:12 PM, Angus Salkeld wrote:
> > Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
> > users happy.
> I don't understand why you would encourage writers of blog posts you
> disagree with by sending them traffic.
>
>
I am not disagreeing with the blog, I am saying we need to respond better
to user/operator
requests so that they don't feel the need to complain.

-Angus


> Anita.
> >
> > 1) Consistent/easy upgrading.
> >  all projects should follow a consistent model to the way they
> approach
> > upgrading.
> >  it should actually work.
> >  - REST versioning
> >  - RPC versioning
> >  - db (data) migrations
> >  - ordering of procedures and clear documentation of it.
> > [this has been begged for by operators, but not sure how we have
> > delivered]
> >
> > 2) HA
> >   - ability to continue operations after been restated
> >   - functional tests to prove the above?
> >
> > 3) Make it easier for small business to "give OpenStack a go"
> >   - produce standard docker images as part of ci with super simple
> > instructions on running them.
> >
> > -Angus
> >
> >
> >
> > On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon 
> wrote:
> >
> >> As you all know, there has recently been several very active discussions
> >> around how to improve assorted aspects of our development process. One
> idea
> >> that was brought up is to come up with a list of cycle goals/project
> >> priorities for Kilo [0].
> >>
> >> To that end, I would like to propose an exercise as discussed in the TC
> >> meeting yesterday [1]:
> >> 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.
> >> The goal of this exercise is to help us see if our individual world
> views
> >> align with the greater community, and to get the ball rolling on a
> larger
> >> discussion of where as a project we should be focusing more time.
> >>
> >>
> >> best,
> >> Joe Gordon
> >>
> >> [0]
> >>
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> >> [1]
> >>
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-07 Thread Robert Collins

On 8 September 2014 13:27, Anita Kuno  wrote:
> On 09/07/2014 09:12 PM, Angus Salkeld wrote:
>> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
>> users happy.
> I don't understand why you would encourage writers of blog posts you
> disagree with by sending them traffic.

Because a) the post is whats disagreed with not the person; b) without
the post to read we'd have no context here.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-07 Thread Anita Kuno

On 09/07/2014 09:12 PM, Angus Salkeld wrote:
> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
> users happy.
I don't understand why you would encourage writers of blog posts you
disagree with by sending them traffic.

Anita.
> 
> 1) Consistent/easy upgrading.
>  all projects should follow a consistent model to the way they approach
> upgrading.
>  it should actually work.
>  - REST versioning
>  - RPC versioning
>  - db (data) migrations
>  - ordering of procedures and clear documentation of it.
> [this has been begged for by operators, but not sure how we have
> delivered]
> 
> 2) HA
>   - ability to continue operations after been restated
>   - functional tests to prove the above?
> 
> 3) Make it easier for small business to "give OpenStack a go"
>   - produce standard docker images as part of ci with super simple
> instructions on running them.
> 
> -Angus
> 
> 
> 
> On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon  wrote:
> 
>> As you all know, there has recently been several very active discussions
>> around how to improve assorted aspects of our development process. One idea
>> that was brought up is to come up with a list of cycle goals/project
>> priorities for Kilo [0].
>>
>> To that end, I would like to propose an exercise as discussed in the TC
>> meeting yesterday [1]:
>> 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.
>> The goal of this exercise is to help us see if our individual world views
>> align with the greater community, and to get the ball rolling on a larger
>> discussion of where as a project we should be focusing more time.
>>
>>
>> best,
>> Joe Gordon
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
>> [1]
>> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-07 Thread Angus Salkeld

Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
users happy.

1) Consistent/easy upgrading.
 all projects should follow a consistent model to the way they approach
upgrading.
 it should actually work.
 - REST versioning
 - RPC versioning
 - db (data) migrations
 - ordering of procedures and clear documentation of it.
[this has been begged for by operators, but not sure how we have
delivered]

2) HA
  - ability to continue operations after been restated
  - functional tests to prove the above?

3) Make it easier for small business to "give OpenStack a go"
  - produce standard docker images as part of ci with super simple
instructions on running them.

-Angus



On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon  wrote:

> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
>
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world views
> align with the greater community, and to get the ball rolling on a larger
> discussion of where as a project we should be focusing more time.
>
>
> best,
> Joe Gordon
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-07 Thread Monty Taylor


On 09/03/2014 08:37 AM, Joe Gordon wrote:

As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].

To that end, I would like to propose an exercise as discussed in the TC
meeting yesterday [1]:
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.
The goal of this exercise is to help us see if our individual world views
align with the greater community, and to get the ball rolling on a larger
discussion of where as a project we should be focusing more time.


If I were king ...

1. Caring about end user experience at all

It's pretty clear, if you want to do things with OpenStack that are not 
running your own cloud, that we collectively have not valued the class 
of user who is "a person who wants to use the cloud". Examples of this 
are that the other day I had to read a section of the admin guide to 
find information about how to boot a nova instance with a cinder volume 
attached all in one go. Spoiler alert, it doesn't work. Another spoiler 
alert - even though the python client has an option for requesting that 
a volume that is to be attached on boot be formatted in a particular 
way, this does not work for cinder volumes, which means it does not work 
for an end user - EVEN THOUGH this is a very basic thing to want.


Our client libraries are clearly not written with end users in mind, and 
this has been the case for quite some time. However, openstacksdk is not 
yet to the point of being usable for "end users" - although good work is 
going on there to get it to be a basis for an end user python library.


We give deployers so much flexibility, that in order to write even a 
SIMPLE program that uses OpenStack, an end user has to know generally 
four of five pieces of information to check for that are different ways 
that a deployer may have decided to do things.


Example:

 - As a user, I want a compute instance that has an IP address that can 
do things.


WELL, now you're screwed, because there is no standard way to do that. 
You may first want to try booting your instance and then checking to see 
if nova returns a network labeled "public". You may get no networks. 
This indicates that your provider decided to deploy neutron, but as part 
of your account creation did not create default networks. You now need 
to go create a router, network and port in neutron. Now you can try 
again. Or, you may get networks back, but neither of them are labeled 
"public" - instead, you may get a public and a private address back in 
the network labeled private. Or, you may only get a private network 
back. This indicates that you may be expected to create a thing called a 
"floating-ip". First, you need to verify that your provider has 
installed the floating-ip's extension. If they have, then you can create 
a floating-ip and attach it to your host. NOW - once you have those 
things done, you need to connect to your host and verify that its 
outbound networking has not been blocked by a thing called security 
groups, which you also may not have been expecting to exist, but I'll 
stop there, because the above is long enough.


Every. Single. One. Of. Those. Cases. is real and has occurred across 
only the two public openstack clouds that infra uses. That means that 
our provisioning code takes every single one of them in to account, and 
anyone who writes code that wants to get a machine to use must take them 
all in to account or else their code is buggy.


That's RIDICULOUS. So we should fix it. I'd say we should fix it by 
removing 1000% of the choices we've given deployers in this case, but I 
won't win there. So how about let's make at least one client library 
that encodes all of the above logic behind some simple task oriented API 
calls? How about we make that library not something which is just a 
repackaging of requests that does not contain intelligent, but instead 
something that is fundamentally usable. How about we have synchronous 
versions of all calls that do the polling and error checking. (if you 
attach a cinder volume to a nova instance, apparently, you need to 
continually re-fetch the volume from cinder and check its "attachments" 
property to see when the attach actually happens, because even though 
there is a python library call to do it, it's an async operation and 
there is no status field field to check, nor is there any indication 
that the operation is async, so when the call returns, the volume may or 
may not be attached.)


This client library should contain exactly ZERO admin functions, because 
hopefully the number of people running OpenStack clouds will be smaller 
than the number of people

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-07 Thread Morgan Fainberg

Comments in line (added my thoughts on a couple of the targets Sean
outlined).

On Thursday, September 4, 2014, Sean Dague  wrote:
>
>
> Here is my top 5 list:
>
> 1. Functional Testing in Integrated projects
>
> The justification for this is here -
> http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html.
> We
> need projects to take more ownership of their functional testing so that
> by the time we get to integration testing we're not exposing really
> fundamental bugs like being unable to handle 2 requests at the same time.
>
> For Kilo: I think we can and should be able to make progress on this on
> all integrated projects, as well as the python clients (which are
> basically untested and often very broken).
>
>
Big +1 from me on this.


> 2. Consistency in southbound interfaces (Logging first)
>
> Logging and notifications are south bound interfaces from OpenStack
> providing information to people, or machines, about what is going on.
> There is also a 3rd proposed south bound with osprofiler.
>
> For Kilo: I think it's reasonable to complete the logging standards and
> implement them. I expect notifications (which haven't quite kicked off)
> are going to take 2 cycles.
>
> I'd honestly *really* love to see a unification path for all the the
> southbound parts, logging, osprofiler, notifications, because there is
> quite a bit of overlap in the instrumentation/annotation inside the main
> code for all of these.
>
>
I agree here as well.  we should prioritize logging and use that success as
the template for the other southbound parts. If we get profiler,
notifications, etc it is a win, but hitting logging hard and getting it
right is a huge step in the right direction.


> 3. API micro version path forward
>
> We have Cinder v2, Glance v2, Keystone v3. We've had them for a long
> time. When we started Juno cycle Nova used *none* of them. And with good
> reason, as the path forward was actually pretty bumpy. Nova has been
> trying to create a v3 for 3 cycles, and that effort collapsed under it's
> own weight. I think major API revisions in OpenStack are not actually
> possible any more, as there is too much intertia on existing interfaces.
>
> How to sanely and gradually evolve the OpenStack API is tremendously
> important, especially as a bunch of new projects are popping up that
> implement parts of it. We have the beginnings of a plan here in Nova,
> which now just needs a bunch of heavy lifting.
>
> For Kilo: A working microversion stack in at least one OpenStack
> service. Nova is probably closest, though Mark McClain wants to also
> take a spin on this in Neutron. I think if we could come up with a model
> that worked in both of those projects, we'd pick up some steam in making
> this long term approach across all of OpenStack.
>
> I like the concept but I absolutely want a definition on what micro
versioning should look like. That way we don't end up with 10 different
implementations of micro versioning. I am very concerned that we will see
nova do this in one way, neutron in a different way, and then other
projects taking bits and peices and ending up with something highly
inconsistent. I am unsure how to resolve this consistency issue if multiple
projects are implementing during the same cycle since retrofitting a
different implementation could break the API contract.

Generally speaking the micro versioning will be much more maintainable than
the current major API version methods.


> 4. Post merge testing
>
> As explained here -
> http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html
> we could probably get a lot more bang for our buck if we had a smaller #
> of integration configurations in the pre merge gate, and a much more
> expansive set of post merge jobs.
>
> For Kilo: I think this could be implemented, it probably needs more
> hands than it has right now.
>
> 5. Consistent OpenStack python SDK / clients
>
> I think the client projects being inside the server programs has not
> served us well, especially as the # of servers has expanded. We as a
> project need to figure out how to get the SDK / unified client effort
> moving forward faster.
>
> For Kilo: I'm not sure how close to "done" we could take this, but this
> needs to become a larger overall push for the project as a whole, as I
> think our use exposed interface here is inhibiting adoption.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>

Cheers,
--Morgan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-07 Thread Chris Dent


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

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-04 Thread Sean Dague

On 09/03/2014 11:37 AM, Joe Gordon wrote:
> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
> 
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world
> views align with the greater community, and to get the ball rolling on a
> larger discussion of where as a project we should be focusing more time.
> 
> 
> best,
> Joe Gordon
> 
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html

Here is my top 5 list:

1. Functional Testing in Integrated projects

The justification for this is here -
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html. We
need projects to take more ownership of their functional testing so that
by the time we get to integration testing we're not exposing really
fundamental bugs like being unable to handle 2 requests at the same time.

For Kilo: I think we can and should be able to make progress on this on
all integrated projects, as well as the python clients (which are
basically untested and often very broken).

2. Consistency in southbound interfaces (Logging first)

Logging and notifications are south bound interfaces from OpenStack
providing information to people, or machines, about what is going on.
There is also a 3rd proposed south bound with osprofiler.

For Kilo: I think it's reasonable to complete the logging standards and
implement them. I expect notifications (which haven't quite kicked off)
are going to take 2 cycles.

I'd honestly *really* love to see a unification path for all the the
southbound parts, logging, osprofiler, notifications, because there is
quite a bit of overlap in the instrumentation/annotation inside the main
code for all of these.

3. API micro version path forward

We have Cinder v2, Glance v2, Keystone v3. We've had them for a long
time. When we started Juno cycle Nova used *none* of them. And with good
reason, as the path forward was actually pretty bumpy. Nova has been
trying to create a v3 for 3 cycles, and that effort collapsed under it's
own weight. I think major API revisions in OpenStack are not actually
possible any more, as there is too much intertia on existing interfaces.

How to sanely and gradually evolve the OpenStack API is tremendously
important, especially as a bunch of new projects are popping up that
implement parts of it. We have the beginnings of a plan here in Nova,
which now just needs a bunch of heavy lifting.

For Kilo: A working microversion stack in at least one OpenStack
service. Nova is probably closest, though Mark McClain wants to also
take a spin on this in Neutron. I think if we could come up with a model
that worked in both of those projects, we'd pick up some steam in making
this long term approach across all of OpenStack.

4. Post merge testing

As explained here -
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html
we could probably get a lot more bang for our buck if we had a smaller #
of integration configurations in the pre merge gate, and a much more
expansive set of post merge jobs.

For Kilo: I think this could be implemented, it probably needs more
hands than it has right now.

5. Consistent OpenStack python SDK / clients

I think the client projects being inside the server programs has not
served us well, especially as the # of servers has expanded. We as a
project need to figure out how to get the SDK / unified client effort
moving forward faster.

For Kilo: I'm not sure how close to "done" we could take this, but this
needs to become a larger overall push for the project as a whole, as I
think our use exposed interface here is inhibiting adoption.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-03 Thread Doug Hellmann

On Sep 3, 2014, at 11:37 AM, Joe Gordon  wrote:

> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
> 
> To that end, I would like to propose an exercise as discussed in the TC 
> meeting yesterday [1]:
> 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.
> The goal of this exercise is to help us see if our individual world views 
> align with the greater community, and to get the ball rolling on a larger 
> discussion of where as a project we should be focusing more time.

Thanks for starting this discussion, Joe. It’s important for us to start 
working on “OpenStack” as a whole, in addition to our individual projects. 

1. Sean has done a lot of analysis and started a spec on standardizing logging 
guidelines where he is gathering input from developers, deployers, and 
operators [1]. Because it is far enough for us to see real progress, it’s a 
good place for us to start experimenting with how to drive cross-project 
initiatives involving code and policy changes from outside of a single project. 
We have a couple of potentially related specs in Oslo as part of the oslo.log 
graduation work [2] [3], but I think most of the work will be within the 
applications.

[1] https://review.openstack.org/#/c/91446/
[2] 
https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
[3] https://blueprints.launchpad.net/oslo.log/+spec/remove-context-adapter

2. A longer-term topic is standardizing our notification content and format. 
See the thread "Treating notifications as a contract” for details. We could set 
a goal for Kilo of establishing the requirements and proposing a spec, with 
implementation to begin in L.

3. Another long-term topic is standardizing our APIs so that we use consistent 
terminology and formatting (I think we have at least 3 forms of errors returned 
now?). I’m not sure we have anyone ready to drive this, yet, so I don’t think 
it’s something to consider for Kilo.

4. I would also like to see the unified SDK and command line client projects 
continued (or resumed, I haven’t been following the SDK work closely). Both of 
those projects will eventually make using OpenStack clouds easier. It would be 
nice to see some movement towards a “user tools” program to encompass both of 
these projects, perhaps with an eye on incubation at the end of Kilo.

5. And we should also be considering the Python 3 porting work. We’ve made some 
progress with the Oslo libraries, with oslo.messaging & eventlet still our main 
blocker. We need to put together a more concrete plan to finish that work and 
for tackling applications, as well as a team willing to help projects through 
their transition. This is very long term, but does need attention, and I think 
it’s reasonable to ask for a plan by the end of Kilo.

From a practical standpoint, we do need to work out details like where we make 
decisions about the plans for these projects once the general idea is approved. 
We’ve done some of this in the Oslo project in the past (log translations, for 
example) but I don’t think that’s the right place for projects at this scale. A 
new openstack-specs repository would give us a place to work on them, but we 
need to answer the question of how to decide what is approved.

Doug

> 
> 
> best,
> Joe Gordon
> 
> [0] http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1] 
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

Re: [openstack-dev] Kilo Cycle Goals Exercise

36 matches

Site Navigation

Mail list logo

Footer information