settingsLogin | Registersettings

[openstack-dev] [Nova] The unbearable lightness of specs

0 votes

Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

That's only a subset of problems. Some more, you ask? OK. No clear
guidelines as to what needs a spec, that defaults to "everything does".
And spec being the absolute worst way to judge the validity of some of
the things that do require them.

Examples of the above are everywhere if you care to look for them but
some that I've hit this week are [1] (spec for a quick and dirty fix?!
really?!) [2] (spec stuck waiting for a single person to comment
something that is an implementation detail, and to make matter worse the
spec is for a bug fix) [3] (see how ill suited the format is for a
discussion + complaints about grammar and spelling instead of actual
point being made).

Nova's problem is not that it's big, it's that it's big and tightly
coupled. This means no one can be trusted to navigate the mess
successfully, so we add the process to stop them. What we should be
doing is fixing the mess, and the very process is preventing that.

Don't take my word for it - ask the Gantt subteam who have been trying
to figure out the scheduler interface for almost 4 cycles now. Folks
doing Cells might have a comment on this too.

The good news is that we have a lot of stuff in place already to help us
reduce this massive coupling of everything. We have versioned objects,
we have versioned RPC. Our internal APIs are terrible, and provide no
isolation, but we have the means to iterate and figure it out.

I don't expect this process issues will get solved quickly, If it were
up to me I'd drop the whole thing, but I understand that it's not how
it's done.

I do hope this makes people think, discuss and move things into the
direction of facilitating quality software development instead of
outright preventing it. I'll follow up with some ideas on how to go
forward once a few people have commented back.

N.

PS - Before you ask - splitting out virt drivers will relieve the
pressure but won't fix the tight coupling of everything else in Nova.

[1] https://review.openstack.org/#/c/84048/
[2] https://review.openstack.org/#/c/193576/
[3] https://review.openstack.org/#/c/165838/


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jun 24, 2015 in openstack-dev by Nikola_Đipanov (5,400 points)   2 3 4
retagged Jan 26, 2017 by admin

61 Responses

0 votes

On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote:
Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

I'd like to see some actual evidence to backup a sweeping statement
as "Specs dont work. They do nothing to facilitate good design happening,
if anything they prevent it."

Comparing Nova today, with Nova before specs were introduced, I think
that specs have had a massive positive impact on the amount of good
design and critique that is happening.

Before specs, the average blueprint had no more than 3 lines of text
in its description. Occassionally a blueprint would link to a wiki
page or google doc with some design information, but that was very
much the exception.

When I was reviewing features in Nova before specs came along, I spent
alot of time just trying to figure out what on earth the code was
actually attempting to address, because there was rarely any statement
of the problem being addressed, or any explanation of the design that
motivated the code. This made life hard for reviewers trying to figure
out if the code was acceptable to merge. It is pretty bad for contributors
trying to implement new features too, as they could spend weeks or months
writing and submitting code, only to be rejected at the end because the
(lack of any design discussions) meant they missed some aspect of the
problem which in turn meant all their work was in vain. That was a collosal
waste of everyone's time and resulted in some of the very horrible code
impl decisions we're still living with today.

That's only a subset of problems. Some more, you ask? OK. No clear
guidelines as to what needs a spec, that defaults to "everything does".
And spec being the absolute worst way to judge the validity of some of
the things that do require them.

Examples of the above are everywhere if you care to look for them but
some that I've hit this week are [1] (spec for a quick and dirty fix?!
really?!) [2] (spec stuck waiting for a single person to comment
something that is an implementation detail, and to make matter worse the
spec is for a bug fix) [3] (see how ill suited the format is for a
discussion + complaints about grammar and spelling instead of actual
point being made).

Nova's problem is not that it's big, it's that it's big and tightly
coupled. This means no one can be trusted to navigate the mess
successfully, so we add the process to stop them. What we should be
doing is fixing the mess, and the very process is preventing that.

Don't take my word for it - ask the Gantt subteam who have been trying
to figure out the scheduler interface for almost 4 cycles now. Folks
doing Cells might have a comment on this too.

The good news is that we have a lot of stuff in place already to help us
reduce this massive coupling of everything. We have versioned objects,
we have versioned RPC. Our internal APIs are terrible, and provide no
isolation, but we have the means to iterate and figure it out.

I don't expect this process issues will get solved quickly, If it were
up to me I'd drop the whole thing, but I understand that it's not how
it's done.

I do hope this makes people think, discuss and move things into the
direction of facilitating quality software development instead of
outright preventing it. I'll follow up with some ideas on how to go
forward once a few people have commented back.

I will agree that the specs process has a number of flaws - in particular
I think we've treated it as too much of a rigid process resulting it in
being very beurocractic. In particular I think are missing an ability to
be pragmmatic in decisions about the level of design required and whether
specs are required. The idea of allowing blueprints without specs in
some cases was an attempt to address this, but I don't feel it has been
very successful - there is still too much stuff being forced through
the specs process unncessarily imho.

I've repeatedly stated that the fact that we created an even smaller
clique of people to approve specs (nova-drivers which is a tiny subset
of the already faaaar too small nova-core) is madness, as it creates
an even worse review burden on them, and thus worsens the bottleneck
than we already have.

In reviewing specs, we also often get into far too much detail about
the actual implementation, which is really counterproductive. eg when
get down to bikeshedding about the names of classes, types of object
attributes, and so forth, it is really insane. That level of detail
and bikesheeding belongs in the code review, not the design for the
most part.

Specs are also inflexible when it comes to dealing with features that
cross multiple projects, because we silo'd spec reviews against the
individual projects. This is sub-optimal, but ultimately not a show
stopper.

I also think the way we couple spec approval & reviews to the dev
cycles is counterproductive. We should be willing to accept and
review specs at any point in any cycle, and once approved they should
remain valid for a prolonged period of time - not require us to go
through re-review every new dev cycle as again that's just creating
extra burden. We should of course though reserve the right to unapprove
specs if circumstances change, invlidating the design for the previous
approval.

In short specs are far from perfect, but to say specs don't solve/help
anything todo with design in nova is really ignoring our history from
before the time specs existed. We must continue to improve our process
overall the biggest thing we lost IMHO is agility and pragmatism in
our decision making - I think we can regain that without throwing away
the specs idea entirely.

Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Daniel_P._Berrange (27,920 points)   2 4 9
0 votes

On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote:
Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

I do not consider specs don't work, personnaly I refer myself to this
relatively good documentation [1] instead of to dig in code to
remember how work a feature early introduced.

I guess we have some efforts to do about the level of details we want
before a spec is approved. We should just consider the general
idea/design, options introduced, API changed and keep in mind the
contributors who will implement the feature can/have to update it
during the developpement phase.

[1] http://specs.openstack.org/openstack/nova-specs/specs/kilo/

s.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Sahid_Orentino_Ferdj (1,740 points)   1
0 votes

On 6/24/2015 7:42 AM, Daniel P. Berrange wrote:
On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote:

Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

I'd like to see some actual evidence to backup a sweeping statement
as "Specs dont work. They do nothing to facilitate good design happening,
if anything they prevent it."

Comparing Nova today, with Nova before specs were introduced, I think
that specs have had a massive positive impact on the amount of good
design and critique that is happening.

Before specs, the average blueprint had no more than 3 lines of text
in its description. Occassionally a blueprint would link to a wiki
page or google doc with some design information, but that was very
much the exception.

Yeah, seems we've forgotten how before we had specs in gerrit everyone
complained about the lack of detail and ability to add comments in the
launchpad blueprint whiteboard. Storyboard was meant to be the savior
but that took too long so specs in gerrit was going to be an alternative
for awhile and it ended up working nicely.

Now that we're tired of the new thing we can start criticizing it and
iterating on how to make it more agile.

When I was reviewing features in Nova before specs came along, I spent
alot of time just trying to figure out what on earth the code was
actually attempting to address, because there was rarely any statement
of the problem being addressed, or any explanation of the design that
motivated the code. This made life hard for reviewers trying to figure
out if the code was acceptable to merge. It is pretty bad for contributors
trying to implement new features too, as they could spend weeks or months
writing and submitting code, only to be rejected at the end because the
(lack of any design discussions) meant they missed some aspect of the
problem which in turn meant all their work was in vain. That was a collosal
waste of everyone's time and resulted in some of the very horrible code
impl decisions we're still living with today.

That's only a subset of problems. Some more, you ask? OK. No clear
guidelines as to what needs a spec, that defaults to "everything does".
And spec being the absolute worst way to judge the validity of some of
the things that do require them.

Examples of the above are everywhere if you care to look for them but
some that I've hit this week are [1] (spec for a quick and dirty fix?!
really?!) [2] (spec stuck waiting for a single person to comment
something that is an implementation detail, and to make matter worse the
spec is for a bug fix) [3] (see how ill suited the format is for a
discussion + complaints about grammar and spelling instead of actual
point being made).

Nova's problem is not that it's big, it's that it's big and tightly
coupled. This means no one can be trusted to navigate the mess
successfully, so we add the process to stop them. What we should be
doing is fixing the mess, and the very process is preventing that.

Don't take my word for it - ask the Gantt subteam who have been trying
to figure out the scheduler interface for almost 4 cycles now. Folks
doing Cells might have a comment on this too.

The good news is that we have a lot of stuff in place already to help us
reduce this massive coupling of everything. We have versioned objects,
we have versioned RPC. Our internal APIs are terrible, and provide no
isolation, but we have the means to iterate and figure it out.

I don't expect this process issues will get solved quickly, If it were
up to me I'd drop the whole thing, but I understand that it's not how
it's done.

I do hope this makes people think, discuss and move things into the
direction of facilitating quality software development instead of
outright preventing it. I'll follow up with some ideas on how to go
forward once a few people have commented back.

I will agree that the specs process has a number of flaws - in particular
I think we've treated it as too much of a rigid process resulting it in
being very beurocractic. In particular I think are missing an ability to
be pragmmatic in decisions about the level of design required and whether
specs are required. The idea of allowing blueprints without specs in
some cases was an attempt to address this, but I don't feel it has been
very successful - there is still too much stuff being forced through
the specs process unncessarily imho.

I've repeatedly stated that the fact that we created an even smaller
clique of people to approve specs (nova-drivers which is a tiny subset
of the already faaaar too small nova-core) is madness, as it creates
an even worse review burden on them, and thus worsens the bottleneck
than we already have.

In reviewing specs, we also often get into far too much detail about
the actual implementation, which is really counterproductive. eg when
get down to bikeshedding about the names of classes, types of object
attributes, and so forth, it is really insane. That level of detail
and bikesheeding belongs in the code review, not the design for the
most part.

Specs are also inflexible when it comes to dealing with features that
cross multiple projects, because we silo'd spec reviews against the
individual projects. This is sub-optimal, but ultimately not a show
stopper.

There is the openstack-specs repo for cross-project specs:

http://specs.openstack.org/openstack/openstack-specs/

That'd be a good place for things like your os-vif library spec which
requires input from both nova and neutron teams, although I think it's
currently OK to have it in nova-specs since a lot of the forklift is
going to come from there and we can add neutron reviewers as needed.

I also think the way we couple spec approval & reviews to the dev
cycles is counterproductive. We should be willing to accept and
review specs at any point in any cycle, and once approved they should
remain valid for a prolonged period of time - not require us to go
through re-review every new dev cycle as again that's just creating
extra burden. We should of course though reserve the right to unapprove
specs if circumstances change, invlidating the design for the previous
approval.

In short specs are far from perfect, but to say specs don't solve/help
anything todo with design in nova is really ignoring our history from
before the time specs existed. We must continue to improve our process
overall the biggest thing we lost IMHO is agility and pragmatism in
our decision making - I think we can regain that without throwing away
the specs idea entirely.

Regards,
Daniel

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Matt_Riedemann (48,320 points)   3 7 21
0 votes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/24/2015 03:23 PM, Sahid Orentino Ferdjaoui wrote:
I do not consider specs don't work, personnaly I refer myself to
this relatively good documentation [1] instead of to dig in code
to remember how work a feature early introduced.

I think a better place for dev docs is devref, not -specs. At least
you can update them with your code at the same time, and make safe
cross-references.

Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVirCUAAoJEC5aWaUY1u57ZW8IANf5gvuYYX1TtpaTOdGrl5E1
daUPdw+PvT/1ex2lggoQGjwKv7wgZ6lRIKyuKQIFUbHA155L0vjROa1kSIKn2dWA
Fr45yL/Io2Dt6pzF+8Vt5teM2GW/xHBQDkzyT7dw5kKlgpWYz472uk8MdftUqps9
6xkTFxE8mr8Y82yRHw8roolp4GZjl0gFUBKwIlrT0GA3ahDyQvHjHhvK7Gh94Co8
rZMsMAYT/8zcOzgSjqiJnFrUE4RkngYpVNhPHOyNmQjhQCtV6jDvDVWJho1Q7cDr
Ti4AK67T8ZYXTo2uZwpsRQh1QZavAFQ8fx9p+VV+opWXji/Vpnn5qk4ZLxkk3eM=
=65hZ
-----END PGP SIGNATURE-----


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Ihar_Hrachyshka (35,300 points)   3 9 16
0 votes

On 6/24/2015 8:23 AM, Sahid Orentino Ferdjaoui wrote:
On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote:

Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

I do not consider specs don't work, personnaly I refer myself to this
relatively good documentation [1] instead of to dig in code to
remember how work a feature early introduced.

I guess we have some efforts to do about the level of details we want
before a spec is approved. We should just consider the general
idea/design, options introduced, API changed and keep in mind the
contributors who will implement the feature can/have to update it
during the developpement phase.

[1] http://specs.openstack.org/openstack/nova-specs/specs/kilo/

s.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I agree completely. The nicely rendered feature docs which is a
byproduct of the specs process in gerrit is a great part of it. So when
someone is trying to use a new feature or trying to fix a bug in said
feature 1-2 years later and trying to understand the big picture idea,
they can refer to the original design spec - assuming it was accurate at
the time that the code was actually merged. Like you said, it's
important to keep the specs up to date based on what was actually
approved in the code.

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Matt_Riedemann (48,320 points)   3 7 21
0 votes

On 06/24/2015 01:42 PM, Daniel P. Berrange wrote:
On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote:

Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

I'd like to see some actual evidence to backup a sweeping statement
as "Specs dont work. They do nothing to facilitate good design happening,
if anything they prevent it."

Comparing Nova today, with Nova before specs were introduced, I think
that specs have had a massive positive impact on the amount of good
design and critique that is happening.

Before specs, the average blueprint had no more than 3 lines of text
in its description. Occassionally a blueprint would link to a wiki
page or google doc with some design information, but that was very
much the exception.

When I was reviewing features in Nova before specs came along, I spent
alot of time just trying to figure out what on earth the code was
actually attempting to address, because there was rarely any statement
of the problem being addressed, or any explanation of the design that
motivated the code. This made life hard for reviewers trying to figure
out if the code was acceptable to merge. It is pretty bad for contributors
trying to implement new features too, as they could spend weeks or months
writing and submitting code, only to be rejected at the end because the
(lack of any design discussions) meant they missed some aspect of the
problem which in turn meant all their work was in vain. That was a collosal
waste of everyone's time and resulted in some of the very horrible code
impl decisions we're still living with today.

Yes there are good reasons to have a place to discuss implementation
before doing it, especially if you are new to the project.

The behemoth we have now is not that. It's miles away as you point out
below.

That's only a subset of problems. Some more, you ask? OK. No clear
guidelines as to what needs a spec, that defaults to "everything does".
And spec being the absolute worst way to judge the validity of some of
the things that do require them.

Examples of the above are everywhere if you care to look for them but
some that I've hit this week are [1] (spec for a quick and dirty fix?!
really?!) [2] (spec stuck waiting for a single person to comment
something that is an implementation detail, and to make matter worse the
spec is for a bug fix) [3] (see how ill suited the format is for a
discussion + complaints about grammar and spelling instead of actual
point being made).

Nova's problem is not that it's big, it's that it's big and tightly
coupled. This means no one can be trusted to navigate the mess
successfully, so we add the process to stop them. What we should be
doing is fixing the mess, and the very process is preventing that.

Don't take my word for it - ask the Gantt subteam who have been trying
to figure out the scheduler interface for almost 4 cycles now. Folks
doing Cells might have a comment on this too.

The good news is that we have a lot of stuff in place already to help us
reduce this massive coupling of everything. We have versioned objects,
we have versioned RPC. Our internal APIs are terrible, and provide no
isolation, but we have the means to iterate and figure it out.

I don't expect this process issues will get solved quickly, If it were
up to me I'd drop the whole thing, but I understand that it's not how
it's done.

I do hope this makes people think, discuss and move things into the
direction of facilitating quality software development instead of
outright preventing it. I'll follow up with some ideas on how to go
forward once a few people have commented back.

I will agree that the specs process has a number of flaws - in particular
I think we've treated it as too much of a rigid process resulting it in
being very beurocractic. In particular I think are missing an ability to
be pragmmatic in decisions about the level of design required and whether
specs are required. The idea of allowing blueprints without specs in
some cases was an attempt to address this, but I don't feel it has been
very successful - there is still too much stuff being forced through
the specs process unncessarily imho.

I've repeatedly stated that the fact that we created an even smaller
clique of people to approve specs (nova-drivers which is a tiny subset
of the already faaaar too small nova-core) is madness, as it creates
an even worse review burden on them, and thus worsens the bottleneck
than we already have.

In reviewing specs, we also often get into far too much detail about
the actual implementation, which is really counterproductive. eg when
get down to bikeshedding about the names of classes, types of object
attributes, and so forth, it is really insane. That level of detail
and bikesheeding belongs in the code review, not the design for the
most part.

Specs are also inflexible when it comes to dealing with features that
cross multiple projects, because we silo'd spec reviews against the
individual projects. This is sub-optimal, but ultimately not a show
stopper.

I also think the way we couple spec approval & reviews to the dev
cycles is counterproductive. We should be willing to accept and
review specs at any point in any cycle, and once approved they should
remain valid for a prolonged period of time - not require us to go
through re-review every new dev cycle as again that's just creating
extra burden. We should of course though reserve the right to unapprove
specs if circumstances change, invlidating the design for the previous
approval.

In short specs are far from perfect, but to say specs don't solve/help
anything todo with design in nova is really ignoring our history from
before the time specs existed. We must continue to improve our process
overall the biggest thing we lost IMHO is agility and pragmatism in
our decision making - I think we can regain that without throwing away
the specs idea entirely.

Basically I agree with everything above.

I urge people to reply to this instead of my original email as the
writing is more detailed and balanced.

Thanks Daniel!

N.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Nikola_Đipanov (5,400 points)   2 3 4
0 votes

On 06/24/2015 02:33 PM, Matt Riedemann wrote:

On 6/24/2015 8:23 AM, Sahid Orentino Ferdjaoui wrote:

On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote:

Hey Nova,

I'll cut to the chase and keep this email short for brevity and clarity:

Specs don't work! They do nothing to facilitate good design happening,
if anything they prevent it. The process layered on top with only a
minority (!) of cores being able to approve them, yet they are a prereq
of getting any work done, makes sure that the absolute minimum that
people can get away with will be proposed. This in turn goes and
guarantees that no good design collaboration will happen. To add insult
to injury, Gerrit and our spec template are a horrible tool for
discussing design. Also the spec format itself works for only a small
subset of design problems Nova development is faced with.

I do not consider specs don't work, personnaly I refer myself to this
relatively good documentation [1] instead of to dig in code to
remember how work a feature early introduced.

I guess we have some efforts to do about the level of details we want
before a spec is approved. We should just consider the general
idea/design, options introduced, API changed and keep in mind the
contributors who will implement the feature can/have to update it
during the developpement phase.

[1] http://specs.openstack.org/openstack/nova-specs/specs/kilo/

s.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I agree completely. The nicely rendered feature docs which is a
byproduct of the specs process in gerrit is a great part of it. So when
someone is trying to use a new feature or trying to fix a bug in said
feature 1-2 years later and trying to understand the big picture idea,
they can refer to the original design spec - assuming it was accurate at
the time that the code was actually merged. Like you said, it's
important to keep the specs up to date based on what was actually
approved in the code.

Of course documentation is good. Make that kind of docs a requirement
for merging a feature, by all means.

But the approval process we have now is just backwards. It's only result
is preventing useful work getting done.

In addition to what Daniel mentioned elsewhere:

Why do cores need approved specs for example - and indeed for many of us
- it's just a dance we do. I refuse to believe that a core can be
trusted to approve patches but not to write any code other than a bugfix
without a written document explaining themselves, and then have a yet
more exclusive group of super cores approve that. It makes no sense.
Document it - sure. Discuss on ML/patches - by all means, but this is
just senseless.

Next - why do priority features need an approved spec? We all know we
want to do it, just design it up on an etherpad/wiki/trello/whatever if
needed, write code and discuss there.

Instead we try to shoehorn PM, design docs, design discussion, release
planning, and a kitchen sink into a rigid inflexible process.

Docs - YES, process over anything - No, thanks!

N.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Nikola_Đipanov (5,400 points)   2 3 4
0 votes

Why do cores need approved specs for example - and indeed for many of us
- it's just a dance we do. I refuse to believe that a core can be
trusted to approve patches but not to write any code other than a bugfix
without a written document explaining themselves, and then have a yet
more exclusive group of super cores approve that. It makes no sense.
Document it - sure. Discuss on ML/patches - by all means, but this is
just senseless.

I completely disagree with this (and find it offensive). Cores are not
gods. They review things and try to do their best to keep quality high.
However, that does not mean that they can single-handedly design and
implement a large complex feature on their own without feedback. It's
the same reason that cores need other cores to review their code.

As a core, I rarely get patches in without iterating at least once due
to feedback, and I certainly don't land blueprints without scrutiny from
others. To me, cores having their code and specs reviewed is not a
"dance we do." Is that your main complaint? That you, a core, have to
have your specs reviewed?

Next - why do priority features need an approved spec? We all know we
want to do it, just design it up on an etherpad/wiki/trello/whatever if
needed, write code and discuss there.

Because review of the design is important?

--Dan


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Dan_Smith (9,860 points)   1 2 4
0 votes

On Wed, Jun 24, 2015 at 02:51:38PM +0100, Nikola Đipanov wrote:
On 06/24/2015 02:33 PM, Matt Riedemann wrote:

[. . .]

I agree completely. The nicely rendered feature docs which is a
byproduct of the specs process in gerrit is a great part of it. So when
someone is trying to use a new feature or trying to fix a bug in said
feature 1-2 years later and trying to understand the big picture idea,
they can refer to the original design spec - assuming it was accurate at
the time that the code was actually merged. Like you said, it's
important to keep the specs up to date based on what was actually
approved in the code.

Of course documentation is good. Make that kind of docs a requirement
for merging a feature, by all means.

But the approval process we have now is just backwards. It's only result
is preventing useful work getting done.

In addition to what Daniel mentioned elsewhere:

Why do cores need approved specs for example - and indeed for many of us
- it's just a dance we do. I refuse to believe that a core can be
trusted to approve patches but not to write any code other than a bugfix
without a written document explaining themselves, and then have a yet
more exclusive group of super cores approve that. It makes no sense.

This is one of the baffling aspects -- that a so-called "super core"
has to approve specs with no obvious valid reasons. As Jay Pipes
mentioned once, this indeed seems like a vestigial remnant from old
times.

FWIW, I agree with others on this thread, Nova should get rid of this
specific senseless non-process. At least a couple of cycles ago.

[Snip, some sensible commentary.]

--
/kashyap


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Kashyap_Chamarthy (4,520 points)   1 2 3
0 votes

On Wed, Jun 24, 2015 at 04:09:16PM +0200, Kashyap Chamarthy wrote:
On Wed, Jun 24, 2015 at 02:51:38PM +0100, Nikola Đipanov wrote:

On 06/24/2015 02:33 PM, Matt Riedemann wrote:

[. . .]

I agree completely. The nicely rendered feature docs which is a
byproduct of the specs process in gerrit is a great part of it. So when
someone is trying to use a new feature or trying to fix a bug in said
feature 1-2 years later and trying to understand the big picture idea,
they can refer to the original design spec - assuming it was accurate at
the time that the code was actually merged. Like you said, it's
important to keep the specs up to date based on what was actually
approved in the code.

Of course documentation is good. Make that kind of docs a requirement
for merging a feature, by all means.

But the approval process we have now is just backwards. It's only result
is preventing useful work getting done.

In addition to what Daniel mentioned elsewhere:

Why do cores need approved specs for example - and indeed for many of us
- it's just a dance we do.

On this part, I fully agree with Dan Smith's reasoning and from my own
observation of other communities I that follow (e.g. KVM/QEMU/libvirt),
every long time dev/reviewer ('core' in OpenStack parlance)does
provide their intent/design thoughts in written form to the list to
discuss, iterate, and get different technical perspectives before going
ahead and implementing them.

I refuse to believe that a core can be
trusted to approve patches but not to write any code other than a bugfix
without a written document explaining themselves, and then have a yet
more exclusive group of super cores approve that. It makes no sense.

This is one of the baffling aspects -- that a so-called "super core"
has to approve specs with no obvious valid reasons. As Jay Pipes
mentioned once, this indeed seems like a vestigial remnant from old
times.

Just to clarify, that I only find it weird that there exists a special
sub-group for specs.

--
/kashyap


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Kashyap_Chamarthy (4,520 points)   1 2 3
...