settingsLogin | Registersettings

Questions in defcore-committee

Search:
CategoryQuestionAnswer

[OpenStack-DefCore] ACTION REQUIRED > pick meeting dates!

All,

We're not going to have a meeting this week - I did not get enough responses.

For the F2F: Josh is not available for 8/14 and I don't think I can get back to SFO for 8/17. Either way, we can run the meeting.

Please review the meeting times and vote.

1) Principles, This Week: (Thurs or Friday) http://doodle.com/75afaha3aypkybia

2) Draft DS on Low Hanging Fruit, Next Week (have have to slide) http://doodle.com/zncaidywetn9qici

3) Finish DS for review, Face to Face, 8/14 and/or 8/17 http://doodle.com/giqhyd85mvtbick2

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140801/86f9117d/attachment.html

[OpenStack-DefCore] PLEASE DISCUSS (or +1) Designated Sections Principles [No Meeting on Friday]

All,

We did not get critical mass on the doodle calendars to justify a meeting. I am planning a meeting next Thursday (10 am?) to draft the strawman. I'll be in SF and looking for a location (South Bay is ok).

Josh and I have the following proposal for "designated sections principles" based on the TC's original document:

Should be DESIGNATED:

Should NOT be DESIGNATED:

? code provides the project external REST API, or
? code is shared and provides common functionality for all options, or
? code implements logic that is critical for cross-platform operation

? code interfaces to vendor-specific functions, or
? project design explicitly intended this section to be replaceable, or
? code extends the project external REST API in a new or different way, or
? code is being deprecated

There are three important additions to these 7 points:

1) unless code is designated, it is assumed to be undesignated. As usual, we have a preference for smaller core.

2) If the community cannot reach a fast consensus about designation then code is considered undesignated. Excepting obvious trolling, this prevents endless wrangling. If there's a true difference of opinion then we default to undesignated.

3) Loose descriptions of designated sections are acceptable. The goal is guidance on where we want upstream contributions not a code inspection police state.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140807/a80b010f/attachment.html

+1

On 8/7/2014 at 01:03 AM, wrote:
All,

We did not get critical mass on the doodle calendars to justify a meeting.
I am planning a meeting next Thursday (10 am?) to draft the strawman. I'll
be in SF and looking for a location (South Bay is ok).

Josh and I have the following proposal for "designated sections principles"
based on the TC's original document:

Should be DESIGNATED:

Should NOT be DESIGNATED:

? code provides the project external REST API, or
? code is shared and provides common functionality for all options, or
? code implements logic that is critical for cross-platform operation

? code interfaces to vendor-specific functions, or
? project design explicitly intended this section to be replaceable, or
? code extends the project external REST API in a new or different way, or
? code is being deprecated

There are three important additions to these 7 points:

1) unless code is designated, it is assumed to be undesignated. As
usual, we have a preference for smaller core.

2) If the community cannot reach a fast consensus about designation
then code is considered undesignated. Excepting obvious trolling, this
prevents endless wrangling. If there's a true difference of opinion then we
default to undesignated.

3) Loose descriptions of designated sections are acceptable. The goal
is guidance on where we want upstream contributions not a code inspection
police state.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

[OpenStack-DefCore] DefCore Thursday 10am @ DLA Piper office

All,

DLA Piper is hosting the Thurs 10/14 @ 10am DefCore meeting.

Call in & Agenda: https://etherpad.openstack.org/p/DefCoreLighthouse.5

The address is
2000 University Avenue
East Palo Alto, California

Also, it looks like we have agreement on the principles. I am planning a blog post to socialize them.

Rob

From: Hirschfeld, Rob
Sent: Thursday, August 07, 2014 1:04 AM
To: Defcore-committee at lists.openstack.org
Subject: [OpenStack-DefCore] PLEASE DISCUSS (or +1) Designated Sections Principles [No Meeting on Friday]

All,

We did not get critical mass on the doodle calendars to justify a meeting. I am planning a meeting next Thursday (10 am?) to draft the strawman. I'll be in SF and looking for a location (South Bay is ok).

Josh and I have the following proposal for "designated sections principles" based on the TC's original document:

Should be DESIGNATED:

Should NOT be DESIGNATED:

? code provides the project external REST API, or
? code is shared and provides common functionality for all options, or
? code implements logic that is critical for cross-platform operation

? code interfaces to vendor-specific functions, or
? project design explicitly intended this section to be replaceable, or
? code extends the project external REST API in a new or different way, or
? code is being deprecated

There are three important additions to these 7 points:

1) unless code is designated, it is assumed to be undesignated. As usual, we have a preference for smaller core.

2) If the community cannot reach a fast consensus about designation then code is considered undesignated. Excepting obvious trolling, this prevents endless wrangling. If there's a true difference of opinion then we default to undesignated.

3) Loose descriptions of designated sections are acceptable. The goal is guidance on where we want upstream contributions not a code inspection police state.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140811/78a78e1c/attachment.html

[OpenStack-DefCore] DefCore Thursday 8/14, 10am @ DLA Piper office

All,

I mean AUGUST 14th. Sorry for the confusion.

Rob

From: Hirschfeld, Rob
Sent: Monday, August 11, 2014 11:01 AM
To: Defcore-committee at lists.openstack.org
Subject: [OpenStack-DefCore] DefCore Thursday 10am @ DLA Piper office

All,

DLA Piper is hosting the Thurs 10/14 @ 10am DefCore meeting.

Call in & Agenda: https://etherpad.openstack.org/p/DefCoreLighthouse.5

The address is
2000 University Avenue
East Palo Alto, California

Also, it looks like we have agreement on the principles. I am planning a blog post to socialize them.

Rob

From: Hirschfeld, Rob
Sent: Thursday, August 07, 2014 1:04 AM
To: Defcore-committee at lists.openstack.org
Subject: [OpenStack-DefCore] PLEASE DISCUSS (or +1) Designated Sections Principles [No Meeting on Friday]

All,

We did not get critical mass on the doodle calendars to justify a meeting. I am planning a meeting next Thursday (10 am?) to draft the strawman. I'll be in SF and looking for a location (South Bay is ok).

Josh and I have the following proposal for "designated sections principles" based on the TC's original document:

Should be DESIGNATED:

Should NOT be DESIGNATED:

? code provides the project external REST API, or
? code is shared and provides common functionality for all options, or
? code implements logic that is critical for cross-platform operation

? code interfaces to vendor-specific functions, or
? project design explicitly intended this section to be replaceable, or
? code extends the project external REST API in a new or different way, or
? code is being deprecated

There are three important additions to these 7 points:

1) unless code is designated, it is assumed to be undesignated. As usual, we have a preference for smaller core.

2) If the community cannot reach a fast consensus about designation then code is considered undesignated. Excepting obvious trolling, this prevents endless wrangling. If there's a true difference of opinion then we default to undesignated.

3) Loose descriptions of designated sections are acceptable. The goal is guidance on where we want upstream contributions not a code inspection police state.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140811/5ef834e6/attachment-0001.html

Just because I love giving you a hard time ... the should/should not
sections below copy/pasted poorly, so it looks like it's all a list of
"should not" :)

In case anyone else read it that way first, the first set of bullets are
should and the second are should not.

BTW - I'd like to explicitly give a shout out to the following sentences:

"Loose descriptions of designated sections are acceptable. The goal is
guidance on where we want upstream contributions not a code inspection
police state."

That may be the best expression I've seen yet of the underlying intent
for this to be helpful, and not legalistically prescriptive and
nitpicky. Thanks!

On 08/11/2014 11:15 AM, Rob_Hirschfeld at Dell.com wrote:
All,

I mean AUGUST 14th. Sorry for the confusion.

Rob

From: Hirschfeld, Rob
Sent: Monday, August 11, 2014 11:01 AM
To: Defcore-committee at lists.openstack.org
Subject: [OpenStack-DefCore] DefCore Thursday 10am @ DLA Piper office

All,

DLA Piper is hosting the Thurs 10/14 @ 10am DefCore meeting.

Call in & Agenda: https://etherpad.openstack.org/p/DefCoreLighthouse.5

The address is
2000 University Avenue
East Palo Alto, California

Also, it looks like we have agreement on the principles. I am planning a blog post to socialize them.

Rob

From: Hirschfeld, Rob
Sent: Thursday, August 07, 2014 1:04 AM
To: Defcore-committee at lists.openstack.org
Subject: [OpenStack-DefCore] PLEASE DISCUSS (or +1) Designated Sections Principles [No Meeting on Friday]

All,

We did not get critical mass on the doodle calendars to justify a meeting. I am planning a meeting next Thursday (10 am?) to draft the strawman. I'll be in SF and looking for a location (South Bay is ok).

Josh and I have the following proposal for "designated sections principles" based on the TC's original document:

Should be DESIGNATED:

Should NOT be DESIGNATED:

? code provides the project external REST API, or
? code is shared and provides common functionality for all options, or
? code implements logic that is critical for cross-platform operation

? code interfaces to vendor-specific functions, or
? project design explicitly intended this section to be replaceable, or
? code extends the project external REST API in a new or different way, or
? code is being deprecated

There are three important additions to these 7 points:

1) unless code is designated, it is assumed to be undesignated. As usual, we have a preference for smaller core.

2) If the community cannot reach a fast consensus about designation then code is considered undesignated. Excepting obvious trolling, this prevents endless wrangling. If there's a true difference of opinion then we default to undesignated.

3) Loose descriptions of designated sections are acceptable. The goal is guidance on where we want upstream contributions not a code inspection police state.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Please review, results from Designated Sections review w/ recommendations. +1s needed

DefCore,

We had a small turn out and very good discussions that were able to produce clear guidance for Designated Sections (see below). We also reviewed the Havana capabilities from the board meeting and the 10 designated sections principles approved by email. Finally, we setup a calendar for community review leading up to the September Board meeting

Here are the recommendations:

  • Havana Nova is by default designated except scheduler, filter, drivers, API extensions and networking.

  • Havana Swift has no designated code due to lack of consensus (see principles)

  • Havana Keystone is not designated.

  • Havana Glance designated sections are the API implementation code and domain model.

  • Havana Cinder designated sections are the API implementation code

  • Havana Neutron has no designated sections.

  • Havana Heat is not a core capability, no position at this time.

  • Havana Horizon is not a core capability, no position at this time.

  • other projects do not are not core capabilities and are not reviewed at this time.

Please contribute to a discussion or +1

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140814/9528cec8/attachment.html

Just to add some additional background information. Today, if you wish to qualify for the OpenStack Powered logo (see attached) as well as other associated trademark rights (i.e. how you name your product if it includes the word ?OpenStack? in it) . You must meet these criteria. Note that this list of requirement is rather old, dating back to a time when we had a LOT fewer projects and capabilities, and thus, in my view, the sooner we can implement something better, the better, even if that something better isn?t perfect (as few things are).

On the substantive questions raised throughout this thread on the right policies, I am very interested to hear from users like Tim on what really matters wrt interop, since in my mind that?s job #1 of this whole exercise.

Current Requirements Language:


a. A primary purpose of your product must be to run a functioning operational instance of the OpenStack software.

b. Your product must:

i. upon its launch, include the entirety of the OpenStack Compute (Nova) code from either of the latest two releases and associated milestones, and

ii. upon its launch, include the entirety of the OpenStack Object Storage (Swift) code from either of the latest two releases and associated milestones, and

iii. expose the associated OpenStack APIs published on http://www.openstack.org without modification.

c. You must clearly state which OpenStack projects and versions are used to set customer expectations, in a way that is conspicuous to customers.

d. As of January 1st, 2012, your product must pass any Faithful Implementation Test Suite (FITS) defined by the Technical Committee that will be made available on http://www.openstack.org/FITS, to verify that you are implementing a sufficiently current and complete version of the software (and exposing associated APIs) to ensure compatibility and interoperability. Your product will be required to pass the current FITS test on an annual basis, which will generally require you to be running either of the latest two software releases.

?????--------------------

So today we require you to have 100% of Nova + the Nova APIs. and 100% of Swift + the Swift APIs. Now one might point out that this lacks some level of specificity to be crystal clear, but I think what Rob and team have been trying to do over the past few months is to bring a lot more specificity to whatever comes next, which is both an ambitious and admirable goal. Both in terms of 1) what APIs we mean specifically 2) what tests we mean you to pass specifically associated with those APIs and 3) what code requirements, specifically, are required (and looking beyond just Nova and Swift to the whole list of possible projects ? which are now thought of as ?capabilities? more so than ?projects? to take a more user centric view).

So how will the contract language re: requirements change as defcore, the board, and community arrive at a consensus on ?what?s next?? Here?s what i expect:

It is my expectation that A) will stay as-is. "A primary purpose of your product must be to run a functioning operational instance of the OpenStack software.? We could tweak it but I think it?s pretty clear.
It is my expectation that c) will stay as-is "You must clearly state which OpenStack projects and versions are used to set customer expectations, in a way that is conspicuous to customers.?
And that everything under b, which deals with capabilities/code/apis today will be re-written to reflect the required capabilities, APIs, and code inclusion once those are approved (note that Icehouse is the first expected enforceable version, as the Havana stuff being discussed today is ?advisory? meaning it wouldn?t be a contract requirement). I am working on this language in conjunction with our trademark attorney (with placeholders for the actual things that are in or out, pending a decision there) and will socialize it with the ecosystem and defcore. We might actually want to take the specificity out of the agreement itself and point instead to a web page where the details are posted, so that we can get this moving faster and not over burden the agreement itself.
My expectation is that d) will be re-written to more accurately reflect the expected testing requirements and mechanisms. Frankly, if we just put the tests and steps up on the page OpenStack.org/FITS then I?m not sure how much change this language needs. That said, we should decide if this is still the standard for freshness and re-testing we want to have "Your product will be required to pass the current FITS test on an annual basis, which will generally require you to be running either of the latest two software releases. ?

The benefit of sticking with as much of the language in D) as possible is that it has been in agreements for years, and is thus socialized and actually agreed to by many many companies already. I?m not against re-writing it but let?s do so for a good reason. One thing that does not seem to jive with the current reality is the statement that the FITS test is ?defined by the Technical Committee. Would it be more accurate to say that we are now looking to the Board to define the test? I don?t have a dog in that fight, just wanting to have the agreements reflect the direction we?re going, so we?re ready to cut over when it?s time.

On Aug 19, 2014, at 12:50 AM, Tom Fifield wrote:

I'm pretty much blocked out until the ops meetup is over (say 1st
September or so) - when is that board meeting again?

but anyway, here's what I'm thinking:

Simple webapp that does away with everything but components, explaining
the complex bits only in context for what a potential trademark
applicant is trying to do with components.

so, two parts:

1) the form (static html) - what is the activity {run a cloud, make a
storage product etc}, what trademark {powered, compatible, etc}, and
which components are being used

2) the result page (a template, filled in by some code based on the form
selections)

that talks about whether the components they've ticked are enough, and
also about what they're allowed to do with those components.
Ideally, each component name would link off to a dedicated page for that
component explaining the 'designated sections' and required API things.

mockups attached - very, very rough!

I'd propose to create this and circulate it so that the community can
understand the impact of the suggested designated sections before the
board meeting.

Regards,

Tom

On 15/08/14 14:04, Rob_Hirschfeld at Dell.com wrote:

Tom / Josh,

We can update the examples; however, I think that we could use some help
here. You can I are very close to the material and make assumptions
about reader knowledge when explaining it.

It would be helpful to have someone (Tom?) with a fresh perspective take
a pass at it.

Rob

-----Original Message-----
From: Tom Fifield [mailto:tom at openstack.org]
Sent: Thursday, August 14, 2014 7:52 PM
To: Joshua McKenty
Cc: defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Please review, results from
Designated Sections review w/ recommendations. +1s needed

All good with me :) Though, I would note the timeframe here is short.
We obviously want the community to be able to understand the real
impact of these suggested designated suggestions and comment on them
well before any board meeting, so revisited sooner the better IMO!

Regards,

Tom

On 15/08/14 10:47, Joshua McKenty wrote:

Tom, those examples we're put together before the trademark was
changed
by the foundation staff. We may need to revisit those practical concerns.

Sent from my iPhone

On Aug 14, 2014, at 7:43 PM, Tom Fifield wrote:

Hit send too soon :) I also didn't find any "practical
implementation concerns" in those slides - that would also be
appreciated :)

I'm also interested in any practical implementation concerns you
think can arise based on the below suggestions.

For example, in the case of an "OpenStack Powered" cloud that
offers an object store that is not swift, would they be
recommended/required to denote that actually that particular bit
was
not "Openstack Powered"?

I could see that being confusing for users, and my guess is
there might be some similar cases that should be managed :)

Regards,

Tom

On 15/08/14 10:41, Tom Fifield wrote:
Hi Rob,

Thanks for the reply :)

I actually find these pretty complicated - is there a chance for
some simpler ones?

Regards,

Tom

On 15/08/14 09:59, Rob_Hirschfeld at Dell.com wrote:
Tom,

I agree!

Josh and I did a presentation with examples in ATL
(http://www.confreaks.com/videos/3695-openstacksummitatl2014-core
-
v
ia-crowd-sourcing-defcores-tempest-in-a-docker-container-tcup
) and I gave an updated version at OSCON
(http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-review
)

These are also discussed on my blog at
http://www.slideshare.net/rhirschfeld/oscon-2014-def-core-review

Please let me know if those examples help explain the use of the
mark better.

Thanks

-----Original Message-----
From: Tom Fifield [mailto:tom at openstack.org]
Sent: Thursday, August 14, 2014 6:14 PM
To: defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Please review, results from
Designated Sections review w/ recommendations. +1s needed

Hi Rob,

Can you provide a few example uses of the commercial marks based
on
below?

eg "I can call my cloud "OpenStack Powered" without regard to
the use of Keystone."

I'm also interested in any practical implementation concerns you
think can arise based on the below suggestions.

For example, in the case of an "OpenStack Powered" cloud that
offers an object store that is not swift, would they be
recommended/required to denote that actually that particular bit
was
not "Openstack Powered"?

I could see that being confusing for users, and my guess is
there might be some similar cases that should be managed :)

Regards,

Tom

On 15/08/14 04:54, Rob_Hirschfeld at Dell.com wrote:
DefCore,

We had a small turn out and very good discussions that were
able to produce clear guidance for Designated Sections (see
below). We also reviewed the Havana capabilities from the board
meeting and the 10 designated sections principles approved by
email. Finally, we setup a calendar for community review
leading up to the September Board meeting

Here are the recommendations:

? Havana Nova is by default designated except scheduler,
filter, drivers, API extensions and networking.

? Havana Swift has no designated code due to lack of consensus
(see principles)

? Havana Keystone is not designated.

? Havana Glance designated sections are the API implementation
code and domain model.

? Havana Cinder designated sections are the API implementation
code

? Havana Neutron has no designated sections.

? Havana Heat is not a core capability, no position at this time.

? Havana Horizon is not a core capability, no position at this
time.

? other projects do not are not core capabilities and are not
reviewed at this time.

Please contribute to a discussion or +1

Rob

______________________________

Rob Hirschfeld

Sr. Distinguished Cloud Solution Architect

Dell| Cloud Edge, Data Center Solutions**

cell+1 512 909-7219 blog robhirschfeld.com, twitter
@zehicle

Please note, I am based in the CENTRAL (-6) time zone


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-comm
it
tee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-commit
te
e


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committ
ee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

<defcore-page1.png><defcore-page2.png><defcore-page3.png>_______________________________________________
Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openstack-powered-sample.png
Type: image/png
Size: 39880 bytes
Desc: not available
URL:

[OpenStack-DefCore] Meeting next Thursday? Joint w/ TC and Designated Sections & Process Review

All,

I'd like to propose next Thursday (8/28 + Doodle) for a DefCore/TC interlock meeting (voice meeting) to review the Designated Sections and the DefCore process (attached).

Here's the Doodle for the time: http://doodle.com/x2tghxq5suvx6pkd

Please plan on 1pm PT until we agree on the time in doodle.

Agenda: https://etherpad.openstack.org/p/DefCoreLighthouse.6

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140822/d924771e/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defcore flow.jpg
Type: image/jpeg
Size: 81602 bytes
Desc: defcore flow.jpg
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140822/d924771e/attachment-0001.jpg

Rob_Hirschfeld at Dell.com wrote:
I?d like to propose next Thursday (8/28 + Doodle) for a DefCore/TC
interlock meeting (voice meeting) to review the Designated Sections and
the DefCore process (attached).

Here?s the Doodle for the time: http://doodle.com/x2tghxq5suvx6pkd

Please plan on 1pm PT until we agree on the time in doodle.

Agenda: https://etherpad.openstack.org/p/DefCoreLighthouse.6

I forwarded the invitation and Doodle link to the TC list.

--
Thierry Carrez (ttx)

[OpenStack-DefCore] DefCore Lighthouse.5 (TC Interlock)

You have been invited to a join.me online meeting \n \nhttps://etherpad.openstack.org/p/DefCoreLighthouse.5 \n \n \nJoin the meeting: https://join.me/616-820-519 \n \nOn a computer, use any browser with Flash. Nothing to download. \nOn a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 616-820-519 \n \n \nJoin the audio conference: \nDial a phone number and enter access code, or connect via internet. \n \nBy phone: \nUnited States - Hartford, CT +1.860.970.0010 \nUnited States - Los Angeles, CA +1.213.226.1066 \nUnited States - Thousand Oaks, CA +1.805.309.5900 \nAccess Code 616-820-519# \n \nOther international numbers available (https://join.me/intphone/616820519/0) \n \nBy computer via internet: \nJoin the meeting, click the phone icon and select 'Call via internet'. A small download might be required. \n \n \nStart time by time zones (https://join.me/timezone/1409248800000/1409252400000) \n \n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140826/f83e89e6/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 1951 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140826/f83e89e6/attachment.ics

[OpenStack-DefCore] DefCore Lighthouse.6 (TC Interlock)

You have been invited to a join.me online meeting \n \nhttps://etherpad.openstack.org/p/DefCoreLighthouse.6 \n \n \nJoin the meeting: https://join.me/616-820-519 \n \nOn a computer, use any browser with Flash. Nothing to download. \nOn a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 616-820-519 \n \n \nJoin the audio conference: \nDial a phone number and enter access code, or connect via internet. \n \nBy phone: \nUnited States - Hartford, CT +1.860.970.0010 \nUnited States - Los Angeles, CA +1.213.226.1066 \nUnited States - Thousand Oaks, CA +1.805.309.5900 \nAccess Code 616-820-519# \n \nOther international numbers available (https://join.me/intphone/616820519/0) \n \nBy computer via internet: \nJoin the meeting, click the phone icon and select 'Call via internet'. A small download might be required. \n \n \nStart time by time zones (https://join.me/timezone/1409248800000/1409252400000) \n \n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140826/63f7a0c5/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 1951 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140826/63f7a0c5/attachment.ics

[OpenStack-DefCore] DefCore Meeting on Designated Sections, Thursday 11am PT

All,

I've closed the doodle poll w/ a clear result: 8/28 @ 11 am PT.

Agenda & Call-in information on https://etherpad.openstack.org/p/DefCoreLighthouse.6

I'd like the call to be 60 minutes but please prepare for 90.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140826/efcce2b1/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defcore flow.jpg
Type: image/jpeg
Size: 81602 bytes
Desc: defcore flow.jpg
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140826/efcce2b1/attachment-0001.jpg

Rob_Hirschfeld at Dell.com wrote:
* Review DefCore Process Chart (attached) ? time limited.

The call yesterday was a bit busy, but I think we actually clarified
something with respect to the "technical community input on designated
sections" stage.

There are two types of proposals in the Designated Sections strawman.
Some projects have /some/ designated sections, while some others don't
have any designated section. In the latter case, at the heart of that
decision is the fact that a lot of companies in the OpenStack ecosystem
ship products that do not include the project at all, and Defcore would
still like to allow those companies to use the "Powered by OpenStack"
trademark license program. I totally respect those decisions: it's a
hard call to make and it's the board prerogative and duty to make it.

But as far as technical feedback is concerned, it's difficult to ask
Swift contributors if they agree that none of the code they wrote is
necessary to call your product "powered by OpenStack". Of course they
won't agree: it's actually not a judgment of technical value, it's just
a trademark policy choice. By extension, it's difficult to ask the
Technical Committee, the body representing all those contributors, to
agree that part of the code they produce is not necessary or less
important. That body can only give one answer, and will continue to do so.

Now, that doesn't mean you can't get any technical input on the
Designated sections strawman, but quite the opposite: it just has to be
organized differently. There is still a lot of value in technical input
to precisely define designated sections lines in the case a project has
/some/ designated sections. For example for Glance, does it make
technically sense to consider the WSGI framework as replaceable or not.

So here would be my suggested way forward: for all the projects that
have "some" designated sections (Nova, Glance, Cinder), organize a
specific call/meeting calling all interested members of our technical
community (individual TC members, project PTL, any contributor
interested) to join and give feedback on the proposed split between
designated and non-designated code in their project. That could be a
30-min-per-project thing in a 90-min time span, or 3 separate meetings.

FWIW, personally, I think the proposed split on Nova, Glance and Cinder
makes technical sense.

--
Thierry Carrez (ttx)

[OpenStack-DefCore] DefCore Meeting on Designated Sections, Thursday 11am PT

-----Original Message-----
From: Auld, Will [mailto:will.auld at intel.com]
I also like having separate meetings (not back to back) for getting
input where possible. I don't think back to back will work because we
will never be able to cut off discussion on one to move to the next
and having different people interested in each will make choosing a reasonable time less possible.

Are you volunteering to attend and coordinate all these meetings to collect the feedback? Thierry and I could use the help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140901/dfd28c83/attachment.html

Great point Alan.

I think from an end user / developer perspective (using the term here to mean those building apps to target ?openstack clouds?), there is a huge need to know what is going to be there consistently when encountering an openstack powered cloud in the wild, whether public or private.

So many things happen before that cloud is deployed that the developer is targeting, like the extremely active upstream development where rapid innovation is happening, downstream to distributions that are productizing that code (sometimes a subset of capabilities and code), down to operators who are taking those distros/products to stand up and run services based on them (for internal customers in private, or external in public cloud), all along the way making decisions about what is suitable for their customers/markets. This creates a lot of diversity in the real world deployments, which is a double edged sword.

The question is how do we ensure that what comes out at the end of that long supply chain (for lack of a better word) is of the highest quality, most relevant, and very consistently applied so that this developer building ?cloud apps? can choose any ?openstack cloud? they want (internal or external) and get a great, consistent experience. And one that isn?t likely to break the compatibility of their apps as that service provider updates to new versions of openstack.

This is why there has always been a sense that the technical community, represented by the TC, are as well positioned as anyone to weigh in on these decisions about what would ideally happen downstream. It?s easy to dismiss this as ?just about commercial questions and trademarks, leave it to the board? but look at it another way? someone like Rackspace takes the code from trunk and puts it into production (this is a gross oversimplification I know). This is not about making a product per se, it?s about standing up a service that people will rely on. How important is it that a public cloud like that has Keystone capabilities? What about the Code? To the end user? end user, again, meaning someone who is really the customer/user of the cloud service itself, who who likely cares deeply about API changes that break capability. What else do they care about, and how do our decisions around defcore take those things into consideration?

I do think that as the footprint of OpenStack clouds has grown, we haven?t necessarily kept up in terms of engaging with this ?end user developer? class, and admittedly the TC is focused on the developers writing openstack not using the clouds based on it per se. We do have several efforts underway to put more focus on engaging with that aspect of the community and getting that voice into the mix. There is a new working group spinning up, a dedicated track at the Atlanta and Paris Summits, developer.openstack.org WIP, new questions on the user survey, and at the foundation we are likely to hire a dedicated community manager for this area in the near future. In the meantime, any developers who have a perspective on this, please speak up! Big decisions are looming and I think we do need to have all stakeholders voicing their opinions leading up to imminent board vote.

Thanks to everyone who keeps pushing on this topic to put us in the best position to serve our users in 2015 and beyond!

On Sep 2, 2014, at 1:17 PM, Alan Clark wrote:

All,

There is another aspect to Designated Sections that I feel is important and I hope not being missed. At least It's an aspect that I'm looking for from designated code sections. Perhaps it simply didn't surface in the call last week because it is easier to identify through other projects than those discussed on the call.

Back in the 'spider' discussions, one of the tensions identified was the need to not inhibit developers ability to innovate, while through the use of the OpenStack mark conveying code maturity, completeness and long term stability. People developing applications, deploying and administrating OpenStack are keen to understand what and which features they can confidently write to and deploy, aka features that are mature, complete and will be sustainable for many future releases. Icehouse had close to 400 new features, Juno will have a similar amount. In fact I don't see that slowing down in any near future. That shows great innovation! Yet even though we have declared that the integrated projects are ready for release, we know that not all of the features fit the "mature, complete and long term supportable" category. Several of the blueprints even explicitly make that declaration.

We don't want to block those. In fact the exact opposite, we want more. The beauty of enabling and including innovative features is for people to try them out and provide feedback and experience to the community.

But let's not miss the opportunity to also tell the ecosystem about those areas that are mature and dependable. We have a ton of features that fit that category. We need to identify those. The creation of capabilities helps but is not complete. This is best resolved through the creation of designated sections. And that is why the TC is critical for the DefCore effort. As Thierry delineates, asking the TC and PTLs opinion on what code is business necessary is not the right question.

In my opinion, asking the PTLs and TC which code features / segments are mature, complete, sustainable and part of the long term vision is the right question to ask.

Regards,

AlanClark

On 8/29/2014 at 01:06 AM, Thierry Carrez wrote:
Rob_Hirschfeld at Dell.com wrote:
* Review DefCore Process Chart (attached) * time limited.

The call yesterday was a bit busy, but I think we actually clarified
something with respect to the "technical community input on designated
sections" stage.

There are two types of proposals in the Designated Sections strawman.
Some projects have /some/ designated sections, while some others don't
have any designated section. In the latter case, at the heart of that
decision is the fact that a lot of companies in the OpenStack ecosystem
ship products that do not include the project at all, and Defcore would
still like to allow those companies to use the "Powered by OpenStack"
trademark license program. I totally respect those decisions: it's a
hard call to make and it's the board prerogative and duty to make it.

But as far as technical feedback is concerned, it's difficult to ask
Swift contributors if they agree that none of the code they wrote is
necessary to call your product "powered by OpenStack". Of course they
won't agree: it's actually not a judgment of technical value, it's just
a trademark policy choice. By extension, it's difficult to ask the
Technical Committee, the body representing all those contributors, to
agree that part of the code they produce is not necessary or less
important. That body can only give one answer, and will continue to do so.

Now, that doesn't mean you can't get any technical input on the
Designated sections strawman, but quite the opposite: it just has to be
organized differently. There is still a lot of value in technical input
to precisely define desi
gnated sections lines in the case a project has
/some/ designated sections. For example for Glance, does it make
technically sense to consider the WSGI framework as replaceable or not.

So here would be my suggested way forward: for all the projects that
have "some" designated sections (Nova, Glance, Cinder), organize a
specific call/meeting calling all interested members of our technical
community (individual TC members, project PTL, any contributor
interested) to join and give feedback on the proposed split between
designated and non-designated code in their project. That could be a
30-min-per-project thing in a 90-min time span, or 3 separate meetings.

FWIW, personally, I think the proposed split on Nova, Glance and Cinder
makes technical sense.


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Swift designated section

I support the following list of designated sections for OpenStack Swift in Havana.

Designated Sections:
proxy server
middleware (to be detailed later)
object server
container server
account server
object expirer

Replaceable Sections:
DiskFile implementations
(future) DBBroker implementations
you may add new middleware

Unsure:
replicators
auditors
updaters
account reaper

--John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140901/00e15f2d/attachment.pgp

From: John Dickinson [mailto:me at not.mn]
I support the following list of designated sections for OpenStack Swift in Havana.

Thanks! That really helps narrow the discussion.

We'll setup detailed reviews of this over the next few weeks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Notes from Thursday Meeting with TC

DefCore,

We had an excellent attendance at today's DefCore/TC interlock meeting; unfortunately, we did not make much progress on review of the designated sections. The plan is to have a series of project specific meetings with the impacted PTLs (Nova, Glance, Swift, Cinder) to review the lists per project.

At this point, I would like to call for a single purpose Board meeting BEFORE the scheduled September meeting to allow discussion of designated sections at the board level. I believe that will be at least 90 minutes long: 30 minutes to review current state and 60 minutes of additional discussion. It would be wise to budget 2 hours.

I'm moving forward on the Thursday 9/10-9/11 community meetings we planned in Lighthouse.5 because I think community input is important before Board action. Please reply on this thread if you believe we should delay this schedule or change it.

I am working to coordinate the additional Technical meetings since we only discussed Swift and did not reach consensus. I am hesitant to extrapolate a pattern from the Swift discussion.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

[OpenStack-DefCore] FYI on Designated Sections JSON in Gerrit

DefCore,

Thought that you'd want to review (+1?) the JSON format for Designated Sections: https://review.openstack.org/#/c/119689/1/defcore/havanasections.json

I've tried to capture the current advice; however, my goal for this patch is FORMAT over content. I expect that we'll take patches on the content.

Please note that I've included a "status" field in the json so we can reflect the overall status of the file against the Board activity for the release.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140908/f97593eb/attachment.html

[OpenStack-DefCore] Updated Bylaws

It is a violation of Board policy to discuss this off of a public mailing list. CCing the defcore mailing list for transparency.

4.1(b)(i) changes are substantially out-of-line with the intended meaning of that clause - the TC is intended to manage the technical matters of all aspects of the openstack project, not just the integrated release. I believe these changes are unnecessary and have negative side effects.

4.1(b)(ii) conflates the Integrated Release with the broader OpenStack project again.

The introduction of the ?OSP New Definition Date? into the Bylaws seems bizarre. Why don?t we vote and approve these bylaw changes once the OSP process is ready, and then simply change the paragraph - instead of preserving THREE different definitions of core in the Bylaws? (In that vein, the second-to-last paragraph of this clause could be struck entirely.)

4.1.(b)(iii) - Could we move the last sentence (posting to the website) into Section 7.3 for clarity?

Is it ?Core OpenStack Project? or ?OpenStack Core Project?? 4.13(c)(i) and 4.1 don?t match. (Ditto 7.4)

4.13(c)(i) Seems like it could be simplified. Again, it seems like all of 4.13 would be simpler without the introduction of the OSP New Definition Date.

4.15 - I strongly object to using DefCore-related bylaws changes to make non-cosmetic changes to the Legal Affairs committee. This should be a separate set of redlines and a separate vote.

4.15 - The legal affairs committee should strive to protect the entire OpenStack project ecosystem, not just the integrated release, no?

4.17(a) - Unnecessary change. The Integrated Release is not a replacement for the term ?OpenStack project? - it?s a subset of the OpenStack Project, in the same way that Core is a subset of the Integrated Release. (ditto 7.4)

Ditto for 7.1(c) - The OpenStack foundation distributes project software beyond the boundaries of the Integrated Release, and we should continue to target ASLv2.0 for that.

7.3 - What does this mean? "The OpenStack trademarks shall only be used to promote the Foundation, the OpenStack Integrated Release or services related to the OpenStack Integrated Release as provided in the Trademark Policy.? I would think that the entire point of a trademark license would be for the licensee to be able to use the trademark under license to promote their own product or services.

Appendix 4, 3(b) - While I think this is an appropriate change, it?s actually out of scope for us to change the definition of ATC from ?Core contributor? to ?Integrated Release contributor? without checking with the TC. (Personally, I think ecosystem contributors should be considered ATCs as well).

Appendix 7 - Do we actually want to restrict the CLA to only cover contributions to the Integrated Release? We will have no way to promote code from Incubation to Integrated status with this approach. Again, see my comments regarding Integrated Release vs. Project, above.

--

Joshua McKenty
Chief Technology Officer
Piston Cloud Computing, Inc.
+1 (650) 242-5683
+1 (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."

On Sep 8, 2014, at 10:20 AM, Radcliffe, Mark <Mark.Radcliffe at dlapiper.com> wrote:

I would like to get your comments by Wednesday COB so we can post it for community comments. Thanks.

From: Radcliffe, Mark
Sent: Tuesday, September 02, 2014 12:11 PM
To: Rob Hirschfeld (rob_hirschfeld at dell.com); 'Joshua McKenty'
Cc: Roay, Leslie; Eileen Evans Esq. (eileen.evans at hp.com); 'Alan Clark'; 'Jonathan Bryce'
Subject: Updated Bylaws

I am enclosing the revision to the bylaws based on our discussion with the Rob to deal with issues from the Technical Committee. We have changed the approach to require the Technical Committee to get approval from the Board prior to making a change in the OpenStack Integrated Release which would delete any of the OpenStack Core Project. I also took another look the Standards provision in Section 7.4 and decided to make clear that it would not affect the new approach to determining the OpenStack Integrated Release and OpenStack Core Project. I am enclosing a markup to the existing version.

This draft has been approved by the Legal Affairs Committee. Please review it and provide any comments so we can put it on the website for community review prior to the September 22 Board meeting Thanks.


Please consider the environment before printing this email.

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster at dlapiper.com. Thank you.

Rob and Jonathan, thank you both for the clarifications. I see where we got wires crossed.

My only further concern is to make sure that, despite the convenience, each potential Bylaws change is structured as a separate redline, and voted on individually - both by the board, and by the membership. Specifically:

  1. DefCore-related changes that clarify the meaning of core, and the difference between integrated release and project.
  2. ATC-related changes that should be considered an amendment to the TC processes.
  3. Legal Affairs committee changes.
  4. Election reform (if we end up coming back to this one).
  5. CLA reform (again, if it comes back in).

Since I?ve seen scope creep on #2 and #3, I start to get worried about 4 and 5 - which would certainly nuke our chances of getting 1 through this window.

I believe the clarification of all of this is one of the things that got sacrificed at the last board meeting due to poor schedule management. Alan, can you make sure we have at least 30 minutes on the agenda for the next board meeting to talk about Bylaws amendments if there?s a goal of driving these forward? That would be on the general topic of making bylaws amendments, not any of the specific redlines that could be in the hopper.

--

Joshua McKenty
Chief Technology Officer
Piston Cloud Computing, Inc.
+1 (650) 242-5683
+1 (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."

On Sep 11, 2014, at 9:36 AM, wrote:

From: Jonathan Bryce [mailto:jonathan at openstack.org]
From Rob's earlier post it sounds like the DefCore process appendix is an absolute pre-requisite before
further review of Bylaws changes, even if that pushes the Bylaws changes out past 2015 Individual Member elections. Is that correct?

Yes, this has been requested as a pre-requisite several times (including at the Board meeting). I can't see how it would help at this point, but I'm happy to provide numerous references to this ordering going back to before ATL.

There is no need to risk the timelines. The purpose of a focus on the appendix (which was drafted in June: https://etherpad.openstack.org/p/DefCoreLighthouse.F2F ) was to make the bylaws changes very minimal.

Consequently:
1) the bylaws changes should be minimal and not require substantial review/discussion
2) the appendix does not require NOT community voting for future changes so the stakes are lower. We can make adjustments as a Board if needed.


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Suggestion to split by-laws changes into separte redlines for voting [was Updated Bylaws]

From: Joshua McKenty [mailto:joshua at pistoncloud.com]
My only further concern is to make sure that, despite the convenience, each potential Bylaws change is structured as a separate redline, and voted on individually - both by the board, and by the membership.

+1

I'd like to see other people object or +1 on this suggestion.

I agree that each of the focus areas for bylaws changes should be a separate vote. There should be the original language and proposed language for each bylaw change focus, along with what the bylaws would look like with each set of changes, plus with all the changes.

I would hate to have DefCore changes derailed by other, unrelated changes that may be more controversial (or vice versa for that matter).

--Rocky

-----Original Message-----
From: RobHirschfeld at Dell.com [mailto:RobHirschfeld at Dell.com]
Sent: Thursday, September 11, 2014 12:18 PM
To: joshua at pistoncloud.com
Cc: aclark at suse.com; eileen.evans at hp.com; defcore-committee at lists.openstack.org; Leslie.Roay at dlapiper.com
Subject: [OpenStack-DefCore] Suggestion to split by-laws changes into separte redlines for voting [was Updated Bylaws]

From: Joshua McKenty [mailto:joshua at pistoncloud.com]
My only further concern is to make sure that, despite the convenience, each potential Bylaws change is structured as a separate redline, and voted on individually - both by the board, and by the membership.

+1

I'd like to see other people object or +1 on this suggestion.


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Results from Community Meetings > discussion/+1 about reconsidering Havana Swift as a core capability

DefCore,

We just completed our two community meetings. Community attendance was light but the dialogs where good.

I am still working to get input from the PTLs against the designated sections; however, I do not think that we are blocked at this point with the following consideration: Swift capabilities should not be considered core for Havana.

I have gotten significant and consistent feedback that the two Swift capabilities should not be included in Havana Core. This has come from multiple sources, a variety of interests, and different reasons were given.

The final straw came today during community review of Swift when the point was made (by Doug Hellman) that if there are no designated sections that having required capabilities does not make sense.

While people arrive at this conclusion in different ways, I am confident in saying that community consensus is to reconsider Swift core capabilities.

I'd like your opinion (and/or +1) on presenting this to the board on Thursday before discussing the details of designated sections and process flow. I believe this change will greatly simplify the discussion and allow us to proceed with the DefCore process and results.

Thanks,

Rob


Rob Hirschfeld
Dell, Sr. Distinguished Cloud Solution Architect
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140911/64bccd84/attachment-0001.html

On Sep 12, 2014, at 11:19 AM, Russell Bryant wrote:

Signed PGP part
On 09/12/2014 10:56 AM, John Dickinson wrote:

On Sep 12, 2014, at 7:34 AM, Doug Hellmann
wrote:

On Sep 12, 2014, at 9:55 AM, Mark Collier
wrote:

I think your reasoning is sound, provided we don't make it
harder to follow through on "phase 2" of your proposal in
icehouse by conceding the removal of a requirement that is
intended to be quickly re-added.

That?s a fair point. I understood the intent of the DefCore
process to be to start small and slowly add to the set of
capabilities for subsequent releases, and adding object storage
capabilities and Swift designated sections seems to fit within
that process.

Unfortunately, at this point I have no idea what the objections are
currently (other than "the PTL and Piston, DreamHost, and IBM don't
agree"--and frankly I'm not sure what decision that's referring
to), and there is nothing that has been presented as steps to for
future inclusion or specific concerns to address.

So I too am concerned by inertia of removing a capability "intended
to be quickly re-added" when the current objections are
undocumented and there is no guidance for the future.

I agree that the objections need to be called out and not danced
around. From my perspective, it seems pretty clear that the issue is:

1) Some organizations want to provide object storage capabilities in
their product and not use Swift (or even any portion of Swift) to do so.

2) These organizations want to ensure that their choice in #1 does not
prevent their ability to use the OpenStack mark.

3) The proposed resolution to this issue by DefCore is to exclude
Swift completely from the requirements around the use of the OpenStack
mark.

The actual current proposal, if I understand correctly, is to require the Swift APIs be provided, but not require the use of Swift?s code to do so. We may be converging on dropping the requirement of the APIs, but I don?t think that?s settled.

I believe, and Rob please correct me if I misunderstood, that some distros would also like to provide an OpenStack product that doesn?t include object storage in any way (neither Swift nor Ceph). I?m not especially inclined to care about that use case, but it?s out there.

Other than those changes, your summary of the situation matches my understanding.

Regarding #1, one primary case is the use of Ceph. It would be nice
to respond to this case very directly. I know it has been discussed,
but is it written down? I'd love to see something (a blog post or
similar) that discusses:

  • how can ceph be used to back swift today?
  • if it can't, what work is required to make that possible?
  • if it's never going to realistically be an option, discuss why

The other case for #1 is some proprietary object store. The answer to
that really is the same as #1. As long as there is a reasonable way
for vendors to back swift with their thing, the objection is no longer
reasonable, IMO.

If someone shows up and just really wants to use some other thing
instead of Nova, does that mean Nova is kicked out? I sure hope not.
If not, then why treat Swift that way? If the issue is that backing
Swift with your "thing" isn't straight forward like backing Nova with
your "thing", then fine. Let's just lay out the path to get to that
point.

I don?t like ?treating Swift that way? either. But I prefer leaving out those capabilities for now over requiring its features but allowing someone else?s code to completely replace ours, because waiting leaves an opening to address the questions you raise above without allowing a toe-in-the-door for another solution to use the trademark without any designated Swift code at all. I?m afraid a capabilities-only solution would be far more difficult to undo than just saying that we haven?t completely addressed the issues around object storage yet and we?ll do that during the Icehouse DefCore review.

Just to be clear, then, I support either (a) including capabilities and the designated sections identified by the development team or (b) having no capabilities or designated sections. I do not support including capabilities without an implementation, for any project.

Doug

--
Russell Bryant

[OpenStack-DefCore] Designated Sections JSON for (re)review

All,

I think we are close, please review. https://review.openstack.org/#/c/119689/

I've addressed all issues that were brought to my attention.

Getting this patch in will allow the PTLs doing review to submit patches via Gerrit instead of relying on etherpad and email.

Thanks for your support.

Rob


Rob Hirschfeld
Dell, Sr. Distinguished Cloud Solution Architect
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140912/e3bd8179/attachment-0001.html

All,

I've made another patch to this file. If you can, please review.

The question of detailed attribution and technical discussion around statements for Swift designated sections has been generating -1s on the file as a whole. This new round omits comments on areas that are either non-consensus or non-core. These comments were seen as pre-wiring the decision.

Once the patch for the overall concept is landed, I am hopeful that we will have a healthy and positive discussion on the individual projects by the interested parties.

Getting the file in place is important so that we can start the process and I appreciate your taking time to participate.

Thanks,

Rob

From: Hirschfeld, Rob
Sent: Thursday, September 11, 2014 9:53 PM
To: Defcore-committee at lists.openstack.org
Subject: Designated Sections JSON for (re)review

All,

I think we are close, please review. https://review.openstack.org/#/c/119689/

I've addressed all issues that were brought to my attention.

Getting this patch in will allow the PTLs doing review to submit patches via Gerrit instead of relying on etherpad and email.

Thanks for your support.

Rob


Rob Hirschfeld
Dell, Sr. Distinguished Cloud Solution Architect
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Updated Bylaws

I agree with your comments and observations.

Thanks for taking the time to dig through it all!

On September 17, 2014 7:22:27 AM Mark McLoughlin wrote:

This feels like deja-vu, but I just spent some time reviewing the wrong
version of these changes before finding the right one.

For the avoidance of doubt, I think this document:

Change-Pro Redline - 233015232-v15-OpenStackFoundation Bylaws FINAL (as
amended September 7, 2012) and 233015232-v24-OpenStackFoundation Bylaws FINAL

is the one we should all be looking at. It shows the changes between the
current bylaws (v15) and the latest proposed changes (v24). I would
really like that document to be published somewhere that we can all
easily refer to rather than it being forwarded around over email.

The main thing that occurs to me is that I wonder why we're perpetuating
this "Core OpenStack Project" term at all. I found this email from
Jonathan extremely instructive:

http://lists.openstack.org/pipermail/foundation/2014-June/001701.html

The intent is of the "Core OpenStack Project" is to help define the
requirements for commercial trademark usage, but we now have
"capabilities" and "designated sections" to define that. The perception
that the "Core" term creates is there is a subset of the Integrated
Release that the board approves of, and by extension a subset that they
disapprove of.

If we now have a clear way of defining the requirements for trademark
usage, I really don't understand why we're seeking to perpetuate the
confusion and controversy created by the "Core OpenStack Project" term.

As for removing the trademark policy from the bylaws, I see the policy
as a high-level set of principles about how the trademarks should be
managed and I'm fine with those principles requiring bylaws changes.
However, specific implementation details of those principles (like the
exact set of trademark programs) should determined by the board.

In other words, if there are parts of the trademark policy which are
"implementation details" which we feel should be determined by the
board, why not just remove those details from the policy?

More specific comments below.

Mark.


4.1

  • The Technical Committee is responsible for managing the OpenStack
    Project, not simply the Integrated Release.

  • I don't know that the sentence "the OpenStack Project shall include
    the" is all that useful, and the new wording really doesn't clear up
    any of the confusion it has caused.

  • The whole "New Definition Date" thing is extremely awkward.

  • This section has been a constant source of confusion and
    controversy. I think the proposed changes are simply going to cause
    more of the same. We should step back and think about what this
    paragraph is attempting to get across. The proposed changes will not
    eliminate the confusion and controversy.

  • "The use of the OpenStack trademarks on the Core OpenStack Project
    shall be defined in the Trademark Policy in Section 7.3." - I think
    that overstates the purpose of the policy. The policy does little
    more than define some high level principles and leaves the way open
    for defining additional programs.

4.13

  • In 4.13(c)(i) we're now requiring the TC to seek board approval
    before removing certain capabilities/code from the Integrated
    Release. I understand that the intent is to avoid poorly handling
    the removal of parts of OpenStack which we see as critically
    important, but I really think we need to trust the TC to manage
    this correctly rather than requiring board sign-off. Imagine the
    Nova v2 is communicated as deprecated for multiple cycles before it
    is removed, and then the TC seeks approval for this in advance of
    the release but the board refuses. Then what?

  • Again, the whole "OSP New Definition Date" thing seems overly
    involved.

4.15

  • IMO, we should just remove the definition of the Legal Affairs
    Committee from the bylaws. I don't see why it shouldn't be like any
    other board subcommittee so that it can be evolved without bylaws
    changes.

  • The emphasis on the Integrated Release is weird/wrong here. What
    was wrong with including the entire OpenStack Project in the remit
    of the committee?

4.17

  • Again, emphasizing the Integrated Release seems wrong.

7.1

  • The "Project" to "Integrated Release" change here implies that the
    Foundation may distribute software under a license other than the
    Apache License 2.0. I doubt that's intentional.

7.3

  • I'm not sure I see why the trademark policy needs to be determined
    by the board. Again, we need the board to be able to determine the
    "implementation details, but not the high level principles.

Appendix 7

  • "The OpenStack Integrated Release must have a CLA on file" makes no
    sense.


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-----Original Message-----
From: Thierry Carrez [mailto:thierry at openstack.org]
Sent: Friday, September 19, 2014 7:29 AM
To: Mark McLoughlin; Radcliffe, Mark
Cc: aclark at suse.com; defcore-committee at lists.openstack.org; eileen.evans at hp.com; Roay, Leslie
Subject: Re: [OpenStack-DefCore] Updated Bylaws

Mark McLoughlin wrote:
This feels like deja-vu, but I just spent some time reviewing the
wrong version of these changes before finding the right one.
[...]

I fully agree with your analysis. Two items are of particular concern:

  • the general search/replace of "the OpenStack Project" by "the OpenStack Integrated Release" reduces the reach of the TC to integrated projects only, which would place critical release-building functions (like release management or infrastructure) out of the TC authority under the bylaws. That's pretty wrong; both from a technical standpoint and a governance standpoint.

RESPONSE: These comments are the reason that we are getting the DefCore review. As I noted to Josh and Mark, we will change Integrated Release to OpenStack Project.

  • the "ask for permission before removing" is, as you clearly mention, impractical. That creates an area where disagreement between the board and the TC would end up being paid by our users (we could be forced to keep around things we technically deprecated and nobody maintains), which I think is unacceptable.

My other concern is that those changes seem to fail to address the issues in the current bylaws. Our bylaws are currently hopelessly out of date because they are not flexible enough and they are hard to change.
Rather than taking this opportunity to clean the mess up, we seem to perpetuate old concepts like "the Core OpenStack Project" or the "Definition Date", while we should have learned by now that in bylaws, less usually means more.

The situation is actually really, really simple: the TC is responsible for a set of code repositories collectively known as "the OpenStack project", which aim to fulfill the OpenStack Mission. Even speaking of the "Integrated Release" is treading on an implementation detail, which may prevent further evolution ! The "Core OpenStack Project" is an historical artifact, and trademark policy now uses much more quantifiable concepts (like capabilities and designated sections), so I don't see the value of continuing to mention it in the bylaws themselves.

Personally I would just get rid of any mention of "Core OpenStack Project" and "Integrated release" in the bylaws, and only keep "the OpenStack Project". That would give us flexibility we need to evolve in the future, both on the TC side and on the Trademark policy side.

RESPONSE: Let's make sure that we remember the background: the Board (and I) agree that the current bylaws are too detailed and too difficult to change. The DefCore process was started by the Board in November to determine how to redefine the process. However, the requirement that changes in the Core require Board approval has been part of the bylaws from the Foundation's beginning (see below). In fact, DefCore is a committee appointed by the Board to determine how to define Core in the future. The Board certainly wants to define those capabilities with the Technical Committee input and has been doing so, so I think that you concern about a disagreement between the Board and the TC are misplaced. However, the Board does have responsibility for trademark policy , if certain code or functionality is required for trademark use, the Board needs to be able to control any proposed deletion to such code/functions. For example, if the trademark policy specifies "designated code" and the Technical Committee deprecates that designated code, what does it mean to have a trademark policy? As I noted to Mark, in the original bylaws, the Technical Committee did have the exclusive right to make proposals to change the scope of Core. I included that approach in the draft this summer, but I was told that the Technical Committee was not interested in continuing that approach. If that view has changed, we should discuss it.

            (b)       The Technical Committee shall have the authority to determine the modules for addition, combination, split or deletion from the OpenStack Project except for modules of the Core OpenStack Project (as defined in Section 4.1(b) above) which shall be managed as provided below.  For modules of the Core OpenStack Project, the Technical Committee may recommend to the Board of Directors the modules for addition, combination, split or deletion from the Core OpenStack Project.  Except as provided below, the Board of Directors shall consider only those additions, combinations, splits or deletions that are recommended by the Technical Committee, but shall have the sole authority to approve or reject such additions, combinations, splits and deletions from the Core OpenStack Project. If any software in the Core OpenStack Project is (i) subject to an injunction or other court order which would subject the distributors or users of such software to liability for intellectual property infringement or misappropriation or (ii) the majority of the Board of Directors believes that such an order is reasonably likely, the Board of Directors shall give notice to the chair of the Technical Committee of the issue. If the Technical Committee does not take reasonable steps to mitigate the risk  (such as ceasing distribution of such software or modifying such software to make it non-infringing) as determined by the Board of Directors within thirty (30) days of the receipt of such notice, the Board of Directors may waive the requirement in the Trademark Policy or otherwise to include such software in a distribution in order to use the OpenStack trademarks.

We need the three definitions for the following reasons:

  1. Core OpenStack Project: The parts of the distributed code/capabilities required for trademark use. Since the Board is responsible for the trademark policy, they need input on removing these functions/designated code.

  2. Integrated Release: The parts of the OpenStack Project (of which the Core OpenStack Project is a subset) which are distributed and need to be under the Apache License version 2.0. The definition of what goes into the Integrated Release is completely in the discretion of the Technical Committee except that it needs to be available under the Apache Software License version 2.0.

  3. OpenStack Project: All of the code managed or used by the OpenStack community (of which the Integrated Release and the Core OpenStack Project are subsets) whether distributed or not. The code that is not distributed does not need to be under the Apache Software License version 2.0 which gives the Technical Committee more flexibility.

I don't understand how defining Integrated Release impinges on implementation details (see above). However, if you can explain the concern, I will work to resolve it.

--
Thierry Carrez (ttx)

Please consider the environment before printing this email.

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster at dlapiper.com. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Results from Community Meetings > discussion/+1 about reconsidering Havana Swift as a core capability

(Top posting because this veers significantly and because Outlook has really sucky reply options)

It just struck me that the "OpenStack Powered" discussion is really just another version of the "Made in America" discussion. And the solution to that eventually evolved into:

Designed and Manufactured in America

% Manufactured (sourced) in America

Assembled in America

(probably others)

Extrapolating from this and various Defcore discussions:

? We have already defined the core parts of projects vs. non-core as:

o Plugins are not core

o Extensions are not core

o Immature features are not yet core

? Trademark definition is not an engineering issue, it is a business issue

? One Trademark will not satisfy how the community wants to use the OpenStack bits

So, how about we turn this whole thing on end.

? We keep Capabilities as defined by maturity, integration and deployment

? We keep Interop Tests as a certification of Capabilities inclusion in products

? We come up with a %OpenStack based on something like APIs, functionality, LOC (I don?t recommend this one) and come decide on a minimum percentage to be met to call a product ?powered by OpenStack? or ?Built on OpenStack? or ?100% OpenStack? or etc.

This approach allows large inclusion of the mature parts of the OpenStack integrated codebase (developers are happy) but doesn?t require any specific part of the codebase be included (keeps vendors happy). The IBM Cloud Storage product might include 100% of Swift, but maybe replaces Horizon and might be 70% OpenStack (Or even 100%) with no Nova code or APIs. Their compute cloud might end up 65% OpenStack based on 100% Nova and some extra code for a proprietary Hypervisor.

Right now I see that the Foundation would have to rely on Vendors to self-report how much extra code that replaces existing OpenStack DefCore capabilities is in their product, but that?s not something that hasn?t been considered before as a short term option.

This approach also gets DefCore out of the politics of Trademark and Business and back to the technical evaluation of maturity (and future direction) of specific OpenStack Integrated features.

Comments? Discussion? Flames?

--Rocky

Trying to think around the box

-----Original Message-----
From: Mark McLoughlin [mailto:markmc at redhat.com]
Sent: Wednesday, September 17, 2014 7:34 AM
To: Doug Hellmann
Cc: Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Results from Community Meetings > discussion/+1 about reconsidering Havana Swift as a core capability

On Wed, 2014-09-17 at 10:17 -0400, Doug Hellmann wrote:

On Sep 17, 2014, at 4:29 AM, Mark McLoughlin wrote:

On Fri, 2014-09-12 at 09:38 -0400, Doug Hellmann wrote:

The point I have been trying to make is that because our community

creates code and not standards, we should not simply trademark an API

without including the implementation.

To make sure the basic point isn't getting lost - we're talking about

the requirements for products and clouds that wish to use the "OpenStack

Powered" trademark. We're not "trademarking an API?.

If the cloud or product does not include the OpenStack implementation,

how is it ?Powered? by OpenStack? I could see saying ?Compatible with?

or something like that. Maybe I?m reading too much into the word

?Powered?.

Yes, a trademark license that just required API compatibility would be a

different thing.

That doesn't mean that some part of every capability needs to be

"OpenStack Powered".

We want there to be a vibrant commercial ecosystem of "OpenStack

Powered" products and clouds. But we also want to ensure that such

products offer an experience which reflects well on our brand and

encourages healthy engagement with our community.

i.e. at least three things to balance - growing this commercial

ecosystem, making sure the brand isn't damaged and growing our

community.

If the implementation of a capability offers users a good experience and

the vendor is engaged with our community in good faith, then I'd err on

the side of allowing the use of the trademark since they will grow the

commercial ecosystem.

So if they are engaged in one area (Nova) but not in another (Swift)

they are allowed to replace the component entirely with their own?

That feels very strange. We don?t apply that logic to any other

component.

Swift is different because it doesn't have "pluggable backends".

Part of my "good faith" criteria here is that (some, at least) of the

vendors who implement a Swift compatible API without using Swift code

need to be engaged with evolving Swift so they can use it.

(The only real data I have on that is that some Red Hat affiliated

developers have been contributing in this area, but this isn't a Red Hat

concern - I don't think the decision affects Red Hat's ability to

license the trademark.)

Point is that this is the kind of stuff that I'd like to hear more about

during the debate, rather than talking in the abstract about

"capabilities must also have designated code".

I don't like to see us making rigid rules like "required capabilities

must have some designated sections", because such rules are so far

removed from the nuanced non-technical considerations we should be

making about trademark usage.

This is a nuanced issue, no doubt. Maybe we should be reconsidering

the idea that we only want to have one trademark. A single mark

doesn?t seem to support the varied ways the ecosystem wants to use

OpenStack in their products while also making clear how those products

differ from each other.

Agree :)

http://lists.openstack.org/pipermail/foundation/2014-July/001709.html

At the same time, there's a balance to be struck - too many trademark

programs and they all begin to lose meaning because no-one can keep

track of the differences between them.

Mark.


Defcore-committee mailing list

Defcore-committee at lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140917/bbc7f689/attachment-0001.html

[OpenStack-DefCore] Updated Bylaws

+1000

On Sep 22, 2014 4:47 AM, Mark Collier wrote:

Well said

On September 22, 2014 2:54:52 AM Thierry Carrez wrote:

Radcliffe, Mark wrote:

The situation is actually really, really simple: the TC is responsible
for a set of code repositories collectively known as "the OpenStack
project", which aim to fulfill the OpenStack Mission. Even speaking of
the "Integrated Release" is treading on an implementation detail, which
may prevent further evolution ! The "Core OpenStack Project" is an
historical artifact, and trademark policy now uses much more
quantifiable concepts (like capabilities and designated sections), so I
don't see the value of continuing to mention it in the bylaws themselves.

Personally I would just get rid of any mention of "Core OpenStack
Project" and "Integrated release" in the bylaws, and only keep "the
OpenStack Project". That would give us flexibility we need to evolve in
the future, both on the TC side and on the Trademark policy side.

RESPONSE:? Let?s make sure that we remember the background: the Board
(and I) agree that the current bylaws are too detailed and too difficult
to change. The DefCore process was started by the Board in November to
determine how to redefine the process. However, the requirement that
changes in the Core require Board approval has been part of the bylaws
from the Foundation's beginning (see below). In fact, DefCore is a
committee appointed by the Board to determine how to define Core in the
future. The Board certainly wants to define those capabilities with the
Technical Committee input and has been doing so, so I think that you
concern about a disagreement between the Board and the TC are misplaced.
However, the Board does have responsibility for trademark policy , if
certain code or functionality is required for trademark use,? the Board
needs to be able to control any proposed deletion to such
code/functions.? For example, if the trademark policy specifies
"designated code" and the Technical Committee deprecates that designated
code, what does it mean to have a trademark policy?? As I noted to
Mark,? in the original bylaws, the Technical Committee did have the
exclusive right to make proposals to change the scope of Core.? I
included that approach in the draft this summer, but I was told that the
Technical Committee was not interested in continuing that approach.? If
that view has changed, we should discuss it.

I think the view of the TC is that we produce a number of projects and
that at every release, the Board picks subsets of those projects to use
for various trademark policies. For example, for havana, the board picks
"designated sections" among the "integrated release" to use with the
"Powered by OpenStack" trademark. For icehouse, it may pick other
projects among those we produce. At every release, the TC creates the
superset and the Board picks the subset(s). The TC is not interested in
proposing subset(s). And the board should not prevent removals from the
superset.

If a given project is abandoned by all developers and no longer part of
the integrated release, having the board mandate that it's still part of
the integrated release would be awkward. Now, I understand the intent --
we don't want to bluntly deprecate / remove items that have become part
of trademark rules. But the TC has structure in place for deprecation /
removal of features already (takes at least two cycles), so I think that
concern can be solved without having the Board step into TC territory in
the definition of the superset.

[...]
We need the three definitions for the following reasons:

1.????? Core OpenStack Project: The parts of the distributed
code/capabilities required for trademark use. Since the Board is
responsible for the trademark policy, they need input on removing these
functions/designated code.

2.????? Integrated Release: The parts of the OpenStack Project (of which
the Core OpenStack Project is a subset) which are distributed and need
to be under the Apache License version 2.0. The definition of what goes
into the Integrated Release is completely in the discretion of the
Technical Committee except that it needs to be available under the
Apache Software License version 2.0.

3.????? OpenStack Project:? All of the code managed or used by the
OpenStack community (of which the Integrated Release and the Core
OpenStack Project are subsets) whether distributed or not. The code that
is not distributed does not need to be under the Apache Software License
version 2.0 which gives the Technical Committee more flexibility.

I don?t understand how defining Integrated Release impinges on
implementation details (see above). However, if you can explain the
concern, I will work to resolve it.

I'll expand on my comment. I think that ideally, we would not have to
change bylaws every time we adapt our processes or trademark license
programs. Ideally, the language in the bylaws would let us some
maneuvering room so that we don't constantly have to consider costly
changes to them (especially around the protected sections). Therefore I
think the language in the bylaws should avoid unnecessary details as
much as possible.

The "Core OpenStack Project" is a detail. It's a subset of projects that
the future "powered by OpenStack" trademark policy will use. Actually,
the policy doesn't even mention "core" anymore, but uses "designated
sections" and "required capabilities", which are much more descriptive.
What if tomorrow we want to have two trademark policies (add "OpenStack
compatible") which affect different subsets of projects, and the bylaws
only define one ? Saying that "the board may pick any subset of the
OpenStack Project as they deem necessary to use as part of trademark
license programs definition" gives the board much more room to evolve
trademark policies in the future without requiring a new bylaws change.

The name "integrated release" is also a detail. If the projects in the
release stop being "integrated" or the release becomes staggered, it
should not prevent the board from picking a subset of it for trademark
policies. That said, I think we can live with this one being in the
bylaws, since there will probably always be a concept that we can map to
it in the future, so it should not really prevent anything from
happening (or require a bylaws change one year down the road).

That said, I'm not a lawyer... you certainly know better than I do about
required language. My concern is about agility. IMHO our bylaws set too
much in stone, so we can't undertake any change in policy without
changing them, and it takes a couple of years to do so.

--
Thierry Carrez (ttx)


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier

All,

Last Thursday, the board did not act on any of our recommendations. The Board is reconsidering one of the guiding principles from Hong Kong - DefCore is trying to define a minimum base definition for OpenStack. Instead, they've asked us for multiple Trademark proposals.

ACTION ITEM: I'd be interested in hearing suggestions from the committee that we can use as the basis for a etherpad.

Towards that end, I think we should schedule a meeting on Thursday 10/2. I'm open to having a working session before that to brainstorm options (possibly with Mark or Jonathan).

I'd ask you to consider two items in preparation:

1) Sean Dague's Layers Model: https://dague.net/2014/08/26/openstack-as-layers/

2) Consideration of OpenStack as a product or "big tent" which seems to be part of the OpenStackSV output: Monty http://inaugust.com/post/108 and Randy http://siliconangle.com/blog/2014/09/17/the-achilles-heel-of-openstack-is-lack-of-product-leadership-openstacksv/

Rob


Rob Hirschfeld
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140922/71a8cb4d/attachment-0001.html

Simon,

Glad you are sharing this feedback with me (and the list). Throughout this process, we (and I personally) have adapted to significant community feedback and responded in a measured way. I take my role as a neutral representative very seriously and strive to speak for many opinions that I?ve heard instead of my own position. That includes positions that YOU have stated. I?d happily allow someone else to lead (or co-lead) this process ? it has been a substantial personal investment for which I?ve drawn negative attention and comments.

Regarding ?thrash? ? I do believe that is the correct term. If the OpenStack board is to succeed, we need to have working sessions and committee discussion that actually produce real results. DefCore had a very open dialog about these issues leading up to the Board meeting. Unless we want to meet much more often (which I would support) then the Board members with strong positions should be active in the committees so that all sides of the issue can be heard where there is sufficient time to address them. If any of these issues were raised before the meeting based on the detailed report I submitted then I would have withdrawn the recommendations and allowed time for other topics.

Personally, I think additional marks are reasonable. They have been part of the stated plan from the start and we intentionally delayed them so that we nail down the smallest definition first. If that is now considered blocking progress then let?s address the suggest marks and keep moving.

Rob

From: Simon Anderson [mailto:simon at dreamhost.com]
Sent: Tuesday, September 23, 2014 1:04 PM
To: Hirschfeld, Rob
Cc: Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Suggestions on trademark changes, possible meeting 10/2 or earlier

Rob, candidly, I think you are way overstating things and being disrespectful of the Board in referring to the careful discussion and debate around DefCore as "thrash".

The Board is very diverse, as it should be, and in the thick of considering an extremely important issue that will have ramifications for the health and growth of the OpenStack community in years to come. It's very important that members of the Board feel fully able to take time to consider and respond to evolving community inputs on DefCore, without being criticized for not dancing to any other stakeholders tune.

I think you are getting too personally attached to the DefCore process. You've been instrumental in leading it so far, but you should carefully think about whether you can shift to the more patient, objective and non-judgmental approach that will be needed to see it through to its conclusion.

Best,
Simon

On Tue, Sep 23, 2014 at 9:36 AM, > wrote:
Dell Customer Communication

From: Simon Anderson [mailto:simon at dreamhost.com] Hi Rob, I may have
heard a different output from the Board call - which was that the Foundation staff would work on some multi-TM proposals and share them with the DefCore committee/Board. So Jonathan, Mark and Lauren may already be working on them.

Simon, I heard a lot of different positions taken. There was no clear guidance from the board in this regard and I believe our charter is to propose a variety of options for discussion. One could/should be "stay the course" and others should explore "levels" like the TC are discussing. Another path would be to accelerate the "submarks" like you've suggested as an addition to the core/base mark we've put into the process.

My issue is NOT with the changes proposed (there are several reasonable options) but with the continuous thrash in the board meeting that dilutes our effectiveness. These issues and discussions should have been raised before the meeting so that we could adjust the agenda.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Updates to Havana Capabilities, reviews welcome

Defcore,

Julia Shapovalova has been working to repopulate the HavanaCore templatehttps://github.com/stackforge/refstack/blob/master/defcore/havanacore.json with the correct test references based on our original analysis.

She has broken the tests by project to make it easier to review. If you are interested, please review her pulls:

Thanks,

Rob


Rob Hirschfeld
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140923/75044fd8/attachment.html

[OpenStack-DefCore] The follow-on ML thread from Monty's reorg post

This thread is the ML masticating on Monty's post about how to reorg the OpenStack human and technical organization. I think this has much food for thought for this ML, also and for DefCore's ML:

http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html

This reinforces the mark as three sets:

  • Distro mark

  • Certified - (DefCore defined 12 areas of maturity and reach) of any OpenStack project

  • Foundational - (Powered by - or Layer 1 in the discussion)

It reinforces the mission of DefCore as defining those aspects of any and every OpenStack big tent project as mature through the DefCore analysis process and the Refstack certification process. The other thing this discussion really showcases is how important Refstack will be as interoperability will become crucial for the higher layer projects.

--Rocky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140924/21fcda10/attachment.html

From: Rochelle.RochelleGrober [mailto:rochelle.grober at huawei.com]
This reinforces the mark as three sets:
* Distro mark
* Certified - (DefCore defined 12 areas of maturity and reach) of any OpenStack project
* Foundational - (Powered by - or Layer 1 in the discussion)

Where does Swift (which seems to be our wedge) fit into those marks? I thought it was not included in layer 1.

Also, does Certified includes designated sections? Are we ready for API only validation?

[OpenStack-DefCore] progress - met w/ Foundation

DefCore,

Since we're time sensitive, I wanted to let you know that I had a working session with the Foundation staff Friday. Alan and Troy also participated.

We laid out a some options that Mark will review on the list next week. I think it was a very positive and productive discussion. I'm optimistic that we have some good suggestions that will address the concerns raised by the Board.

Also, I'd like to thank those of you who reached out 1x1 after the last Board meeting.

Rob


Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20140927/6db57b95/attachment.html

Thanks SImon and Tim for reading and considering the proposal. It?s a lot of words I know :)

The rationale behind it was to take the existing 2 programs that fall under ?Powered? and update the technical requirements per Defcore output (to make it easy of existing licenses to understand and implement), and to add a 3rd ?component? oriented Powered Program for ?Compute? to address the use case that seemed to be a sticking point for some key stakeholders, namely the lack of Swift code in a Computing context (e.g. Nebula, Dreamhost, and others).

My view is that by following the ?storage? precedent, which is an existing ?component? Powered Program with qualifiers in the naming rights to educate the market, we are operating under the existing framework for licenses to address the case without having to rush into a ?compatible? type program that doesn?t require any code and is API only. While I do think a ?compatible? program for APIs only is likely in the future, I personally would prefer not to rush into it if we can address it via this addition of a 3rd ?Powered Program?. For one thing, our test coverage may not yet be high enough to have full confidence in assuring it really is ?compatible? by testing alone. The code piece adds a level or assurance that we?re not going to let end users down.

Regarding the ?Compute Powered Program? that is proposed, one thing we may want to consider is adding something like ?If your compute product or service does enable object storage as a service, you must enable the object storage capabilities" (read: pass the API tests but not include the code). This deviates a bit from the Storage Powered Program precedent so I was hesitant to include it in the proposal, however it does actually mirror the implementation of the cases we were trying to address (e.g. Nebula, Dreamhost) so it might be a shame to not give them (you) credit for having the APIs on top of an alternate back end, which is unquestionably a benefit for interop. And at the same time, if someone has no object storage as a service at all, we don?t force it on them. The proposed framework actually doesn?t make this decision per se it says Defcore would determine the appropriate subset of capabilities relevant to ?compute? so maybe we could go this route under the proposed Compute Powered Program in the table I put together (see link: https://docs.google.com/a/collierclan.net/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit https://docs.google.com/a/collierclan.net/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit )

Regarding the point that several have raised that an ?OpenStack Powered Storage? program is object storage specific and doesn?t allow for something like a Cinder or Manila, I would just say that we ought to consider that in the future. I see no reason not to. However, for getting us through this very important evolution that we are on the cusp of, which in my mind is a huge leap forward from the status quo we are operating under every day until we make a change, I?d suggest we table that for a future cycle or two. Certainly for Manlia which is not integrated. There?s nothing inherent in the framework that would prevent it.

In some important ways we haven?t really iterated in 4 years on the basic requirements, and so I for one am very eager to take the very thoughtful work defcore has done, map it to existing concepts into this framework with a few tweaks based on the last board meeting, and implement the hell out of it.

We are so close! Let?s do this!

Mark

On Oct 1, 2014, at 7:13 PM, Simon Anderson wrote:

Mark, on first pass, I see the merit of the Program approach and detail you have described. I'd also like to hear thoughts on Tim's question.

Best,
Simon

On Wed, Oct 1, 2014 at 10:59 AM, Mark Collier > wrote:
Background:

On a day to day basis, Foundation employees manage the various trademark license Programs (working with our trademark attorneys as needed). A ?Program? provides a license for use of the trademarks in commercial contexts, executed between a company in the ecosystem and the Foundation, specific to a product or service. Note: There are multiple Programs (e.g. ?OpenStack Powered?, ?OpenStack Powered Storage?, ?OpenStack Training?).

A Program typically includes access to a particular commercial-use logo (e.g. ?OpenStack Powered?) and some ability to use the word ?OpenStack? in the product name and marketing collateral (this is known as the ?wordmark? in legalese). A signed contract is required, and there are technical requirements to qualify which include API Capabilities inclusion of specific upstream code (a la Designated Sections).

Now that we?re nearing the end of the initial DefCore committee work for Havana, the Board felt it was a good time for the Foundation staff to look at how we might map the DefCore Capabilities and Designated Code to existing or new licensing Programs. Jonathan and I are working on a proposal for the October 20th Board Meeting and want as much input as possible prior.

This mapping will give everyone another level of understanding regarding how the DefCore components will play out in the market under such Programs, and ultimately give the Board something that they?re confident voting for to move this to implementation phase soon.

Note that while the Board DID approve the Havana Capabilities in the July Board meeting, they did not approve the proposed update in the September Board meeting, citing various concerns, including the status of Swift and a lack of clarity about how the requirements would play out with our trademark licensees. I believe that by illustrating the different Programs that we would expect to implement with respect to the DefCore work, along with some tweaks to the Designated Sections themselves, we can all get on the same page. We are very close.

What you?ll see is in practice it?s not an either/or thing with Swift because we have more than one Program to address different markets and choices. Multiple Programs is not a new concept.

For the purposes of this email I?m going to focus on the ?OpenStack Powered? Programs, summarize the requirements and benefits today, then suggest a way that we could map the DefCore output to the two existing programs in a practical way, while adding a third program to address a specific use case. All without creating any more logos.

I believe this proposal can address the many different stakeholders' input to date, the incredible work of DefCore, TC and community input, while keeping true to our goal of improving interoperability.

Note: I strongly advise you check the Google Doc version because a table is a lot easier to follow:
https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing

?OpenStack Powered? Programs today:
1) Program Name: OpenStack Powered
Requirements: Nova and Swift code included, Nova and Swift APIs exposed
Benefits: Can use ?OpenStack Powered? logo, can use ?OpenStack? in product name within guidelines
2) Program Name: OpenStack Powered Storage
Requirements: Swift code included and Swift APIs exposed
Benefits: Can use ?OpenStack Powered? logo, can use ?OpenStack Storage? in product name within guidelines
? Note: Has more restrictive rights, such a requirement to include ?Storage? qualifier in product marketing

Future Programs mapped to DefCore
1) Program Name: OpenStack Powered Platform
? Requirements: All Capabilities required by Defcore, All Designated Sections from Defcore, Pass Tests
Benefits: Can use ?OpenStack Powered? logo, can use ?OpenStack? in product name within guidelines ? has broadest rights to use the name, such a ?ACME OpenStack? for a distro and ?ACME OpenStack Cloud? for a public cloud service
2) Program Name: OpenStack Powered Storage
Requirements: All object storage specific Capabilities from Defcore, all Swift specific Designated Sections from Defcore, Pass Tests
Benefits: Can use ?OpenStack Powered? logo, can use ?OpenStack? in product name within guidelines.
Note: Has more restrictive rights, such as requirement to include ?Storage? qualifier in product marketing

3) Program Name: OpenStack Powered Compute
Requirements: All compute specific Capabilities from Defcore, all Nova, Glance, Cinder specific Designated Sections from Defcore, Pass Tests
Benefits: Can use ?OpenStack Powered? logo, can use ?OpenStack? in product name within guidelines
Note: Has more restrictive rights, such as requirement to include ?Compute? qualifier in product marketing.

*For implementation, Defcore would need to group subsets of the overall output. For example:
? Platform - no need to group as this is the superset. Suggest adding Swift Designated Sections for Havana based on input from September, and Keystone in Icehouse/Juno based on user input from Das Kamhout & Tim Bell)
? Storage - subset focused on Object Storage Capabilities and Designated Sections
? Compute - subset including the Nova, Glance, Cinder for Havana. Suggest adding others as they are included in future releases (e.g. Keystone)

All of this is also captured in a Google doc that is frankly more readable due to the table and formatting:
https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing

On Sep 27, 2014, at 6:09 AM, Rob_Hirschfeld at Dell.com wrote:

To clarify, Mark Collier. We have a lot of Marks working on marks.

<>From: Hirschfeld, Rob
Sent: Saturday, September 27, 2014 12:20 AM
To: Defcore-committee at lists.openstack.org
Subject: [OpenStack-DefCore] progress - met w/ Foundation

DefCore,

Since we?re time sensitive, I wanted to let you know that I had a working session with the Foundation staff Friday. Alan and Troy also participated.

We laid out a some options that Mark will review on the list next week. I think it was a very positive and productive discussion. I?m optimistic that we have some good suggestions that will address the concerns raised by the Board.

Also, I?d like to thank those of you who reached out 1x1 after the last Board meeting.

Rob
Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 <tel:%2B1%20512%20909-7219> blog robhirschfeld.com , twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Discussion Session on 10/2 @ 10:30 PT - open agenda

All,

We don't have the notes from the Foundation session yet; however, I'd like to suggest a DefCore discussion about possible changes based on the last Board meeting.

I don't have a formal agenda and am not setting up an etherpad. I am hoping simply talk over the ideas on the table and review alternatives.

Thursday 10/2 @ 10:30 PT (12:30 CT)

Join the meeting: https://join.me/783-950-673

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me apphttps://join.me/app and enter meeting code: 783-950-673

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - Thousand Oaks, CA +1.805.309.5900
Access Code 783-950-673#

Other international numbers availablehttps://join.me/intphone/783950673/0

Rob

From: Hirschfeld, Rob
Sent: Monday, September 22, 2014 5:09 PM
To: Defcore-committee at lists.openstack.org
Cc: jonathan at openstack.org; 'Mark Collier'
Subject: Suggestions on trademark changes, possible meeting 10/2 or earlier

All,

Last Thursday, the board did not act on any of our recommendations. The Board is reconsidering one of the guiding principles from Hong Kong - DefCore is trying to define a minimum base definition for OpenStack. Instead, they've asked us for multiple Trademark proposals.

ACTION ITEM: I'd be interested in hearing suggestions from the committee that we can use as the basis for a etherpad.

Towards that end, I think we should schedule a meeting on Thursday 10/2. I'm open to having a working session before that to brainstorm options (possibly with Mark or Jonathan).

I'd ask you to consider two items in preparation:

1) Sean Dague's Layers Model: https://dague.net/2014/08/26/openstack-as-layers/

2) Consideration of OpenStack as a product or "big tent" which seems to be part of the OpenStackSV output: Monty http://inaugust.com/post/108 and Randy http://siliconangle.com/blog/2014/09/17/the-achilles-heel-of-openstack-is-lack-of-product-leadership-openstacksv/

Rob


Rob Hirschfeld
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141001/616a84f5/attachment.html

All,

I had setup the wrong day (10/1) in Join.me! The correct code is 549-006-316 (or https://join.me/549-006-316).

My apologies, call starting right now.

Rob

From: Hirschfeld, Rob
Sent: Wednesday, October 01, 2014 12:18 AM
To: Defcore-committee at lists.openstack.org
Cc: 'jonathan at openstack.org'; 'Mark Collier'
Subject: Discussion Session on 10/2 @ 10:30 PT - open agenda

All,

We don't have the notes from the Foundation session yet; however, I'd like to suggest a DefCore discussion about possible changes based on the last Board meeting.

I don't have a formal agenda and am not setting up an etherpad. I am hoping simply talk over the ideas on the table and review alternatives.

Thursday 10/2 @ 10:30 PT (12:30 CT)

Join the meeting: https://join.me/783-950-673

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me apphttps://join.me/app and enter meeting code: 783-950-673

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - Thousand Oaks, CA +1.805.309.5900
Access Code 783-950-673#

Other international numbers availablehttps://join.me/intphone/783950673/0

Rob

From: Hirschfeld, Rob
Sent: Monday, September 22, 2014 5:09 PM
To: Defcore-committee at lists.openstack.org
Cc: jonathan at openstack.org; 'Mark Collier'
Subject: Suggestions on trademark changes, possible meeting 10/2 or earlier

All,

Last Thursday, the board did not act on any of our recommendations. The Board is reconsidering one of the guiding principles from Hong Kong - DefCore is trying to define a minimum base definition for OpenStack. Instead, they've asked us for multiple Trademark proposals.

ACTION ITEM: I'd be interested in hearing suggestions from the committee that we can use as the basis for a etherpad.

Towards that end, I think we should schedule a meeting on Thursday 10/2. I'm open to having a working session before that to brainstorm options (possibly with Mark or Jonathan).

I'd ask you to consider two items in preparation:

1) Sean Dague's Layers Model: https://dague.net/2014/08/26/openstack-as-layers/

2) Consideration of OpenStack as a product or "big tent" which seems to be part of the OpenStackSV output: Monty http://inaugust.com/post/108 and Randy http://siliconangle.com/blog/2014/09/17/the-achilles-heel-of-openstack-is-lack-of-product-leadership-openstacksv/

Rob


Rob Hirschfeld
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Meeting Next Week

All,

To prepare for the 10/20 board meeting, we should have a proposal for discussion
next week. Since there appears to be consensus on the Foundation's
recommendation (add programs and platform levels), I will write up a strawman
recommendation.

If anyone else wants to write the strawman instead, please let my know by
tomorrow so that we do not duplicate effort.

Thanks,

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141009/fcc42300/attachment.html

I think that Mark was pretty close to having even the legal stuff written up, just needing the specifics of ?capability + implementing code? aspect of the discussion.

How about he tweaks his work to match the outcome of the discussion and Rob just addresses the technical requirements of capability + code? Is that reasonable?

--Rocky

From: rob at zehicle.com [mailto:rob at zehicle.com]
Sent: Thursday, October 09, 2014 4:00 PM
To: defcore-committee at lists.openstack.org; Mark Collier
Subject: [OpenStack-DefCore] Meeting Next Week

All,

To prepare for the 10/20 board meeting, we should have a proposal for discussion next week. Since there appears to be consensus on the Foundation's recommendation (add programs and platform levels), I will write up a strawman recommendation.

If anyone else wants to write the strawman instead, please let my know by tomorrow so that we do not duplicate effort.

Thanks,

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Programs & Platform layout for board meeting on Monday

All,

Please review the following graphic as part of our board meeting.

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141016/64eef15a/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Untitled drawing.png
Type: image/png
Size: 57077 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141016/64eef15a/attachment-0001.png

Perhaps having a second slide that shows a likely Icehouse layout would help to show how the program will grow/change from release to release and answer the questions like mine without any discussion.

From: rob at zehicle.com [mailto:rob at zehicle.com]
Sent: Thursday, October 16, 2014 1:28 PM
To: Rochelle.RochelleGrober; defcore-committee at lists.openstack.org; Alan Clark
Subject: RE: [OpenStack-DefCore] Programs & Platform layout for board meeting on Monday

Great question. At this point, it's not a Havana Capability. Once there are tests, then I suspect it could become a program.

I believe that the Foundation wanted programs to be driven by vendor interest in trademarks. From that perspective, we'd add it if there was someone asking for an Identity program.

On October 16, 2014 at 3:10 PM "Rochelle.RochelleGrober" <rochelle.grober at huawei.com> wrote:
What about Identity/Auth service? I would think you might want to put that into the ?program??

From: rob at zehicle.com [mailto:rob at zehicle.com]
Sent: Thursday, October 16, 2014 1:00 PM
To: defcore-committee at lists.openstack.org; Alan Clark
Subject: Re: [OpenStack-DefCore] Programs & Platform layout for board meeting on Monday

Alan,

How about this?

Rob

On October 16, 2014 at 2:21 PM Alan Clark wrote:

Rob, Nice work. A suggested addition. Add a venn diagram feel to the graphic by encompassing the Programs and Platform parts in color.

>
All,

Please review the following graphic as part of our board meeting.

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] More details about DefCore Platform & Programs Split

DefCore,

Feedback is welcome! I'm preparing the board report for the meeting Monday
(yikes, Monday!) and need to create the background info and proposals for the
meeting.

Here's the description I have for the change. I'll send the proposals out for
review tomorrow.


During the post-meeting review, Mark Collier drafted a Foundation supported
recommendation
https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing
that basically creates an additional core tier without changing the fundamental
capabilities & designated code concepts. This proposal has been reviewed by the
DefCore committee (but not formally approved in a meeting).

The original DefCore proposed capabilities set becomes the "platform" level
while capability subsets are called "programs." We are considering two initial
programs, Compute & Object, and both are included in the platform (see
illustration below). The approach leaves the door open for new core programs to
exist both under and outside of the platform umbrella.

[DefCore Platform and Programs v1.1]
https://robhirschfeld.files.wordpress.com/2014/10/defcore-platform-and-programs-v1-1.png

In the proposal, OpenStack vendors who meet either program or platform
requirements can qualify for the "OpenStack Powered" logo; however, vendors
using the only a program (instead of the full platform) will have more
restrictive marks and limitations about how they can use the term OpenStack.

This approach addresses the "is Swift required?" question. For platform, Swift
capabilities will be required; however, vendors will be able to implement the
Compute program without Swift and implement the Object program without
Nova/Glance/Cinder.

It's important to note that there is only one yard stick for programs or the
platform: the capabilities groups and designed code defined by the DefCore
process. From that perspective, OpenStack is one consistent thing. This change
allows vendors to choose sub-components if that serves their business
objectives.

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141016/b831eead/attachment.html

The ironic thing is the use of "trademark program" pre-dates the use of
program in OpenStack, and it hasn't seemed to create a large problem to
this point.

Jonathan

On October 16, 2014 11:05:28 PM Michael Still wrote:

Given the term "program" is already in use in OpenStack to describe
something different, I think you need to find a different word here.

Michael

On Fri, Oct 17, 2014 at 6:50 AM, rob at zehicle.com wrote:

DefCore,

Feedback is welcome! I'm preparing the board report for the meeting
Monday (yikes, Monday!) and need to create the background info and
proposals for the meeting.

Here's the description I have for the change. I'll send the proposals out
for review tomorrow.


During the post-meeting review, Mark Collier drafted a Foundation
supported recommendation

https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing
that basically

creates an additional core tier without changing the fundamental
capabilities & designated code
concepts. This proposal has been
reviewed by the DefCore committee (but not formally approved in a meeting).

The original DefCore proposed capabilities set becomes the "platform"
level while capability subsets are called "programs." We are considering
two initial programs, Compute & Object, and both are included in the
platform (see illustration below). The approach leaves the door open
for new core programs to exist both under and outside of the platform
umbrella.

[image: DefCore Platform and Programs v1.1]

https://robhirschfeld.files.wordpress.com/2014/10/defcore-platform-and-programs-v1-1.png

In the proposal, OpenStack vendors who meet either program or platform
requirements can qualify for the "OpenStack Powered" logo; however, vendors
using the only a program (instead of the full platform) will have
more restrictive marks and limitations about how they can use the term
OpenStack.

This approach addresses the "is Swift required?" question. For platform,
Swift capabilities will be required; however, vendors will be able
to implement the Compute program without Swift and implement the Object
program without Nova/Glance/Cinder.

It's important to note that there is only one yard stick for programs or
the platform: the capabilities groups and designed code defined by the
DefCore process. From that perspective, OpenStack is one consistent
thing. This change allows vendors to choose sub-components if that serves
their business objectives.

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--
Rackspace Australia



Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Specific Capabilities Recommendation

DefCore,

I believe it's important for us to have a specific recommendation for the board
meeting so there can be a vote that moves us forward. I've compiled a draft
based on my understanding of the Foundation's proposal and discussions on the
list. Discussion (or +1) is encouraged!

I will preemptively remind everyone about the glaring omission of Keystone.
There were no tests, so we have no Havana Keystone capabilities.

Platform and Program Capabilities

Recommendation: Extend the DefCore principles to allow for multiple levels:
programs and platforms. Programs represent subsections of the overall platform.
In some cases, it is acceptable for a program identified without being included
in the platform. New programs are added at Foundation recommendation via board
approval. Programs are added to the platform via board approval.

Recommendation: The initial programs will be Compute & Object. The DefCore
platform will require the Compute program, Object program and additional
capabilities.

Recommendation: The Compute Program will consist of the following capabilities:

  • compute-servers

  • compute-volume

  • compute-quotas

  • compute-flavors

  • compute-auth

  • compute-keypairs

  • compute-servers-metadata

  • compute-floating-ips

  • compute-images

  • compute-instance-actions

  • compute-security-groups

Recommendation: The Object Program will consist of the following capabilities:

  • objectstore-object,

  • objectstore-container

Recommendation: The Platform will consist of all the capabilities in the Compute
and Object programs and the following capabilities:

  • images-v1

  • volume

  • volume-snapshots

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141016/455ba825/attachment.html

On Oct 17, 2014, at 11:11 AM, Chris Hoge wrote:

I have to back off on my statement about using the client too. It appears
that many of the tests are using direct access. I?m not sure test coverage
is the real issue here. Need to investigate more.

We're talking about tests for Havana - not trunk. Since we switched to
branchless (but not fully incorporated that into the capabilities) we may have
additional tests from later releases to pull from.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Quick Update, ALL designated sections & changes to DefCore structure proposed for next board meeting

All,

The board accepted our recommendations for platform & component program at the
last meeting. The existing capabilities were divided between object (both
object- tests) and the compute (all the rest).

We are going to take up the designated sections proposals next week. I talked
with John Dickinson and I believe that we'll have a solid recommendation for all
core projects by the board meeting. Please watch this list so that we can get
quick review of the Swift sections.

Further, I'd like to recommend some changes to DefCore itself:
1) change to a Board working group - the Foundation will assign staff to assist
in regular management of the process.
2) officially require Board co-chairs with rotating 2 year terms for continuity.

I'm planning to propose these changes at the board meeting next week and would
like comment or support (+1s) for the recommendation.

Thanks,

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141024/e42a6c74/attachment.html

+1 +1 thanks Rob!

Best,
Simon

On Oct 24, 2014, at 4:46 PM, Monty Taylor wrote:

+1 to both

On Oct 24, 2014 3:48 PM, "rob at zehicle.com" wrote:

All,

The board accepted our recommendations for platform & component program at the last meeting. The existing capabilities were divided between object (both object- tests) and the compute (all the rest).

We are going to take up the designated sections proposals next week. I talked with John Dickinson and I believe that we'll have a solid recommendation for all core projects by the board meeting. Please watch this list so that we can get quick review of the Swift sections.

Further, I'd like to recommend some changes to DefCore itself:
1) change to a Board working group - the Foundation will assign staff to assist in regular management of the process.
2) officially require Board co-chairs with rotating 2 year terms for continuity.

I'm planning to propose these changes at the board meeting next week and would like comment or support (+1s) for the recommendation.

Thanks,

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Revised Bylaws

After some additional discussion, we are going to make the draft available on the website on Friday (after we incorporate any comments from you, the Board and the Technical Committee) so the community can review it prior to the Board meeting on December 2.

-----Original Message-----
From: Radcliffe, Mark [mailto:Mark.Radcliffe at dlapiper.com]
Sent: Friday, November 14, 2014 2:38 PM
To: Defcore-committee at lists.openstack.org
Cc: Roay, Leslie
Subject: Revised Bylaws

Sorry for the length of the email, but I am sending you the final draft of the revised bylaws to implement the DefCore process. As you may recall, the original bylaws provided for very detailed (and inflexible) approach to the use of trademarks and the modification of the Core OpenStack Project. This draft includes the feedback from the Defcore committee and is meant to provide flexibility to adopt the Defcore procedures and any changes to those procedures in the future. These changes have included input from the Legal Affairs Committee, OpenStack Foundation management and your committee. We have incorporated most of the proposals from the DefCore committee (for more information on the comments you can see my emails to the committee). Thanks particularly to Mark McLoughlin and Joshua McKenty for their comments. I am enclosing two marked copies depending to assist you in reviewing the documents:

  1. v.24 to v.29: Last version seen by Defcore to most current version
  2. v.15 to v.29: Current bylaws to most current version

The changes from the last draft reviewed by the Defcore committee (version 24) are summarized as follows:

  1. Deleted the transition provisions and provided that the Board will make decide when the new procedure for managing the use of trademarks becomes effective.
  2. Changed the definitions used for Core OpenStack Project and OpenStack Integrated Release:
    "Core OpenStack Project" to "Trademark Designated OpenStack Project" and
    "OpenStack Integrated Release" to "OpenStack TC Designated Release"
  3. Deleted the changes to the Legal Affairs Committee which will be handled (and voted upon) separately
  4. Replaced "OpenStack Integrated Release" with the broader "OpenStack Project" in all places
  5. Provided for the Board and the Technical Committee to agree on procedures for interaction which can be changed without referral to the bylaws; these procedures will need to be agreed upon by Board and the Technical Committee and are not yet in existence.

Please provide me with any comments by noon on Thursday, November 20. We will also be sending a similar email to the Board of Directors and the Technical Committee. After considering and incorporating any relevant comments, the Foundation is planning to have a Board meeting in the first week of December to approve the final draft. Then, such draft will be put on the Foundation website to prepare for approval by the Individual Members as part of their election of Individual Directors.

The changes from the existing bylaws are summarized as follows:

1.??????????? Revisions for Determination Core and Trademark Policy.

??????????????? a.??????????? Shift from two to three categories of software

??????????????????????????????? i.????????????? Current bylaws

??????????????????????????????????????????????? A.??????????? OpenStack Project
??????????????????????????????????????????????? B.??????????? Core OpenStack Project

??????????????????????????????? ii.???????????? Revised bylaws

??????????????????????????????????????????????? A.??????????? OpenStack Project
??????????????????????????????????????????????? B.??????????? OpenStack TC Approved Release
??????????????????????????????????????????????? C.??????????? Trademark Designated OpenStack Software

??????????????? b.??????????? Change in determination of Trademark Designated OpenStack Software by the Board

??????????????????????????????? i.????????????? Current bylaws

??????????????????????????????????????????????? A.??????????? Modules: Block Storage, Compute, Dashboard, Identity Service, Image Service, Networking, and Object Storage
??????????????? ????????????????????????????????B.??????????? Add/Remove Modules Process: Proposed by Technical Committee and approved by the Board of Directors ("Board")
??????????????????????????????????????????????? C.??????????? This? provision can only be changed by a vote of the Board and the affirmative vote of (i) two-thirds of the Gold Members, (ii) two-thirds of the Platinum Members, and (iii) a majority of the Individual Members voting (but only if at least 25% of the Individual Members voting at an? annual or special meeting).???????????????????????????????

??????????????????????????????? ii.???????????? Revised bylaws

??????????????????????????????????????????????? A.???????????Trademark Designated OpenStack Software:? Process for determining Trademark Designated OpenStack Software will be determined by the Board and does not need any vote by the members, but changes in process require Technical Committee approval (i.e. change from DefCore)
??????????????????????????????????????????????? B.??????????? OpenStack TC Approved Release (formerly Integrated Release):? Determined by Technical Committee but "Trademark Designated OpenStack Software" can be deleted from OpenStack TC Approved Release only with permission of Board

??????????????? c.???????????? Change in management of trademarks

??????????????????????????????? i.????????????? Current bylaws

??????????????????????????? ????????????????????A.??????????? Trademarks governed by detailed trademark policy in Appendix 8
??????????????????????????????????????????????? B.??????????? This? provision can only be changed by a vote of the Board and the affirmative vote of (i) two-thirds of the Gold Members, (ii) two-thirds of the Platinum Members, and (iii) a majority of the Individual Members voting (but only if at least 25% of the Individual Members vote at? an ?annual or special meeting).???????????????

??????????????????????????????? ii.???????????? Revised bylaws

??????????????????????????????????????????????? A.??????????? Trademarks will be governed by a trademark policy to be determined by the Board and does not need any vote by the members

2.??????????? Determination of ATC

??????????????????????????????? a.????????????? Current bylaws:??????????????? ATC must contribute to Core OpenStack Project.?

??????????????????????????????? b.???????????? Revised bylaws:??????????????? ATC must contribute to OpenStack Project .

Separate Approval

  1. Legal Affairs Committee

    a. Current bylaws: Legal Affairs Committee currently is limited to five members (but eleven lawyers are attending).

    b. Revised bylaws: The Board can set the criteria for membership on the Legal Affairs Committee.

  2. Quorum for Individual Members to Amend the Bylaws

    a. Current bylaws: A majority of the Individual Members voting (but only if at least 25% of the Individual Members vote at an annual or special meeting). This vote was selected rather arbitrarily at the time the bylaws were drafted and did not anticipate the number of Individual Members which have joined the Foundation. The 2014 election for Individual Directors had participation of only [11%] of the Individual Members.

    b. Revised bylaws: A majority of the Individual Members voting (but only if at least 10% of the Individual Members vote at an annual or special meeting).

Please consider the environment before printing this email.

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster at dlapiper.com. Thank you.

[OpenStack-DefCore] Revised Bylaws Reminder

Just a reminder that any comments on the bylaws need to be received by noon on Thursday.

As I noted, we sent a similar email to the Technical Committee and the Board. The Technical Committee responded this morning and only requested that we change the abbreviations to the full word so TC goes to Technical Committee and ATC goes to Active Technical Contributor.

-----Original Message-----
From: Radcliffe, Mark [mailto:Mark.Radcliffe at dlapiper.com]
Sent: Friday, November 14, 2014 2:38 PM
To: Defcore-committee at lists.openstack.org
Cc: Roay, Leslie
Subject: Revised Bylaws

Sorry for the length of the email, but I am sending you the final draft of the revised bylaws to implement the DefCore process. As you may recall, the original bylaws provided for very detailed (and inflexible) approach to the use of trademarks and the modification of the Core OpenStack Project. This draft includes the feedback from the Defcore committee and is meant to provide flexibility to adopt the Defcore procedures and any changes to those procedures in the future. These changes have included input from the Legal Affairs Committee, OpenStack Foundation management and your committee. We have incorporated most of the proposals from the DefCore committee (for more information on the comments you can see my emails to the committee). Thanks particularly to Mark McLoughlin and Joshua McKenty for their comments. I am enclosing two marked copies depending to assist you in reviewing the documents:

  1. v.24 to v.29: Last version seen by Defcore to most current version
  2. v.15 to v.29: Current bylaws to most current version

The changes from the last draft reviewed by the Defcore committee (version 24) are summarized as follows:

  1. Deleted the transition provisions and provided that the Board will make decide when the new procedure for managing the use of trademarks becomes effective.
  2. Changed the definitions used for Core OpenStack Project and OpenStack Integrated Release:
    "Core OpenStack Project" to "Trademark Designated OpenStack Project" and
    "OpenStack Integrated Release" to "OpenStack TC Designated Release"
  3. Deleted the changes to the Legal Affairs Committee which will be handled (and voted upon) separately
  4. Replaced "OpenStack Integrated Release" with the broader "OpenStack Project" in all places
  5. Provided for the Board and the Technical Committee to agree on procedures for interaction which can be changed without referral to the bylaws; these procedures will need to be agreed upon by Board and the Technical Committee and are not yet in existence.

Please provide me with any comments by noon on Thursday, November 20. We will also be sending a similar email to the Board of Directors and the Technical Committee. After considering and incorporating any relevant comments, the Foundation is planning to have a Board meeting in the first week of December to approve the final draft. Then, such draft will be put on the Foundation website to prepare for approval by the Individual Members as part of their election of Individual Directors.

The changes from the existing bylaws are summarized as follows:

1.??????????? Revisions for Determination Core and Trademark Policy.

??????????????? a.??????????? Shift from two to three categories of software

??????????????????????????????? i.????????????? Current bylaws

??????????????????????????????????????????????? A.??????????? OpenStack Project
??????????????????????????????????????????????? B.??????????? Core OpenStack Project

??????????????????????????????? ii.???????????? Revised bylaws

??????????????????????????????????????????????? A.??????????? OpenStack Project
??????????????????????????????????????????????? B.??????????? OpenStack TC Approved Release
??????????????????????????????????????????????? C.??????????? Trademark Designated OpenStack Software

??????????????? b.??????????? Change in determination of Trademark Designated OpenStack Software by the Board

??????????????????????????????? i.????????????? Current bylaws

??????????????????????????????????????????????? A.??????????? Modules: Block Storage, Compute, Dashboard, Identity Service, Image Service, Networking, and Object Storage
??????????????? ????????????????????????????????B.??????????? Add/Remove Modules Process: Proposed by Technical Committee and approved by the Board of Directors ("Board")
??????????????????????????????????????????????? C.??????????? This? provision can only be changed by a vote of the Board and the affirmative vote of (i) two-thirds of the Gold Members, (ii) two-thirds of the Platinum Members, and (iii) a majority of the Individual Members voting (but only if at least 25% of the Individual Members voting at an? annual or special meeting).???????????????????????????????

??????????????????????????????? ii.???????????? Revised bylaws

??????????????????????????????????????????????? A.???????????Trademark Designated OpenStack Software:? Process for determining Trademark Designated OpenStack Software will be determined by the Board and does not need any vote by the members, but changes in process require Technical Committee approval (i.e. change from DefCore)
??????????????????????????????????????????????? B.??????????? OpenStack TC Approved Release (formerly Integrated Release):? Determined by Technical Committee but "Trademark Designated OpenStack Software" can be deleted from OpenStack TC Approved Release only with permission of Board

??????????????? c.???????????? Change in management of trademarks

??????????????????????????????? i.????????????? Current bylaws

??????????????????????????? ????????????????????A.??????????? Trademarks governed by detailed trademark policy in Appendix 8
??????????????????????????????????????????????? B.??????????? This? provision can only be changed by a vote of the Board and the affirmative vote of (i) two-thirds of the Gold Members, (ii) two-thirds of the Platinum Members, and (iii) a majority of the Individual Members voting (but only if at least 25% of the Individual Members vote at? an ?annual or special meeting).???????????????

??????????????????????????????? ii.???????????? Revised bylaws

??????????????????????????????????????????????? A.??????????? Trademarks will be governed by a trademark policy to be determined by the Board and does not need any vote by the members

2.??????????? Determination of ATC

??????????????????????????????? a.????????????? Current bylaws:??????????????? ATC must contribute to Core OpenStack Project.?

??????????????????????????????? b.???????????? Revised bylaws:??????????????? ATC must contribute to OpenStack Project .

Separate Approval

  1. Legal Affairs Committee

    a. Current bylaws: Legal Affairs Committee currently is limited to five members (but eleven lawyers are attending).

    b. Revised bylaws: The Board can set the criteria for membership on the Legal Affairs Committee.

  2. Quorum for Individual Members to Amend the Bylaws

    a. Current bylaws: A majority of the Individual Members voting (but only if at least 25% of the Individual Members vote at an annual or special meeting). This vote was selected rather arbitrarily at the time the bylaws were drafted and did not anticipate the number of Individual Members which have joined the Foundation. The 2014 election for Individual Directors had participation of only [11%] of the Individual Members.

    b. Revised bylaws: A majority of the Individual Members voting (but only if at least 10% of the Individual Members vote at an annual or special meeting).

Please consider the environment before printing this email.

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster at dlapiper.com. Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 251582570-v2-Legal Affairs Committee Bylaws.doc
Type: application/msword
Size: 28160 bytes
Desc: 251582570-v2-Legal Affairs Committee Bylaws.doc
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141119/d5d076f0/attachment-0007.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change-Pro Redline with Track Changes - 251582570-v1-Legal Affairs Committee Bylaws and 251582570-v2-Legal Affairs Committee Bylaws.doc
Type: application/msword
Size: 38400 bytes
Desc: Change-Pro Redline with Track Changes - 251582570-v1-Legal Affairs Committee Bylaws and 251582570-v2-Legal Affairs Committee Bylaws.doc
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141119/d5d076f0/attachment-0008.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 251955172-v2-Voting Quorum Change.doc
Type: application/msword
Size: 32768 bytes
Desc: 251955172-v2-Voting Quorum Change.doc
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141119/d5d076f0/attachment-0009.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change-Pro Redline with Track Changes - 251955172-v1-Voting Quorum Change and 251955172-v2-Voting Quorum Change.doc
Type: application/msword
Size: 43008 bytes
Desc: Change-Pro Redline with Track Changes - 251955172-v1-Voting Quorum Change and 251955172-v2-Voting Quorum Change.doc
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141119/d5d076f0/attachment-0010.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 233015232-v29-OpenStackFoundation Bylaws FINAL (as amended September 7, 2012).doc
Type: application/msword
Size: 207872 bytes
Desc: 233015232-v29-OpenStackFoundation Bylaws FINAL (as amended September 7, 2012).doc
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141119/d5d076f0/attachment-0011.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change-Pro Redline with Track Changes - 233015232-v15-OpenStackFoundation Bylaws FINAL (as amended September 7, 2012) and 233015232-v29-OpenStackFound.doc
Type: application/msword
Size: 253952 bytes
Desc: Change-Pro Redline with Track Changes - 233015232-v15-OpenStackFoundation Bylaws FINAL (as amended September 7, 2012) and 233015232-v29-OpenStackFound.doc
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141119/d5d076f0/attachment-0012.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change-Pro Redline with Track Changes - 233015232-v24-OpenStackFoundation Bylaws FINAL (as amended September 7, 2012) and 233015232-v29-OpenStackFound.doc
Type: application/msword
Size: 227328 bytes
Desc: Change-Pro Redline with Track Changes - 233015232-v24-OpenStackFoundation Bylaws FINAL (as amended September 7, 2012) and 233015232-v29-OpenStackFound.doc
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141119/d5d076f0/attachment-0013.doc

[OpenStack-DefCore] Update for 12/2 Board Meeting & Swift Designated Sections, Icehouse/Juno Capabilities

DefCore Committee,

Since much of our work has been on hold waiting for Board approval,
there has been no reason to call a meeting. I am optimistic that we
will be able to complete the designated sections principles and other
items that have been on the Board agenda since OSCON.

John Dickinson and I have proposed a set of designated sections for
Swift that complete the list for board approval. Please review them:
https://review.openstack.org/#/c/136677/2

If you know someone who has an opinion about these sections, please
invite them to review also!

Just because the committee has not met does not mean we have been
inactive! Catherine Dielp (IBM) abd Julia Shapovalova (Mirantis) have
been working on the Icehouse and Juno capabilities. Reviews are
encouraged:
https://review.openstack.org/#/q/status:open+project:stackforge/refstack,n,z

I'm excited for DefCore to enter a new phase in 2015 with the process
defined so that we can focus on execution against Icehouse and Juno.

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

[OpenStack-DefCore] DefCore Meeting [agenda in description]

Hi there,

Rob Hirschfeld (rob at zehicle.com) invites you to participate in the
Doodle poll "DefCore Meeting [agenda in description]".

Rob Hirschfeld says:
Please plan 90 Minutes - long agenda!

Agenda:
1) Celebrate
status of Havana & principles from Lighthouse Cycle
2) Name new
cycle
3a) Discuss and recommend structure changes (proposal for
board)
3b) Elect co-chair for 2015-2016
4) Communication plan for
by-laws change "get out the vote" campaign
5) discuss process
description for OpenStack Board & TC

Participate now
https://doodle.com/cusb6zbu93s9ce89?tmail=poll_invitecontact_participant_invitation_with_message&tlink=pollbtn

What is Doodle? Doodle is a web service that helps Rob Hirschfeld to
find a suitable date for meeting with a group of people. Learn more
about how Doodle works.
(https://doodle.com/main.html?tlink=checkOutLink&tmail=poll_invitecontact_participant_invitation_with_message)


You have received this e-mail because "Rob Hirschfeld" has invited you
to participate in the Doodle poll "DefCore Meeting [agenda in
description]."


Doodle AG, Werdstrasse 21, 8021 Z?rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141210/ecdbe52d/attachment.html

[OpenStack-DefCore] DefCore

You have been invited to a join.me online meeting \n \nhttps://etherpad.openstack.org/p/DefCore2014Dec17 \n \nAgenda: \n1) Celebrate status of Havana & principles from Lighthouse Cycle \n2) Name new cycle \n3a) Discuss and recommend structure changes (proposal for board) \n3b) Elect co-chair for 2015-2016 \n4) Communication plan for by-laws change "get out the vote" campaign \n5) discuss process description for OpenStack Board & TC \n \n \nJoin the meeting: https://join.me/770-549-494 \n \nOn a computer, use any browser with Flash. Nothing to download. \nOn a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 770-549-494 \n \n \nJoin the audio conference: \nDial a phone number and enter access code, or connect via internet. \n \nBy phone: \nUnited States - Camden, DE +1.302.202.5900 \nUnited States - Detroit, MI +1.734.746.0035 \nUnited States - Hartford, CT +1.860.970.0010 \nUnited States - Los Angeles, CA +1.213.226.1066 \nUnited States - New York, NY +1.646.307.1990 \nUnited States - San Francisco, CA +1.415.655.0381 \nUnited States - Saugus, MA +1.781.666.2350 \nAccess Code 770-549-494# \n \nOther international numbers available (https://join.me/intphone/770549494/0) \n \nBy computer via internet: \nJoin the meeting, click the phone icon and select 'Call via internet'. A small download might be required. \n \n \nStart time by time zones (https://join.me/timezone/1418851800000/1418857200000) \n \n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141215/6724904f/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2324 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141215/6724904f/attachment.ics

[OpenStack-DefCore] Meeting Recap, additional threads (vote & process) to follow

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20141217/774a569e/attachment.html

[OpenStack-DefCore] For your review; draft emails to get individual members to vote

DefCore committee:
Welcome back from the holidays. Hope everyone was able to take a least a few days down time.

I had the action item from the last DefCore meeting to produce a couple of draft emails that could be used to get our individual members out to vote on the bylaw updates. Incorporating the points discussed in the meeting, here's 2 email drafts. The first could be sent to all individual members. The second could be used by corporate members to send to their employees who are signed up as individual members. The goal is not to tell people how to vote, simply to encourage them to vote.

Reply with suggested improvements on the draft emails.

Thanks,
AlanClark


Draft email that could be used to remind individual members to vote on the bylaw updates.

OpenStack Individual Members we need your help!

Included on the upcoming individual elections ballot is set of proposed bylaw changes. To be enacted, these changes require approval by the individual members.

The unprecedented growth, community size and active nature of the OpenStack community has precipitated the need for OpenStack Bylaw updates. The updates will enable our community to adapt to our continued rapid growth, change and diversity, while reflecting our success and market leadership. Although the proposed changes only effect a small set of verbiage in the bylaws, the changes eliminate some of the hard coded values and naive initial assumptions that found their way into the bylaws when they were initially created in 2013. Those initial assumptions did not anticipate that by 2015 we would have such a large, active community of over 17,000 individual members, over 430 corporate members, and a large diverse set of OpenStack based products and services.
DefCore committee members,

Through many months of community iterative discussion and debate, the DefCore team and board have unanimously accepted a set of changes that are now placed before you for your approval. The changes replace the original hardcoded "core" definition with a process for determining the latest set of software required for use of the OpenStack commercial trademark. Processes which will also account for future revisions and determinations for Core and Trademark Policy.

Complete details on the proposed changes are located at:
https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment

Watch for the election notices from the Foundation staff and be ready to cast your vote.


Email template for corporate members could use to remind individual members to vote.

On January 12, 2015 the OpenStack individual elections begin. This a reminder to cast your votes. Information on the candidates is available on openstack.org. We are not telling you how to vote, we simply provide this reminder to study the candidates and as a responsible individual member to cast your vote.

Included on the upcoming individual elections ballot is set of proposed bylaw changes. The unprecedented growth, community size and active nature of the OpenStack community has precipitated the need for OpenStack Bylaw updates. The updates will enable the OpenStack community to adapt to the continued rapid growth, change and diversity, while reflecting the community success and market leadership.

Complete details on the proposed changes are located at:
https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment

Happy New Year All. Thanks for the drafts Alan. I made a couple of edits and included updated drafts for both emails below.
Carol

--------------------Email for Individual Members

OpenStack Individual Members we need your help - Please Vote!

Included on the upcoming individual elections ballot is set of proposed bylaw changes. To be enacted, these changes require approval by the individual members. At least 25% of the Individual Members must participate in this election in order for the vote to take effect which is why we are reaching out to you. The election will start Monday January 12, 2015 and run thru Friday January 16, 2015.

The unprecedented growth, community size and active nature of the OpenStack community have precipitated the need for OpenStack Bylaw updates. The updates will enable our community to adapt to our continued rapid growth, change and diversity, while reflecting our success and market leadership. Although the proposed changes only effect a small set of verbiage in the bylaws, the changes eliminate some of the hard coded values and naive initial assumptions that found their way into the bylaws when they were initially created in 2013. Those initial assumptions did not anticipate that by 2015 we would have such a large, active community of over 17,000 individual members, over 430 corporate members, and a large diverse set of OpenStack based products and services.
DefCore committee members,

Through many months of community iterative discussion and debate, the DefCore team and board have unanimously accepted a set of changes that are now placed before you for your approval. The changes replace the original hard coded "core" definition with a process for determining the software elements required for use of the OpenStack commercial trademark. Processes which will also account for future revisions and determinations for Core and Trademark Policy.

Complete details on the proposed changes are located at:
https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment

Complete details on the 2015 Board Election are located at:
http://www.openstack.org/election/2015-individual-director-election/

Watch for the election notices from the Foundation staff and be ready to cast your vote.

-------------------- Email template for corporate members
On January 12, 2015 the OpenStack individual elections begin. While we always encourage your participation, for this election it's especially important.

Included on the upcoming individual elections ballot is set of proposed bylaw changes. The unprecedented growth, community size and active nature of the OpenStack community have precipitated the need for OpenStack Bylaw updates. The updates will enable the OpenStack community to adapt to the continued rapid growth, change and diversity, while reflecting the community success and market leadership.

In order for the vote to change the bylaws to be effective at least 25% of the Individual Members must participate in the election. We are not telling you how to vote, rather we are asking you to study the candidates and as a responsible individual member cast your vote.

Information on the candidates is available at this location:
http://www.openstack.org/election/2015-individual-director-election/CandidateList

Complete details on the proposed changes are located at:
https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment

-----Original Message-----
From: Alan Clark [mailto:aclark at suse.com]
Sent: Monday, January 05, 2015 11:14 AM
To: Defcore-committee at lists.openstack.org
Subject: [OpenStack-DefCore] For your review; draft emails to get individual members to vote

DefCore committee:
Welcome back from the holidays. Hope everyone was able to take a least a few days down time.

I had the action item from the last DefCore meeting to produce a couple of draft emails that could be used to get our individual members out to vote on the bylaw updates. Incorporating the points discussed in the meeting, here's 2 email drafts. The first could be sent to all individual members. The second could be used by corporate members to send to their employees who are signed up as individual members. The goal is not to tell people how to vote, simply to encourage them to vote.

Reply with suggested improvements on the draft emails.

Thanks,
AlanClark


Draft email that could be used to remind individual members to vote on the bylaw updates.

OpenStack Individual Members we need your help!

Included on the upcoming individual elections ballot is set of proposed bylaw changes. To be enacted, these changes require approval by the individual members.

The unprecedented growth, community size and active nature of the OpenStack community has precipitated the need for OpenStack Bylaw updates. The updates will enable our community to adapt to our continued rapid growth, change and diversity, while reflecting our success and market leadership. Although the proposed changes only effect a small set of verbiage in the bylaws, the changes eliminate some of the hard coded values and naive initial assumptions that found their way into the bylaws when they were initially created in 2013. Those initial assumptions did not anticipate that by 2015 we would have such a large, active community of over 17,000 individual members, over 430 corporate members, and a large diverse set of OpenStack based products and services.
DefCore committee members,

Through many months of community iterative discussion and debate, the DefCore team and board have unanimously accepted a set of changes that are now placed before you for your approval. The changes replace the original hardcoded "core" definition with a process for determining the latest set of software required for use of the OpenStack commercial trademark. Processes which will also account for future revisions and determinations for Core and Trademark Policy.

Complete details on the proposed changes are located at:
https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment

Watch for the election notices from the Foundation staff and be ready to cast your vote.


Email template for corporate members could use to remind individual members to vote.

On January 12, 2015 the OpenStack individual elections begin. This a reminder to cast your votes. Information on the candidates is available on openstack.org. We are not telling you how to vote, we simply provide this reminder to study the candidates and as a responsible individual member to cast your vote.

Included on the upcoming individual elections ballot is set of proposed bylaw changes. The unprecedented growth, community size and active nature of the OpenStack community has precipitated the need for OpenStack Bylaw updates. The updates will enable the OpenStack community to adapt to the continued rapid growth, change and diversity, while reflecting the community success and market leadership.

Complete details on the proposed changes are located at:
https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Structural: 1. Secretary, 2. Calendar, 3. Decouple Refstack -> DISCUSSIONS / +1s

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150105/ae7178b1/attachment.html

My apologies for having missed this meeting. I was on vacation, and managed to double-book over the meeting time.?

1.) ACTION: +1

2.) ACTION: +1

?
Sent from Mailbox
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Fwd: [Foundation Board] Please encourage members to vote Monday January 12; A special reminder to vote on the proposed bylaw changes

REMINDER! Please help encourage people to click that link and vote! We
need the quorum.

-------- Forwarded Message --------
Subject: [Foundation Board] Please encourage members to vote Monday
January 12; A special reminder to vote on the proposed bylaw changes
Date: Fri, 09 Jan 2015 16:03:20 -0700
From: Alan Clark
To: foundation-board at lists.openstack.org,
goldmembers at lists.openstack.org

On January 12, the Individual elections begin. Included on ballot is set of proposed bylaw changes. To be enacted, these changes require approval by the individual members. At least 25% of the Individual Members must participate in this election in order for the vote to take effect. Getting %25 of the community out to vote is a challenge. We need your help. We are not telling people how to vote, we simply want people to get out and vote, particularly on the bylaw changes.

The unprecedented growth, community size and active nature of the OpenStack community has precipitated the need for OpenStack Bylaw updates. The updates will enable our community to adapt to our continued rapid growth, change and diversity, while reflecting our success and market leadership. Although the proposed changes only effect a small set of verbiage in the bylaws, the changes eliminate some of the hard coded values and naive initial assumptions that found their way into the bylaws when they were initially created in 2013. Those initial assumptions did not anticipate that by 2015 we would have such a large, active community of over 17,000 individual members, over 430 corporate members, and a large diverse set of OpenStack based products and services.

Through many months of community iterative discussion and debate, the DefCore team and Board have unanimously accepted a set of changes that are now placed before you for your approval. The changes replace the original hard coded "core" definition with a process for determining the software elements required for use of the OpenStack commercial trademark. Processes which will also account for future revisions and determinations for Core and Trademark Policy.

Much effort has been put forth to get the bylaw changes ready in time for this ballot. Would you please send out a "Get out and vote" reminder to those you know, and members from your company.

A reminder can be as simple as the following:


On January 12, 2015 the OpenStack individual elections begin. While we always encourage your participation, for this election it's especially important.

Included on the upcoming individual elections ballot is set of proposed bylaw changes. The unprecedented growth, community size and active nature of the OpenStack community have precipitated the need for OpenStack Bylaw updates. The updates will enable the OpenStack community to adapt to the continued rapid growth, change and diversity, while reflecting the community success and market leadership.

In order for the vote to change the bylaws to be effective at least 25% of the Individual Members must participate in the election. We are not telling you how to vote, rather we are asking you to study the candidates and as a responsible individual member cast your vote.

Information on the candidates is available at this location:
http://www.openstack.org/election/2015-individual-director-election/CandidateList

Complete details on the proposed bylaw changes are located at:
https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment

Watch for the election notices from the Foundation with information on how and where to vote.


Foundation-board mailing list
Foundation-board at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150109/35cb9c14/attachment.html

[OpenStack-DefCore] Fwd: [Foundation Board] Election is open

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150111/e344a8db/attachment.html

[OpenStack-DefCore] DefCore capabilities meeting

Hello everyone,

As discussed a week or so ago, we need to start having meetings about the capabilities mapping for Icehouse and Juno. This subcommittee will take the Havana capabilities Googlesheet as a starting point and look to create updated sheets for the next two releases using the same scoring methodology.

Anyone is invited to participate.

Doodle poll to find a good time: http://doodle.com/akzdbqsbw6dy9fyk

Note that although this poll is for next week only, we will be using this time on a weekly or bi-weekly basis as needed.

Thanks,
Van

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150116/94a359d6/attachment.html

Hello everyone,

Per the doodle, Wednesdays at 1PM Central (11am Pacific) are the most-available times for meetings to move the DefCore capabilities work forward.

I have made a copy of Troy Toman?s worksheet used for Havana. We will be updating this for Icehouse:

https://docs.google.com/spreadsheet/ccc?key=0Ags6GY_6T6qqdDBFOUNfdGs1VF85NmU3WjZXeFd3bGc&usp=sharing

Anyone with that link has the ability to edit.

A calendar invitation will also be sent to this list with call-in information.

Thanks,
Van


Van Lindberg
VP and Associate General Counsel
van.lindberg at rackspace.com
m: 214.364.7985

From: Van Lindberg <van.lindberg at rackspace.com<mailto:van.lindberg at rackspace.com>>
Date: Friday, January 16, 2015 at 9:52 AM
To: Rochelle Grober <rochelle.grober at huawei.com<mailto:rochelle.grober at huawei.com>>, Rob Hirschfeld >, "defcore-committee at lists.openstack.org" >, Christopher MacGown >, Adrian Otto <adrian.otto at rackspace.com<mailto:adrian.otto at rackspace.com>>, Justin Shepherd >
Subject: DefCore capabilities meeting

Hello everyone,

As discussed a week or so ago, we need to start having meetings about the capabilities mapping for Icehouse and Juno. This subcommittee will take the Havana capabilities Googlesheet as a starting point and look to create updated sheets for the next two releases using the same scoring methodology.

Anyone is invited to participate.

Doodle poll to find a good time: http://doodle.com/akzdbqsbw6dy9fyk

Note that although this poll is for next week only, we will be using this time on a weekly or bi-weekly basis as needed.

Thanks,
Van

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] DefCore Scale.2

Hi there,

Rob Hirschfeld (rob at zehicle.com) invites you to participate in the
Doodle poll "DefCore Scale.2."

Rob Hirschfeld says:
Meeting this week - help schedule!

Kick-off Meeting for 2015 to
set the agenda for this cycle.

We have two major threads to
complete before the Vancouver summit:
1) capabilities scoring for
Board approval.
2) define the detaile DefCore process for Board & TC
approval

Participate now
https://doodle.com/tehrzguk7t2qaw6z?tmail=poll_invitecontact_participant_invitation_with_message&tlink=pollbtn

What is Doodle? Doodle is a web service that helps Rob Hirschfeld to
find a suitable date for meeting with a group of people. Learn more
about how Doodle works.
(https://doodle.com/main.html?tlink=checkOutLink&tmail=poll_invitecontact_participant_invitation_with_message)


You have received this e-mail because "Rob Hirschfeld" has invited you
to participate in the Doodle poll "DefCore Scale.2."


Doodle AG, Werdstrasse 21, 8021 Z?rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150120/5744e96d/attachment.html

Hi there,

Rob Hirschfeld has chosen the following final date in the poll
?DefCore Scale.2?:

Time zone: Central Time

  • Friday, January 23, 2015 1:00 PM ? 2:00 PM

Rob Hirschfeld says:
We're set for 11 PT (1 Central). I'll send out an invite from
Join.me.

Go to poll
https://doodle.com/tehrzguk7t2qaw6z?tmail=poll_invitecontact_participant_finalpick&tlink=pollbtn


You have received this e-mail because "Rob Hirschfeld" has invited you
to participate in the Doodle poll "DefCore Scale.2."


Doodle AG, Werdstrasse 21, 8021 Z?rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Doodle.ics
Type: text/calendar
Size: 890 bytes
Desc: not available
URL:

[OpenStack-DefCore] Possible Meeting on Friday to set Scale Cycle agenda

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150120/aae29a62/attachment.html

[OpenStack-DefCore] DefCore Meeting Poll - wrong days :/

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150121/099a8503/attachment.html

Works for me

~sean

On Jan 21, 2015, at 7:09 AM, Hirschfeld, Rob wrote:

All,

I'm sorry, I missed the poll dates by a day. I did NOT mean to suggest a Saturday meeting.

I've updated the poll for 3 times on Friday. The most likely is 3 central (1 PT).

http://doodle.com/tehrzguk7t2qaw6z

Rob


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Meeting Details for Today

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150123/497f45cd/attachment.html

[OpenStack-DefCore] DefCore Scale.2 Meeting Minutes, next meeting tentative for 2/4 9am PT

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150123/52556de0/attachment.html

I volunteer to co-chair. I will catch up on the meeting notes and join you on the next meeting.

~sean

On Jan 23, 2015, at 12:47 PM, Hirschfeld, Rob wrote:

All,

We had a good 2015 kickoff meeting today. Next meeting 2/4 @ 9am PT.

Summary:

Basic kick-off meeting to launch Capabilities & Process sub committees.

Due to amount of work, expect bi-weekly (or more frequent) meetings.
Chris Hoge will be coordinating the coordinating the capabilities meetings
Rob Hirschfeld will be coordinating the process meetings
Calendar of deliverables is very aggressive!
We need to have a new board co-chair for the committee.
Here are the foll minutes: https://etherpad.openstack.org/p/DefCoreScale.2

DefCore Scale.2
Kick-off Meeting for 2015 to set the agenda for this cycle. ## Agenda: We have two major threads to complete before the Vancouver summit:

Refstack status
Review December Approvals
Co-chair replacement
TC Cross Membership ? Monty & Russel
Meeting Cadence
Capabilities scoring for Board approval.
Define the detaile DefCore process for Board and TC approval

Minutes:Roll Call:

Rob Hirschfeld
Vince Brunssen
Mark T. Voelker
Chris Hoge
Carol Barrett
Will Auld
Rocky Grober
Russell Bryant

Refstack/Testing

Background: Refstack is intended to collect vendor data from multiple clouds for comparision. It is not required for DefCore but helpful.Status:

Client in pretty good shape
Documentation, feedback, documentation.
I (Chris Hoge) am here to help! Ask lots of questions and give me a hard time when things go wrong.
Would like to run only defined capability tests (~160 for core capabilities) rather than 1000+ API tests
Modest amount of development effort
Tempest UUID is imperative to go forward so we can start patching Tempest tests that have bugs not caught by Devstack.
https://review.openstack.org/#/c/144329/2/specs/meta-data-and-uuid-for-tests.rst,cm
Gathering beta testers final weeks of January for beginning testing in Febrary
List to reach out to:
Private/Distro
Metacloud/Cisco
SuSE
Mirantis
IBM
VMWare
Public
HP
Rackspace
Bluebox
Dreamhost
Goal is to have meaningful vendor participation for Vancouver, with scoring in Marketplace.
Refstack server not to be used as is, but remains in consideration
Requirements of security (identity, auth, schema validation, rate limiting)
Demonstrated history of maintenance and project leadership
Foundation staff liked score card, may use skinned/modified version for Marketplace

Approved items from December 2014

1) Role for Foundation on DefCore
I felt that it was important to have an official role for the Foundation so that meetings and announcements could make official progress even without having one of the Chairs involved. There is substantial work to be done and we cannot be limited by the schedule of the chairs. After discussing several options including leaving it ad hoc, everyone on the call agreed that having an official Secretary would address all concerns. There's an expectation, not a requirement, that the Secretary is also on the Foundation staff.
Since this is internal to the committee, we can act on it immediately. If you have concerns, please raise this here! If not, please +1.+1

APPROVED: Appoint Foundation staffer, Chris Hoge, to be DefCore Secretary for the Scale cycle.
2) Burn Down Calendar for Icehouse & Juno
Companies will want to prepare to make statements in Early April so that Board needs to approve capabilities in early April! That means we need to target March 3rd to have Juno capabilities in community review! Ideally, we can mainly focus on deltas from Havana and this work can go quickly.
We considered that it likely practical to review Icehouse and Juno in parallel since they are additive.
APPROVED: Form subcommittee to start capabilities review process. Coordinated by DefCore Secretary.

January
Refstack-client mods to run only defcore capabilities test
Process documentation.
Beta tester recruitement.
February
Evaluating tests, writing new tests
Remove admin requirements?
UUID Implementation
Clean up environment after running tests
Private beta testing concurrent
March
Partner Testing
April
Partner Testing, Markteplace buildout.

3) Decoupling Refstack
DefCore is about defining the tests, not scoring them. We have clear needs for a project like Refstack to help score vendors and collect usage data, it's not a blocker for our process. We want to support Refstack; however, we also need to keep DefCore timelines. For that reason, it's important to acknowledge that DefCore, as approved by the Board, is not dependent on Refstack milestones.

APPROVED: For Scale cycle, vendors can SELF-CERTIFY that they meet the DefCore criteria without any additional validation. Ideally, we'd have Refstack to allow them to prove compliance; however, we cannot commit to that right now. Basically, we are agreeing to take vendors at their word at this point.

Co-chairs

We are looking for a co-chair ? must be a board member. Please contact Rob Hirschfeld with interest.

TC Cross Membership

Monty & Russel chosen by the TC because they are cross membership w/ Board. Thierry is their backup.
Focus on process side.

Meeting Cadence

Q: Can we have an 8am PT start for meetings to be more EU friendly? +1-1+1Weekday preferences: no TUESDAY! (MWF), No FRIDAY Poll: Please +/- 1 : 8;00am+1+1+1-1 8:30am +1+1+1+1+1WINNER > 9:00am+1 +1+1+1+1+1 10:00am +1+1+1
Need to have at bi-weekly DefCore meeting (subcomittees will be active too) to ensure status & schedule updates.

at least having bi-weekly status reports to list.

Open Doors for the Secretary & Chairs ? communicate issues quickly

Capabilities Sub Commitee

Chris Hoge & Van L leading.
Need to engage technical review / PTLs
Goals this subcommittee: 1) draft the capabilities documents 2) identify the capabilities (changes from Havana)

2.a) Sample of results of defcore capabilities meeting with Keystone PTL https://etherpad.openstack.org/p/keystone-defcore
3) add new tests into capability and add capabilities 4) score the capabilities 5) designated sections also need to be reviewed 6) identify flagged testsWe hope that I & J in parallel. Icehouse is primary target.
Expected trend is weekly cadence but not all people have to attend all meetings. Chris is the common thread.
DECISION: Chris has authority to work 1x1 or in groups to collect and review this data. Please advise via the DefCore list if there is a planned meeting so that we have visiblity and option to join.

DefCore Process

Rob & Russell coordinating
Bylaws changes require having a documented process. Process needs to be approved by the TC & Board.
Goals: 1) draft a process (as patch) for TC & Board approval 2) vet process in community 3) find new home for .json files (if needed) 4) timeline ? should be presented to Board for March f2f meeting 5) post Board & TC review, needs to be go legal review (mid-March target)Expected trend is weekly cadence. There should not be out-of-band meetings.

SAMPLE:

Drawing: https://wiki.openstack.org/wiki/File:DefCoreProcessFlow.pdf
The following items are key points:

We are using the documents in the Gerrit review process to ensure that we work within the community processes.
Going forward, we want to rely on the technical leadership to create, cluster and describe capabilities. DefCore bootstrapped this process for Havana. Further, Capabilities are defined by tests in Tempest so test coverage gaps (like Keystone v2) translate into Core gaps.
We are investing in data driven and community involved feedback (via Refstack) to engage the largest possible base for core decisions.
There is a ?safety valve? for vendors to deal with test scenarios that are difficult to recreate in the field.
The Board is responsible for approving the final artifacts based on the recommendations. By having a transparent process, community input is expected in advance of that approval.
The process is time sensitive. There?s a need for the Board to produce Core definition in a timely way after each release and then feed that into the next one. Ideally, the definitions will be approved at the Board meeting immediately following the release.


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] DefCore capabilities

When: Occurs every Wednesday from 1:00 PM to 1:30 PM effective 1/28/2015. (UTC-06:00) Central Time (US & Canada)
Where: 1-855-600-7225, code 4625040

~~~~~~~~~

DefCore capabilities meetings. We will be updating this for Icehouse:

https://docs.google.com/spreadsheet/ccc?key=0Ags6GY_6T6qqdDBFOUNfdGs1VF85NmU3WjZXeFd3bGc&usp=sharing

Anyone with that link has the ability to edit.

Call-in information:
855.600.7225 (primary call-in)
212.231.7004 (secondary call-in)
4625040# (conference code)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150128/4046ee7c/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2595 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150128/4046ee7c/attachment.ics

When: Wednesday, February 18, 2015 1:00 PM-1:30 PM. (UTC-06:00) Central Time (US & Canada)
Where: 1-855-600-7225, code 4625040

~~~~~~~~~

DefCore capabilities meetings. We will be updating this for Icehouse:

https://docs.google.com/spreadsheet/ccc?key=0Ags6GY_6T6qqdDBFOUNfdGs1VF85NmU3WjZXeFd3bGc&usp=sharing

Anyone with that link has the ability to edit.

Call-in information:
855.600.7225 (primary call-in)
212.231.7004 (secondary call-in)
4625040# (conference code)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 3713 bytes
Desc: not available
URL:

[OpenStack-DefCore] New appointment: DefCore Scale.3 Meeting

You have been invited to an event by Hirschfeld, Rob:

====[ DefCore Scale.3 Meeting ]====

All times will be shown in the timezone Central Standard Time

When: Wednesday, January 28, 2015 - Every 2 weeks on Wednesday, Until Wednesday, April 1, 2015 11:00 AM - 12:00 PM
Where: https://join.me/852-233-300

====================================
Agenda TBD
https://etherpad.openstack.org/p/DefCoreScale.3

Join the meeting: https://join.me/852-233-300

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 852-233-300

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
Access Code 852-233-300#

Other international numbers available (https://join.me/intphone/852233300/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required.

Start time by time zones (https://join.me/timezone/1423069200000/1423072800000)

====================================

== Participants: ==

Hirschfeld, Rob (accepted)
defcore-committee at lists.openstack.org (waiting)

== Resources ==

== Details: ==

Show as: Reserved
Created: Friday, January 30, 2015 3:44 PM - Hirschfeld, Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150130/1e7e25e5/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2286 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150130/1e7e25e5/attachment-0001.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2328 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150130/1e7e25e5/attachment-0001.bin

[OpenStack-DefCore] DefCore Meeting TODAY/WEDNESDAY 2/4 @ 9 PT (schedule mix-up)

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/cb676b02/attachment.html

[OpenStack-DefCore] New appointment: DefCore Scale.3

You have been invited to an event by Hirschfeld, Rob:

====[ DefCore Scale.3 ]====

All times will be shown in the timezone Central Standard Time

When: Wednesday, February 4, 2015 11:00 AM - 12:00 PM
Where: https://etherpad.openstack.org/p/DefCoreScale.3

====================================
Conference Details: https://join.me/852-233-300

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code: 852-233-300

Access Code 852-233-300#

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
International: https://join.me/intphone/852233300/0

Agenda:
Appoint / Discuss Co-Chair Appointments & Elections
Face to Face Working Session (Austin TX)
Update on Capabilities
Review Process Materials to Date
Plan Process Vetting Options (Strawman, Working Sessions, Email Discussion, GoogleDocs)
Time permitting: start process review

====================================

== Participants: ==

Chris Hoge (waiting)
Egle Sigler (waiting)
Hirschfeld, Rob (accepted)
defcore-committee at lists.openstack.org (waiting)

== Resources ==

== Details: ==

Show as: Reserved
Created: Wednesday, February 4, 2015 12:07 AM - Hirschfeld, Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/2e2d0f4e/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2397 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/2e2d0f4e/attachment.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2440 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/2e2d0f4e/attachment.bin

[OpenStack-DefCore] Appointment changed: DefCore Scale.3

Hirschfeld, Rob has changed an event:

rob at rackn.com has been invited to the appointment.

====[ DefCore Scale.3 ]====

All times will be shown in the timezone Central Standard Time

When: Wednesday, February 4, 2015 11:00 AM - 12:00 PM
Where: https://etherpad.openstack.org/p/DefCoreScale.3

====================================
Conference Details: https://join.me/852-233-300

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code: 852-233-300

Access Code 852-233-300#

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
International: https://join.me/intphone/852233300/0

Agenda:
Appoint / Discuss Co-Chair Appointments & Elections
Face to Face Working Session (Austin TX)
Update on Capabilities
Review Process Materials to Date
Plan Process Vetting Options (Strawman, Working Sessions, Email Discussion, GoogleDocs)
Time permitting: start process review

====================================

== Participants: ==

Chris Hoge (waiting)
Egle Sigler (waiting)
Hirschfeld, Rob (accepted)
defcore-committee at lists.openstack.org (waiting)
rob at rackn.com (waiting)

== Resources ==

== Details: ==

Show as: Reserved
Created: Wednesday, February 4, 2015 12:07 AM - Hirschfeld, Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/6e8c273f/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2498 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/6e8c273f/attachment-0001.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2542 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/6e8c273f/attachment-0001.bin

[OpenStack-DefCore] DefCore Scale Process Discussion Backgrounders

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/67b8046a/attachment.html

In advance of the meeting I have some notes and observations regarding testing Havana advisory capabilities against my test cloud. I encourage anyone else to contribute their own observations and suggestions.

https://etherpad.openstack.org/p/havana-advisory-testing-notes https://etherpad.openstack.org/p/havana-advisory-testing-notes

Chris Hoge
Interop Engineer
OpenStack Foundation

On Feb 3, 2015, at 10:21 PM, Rob Hirschfeld wrote:

All,

Sorry for the late updates, I'm pulling together background material for tomorrow's meeting (It's still tomorrow in PT) and I wanted to drop some links and material that we will review in the meeting.

Sources of text copied below:

Rob's Blog about process & flow chart: http://robhirschfeld.com/2014/09/02/defcore-process-flow/
Detailed Process: https://etherpad.openstack.org/p/DefCoreLighthouse.F2F https://etherpad.openstack.org/p/DefCoreLighthouse.F2F https://etherpad.openstack.org/p/DefCoreLighthouse.F2F

Presented to the Board in December 2014:

The draft process flow chart was provided to the Board at our OSCON meeting without additional review. It below boils down to a few key points:

We are using the documents in the Gerrit review process to ensure that we work within the community processes.
Going forward, we want to rely on the technical leadership to create, cluster and describe capabilities. DefCore bootstrapped this process for Havana. Further, Capabilities are defined by tests in Tempest so test coverage gaps (like Keystone v2) translate into Core gaps.
We are investing in data driven and community involved feedback (via Refstack) to engage the largest possible base for core decisions.
There is a ?safety valve? for vendors to deal with test scenarios that are difficult to recreate in the field.
The Board is responsible for approving the final artifacts based on the recommendations. By having a transparent process, community input is expected in advance of that approval.
The process is time sensitive. There?s a need for the Board to produce Core definition in a timely way after each release and then feed that into the next one. Ideally, the definitions will be approved at the Board meeting immediately following the release.

Drafted at the June 2014 DefCore Face to Face:

PROCESS FOR DEFINITION OF CORE

Today's core definitions are tightly coupled to individual projects.Tomorrow's core definitions will be individual capabilities of different projects.

DEFINITION: Certification to use the OpenStack mark requires passing tests of capabilities, and including designated sections of code.

A. TESTS

All tempest tests for OpenStack must be grouped into capabilities.
Tests that don't pass in trunk (or that can only be passed by certain configurations) can be ?flagged? by DefCore, and will be skipped.
These capabilities are scored by the DefCore committee during each release cycle, using board-approved criteria.
The board defines the criteria for this scoring and may adjust relative importance of criteria with each release.
The board defines the cut-off score for determining that a capability is core
Capabilities that surpass the cutoff score are considered ?core capabilities?.
In each core capability, all non-flagged tests must pass in any OpenStack product or service that uses the mark
Capabilities will not be depricated without with at least 1 release notice

B. DESIGNATED SECTIONS

The PTL of each project will identify sections of code to be ?designated? which must be used in OpenStack products and services.
The TC will ratify these designated sections.
Designated sections only apply to projects that have some core capabilities.
Designated sections will not be increased without at least 1 release notice

C. ACTIVITIES(Work Flow?)

Criteria changes are managed by the DefCore committee and ratified by Board vote and posted on the OpenStack Wiki
Designated Sections changes are managed by the TC as Gerrit proposals
Capabilities changes are managed via Gerrit reviews
all tests are categorized into a capability by the PTL through Gerrit patch of the JSON file
tests are flagged-to-skip by approval of patches to the refstack json (by the Board as a slate vote)
Tests are unflagged through the same mechanism (by action of the DefCore committee)
DefCore changes to flagged to skip tests, criteria are to be ratified by the Board

D. GRIEVANCES

Test Issues > via Gerrit to Capabilities list
Critiera Issues > via DefCore mailing list & meetings
Designated Sections > via TC processes
Compliance Violations > same as trademark issues ACTION> SETUP trademark at openstack.org
Capabilities scores -> Community forums and roundtables during matrix review / also through Gerrit

E. PUBLISHING

The DefCore committee will manage content of a community website (currently at http://RefStack.org) and publish:
The DefCore principles
The current and historical scoring criteria
The categorization of tests into capabilities
The current and historical scored matrixes of capabilities
The scorecards of licensed products and services
Only ?pass? tests will be reported in the process
OpenStack retains the right to be the official source of the results, and will copyright the RefStack and DefCore materials to support this.

F. TIMELINES:

Vendors will anonymously self-certify their products and services under the DefCore program for the Juno release.
In the ?K? release, the Vendor's scorecards will be made public on the RefStack website.
Process modifications will be applied to future releases.


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Clarification requested in defcore process

Howdy defcore - I apologize if these have already been answered -

1) When do icehouse-core capabilities become "defcore" and accepted?

2) Based on https://docs.google.com/spreadsheet/ccc?key=0Ags6GY_6T6qqdDBFOUNfdGs1VF85NmU3WjZXeFd3bGc&usp=sharing#gid=6 (which I think may be a work-in-progress), the only identity capability candidate rated high is , but that doesn't seem to have any tests: https://github.com/stackforge/refstack/blob/master/defcore/icehousecore.json#L1449. Am I reading that right as a gap?

Thanks,
joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150204/3a054151/attachment.html

An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Coordinating DefCore Talks For Vancouver

DefCore Folks,

At today?s DefCoreScale.3 meeting, the matter of discussing DefCore at the Vancouver design summit was brought up. It sounds like we may have multiple folks interested in submitting talks and/or panels about DefCore and RefStack. Rather than have a lot of folks submitting overlapping talks, we?d like to try to do a little coordination beforehand. If you?re planning to submit a DefCore/RefStack talk, please make a note of it it here:

https://etherpad.openstack.org/p/DefCoreScale.3

If you?re looking for other DefCore folks to join your talk/panel, please note that as well.

At Your Service,

Mark T. Voelker
OpenStack Architect

Lauren Sell wrote:
Good point. I think we could either change the ?Community Building? track to simply be ?Community? and expand the scope and # of sessions to cover Governance, or we could add another small track for ?Community Governance.?

Thoughts?

I guess "Community" (with alteration of the track description to include
governance/structural topics) would do the trick.

Cheers,

--
Thierry Carrez (ttx)

[OpenStack-DefCore] DefCore Scale.3 Summary -> REMINDER Scale.4 on 2/11 @ 9am PT

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150205/cdad7426/attachment.html

[OpenStack-DefCore] DefCore Scale.4

You have been invited to a join.me online meeting \n \nJoin the meeting: https://join.me/983-251-904 \n \nOn a computer, use any browser with Flash. Nothing to download. \nOn a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 983-251-904 \n \nJoin the audio conference: \nDial a phone number and enter access code, or connect via internet. \n \nBy phone: \nUnited States - Camden, DE +1.302.202.5900 \nUnited States - Detroit, MI +1.734.746.0035 \nUnited States - Hartford, CT +1.860.970.0010 \nUnited States - Los Angeles, CA +1.213.226.1066 \nUnited States - New York, NY +1.646.307.1990 \nUnited States - San Francisco, CA +1.415.655.0381 \nUnited States - Saugus, MA +1.781.666.2350 \nUnited States - Tampa, FL +1.813.769.0500 \nAccess Code 983-251-904# \n \nOther international numbers available (https://join.me/intphone/983251904/0) \n \nBy computer via internet: \nJoin the meeting, click the phone icon and select 'Call via internet'. A small download might be required. \n \nStart time by time zones (https://join.me/timezone/1423717200000/1423720800000) \n \n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150206/7b66351b/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2016 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150206/7b66351b/attachment.ics

[OpenStack-DefCore] Appointment changed: DefCore Scale.4 Meeting

Hirschfeld, Rob has changed an event:

The appointment has a new subject: DefCore Scale.4 Meeting.
The appointment takes place in a new location: https://join.me/983-251-904 .
The appointment description has changed.

====[ DefCore Scale.4 Meeting ]====

All times will be shown in the timezone Central Standard Time

When: Wednesday, February 11, 2015 11:00 AM - 12:00 PM
Where: https://join.me/983-251-904

====================================
https://etherpad.openstack.org/p/DefCoreScale.4

Join the meeting: https://join.me/983-251-904

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code: 983-251-904

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 983-251-904#

Other international numbers available
https://join.me/intphone/983251904/0
====================================

== Participants: ==

Hirschfeld, Rob (accepted)
defcore-committee at lists.openstack.org (waiting)

== Resources ==

== Details: ==

Show as: Reserved
Created: Thursday, February 5, 2015 10:24 PM - Hirschfeld, Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150205/477a88e8/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2026 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150205/477a88e8/attachment-0001.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2068 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150205/477a88e8/attachment-0001.bin

[OpenStack-DefCore] DefCore Scale.4

You have been invited to a join.me online meeting \n \nhttps://etherpad.openstack.org/p/DefCoreScale.4 \n \nRealized that this was PM, not AM. \nMy emails are CORRECT - apparently, I cannot use Join.me to schedule. \n \n \nJoin the meeting: https://join.me/983-251-904 \n \nOn a computer, use any browser with Flash. Nothing to download. \nOn a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 983-251-904 \n \nJoin the audio conference: \nDial a phone number and enter access code, or connect via internet. \n \nBy phone: \nUnited States - Camden, DE +1.302.202.5900 \nUnited States - Detroit, MI +1.734.746.0035 \nUnited States - Hartford, CT +1.860.970.0010 \nUnited States - Los Angeles, CA +1.213.226.1066 \nUnited States - New York, NY +1.646.307.1990 \nUnited States - San Francisco, CA +1.415.655.0381 \nUnited States - Saugus, MA +1.781.666.2350 \nUnited States - Tampa, FL +1.813.769.0500 \nAccess Code 983-251-904# \n \nOther international numbers available (https://join.me/intphone/983251904/0) \n \nBy computer via internet: \nJoin the meeting, click the phone icon and select 'Call via internet'. A small download might be required. \n \nStart time by time zones (https://join.me/timezone/1423674000000/1423720800000) \n \n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150211/d8e116ca/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2188 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150211/d8e116ca/attachment-0001.ics

You have been invited to a join.me online meeting \n \nhttps://etherpad.openstack.org/p/DefCoreScale.4 \n \nRealized that this was PM, not AM. \nMy emails are CORRECT - apparently, I cannot use Join.me to schedule. \n \n \nJoin the meeting: https://join.me/983-251-904 \n \nOn a computer, use any browser with Flash. Nothing to download. \nOn a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 983-251-904 \n \nJoin the audio conference: \nDial a phone number and enter access code, or connect via internet. \n \nBy phone: \nUnited States - Camden, DE +1.302.202.5900 \nUnited States - Detroit, MI +1.734.746.0035 \nUnited States - Hartford, CT +1.860.970.0010 \nUnited States - Los Angeles, CA +1.213.226.1066 \nUnited States - New York, NY +1.646.307.1990 \nUnited States - San Francisco, CA +1.415.655.0381 \nUnited States - Saugus, MA +1.781.666.2350 \nUnited States - Tampa, FL +1.813.769.0500 \nAccess Code 983-251-904# \n \nOther international numbers available (https://join.me/intphone/983251904/0) \n \nBy computer via internet: \nJoin the meeting, click the phone icon and select 'Call via internet'. A small download might be required. \n \nStart time by time zones (https://join.me/timezone/1423674000000/1423764000000) \n \n
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2188 bytes
Desc: not available
URL:

[OpenStack-DefCore] DefCore Scale.4 - Defcore Repository

One item that I?ve added to the agenda is a location for the Defcore repository that will host capabilities, process documents, and testing tools. This is an important component of expanding our community review process of upcoming capabilities.

Options include a new project in the openstack namespace, stackforge, or as part of the governance repository.

-Chris

[OpenStack-DefCore] Scale.4 Summary, Scale.5 2/18 @ 9am PT & F2F 2/20 in Austin

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150211/e2e8e35c/attachment.html

An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Technical governance changes that may impact DefCore processes

I want to make sure that all on the DefCore committee is aware of Technical Governance changes that may impact how DefCore accomplishes its job.

The TC and developer community have been discussing "small core, big tent" for a while (about 9 months) and have released documents that direct how it intends to move forward with the changes. Here are links to some of those documents, either approved or still in flight. The items on the governance pages are approved and currently implemented or being implemented. There is still a lot of uncertainty as to how the TC will manage/direct all the cascading changes required.

Organizational changes:
http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html

New project tag "Integrated-Release":
http://governance.openstack.org/reference/tags/integrated-release.html
Note on the above, the last section lists the "integrated" projects for Kilo.

These specify the new process for a project to "join" OpenStack. They no longer will be moved to the OpenStack repositories, but can remain in stackforge. All contributors to stackforge projects will
https://wiki.openstack.org/wiki/Governance/NewProjectTeams
And requirements needed to be met:
http://governance.openstack.org/reference/new-projects-requirements.html

supporting discussions:
https://etherpad.openstack.org/p/project-restructure-hangouts
Note: There are discussions here about the expanding ATC base, the summit pass rules changes, etc.

Along with the new project process, there is also a new testing guidelines document that will be applied to all projects wanting to become part of OpenStack:
http://governance.openstack.org/reference/project-testing-interface.html

QA is currently proposing changing the gates to only gate continuously on the "core projects". They are trying to work out how to incorporate the non-core projects.

QA changes:
https://review.openstack.org/#/c/152683/

The other projects/programs identified as "horizontal" or spanning most or all other projects have not merged any specs on their process changes.

--Rocky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150211/c9a4958c/attachment.html

Thanks for the clarifications, Thierry! Not being totally involved and following only parts leads to my getting some foggy results, especially trying to find wikis and other related docs through not great search tools. Hopes this makes things clearer for the DefCore team. It might also lead to another blog post and/or more words tiring these altogether on a wiki or doc for the various communities. I try to keep up, but those at the center seldom realize how much context needs to be added for those only seeing the final decisions.

Again,thanks for the clarifications and corrections and hope this helps those reading Defcore ML

--Rocky

Sent from my iPad

On Feb 12, 2015, at 01:06, Thierry Carrez wrote:

See comments & corrections below.

FWIW I'm preparing a openstack.org blog post to publicize the recent
changes.

Rochelle Grober wrote:

[...]
New project tag ?Integrated-Release?:

http://governance.openstack.org/reference/tags/integrated-release.html

Note on the above, the last section lists the ?integrated? projects for
Kilo.

This tag is more a way to seamlessly transition the previous
categorization (being part of the integrated release or not) into the
new world order. Kilo will still do an integrated release, so we use the
tag to describe it.

[...]
These specify the new process for a project to ?join? OpenStack. They
no longer will be moved to the OpenStack repositories, but can remain in
stackforge.

I don't know where you got that information. Obviously projects
recognized as "produced by the OpenStack community" will live under the
openstack/ git organization name. Stackforge is explicitly not OpenStack.

The spec you linked to states:

"The second part of the change is recognizing that there is more to
?OpenStack? than a finite set of projects blessed by the Technical
Committee. We already have plenty of projects that are developed on
OpenStack infrastructure, follow the OpenStack way of doing things, have
development discussions on the openstack-dev mailing-list and use

openstack-meeting channels for their team meetings. Those are part of

the OpenStack community as well, and we propose that those should
considered ?OpenStack projects? (and be hosted under openstack git
namespaces), as long as they meet an objective criteria for inclusion
(to be developed as one of the work items below)."

[...]
Along with the new project process, there is also a new testing
guidelines document that will be applied to all projects wanting to
become part of OpenStack:

http://governance.openstack.org/reference/project-testing-interface.html

This document is actually not new. It describes how we operated in the
past years.

Cheers,

--
Thierry Carrez (ttx)


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Feedback on DefCore Process document

During the DefCore meeting yesterday, feedback was requested on the
following DefCore process document:

https://docs.google.com/document/d/1rekLXVuyXUxV1zWWxvpVaaS_8MSxGUqUp0bvC1C2prU/edit#heading=h.gqn73w9yzkli

I made some comments and suggested some edits, but wanted to bring some
of that here for discussion.

1) Ongoing maintenance of capabilities

One of the key points in the document is:

"Going forward, we want to rely on the technical leadership to
create, cluster and describe capabilities. DefCore bootstrapped
this process for Havana. Further, Capabilities are defined by
tests in Tempest..."

Later in the document, "technical leadership" was clarified as:

"all tests are categorized into a capability by the PTL
through a Gerrit patch of the JSON file"

I'm curious how much discussion there has been with the technical
leadership about this part. It seems important to work out for this to
be sustainable long term.

As I understand it, the test groupings into capabilities has been a
manual process so far. Is that right?

Ideally, I think we should be working with the tempest team to have the
required metadata be a part of tempest itself and kept up to date as
tests are added/removed/changed over time. I think that should be the
primary request to the technical leadership. Define a set of
requirements for the metadata needed about available tests and then
discuss possible solutions.

Perhaps there is existing work in this area already?

2) Designated Sections

I made several suggested edits to the document to clarify that the TC is
not responsible for defining designated sections. To recap, the
official TC response to this was:

http://governance.openstack.org/resolutions/20140211-tc_defcore_response.html

The suggested edits just change it such that the defcore committee is
responsible for defining designated sections, but will do so with input
from any interested community members. Further, the suggested edits
clarify that the ongoing maintenance of the designated sections
definitions will be done in the defcore git repository.

--
Russell Bryant

Thanks. There are places where the document pre-dates discussions where
we changed direction.

I think how capabilities will be maintained and formed over time is a
key aspect of the discussion around the DefCore process. Ideally, all
stakeholders would have a voice (e.g: users, ecosystem clients and
operators). There are a lot of ways to maintain the mapping of
capabilities to tests. One thing to think about is how to we handle if
"tests" expand beyond Tempest.

On 02/12/2015 10:01 AM, Russell Bryant wrote:
During the DefCore meeting yesterday, feedback was requested on the
following DefCore process document:

https://docs.google.com/document/d/1rekLXVuyXUxV1zWWxvpVaaS_8MSxGUqUp0bvC1C2prU/edit#heading=h.gqn73w9yzkli

I made some comments and suggested some edits, but wanted to bring some
of that here for discussion.

1) Ongoing maintenance of capabilities

One of the key points in the document is:

"Going forward, we want to rely on the technical leadership to
 create, cluster and describe capabilities.  DefCore bootstrapped
 this process for Havana.  Further, Capabilities are defined by
 tests in Tempest..."

Later in the document, "technical leadership" was clarified as:

"all tests are categorized into a capability by the PTL
 through a Gerrit patch of the JSON file"

I'm curious how much discussion there has been with the technical
leadership about this part. It seems important to work out for this to
be sustainable long term.

As I understand it, the test groupings into capabilities has been a
manual process so far. Is that right?

Ideally, I think we should be working with the tempest team to have the
required metadata be a part of tempest itself and kept up to date as
tests are added/removed/changed over time. I think that should be the
primary request to the technical leadership. Define a set of
requirements for the metadata needed about available tests and then
discuss possible solutions.

Perhaps there is existing work in this area already?

2) Designated Sections

I made several suggested edits to the document to clarify that the TC is
not responsible for defining designated sections. To recap, the
official TC response to this was:

http://governance.openstack.org/resolutions/20140211-tc_defcore_response.html

The suggested edits just change it such that the defcore committee is
responsible for defining designated sections, but will do so with input
from any interested community members. Further, the suggested edits
clarify that the ongoing maintenance of the designated sections
definitions will be done in the defcore git repository.

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

[OpenStack-DefCore] Definition of capabilities scoring

During the capabilities discussion yesterday, we discussed breaking up
the new capabilities that needed to be scored. Where can I find a
definition for each column in the scoring spreadsheet so that I can
ensure it is scored appropriately?

--
Russell Bryant

This should be considered the definitive source >
https://wiki.openstack.org/wiki/Governance/CoreCriteria

If we find needed updates, they should be discussed by the DefCore
committee.

On 02/12/2015 12:19 PM, Russell Bryant wrote:
During the capabilities discussion yesterday, we discussed breaking up
the new capabilities that needed to be scored. Where can I find a
definition for each column in the scoring spreadsheet so that I can
ensure it is scored appropriately?

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

[OpenStack-DefCore] DefCore capabilities 1 PM CST

Hello Everyone, this is a reminder of upcoming DefCore capabilities meeting.

Thank you,

Egle

When: Wednesday, February 18, 2015 1:00 PM-1:30 PM. (UTC-06:00) Central Time (US & Canada)
Where: 1-855-600-7225, code 4625040

~~~~~~~~~
DefCore capabilities meetings. We will be updating this for Icehouse:

https://docs.google.com/spreadsheet/ccc?key=0Ags6GY_6T6qqdDBFOUNfdGs1VF85NmU3WjZXeFd3bGc&usp=sharing

Anyone with that link has the ability to edit.

Call-in information:
855.600.7225 (primary call-in)
212.231.7004 (secondary call-in)
4625040# (conference code)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/82456617/attachment.html

Etherpad: https://etherpad.openstack.org/p/defcore-capabilities-feb-18-2015

From: ushnishtha at hotmail.com
To: defcore-committee at lists.openstack.org
Date: Wed, 18 Feb 2015 12:06:35 -0600
Subject: [OpenStack-DefCore] DefCore capabilities 1 PM CST

Hello Everyone, this is a reminder of upcoming DefCore capabilities meeting.

Thank you,

Egle

When: Wednesday, February 18, 2015 1:00 PM-1:30 PM. (UTC-06:00) Central Time (US & Canada)
Where: 1-855-600-7225, code 4625040

~~~~~~~~~
DefCore capabilities meetings. We will be updating this for Icehouse:

https://docs.google.com/spreadsheet/ccc?key=0Ags6GY_6T6qqdDBFOUNfdGs1VF85NmU3WjZXeFd3bGc&usp=sharing

Anyone with that link has the ability to edit.

Call-in information:
855.600.7225 (primary call-in)
212.231.7004 (secondary call-in)
4625040# (conference code)


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Invitation: (optional) DefCore F2F Prep Session @ Thu Feb 19, 2015 2pm - 5pm (Rob Hirschfeld)

You have been invited to the following event.

Title: (optional) DefCore F2F Prep Session
Chris, Egle & Rob Prepare for F2F on Friday
When: Thu Feb 19, 2015 2pm - 5pm Central Time
Where: Hangout & OpenStack Office
Video call: https://plus.google.com/hangouts/_/rackn.com/defcore-rob
https://plus.google.com/hangouts/_/rackn.com/defcore-rob?hceid=cm9iQHJhY2tuLmNvbQ.iksvnvb191v8ii7v38db80uip4
Calendar: Rob Hirschfeld
Who:
* Rob Hirschfeld - organizer
* defcore-committee at lists.openstack.org - optional

Your attendance is optional.

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=aWtzdm52YjE5MXY4aWk3djM4ZGI4MHVpcDQgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWVjMzA5ODZlNDM3ZDhjZTY3MTg2OTVkZDI1ZmY1OWQ2YTAxYzVkYzc&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/4a15a217/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1142 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/4a15a217/attachment.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1172 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/4a15a217/attachment.bin

[OpenStack-DefCore] Invitation: DefCore Face to Face Meeting @ Fri Feb 20, 2015 10am - 4pm (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Face to Face Meeting
See etherpad for details.

Capabilities Update / Scrub [1:00]
Use Cases for Tooling [0:30]
Process TC/Board Documentation [1:00]
Lunch Break [1:30]
Vendor Interfacing requirements [1:00]
review vendor feedback
Calendar Review [0:30] <- include Foundation Comms Team
Trademark Communication and Impacts [0:30] <- include Foundation Brand
Team
Communication Plan [1:00] <- include Foundation Comms Team
Summary / Wrap-up [0:30]

When: Fri Feb 20, 2015 10am - 4pm Central Time
Where: https://etherpad.openstack.org/p/DefCoreScale.F2F
Video call: https://plus.google.com/hangouts/_/rackn.com/defcore-f2f
https://plus.google.com/hangouts/_/rackn.com/defcore-f2f?hceid=cm9iQHJhY2tuLmNvbQ.qra46gvfjk083gpsv682e92hgc
Calendar: rob at rackn.com
Who:
* Rob Hirschfeld - organizer
* chris at openstack.org
* Egle Sigler
* defcore-committee at lists.openstack.org - optional

Your attendance is optional.

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=cXJhNDZndmZqazA4M2dwc3Y2ODJlOTJoZ2MgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTE4ODliYTUxZmVlMDE0NjQzMDVjODk0MzM0NzdiNDZhNWExMTRkODE&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/ac564a4d/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1852 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/ac564a4d/attachment-0001.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1891 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/ac564a4d/attachment-0001.bin

[OpenStack-DefCore] DefCore Scale.5 Summary. 2/20 (Friday!) Face to Face, 2/25 Scale.6

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/4abfe851/attachment.html

[OpenStack-DefCore] Invitation: DefCore @ Wed Feb 25, 2015 11am - 12pm (rob@rackn.com)

You have been invited to the following event.

Title: DefCore

DefCore.6

2015, Feb 25 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.5
Previous https://etherpad.openstack.org/p/DefCoreScale.F2F
Following: https://etherpad.openstack.org/p/DefCoreScale.7 (likely 3/11)

Meeting Contact Info

Join the meeting: https://join.me/105-877-178

Agenda

Status Updates
Review Face to Face items
Prep for Board Meeting on 3/2

When: Wed Feb 25, 2015 11am - 12pm Central Time
Where: https://etherpad.openstack.org/p/DefCoreScale.6
Calendar: rob at rackn.com
Who:
* Rob Hirschfeld - organizer
* chris at openstack.org
* Egle Sigler
* defcore-committee at lists.openstack.org - optional

Your attendance is optional.

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=dHZiZGZlcm50cXZmOWI3N3FoZnUwMXUzY2cgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTRjZWI2N2NkMDUxMWNjOWQyOGZiMzBmYTllZjlmYjcxMGU5ZmUzMmY&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/45b3cde7/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1791 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/45b3cde7/attachment-0001.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1830 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/45b3cde7/attachment-0001.bin

[OpenStack-DefCore] Please vote for DefCore sessions

An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150218/e9da0503/attachment.html

Hi Rob,

We have submitted a session titled "DefCore and Me". The plan was to show how our companies are beginning to assess their readiness for DefCore using tools like RefStack and capabilities. Please view the abstract for further details.

https://www.openstack.org/vote-vancouver/presentation/defcore-and-me

Thanks,
Shamail

On Feb 18, 2015, at 3:20 PM, Rob Hirschfeld wrote:

All,

It's the nature of this process, we need to encourage voting.

Please help promote the DefCore sessions:

The DefCore Show: ?is it core or not? feud episode ( Speakers: Rob Hirschfeld, Rock Grober, Alan Clark, Egle Sigler, Chris Hoge, Van Lindberg, Randy Bias )
https://www.openstack.org/vote-vancouver/Presentation/the-defcore-show-is-it-core-or-not-feud-episode

DefCore 2015 submitted by Sean Roberts ( Speakers: Sean Roberts, Rob Hirschfeld, Alan Clark, Egle Sigler )
https://www.openstack.org/vote-vancouver/Presentation/defcore-2015

Thanks

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob at rackn.com)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Excellent Results from DefCore List > Scale.6 meeting 9am on Wed!

DefCore Committee,

We had a very productive Face to Face meeting yesterday. Thank you for
the many who joined us! We had 5 board members participating in the
process, great Foundation participation and engaged community turn out.

It's going to take some time to pull together all the great work into a
single report.

The very short summary is:
1) we made progress on scoring capabilities
2) we committed to having a "quick pass" on next capabilities for the
board meetings in March AND April AND May.
3) we created two summary graphics that show how DefCore operates
4) we have a proposal to change how we deliver DefCore from a release
score concept into a time based guidelines approach
this approach decouples DefCore from specific releases in a very
positive way
and makes it easier for us to communicate results and cross-release
interoperability expectations
5) we made a lot of progress on the process document for review on 3/3
by the BoD.

Come to the meeting on Wednesday for more details:
https://etherpad.openstack.org/p/DefCoreScale.6

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

Expedia ego...

Sent from my Verizon 4G LTE Smartphone

----- Reply message -----
From: "sean roberts"
To: "Rob Hirschfeld"
Cc: "defcore-committee at lists.openstack.org"
Subject: [OpenStack-DefCore] Excellent Results from DefCore List > Scale.6 meeting 9am on Wed!
Date: Mon, Feb 23, 2015 8:23 PM

Lots of clean up underway on the process gdoc. The four graphics are very close to complete for this revision. We need some extra eyeballs on the detailed process steps. Rob kept us on task last Friday, which has led to a explosion of good work.

Join in today as we have a board meeting next Monday which will be reviewing DefCore progress

On Saturday, February 21, 2015, Rob Hirschfeld > wrote:
DefCore Committee,

We had a very productive Face to Face meeting yesterday. Thank you for the many who joined us! We had 5 board members participating in the process, great Foundation participation and engaged community turn out.

It's going to take some time to pull together all the great work into a single report.

The very short summary is:
1) we made progress on scoring capabilities
2) we committed to having a "quick pass" on next capabilities for the board meetings in March AND April AND May.
3) we created two summary graphics that show how DefCore operates
4) we have a proposal to change how we deliver DefCore from a release score concept into a time based guidelines approach
this approach decouples DefCore from specific releases in a very positive way
and makes it easier for us to communicate results and cross-release interoperability expectations
5) we made a lot of progress on the process document for review on 3/3 by the BoD.

Come to the meeting on Wednesday for more details: https://etherpad.openstack.org/p/DefCoreScale.6

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--
~sean

[OpenStack-DefCore] Appointment canceled: DefCore Scale.3 Meeting

Hirschfeld, Rob has deleted an appointment, or you have been removed as a participant:

====[ DefCore Scale.3 Meeting ]====

All times will be shown in the timezone Central Standard Time

When: Wednesday, January 28, 2015 - Every 2 weeks on Wednesday, Until Wednesday, April 1, 2015 11:00 AM - 12:00 PM
Where: https://join.me/852-233-300

====================================
Agenda TBD
https://etherpad.openstack.org/p/DefCoreScale.3

Join the meeting: https://join.me/852-233-300

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 852-233-300

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
Access Code 852-233-300#

Other international numbers available (https://join.me/intphone/852233300/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required.

Start time by time zones (https://join.me/timezone/1423069200000/1423072800000)

====================================

== Details: ==

Show as: Reserved
Created: Friday, January 30, 2015 3:44 PM - Friday, January 30, 2015 3:44 PM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150224/5b85e379/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2285 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150224/5b85e379/attachment.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cancel.ics
Type: application/ics
Size: 2327 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150224/5b85e379/attachment.bin

[OpenStack-DefCore] reminder of today's meeting

*9am PST *
https://etherpad.openstack.org/p/DefCoreScale.6
https://join.me/105-877-178

~ sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150225/1f7e3858/attachment.html

Following up on the discussion about ?next steps? for mark application, this Foundation page will always be kept up to date on the process for working with the OpenStack Foundation to apply the brand to a product.

http://www.openstack.org/brand

On Feb 25, 2015, at 8:21 AM, sean roberts wrote:

9am PST
https://etherpad.openstack.org/p/DefCoreScale.6 https://etherpad.openstack.org/p/DefCoreScale.6
https://join.me/105-877-178 https://join.me/105-877-178

~ sean


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Draft 2015.03 Spec

Hello all

Per the discussion today and at the face to face meeting last week, we have the following draft 2015.03 spec for comments and approval:

https://etherpad.openstack.org/p/defcore-draft-spec-2015.03

Notes:
- There are two advisory sections: auth-token (which we created a placeholder for) and compute-servers-metadata (which didn't exist in havanacore, but was in icehousecore). Because the point of this doc is "havanacore - anything possibly troublesome," we suggested moving compute-servers-metadata to advisory for action in 2015.04.
- This is .rst formatted and designed for human consumption. There is a linked (and also authoritative) .json file for machine consumption.
- The .json file (draft in gdoc for easy multi-editing right now) has everything that is not mandatory or advisory removed.
- We updated the versioning of the .json file (to 1.1), removed "status" from the top-level, and added "advisory" flags for those two items that were advisory. We also updated "core" to false for the two advisory items.
- We need designated sections for keystone.

Thanks,
Van

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150225/d0e64095/attachment.html

Chris,

Yes, the Tempest pattern is established (pattern of 1), and as I mentioned earlier, I'm not opposed to that, in principle. However, that will need more discussion and coding time from other Swift contributors (especially the core reviewers). As you mentioned, this took a year in Tempest. I'm not trying to judge UUID decorators on methods (I'm sure that could occupy a few mailing lists for a while).

While other discussions and code work around decorating in-tree functional tests are ongoing, is there a path forward for mapping Swift's existing in-tree functional tests to DefCore object storage capabilities?

--John

On Mar 1, 2015, at 3:27 PM, Chris Hoge wrote:

John,

This is very new. There has been intention to make this a standard in Tempest tests for a year now, and we finally found the resources to push an implementation through. I think that following the Tempest lead and decorating tests with a uuid of the same or similar format (@test.idempotent_id(?12345678-1234-1234-1234-1234-123456789abc?)) would future proof the tests against any potential refactoring and make the identification in capabilities consistent across all of the projects.

-Chris

On Feb 27, 2015, at 2:35 PM, John Dickinson wrote:

That is interesting. I'll certainly bring it up with the rest of the Swift contributors, and, on the surface, it seems possible.

As I mentioned, the tests-have-UUIDs is new to me (and it seems to have only very recently landed in tempest). The test names in Swift's functional tests are very stable. While I'm not opposed to figuring out how a UUID scheme for tests might work, can we move forward with mapping them to capabilities while other discussions happen with UUIDs?

--John

On Feb 27, 2015, at 10:11 AM, Mark Voelker wrote:

Signed PGP part
Just so. Background info:

http://lists.openstack.org/pipermail/openstack-dev/2015-February/057923.html

At Your Service,

Mark T. Voelker

On Feb 27, 2015, at 9:27 AM, Monty Taylor wrote:

Signed PGP part
On 02/27/2015 12:18 PM, John Dickinson wrote:

Rob, is that question directed to me? I'm not sure what a test UUID
is.

They added UUIDs to tempest tests so that as test names or re-org'd,
the defcore mapping didn't have to implode. So I think the question is
about the feasibility of doing such a thing in the swift functional tests.

--John

On Feb 25, 2015, at 3:58 PM, Rob Hirschfeld
wrote:

Good question. Can those tests also get UUIDs?

On Feb 25, 2015 5:30 PM, John Dickinson wrote:

Looks like all of the tests mentioned are still focused on
tempest. Since many projects are moving towards in-tree
functional tests, how can those be reflected in the listed
tests. For example, i'd love to also use the swift in-tree
functional tests for referenced swift capabilities.

--John

On Feb 25, 2015, at 3:11 PM, Van Lindberg
<van.lindberg at rackspace.com> wrote:

Should we forward this on to the board?

From: Van Lindberg <van.lindberg at rackspace.com> Date:
Wednesday, February 25, 2015 at 1:51 PM To:
"defcore-committee at lists.openstack.org"
Cc: Egle Sigler
<egle.sigler at rackspace.com>, Adrian Otto
<adrian.otto at rackspace.com> Subject: [OpenStack-DefCore]
Draft 2015.03 Spec

Hello all

Per the discussion today and at the face to face meeting last
week, we have the following draft 2015.03 spec for comments
and approval:

https://etherpad.openstack.org/p/defcore-draft-spec-2015.03

Notes: - There are two advisory sections: auth-token (which
we created a placeholder for) and compute-servers-metadata
(which didn?t exist in havanacore, but was in icehousecore).
Because the point of this doc is ?havanacore - anything
possibly troublesome,? we suggested moving
compute-servers-metadata to advisory for action in 2015.04. -
This is .rst formatted and designed for human consumption.
There is a linked (and also authoritative) .json file for
machine consumption. - The .json file (draft in gdoc for easy
multi-editing right now) has everything that is not mandatory
or advisory removed. - We updated the versioning of the .json
file (to 1.1), removed ?status? from the top-level, and added
?advisory? flags for those two items that were advisory. We
also updated ?core? to false for the two advisory items. - We
need designated sections for keystone.

Thanks, Van


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

_______________________________________________ Defcore-committee
mailing list Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:

[OpenStack-DefCore] Rally in a Containter : A reference implementation similar to TCup

Hello,

I am working on an implementation similar to TCup which does temepst tests
and get results back. Instead of using tempest I have used rally in a
docker container.

I have a ready available demo for same with docker & k8s, I would like to
present what i have done, how it works, get feedback, improvise and
possibility of getting it in refstack.

Please let me know how I can do that.

Best Regards,
Swapnil Kulkarni
irc : coolsvap
coolsvap at gmail.com
+91-87960 10622(c)
http://in.linkedin.com/in/coolsvap
"It's better to SHARE"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150226/4ba592cb/attachment.html

As discussed with Chris,

I have pushed a reference docker image [1] and steps are listed at [2].
This is at very early stage, I am working on adding more features.
Currently you can just provide the deployment details and get the tempest
logs for it.

Please have a look and let me know your review comments.

[1] https://registry.hub.docker.com/u/coolsvap/docker-rally/
[2] http://wp.me/p35Y7M-3l

Best Regards,
Swapnil Kulkarni
irc : coolsvap
coolsvap at gmail dot com
+91-87960 10622(c)
http://in.linkedin.com/in/coolsvap
"It's better to SHARE"

On Sat, Feb 28, 2015 at 10:43 AM, Swapnil Kulkarni
wrote:

On Sat, Feb 28, 2015 at 4:05 AM, Rochelle Grober <
rochelle.grober at huawei.com> wrote:

Monty,

I believe that this tempest/rally in a container is specifically for
clouds other than infra, e.g., customers' clouds.

This is exactly the use case I am targeting at.

They need to test, too;-)

--Rocky

-----Original Message-----
From: Monty Taylor [mailto:mordred at inaugust.com]
Sent: Friday, February 27, 2015 14:30
To: sean roberts; Swapnil Kulkarni; Chris Hoge
Cc: defcore-commit.
Subject: Re: [OpenStack-DefCore] Rally in a Containter : A reference
implementation similar to TCup

Hi!

That's pretty cool, and I'd love to see it just in general.

HOWEVER - I do want to make sure I say something to be really clear.

We have kind of a lot of automation already existing to handle tasks
like "run tempest" or "run rally" We have a giant farm of servers ready
to go that do such tasks between 10k and 20k times a day.

It may be that not taking advantage of that is necessary, that there are
requirements that I don't know about, etc. But I would be remiss if I
did not point out its existence

Monty

On 02/27/2015 05:12 PM, sean roberts wrote:

Chris: will this approach help with restarting RefStack?

On Wednesday, February 25, 2015, Swapnil Kulkarni
wrote:

Hello,

I am working on an implementation similar to TCup which does temepst
tests
and get results back. Instead of using tempest I have used rally in a
docker container.

I have a ready available demo for same with docker & k8s, I would like
to
present what i have done, how it works, get feedback, improvise and
possibility of getting it in refstack.

Please let me know how I can do that.

Best Regards,
Swapnil Kulkarni
irc : coolsvap
coolsvap at gmail.com <javascript:_e(%7B%7D,'cvml','coolsvap at gmail.com
');>
+91-87960 10622(c)
http://in.linkedin.com/in/coolsvap
*"It's better to SHARE"*


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Invitation: DefCore.7 @ Wed Mar 11, 2015 9am - 10am (Rob Hirschfeld)

You have been invited to the following event.

Title: DefCore.7
Join the meeting: https://join.me/600-225-471

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code:
600-225-471

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 600-225-471#

Other international numbers available https://join.me/intphone/600225471/0
When: Wed Mar 11, 2015 9am - 10am Central Time
Where: https://etherpad.openstack.org/p/DefCoreScale.7
Video call: https://plus.google.com/hangouts/_/rackn.com/defcore-rob
https://plus.google.com/hangouts/_/rackn.com/defcore-rob?hceid=cm9iQHJhY2tuLmNvbQ.gldq0g79td00n630luloqm6spo
Calendar: Rob Hirschfeld
Who:
* Rob Hirschfeld - organizer
* defcore-committee at lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=Z2xkcTBnNzl0ZDAwbjYzMGx1bG9xbTZzcG8gZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWUxNWYzYjJhYTIyMTg3NjlmN2Y0YzgyYzZiNGQ1MTU4OWNkYWZjMDc&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150226/894354ed/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1935 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150226/894354ed/attachment.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1975 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150226/894354ed/attachment.bin

[OpenStack-DefCore] Trying to explain Guidelines... here's what I'm thinking [feedback welcome]

DefCore... does this explain Guidelines?

Last week, the OpenStack DefCore committee rolled up our collective
sleeves and got to work in a serious way. We had a in-person meeting
with great turn out with 5 board members, Foundation executives/staff
and good community engagement.

TL;DR > We think DefCore should dated milestone guidelines instead
tightly coupled to release events (see graphic
https://robhirschfeld.files.wordpress.com/2015/02/defcore-timeline1.png).

DefCore has a single goal expressed from two sides: 1) defining the
"what is OpenStack" brand for Vendors and 2) driving interoperability
between OpenStack installations. From that perspective, it is not about
releases, but about testable stable capabilities. Over time, these
changes should be incremental and, most importantly, trail behind new
features that are added.

For those reasons, it was becoming confusing for DefCore to focus on an
"Icehouse" definition when most of the capabilities listed are "Havana"
ones. We also created significant time pressure to get the "Kilo
DefCore" out quickly after the release even though there were no "Kilo"
specific additions covered.

In the face-to-face, we settled on a more incremental approach. DefCore
would regularly post a set of guidelines for approval by the Board.
These Guidelines would include the required, deprecated (leaving) and
advisory (coming) capabilities required for Vendors to use the mark (see
footnote*). They would also include the relevant designated sections.
These Guidelines would use the open draft and discussion process that we
are in the process of outlining for approval in Vancouver.

Since DefCore Guidelines are simple time based lists of capabilities,
the vendors and community can simply reference an approved Guideline
using the date of approval (for example DefCore 2015.03) and know
exactly what was included. While each Guideline stands alone, it is
easy to compare them for incremental changes.

We've been getting positive feedback about this change; however, we are
still discussing it appreciate your input and questions. It is very
important for us to make DefCore simple and easy. For that, your
confused looks and WTF? comments are very helpful.

  • footnote: the Foundation manages that process the Vendors. DefCore
    Guidelines are just one part of the brand process.

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

Shamail,

I think that needs to be a subject of discussion once we start getting
some data.

My gut is that we'd want to see at least 70% penetration of a API set.
That means that in 70% of the reports, we see 100% passing of the tests
in the capability. Said another way, 7 out of 10 OpenStack
implementations (reporting results) would have that capability in a
fully functioning way.

I don't know if that's the right cut off - the only way to know is to
compare it against other capabilities. I am very confident that we'll
see a clear in/out range once we start collecting data. I just don't
know the actual %.

I hope that helps.

Rob

On 02/27/2015 12:43 PM, Shamail wrote:
How do we define "broad adoption"? Should we state some threshold or
criteria or will it be subjective for now?

Thanks,
Shamail

On Feb 27, 2015, at 12:03 PM, Rob Hirschfeld > wrote:

YES! very very well said.

On 02/27/2015 10:38 AM, Barrett, Carol L wrote:

Thanks Rob ? so when capabilities become accepted in the market
Defcore ensures support for them moving forward, until it?s no
longer appropriate.

I?ll take up my branding concerns with the marketing side of the house.

Carol

From:Rob Hirschfeld [mailto:rob at zehicle.com]
Sent: Friday, February 27, 2015 8:36 AM
To: Barrett, Carol L; Rob Hirschfeld; Shamail
Cc: defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Trying to explain Guidelines...
here's what I'm thinking [feedback welcome]

Carol,

DefCore can't. IMHO, it one of Vendors' roles to select, validate
and support new capabilities. DefCore comes along after those
capabilities are broadly adopted. It would be an anti-pattern if we
selected capabilities that were only in one or two products/distros.

The reason to move away from releases was to decouple this exact
discussion. DefCore is not about features in releases but long term
capabilities of the platform.

Rob

On 02/27/2015 10:00 AM, Barrett, Carol L wrote:

Rob ? With my Branding hat on, it?s less about API uptake and
more about the connotation of the Brand on a release. If the
OpenStack Brand on a distro means a promise of quality,
interoperability and backward compatibility how can we deliver
on that for new capabilities without having evaluated them and
ensure there?s appropriate testing?

Carol

*From:*Rob Hirschfeld [mailto:rob at zehicle.com]
*Sent:* Thursday, February 26, 2015 4:41 PM
*To:* Barrett, Carol L; Rob Hirschfeld; Shamail
*Cc:* defcore-committee at lists.openstack.org
<mailto:defcore-committee at lists.openstack.org>
*Subject:* Re: [OpenStack-DefCore] Trying to explain
Guidelines... here's what I'm thinking [feedback welcome]

Carol,

Let me turn that around.  If a project released new capabilities
out of cycle, how quickly would you expect them to surface into
the DefCore guidelines?

By design, we select for widely-used APIs.  So, how fast should
we expect a new feature to get wide adoption.

Rob

On 02/26/2015 03:48 PM, Barrett, Carol L wrote:

    I expect that the unpredictability of project releases will
    create challenges in many ways. Branding is one of them ? if
    a project releases new capabilities out of cycle to the
    core-projects release of the Defcore definition update,
    those new features will not be covered by the Brand (which
    means they haven?t been validated to a certain level nor is
    there any backward API compatibility promise). How will an
    end-user know that?  If the Brand doesn?t simplify the
    purchasing process for the end-user, then we?re not on the
    right track..imho.

    *From:*Rob Hirschfeld [mailto:rob at rackn.com]
    *Sent:* Thursday, February 26, 2015 1:42 PM
    *To:* Shamail
    *Cc:* Barrett, Carol L;
    defcore-committee at lists.openstack.org
    <mailto:defcore-committee at lists.openstack.org>
    *Subject:* Re: [OpenStack-DefCore] Trying to explain
    Guidelines... here's what I'm thinking [feedback welcome]

    Good questions.  We're including which releases are covered
    in each guideline so, for example, you can track DefCore
    2015.07 to the I,J & K releases.  You can't use that
    guideline against H or L

    On Thu, Feb 26, 2015 at 3:38 PM, Shamail
    <itzshamail at gmail.com <mailto:itzshamail at gmail.com>> wrote:

    Hi Carol,

    I agree with the concern but I think (I didn't attend the
    F2F) some of this may be driven by the fact that we don't
    necessarily have a concrete definition of what a release may
    look like in the future.

    If the releases (due to project structure reform) end up
    having a cadence with a usual group of components then I
    could see aligning with releases but I think some of that is
    TBD at this point, therefore this seems like a safe bet.

    Thanks,
    Shamail



    > On Feb 26, 2015, at 3:52 PM, Barrett, Carol L
    <carol.l.barrett at intel.com
    <mailto:carol.l.barrett at intel.com>> wrote:
    >
    > I am concerned about achieving the Brand goal,  using a
    month/year approach rather than a release approach. Is the
    expectation that a vendor will pull the upstream  for the
    month/year Defcore test and ship a product?  If a vendor
    release cycle is offset by 2 months, what would use to
    validate their Brand compliance? My thought is by that time
    new things will be included in a variety of projects that
    will be included in the Vendor release but not comprehended
    in the 2 month old Defcore definition.
    >
    > Carol
    >
    > -----Original Message-----
    > From: Rob Hirschfeld [mailto:rob at zehicle.com
    <mailto:rob at zehicle.com>]
    > Sent: Thursday, February 26, 2015 11:37 AM
    > To: defcore-committee at lists.openstack.org
    <mailto:defcore-committee at lists.openstack.org>
    > Subject: Re: [OpenStack-DefCore] Trying to explain
    Guidelines... here's what I'm thinking [feedback welcome]
    >
    > Chris Lee pinged me about missing a note Component &
    Platform levels.
    > We need to include that in the Guidelines.
    >
    > Good catch Chris!
    >
    >> On 02/26/2015 12:46 PM, Rob Hirschfeld wrote:
    >> DefCore... does this explain Guidelines?
    >>
    >> Last week, the OpenStack DefCore committee rolled up our
    collective
    >> sleeves and got to work in a serious way.  We had a
    in-person meeting
    >> with great turn out with 5 board members, Foundation
    executives/staff
    >> and good community engagement.
    >>
    >> TL;DR > We think DefCore should dated milestone
    guidelines instead
    >> tightly coupled to release events (see graphic
    >>
    https://robhirschfeld.files.wordpress.com/2015/02/defcore-timeline1.png).
    >>
    >> DefCore has a single goal expressed from two sides: 1)
    defining the
    >> "what is OpenStack" brand for Vendors and 2) driving
    interoperability
    >> between OpenStack installations.  From that perspective,
    it is not
    >> about releases, but about testable stable capabilities. 
    Over time,
    >> these changes should be incremental and, most
    importantly, trail
    >> behind new features that are added.
    >>
    >> For those reasons, it was becoming confusing for DefCore
    to focus on
    >> an "Icehouse" definition when most of the capabilities
    listed are
    >> "Havana" ones.  We also created significant time pressure
    to get the
    >> "Kilo DefCore" out quickly after the release even though
    there were no
    >> "Kilo" specific additions covered.
    >>
    >> In the face-to-face, we settled on a more incremental
    approach.
    >> DefCore would regularly post a set of guidelines for
    approval by the
    >> Board.  These Guidelines would include the required,
    deprecated
    >> (leaving) and advisory (coming) capabilities required for
    Vendors to
    >> use the mark (see footnote*).  They would also include
    the relevant
    >> designated sections.  These Guidelines would use the open
    draft and
    >> discussion process that we are in the process of
    outlining for
    >> approval in Vancouver.
    >>
    >> Since DefCore Guidelines are simple time based lists of
    capabilities,
    >> the vendors and community can simply reference an
    approved Guideline
    >> using the date of approval (for example DefCore 2015.03)
    and know
    >> exactly what was included.  While each Guideline stands
    alone, it is
    >> easy to compare them for incremental changes.
    >>
    >> We've been getting positive feedback about this change;
    however, we
    >> are still discussing it appreciate your input and
    questions. It is
    >> very important for us to make DefCore simple and easy. 
    For that, your
    >> confused looks and WTF? comments are very helpful.
    >>
    >> * footnote: the Foundation manages that process the
    Vendors. DefCore
    >> Guidelines are just one part of the brand process.
    >
    > --
    >
    >
    > Rob
    > ____________________________
    > Rob Hirschfeld, 512-773-7522 <tel:512-773-7522>
    >
    > I am in CENTRAL (-6) time
    > http://robhirschfeld.com
    > twitter: @zehicle, github: cloudedge & ravolt
    >
    >
    > _______________________________________________
    > Defcore-committee mailing list
    > Defcore-committee at lists.openstack.org
    <mailto:Defcore-committee at lists.openstack.org>
    >
    http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
    >
    > _______________________________________________
    > Defcore-committee mailing list
    > Defcore-committee at lists.openstack.org
    <mailto:Defcore-committee at lists.openstack.org>
    >
    http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

    _______________________________________________
    Defcore-committee mailing list
    Defcore-committee at lists.openstack.org
    <mailto:Defcore-committee at lists.openstack.org>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee



    -- 

    Rob
    ____________________________
    Rob Hirschfeld, 512-773-7522
    RackN CEO/Founder (rob at rackn.com <mailto:rob at rackn.com>)

    I am in CENTRAL (-6) time
    http://robhirschfeld.com
    twitter: @zehicle, github: cloudedge & ravolt





    _______________________________________________

    Defcore-committee mailing list

    Defcore-committee at lists.openstack.org  <mailto:Defcore-committee at lists.openstack.org>

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




-- 

   

  

Rob

____________________________

Rob Hirschfeld, 512-773-7522

  

I am in CENTRAL (-6) time

http://robhirschfeld.com

twitter: @zehicle, github: cloudedge & ravolt

--


Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] INTRO: Hi, I'm Jim.

So, this guy walks into a mailing list ... and introduces himself.

I'm Jim Meyer. I work for HP Cloud, leading the Helion OpenStack Distro teams. I've been here about a third of a year, and we've just gone through our first release with me involved. No fatalities have been reported as yet, but it's early days.

Not so long ago, I was at Rackspace working side-by-side with several of the fine folks on this committee; it's good to see y'all again. For those I don't know yet, I'm looking forward to getting to know you.

Meanwhile, I'm reading the archives to get a bit caught up. I expect I'll mostly be listening for a while except when I'm asking obnoxious numbers of questions trying to cure my ignorance. I look forward to helping out and, eventually, pulling my weight with useful contributions.

Until then,

--j

Roger, and will do. Having a challenge about next week?s Friday meeting in that I?m not in the office, but y?all won?t miss me much if I can?t make it.

?j

On Mar 5, 2015, at 10:39 AM, Egle Sigler > wrote:

Hello Jim, welcome to the list! Let us know if you have any questions. I think a lot of people are traveling this week, so slow on the responses. Join us during the weekly meetings at 9 am PST/ 11 am CST on Wednesdays.

Egle

From: jim.meyer at hp.com<mailto:jim.meyer at hp.com>
To: defcore-committee at lists.openstack.org
Date: Tue, 3 Mar 2015 04:35:38 +0000
Subject: [OpenStack-DefCore] INTRO: Hi, I'm Jim.

So, this guy walks into a mailing list ... and introduces himself.

I'm Jim Meyer. I work for HP Cloud, leading the Helion OpenStack Distro teams. I've been here about a third of a year, and we've just gone through our first release with me involved. No fatalities have been reported as yet, but it's early days.

Not so long ago, I was at Rackspace working side-by-side with several of the fine folks on this committee; it's good to see y'all again. For those I don't know yet, I'm looking forward to getting to know you.

Meanwhile, I'm reading the archives to get a bit caught up. I expect I'll mostly be listening for a while except when I'm asking obnoxious numbers of questions trying to cure my ignorance. I look forward to helping out and, eventually, pulling my weight with useful contributions.

Until then,

--j


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] weekly Wed morning mtgs

I was asked to put the weekly Wed morning meetings on my manager's calendar, but not sure where I find them. I believe the mtgs are on Wed mornings 9 - 10 CST. Thank you, Vicky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150303/cf101a6f/attachment.html

[OpenStack-DefCore] Invitation: DefCore.7 @ Wed Mar 11,

Rob, Jim Meyer thought this mtg was PST and it email shows CST, can you let me know which time zone call on March 11th will be. Thank you, Vicky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150303/b97b1850/attachment.html

Hello Vicky,

The meetings are held on Wednesdays, 9 AM PST/ 11 CST.
Etherpad: https://etherpad.openstack.org/p/DefCoreScale.7

DefCore.7 2015, March 11 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.6Following: https://etherpad.openstack.org/p/DefCoreScale.8
Join the meeting: https://join.me/600-225-471
On a computer, use any browser with Flash. Nothing to download. On a phone or tablet, launch the join.me app and enter meeting code: 600-225-471
Join the audio conference: Dial a phone number and enter access code, or connect via internet.
By phone: United States - Camden, DE +1.302.202.5900 United States - Detroit, MI +1.734.746.0035 United States - Hartford, CT +1.860.970.0010 United States - Los Angeles, CA +1.213.226.1066 United States - New York, NY +1.646.307.1990 United States - San Francisco, CA +1.415.655.0381 United States - Saugus, MA +1.781.666.2350 United States - Tampa, FL +1.813.769.0500 Access Code 600-225-471#
Other international numbers available https://join.me/intphone/600225471/0
Thank you,
Egle

From: vicky.boles at hp.com
To: defcore-committee at lists.openstack.org
Date: Tue, 3 Mar 2015 15:01:50 +0000
Subject: Re: [OpenStack-DefCore] Invitation: DefCore.7 @ Wed Mar 11,

Rob, Jim Meyer thought this mtg was PST and it email shows CST, can you let me know which time zone call on March 11th will be. Thank you, Vicky


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Invitation: DefCore Scale.7 @ Fri Mar 13, 2015 11am - 12pm (null)

You have been invited to the following event.

Title: DefCore Scale.7
You have been invited to a join.me online meeting

https://etherpad.openstack.org/p/DefCoreScale.7

Join the meeting: https://join.me/600-225-471

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 600-225-471

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 600-225-471#

Other international numbers available (https://join.me/intphone/600225471/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1426262400000/1426266000000)

When: Fri Mar 13, 2015 11am - 12pm Central Time
Where: join.me/600-225-471, see conference numbers in the invitation
Who:
* Rob Hirschfeld via join.me - organizer
* Rob Hirschfeld - creator
* ushnishtha at hotmail.com
* defcore-committee at lists.openstack.org

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/7c8f6e03/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2245 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/7c8f6e03/attachment.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2289 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/7c8f6e03/attachment.bin

[OpenStack-DefCore] Fwd: [OpenStack Foundation] March 2 Board of Directors Meeting

DefCore! We made great progress w/ the Board this week! Thanks
everyone for the hard work and support.

Following the strategic planning discussions, Rob Hirschfeld gave an update from the DefCore committee and presented a slate of capabilities for the Board to approve as the official ?2015.3? specification.*T**he Board approved the proposed DefCore committee process and slate of capabilities for "OpenStack Powered? products.*  This was a huge milestone for the DefCore efforts, and enables the Foundation staff to now implement the new license agreements and product testing program when the bylaws changes go into effect at the end of March. If you are responsible for an OpenStack Powered product or service within your company, we will be reaching out to help you adopt the new licensing programs. A very big thank you to Rob Hirschfeld and the DefCore committee who worked hard to make quick progress over the past couple of months.

-------- Forwarded Message --------
Subject: [OpenStack Foundation] March 2 Board of Directors Meeting
Date: Thu, 5 Mar 2015 17:10:31 -0600 (CST)
From: jonathan at openstack.org
To: foundation at lists.openstack.org

Hi everyone,

On Tuesday, the Board of Directors held a face-to-face meeting in chilly New York City. We had 19 of 24 directors in person, and three participated on the phone throughout.

The primary objective of this meeting was to engage in some strategic planning with the Board. Mark Collier kicked off the meeting by providing some context about the state of OpenStack and relevant emerging market trends. The Board members then broke into four small groups to dive into 4 areas: (1) Network Functions Virtualization / Internet of Things, (2) containers / developer productivity and tools, (3) public & hybrid clouds and (4) coordinating efforts across projects and companies within OpenStack, including the new product manager community working group. There was a lot of discussion about how we can better engage with other industry groups and open source technologies, the importance of continuing to attract developers to OpenStack, and how we can become more strategic with our contributions. The Directors spent time within their small groups and then presented their thoughts for discussion to the full Board after lunch. Coming out of the meeting the Foundation staff and Directors will turn this input into actions that can be incorporated into 2015 plans, as well as longer-term initiatives.

Following the strategic planning discussions, Rob Hirschfeld gave an update from the DefCore committee and presented a slate of capabilities for the Board to approve as the official ?2015.3? specification. The Board approved the proposed DefCore committee process and slate of capabilities for "OpenStack Powered? products. This was a huge milestone for the DefCore efforts, and enables the Foundation staff to now implement the new license agreements and product testing program when the bylaws changes go into effect at the end of March. If you are responsible for an OpenStack Powered product or service within your company, we will be reaching out to help you adopt the new licensing programs. A very big thank you to Rob Hirschfeld and the DefCore committee who worked hard to make quick progress over the past couple of months.

Finally, the Board wrapped up with an hour-long discussion about transparency and diversity. Discussion points included implementing better mailing list procedures, potential changes to the Transparency Policy and how Board Members can better engage with and support all of our global communities. Sean Roberts is picking up the Transparency Committee work, which will convene in the next few weeks to follow up on the discussion with more concrete recommendations and actions on that front. Also, Robert Esker started a thread on this list to discuss potential updates to the Transparency Policy.

After the meeting many of the participants trekked across a wet and snowy NYC to continue discussions over dinner. It was really energizing to see how far the community has come in five years and consider the opportunities for OpenStack over the next five. I appreciate the enthusiasm and engagement from the Board on all of these important topics. Thanks to everyone who participated in person and remotely!

Thanks,
Jonathan


Foundation mailing list
Foundation at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/4cec25c5/attachment-0001.html

Rocky, thanks for the google doc link.. but for other releases the json file has been merged in to a github repository (i.e. refstack). Or are we not doing that any more?
On Mar 6, 2015, at 3:34 PM, Rochelle Grober <rochelle.grober at huawei.com<mailto:rochelle.grober at huawei.com>> wrote:

Take a look at the last defcore.scale etherpad. There are links to google docs?. I think it?s:

https://docs.google.com/spreadsheet/ccc?key=0Ags6GY_6T6qqdDBFOUNfdGs1VF85NmU3WjZXeFd3bGc&usp=drive_web#gid=6 (don?t know for sure as I?m behind a proxy that won?t let me go to googledocs)

I got it from: https://etherpad.openstack.org/p/DefCoreScale.F2F

--Rocky

From: Justin Shepherd [mailto:jshepher at rackspace.com]
Sent: Friday, March 06, 2015 13:26
To: Meyer, Jim
Cc: defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] [OpenStack Foundation] March 2 Board of Directors Meeting

Does anyone happen to know where the 2015.3 json spec exists repo wise? Does not seem to be in the refstack repo.

Thanks,
Justin Shepherd
On Mar 6, 2015, at 10:33 AM, Meyer, Jim <jim.meyer at hp.com<mailto:jim.meyer at hp.com>> wrote:

That's outstanding. I'm glad to join in time to congratulate y'all on the achievement, and to help with the next one.

By chance, is anyone here headed to the operators mid cycle next Mon/Tue? Would love to meet up if possible.

--j

On Mar 6, 2015, at 7:56 AM, Rob Hirschfeld > wrote:

DefCore! We made great progress w/ the Board this week! Thanks everyone for the hard work and support.

Following the strategic planning discussions, Rob Hirschfeld gave an update from the DefCore committee and presented a slate of capabilities for the Board to approve as the official ?2015.3? specification. The Board approved the proposed DefCore committee process and slate of capabilities for "OpenStack Powered? products. This was a huge milestone for the DefCore efforts, and enables the Foundation staff to now implement the new license agreements and product testing program when the bylaws changes go into effect at the end of March. If you are responsible for an OpenStack Powered product or service within your company, we will be reaching out to help you adopt the new licensing programs. A very big thank you to Rob Hirschfeld and the DefCore committee who worked hard to make quick progress over the past couple of months.

-------- Forwarded Message --------
Subject: [OpenStack Foundation] March 2 Board of Directors Meeting
Date: Thu, 5 Mar 2015 17:10:31 -0600 (CST)
From: jonathan at openstack.org
To: foundation at lists.openstack.org

Hi everyone,

On Tuesday, the Board of Directors held a face-to-face meeting in chilly New York City. We had 19 of 24 directors in person, and three participated on the phone throughout.

The primary objective of this meeting was to engage in some strategic planning with the Board. Mark Collier kicked off the meeting by providing some context about the state of OpenStack and relevant emerging market trends. The Board members then broke into four small groups to dive into 4 areas: (1) Network Functions Virtualization / Internet of Things, (2) containers / developer productivity and tools, (3) public & hybrid clouds and (4) coordinating efforts across projects and companies within OpenStack, including the new product manager community working group. There was a lot of discussion about how we can better engage with other industry groups and open source technologies, the importance of continuing to attract developers to OpenStack, and how we can become more strategic with our contributions. The Directors spent time within their small groups and then presented their thoughts for discussion to the full Board after lunch. Coming out of the meeting the Foundation staff an
d
Directors will turn this input into actions that can be incorporated into 2015 plans, as well as longer-term initiatives.

Following the strategic planning discussions, Rob Hirschfeld gave an update from the DefCore committee and presented a slate of capabilities for the Board to approve as the official ?2015.3? specification. The Board approved the proposed DefCore committee process and slate of capabilities for "OpenStack Powered? products. This was a huge milestone for the DefCore efforts, and enables the Foundation staff to now implement the new license agreements and product testing program when the bylaws changes go into effect at the end of March. If you are responsible for an OpenStack Powered product or service within your company, we will be reaching out to help you adopt the new licensing programs. A very big thank you to Rob Hirschfeld and the DefCore committee who worked hard to make quick progress over the past couple of months.

Finally, the Board wrapped up with an hour-long discussion about transparency and diversity. Discussion points included implementing better mailing list procedures, potential changes to the Transparency Policy and how Board Members can better engage with and support all of our global communities. Sean Roberts is picking up the Transparency Committee work, which will convene in the next few weeks to follow up on the discussion with more concrete recommendations and actions on that front. Also, Robert Esker started a thread on this list to discuss potential updates to the Transparency Policy.

After the meeting many of the participants trekked across a wet and snowy NYC to continue discussions over dinner. It was really energizing to see how far the community has come in five years and consider the opportunities for OpenStack over the next five. I appreciate the enthusiasm and engagement from the Board on all of these important topics. Thanks to everyone who participated in person and remotely!

Thanks,
Jonathan


Foundation mailing list
Foundation at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] DefCore Scale.7 on 3/11 MOVED TO Friday 3/13

DefCore,

Sorry about the late change - Egle and I are not available on 3/11 and have
to move the meeting.

I'm able to host on 3/13 and moved meeting to that day (same 9am PT time).

I'm working on the agenda: https://etherpad.openstack.org/p/DefCoreScale.7
which will review the board meeting results, review process points and plan
for getting documents into the new repo.

--
Rob


Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob at rackn.com)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/68e70a72/attachment.html

[OpenStack-DefCore] Invitation: DefCore Scale.8 [hosted by Egle] @ Wed Mar 18, 2015 11am - 12pm (Rob Hirschfeld)

You have been invited to the following event.

Title: DefCore Scale.8 [hosted by Egle]
When: Wed Mar 18, 2015 11am - 12pm Central Time
Where: see https://etherpad.openstack.org/p/DefCoreScale.8
Calendar: Rob Hirschfeld
Who:
* Rob Hirschfeld - organizer
* Egle Sigler
* defcore-committee at lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=OTl0cnBsYjZkamNnbmhraGRrcDU5czk4N2sgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTZlZGRjYmE5N2Y2N2ExNGMzMmYwNzU0NDgzNDZjMWM0NDYzOTViNDQ&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/18de4580/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1258 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/18de4580/attachment.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1289 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/18de4580/attachment.bin

[OpenStack-DefCore] Invitation: DefCore Scale.10 @ Wed Apr 1, 2015 11am - 12pm (null)

You have been invited to the following event.

Title: DefCore Scale.10
You have been invited to a join.me online meeting

https://etherpad.openstack.org/p/DefCoreScale.10

Join the meeting: https://join.me/933-636-202

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 933-636-202

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 933-636-202#

Other international numbers available (https://join.me/intphone/933636202/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1427904000000/1427907600000)

When: Wed Apr 1, 2015 11am - 12pm Central Time
Where: join.me/933-636-202, see conference numbers in the invitation
Who:
* Rob Hirschfeld via join.me - organizer
* Rob Hirschfeld - creator
* ushnishtha at hotmail.com
* defcore-committee at lists.openstack.org - optional

Your attendance is optional.

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/c2fdf7cf/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2251 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/c2fdf7cf/attachment-0001.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2295 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/c2fdf7cf/attachment-0001.bin

[OpenStack-DefCore] Invitation: DefCore Scale.9 @ Wed Mar 25, 2015 11am - 12pm (null)

You have been invited to the following event.

Title: DefCore Scale.9
You have been invited to a join.me online meeting

https://etherpad.openstack.org/p/DefCoreScale.9

Join the meeting: https://join.me/480-000-531

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 480-000-531

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 480-000-531#

Other international numbers available (https://join.me/intphone/480000531/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1427299200000/1427302800000)

When: Wed Mar 25, 2015 11am - 12pm Central Time
Where: join.me/480-000-531, see conference numbers in the invitation
Who:
* Rob Hirschfeld via join.me - organizer
* Rob Hirschfeld - creator
* chris at openstack.org
* ushnishtha at hotmail.com
* defcore-committee at lists.openstack.org - optional

Your attendance is optional.

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/508bfa70/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2396 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/508bfa70/attachment.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2442 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/508bfa70/attachment.bin

[OpenStack-DefCore] Invitation: DefCore Scale.11 @ Wed Apr 8, 2015 11am - 12pm (null)

You have been invited to the following event.

Title: DefCore Scale.11
You have been invited to a join.me online meeting

https://etherpad.openstack.org/p/DefCoreScale.11

Join the meeting: https://join.me/728-036-448

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 728-036-448

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 728-036-448#

Other international numbers available (https://join.me/intphone/728036448/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1428508800000/1428512400000)

When: Wed Apr 8, 2015 11am - 12pm Central Time
Where: join.me/728-036-448, see conference numbers in the invitation
Who:
* Rob Hirschfeld via join.me - organizer
* Rob Hirschfeld - creator
* ushnishtha at hotmail.com
* defcore-committee at lists.openstack.org - optional

Your attendance is optional.

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/bfb36660/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2251 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/bfb36660/attachment-0001.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2295 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150306/bfb36660/attachment-0001.bin

[OpenStack-DefCore] Canceled Event: DefCore.7 @ Wed Mar 11, 2015 9am - 10am (Rob Hirschfeld)

This event has been canceled and removed from your calendar.

Title: DefCore.7
Join the meeting: https://join.me/600-225-471

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code:
600-225-471

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 600-225-471#

Other international numbers available https://join.me/intphone/600225471/0
When: Wed Mar 11, 2015 9am - 10am Central Time
Where: https://etherpad.openstack.org/p/DefCoreScale.7
Video call: https://plus.google.com/hangouts/_/rackn.com/defcore-rob
https://plus.google.com/hangouts/_/rackn.com/defcore-rob?hceid=cm9iQHJhY2tuLmNvbQ.gldq0g79td00n630luloqm6spo
Calendar: Rob Hirschfeld
Who:
* Rob Hirschfeld - organizer
* defcore-committee at lists.openstack.org

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee at lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150307/373d9166/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1640 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150307/373d9166/attachment-0001.ics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1677 bytes
Desc: not available
URL: http://lists.openstack.org/pipermail/defcore-committee/attachments/20150307/373d9166/attachment-0001.bin

[OpenStack-DefCore] Initial Draft of 2015.03 Guideline [Please Review]

DefCore,

I've managed to review Van's initial 2015.03 specs and post the for
broader review into our shiny new OpenStack/DefCore repo!

We're a little out of order because we have BOTH content and format to
review. Once this is approved, I'll create the next draft for review.

Here's the link for review > https://review.openstack.org/#/c/162655/

I'm including the RST here for easy review, BUT ONLY THE ONLINE ONES COUNT.

OpenStack DefCore 2015.03
=================================

Status: Approved
Replaces: 2014.07

This document outlines the mandatory and advisory capabilities
required to exist in a software installation in order to be
eligible to use marks controlled by the OpenStack Foundation.

This document supersedes the companion JSON version.

Releases Covered


Applies to Havana, Icehouse

Platform Components


Required: Compute and Object
Advisory: None
Deprecated: None
Removed: None

Compute Component Capabilities

======================== ====================
Capability Name Associated Project


compute-auth Nova
compute-flavors Nova
compute-images Nova
compute-instance-actions Nova
compute-keypairs Nova
compute-quotas Nova
compute-servers Nova
compute-volume Nova
images-v2 Glance

Advisory Capabilities


======================== ====================
Capability Name Associated Project


auth-token Keystone
compute-servers-metadata Nova
======================== ====================

Deprecated Capabilities


None.

Removed Capabilities


======================== ====================
Capability Name Associated Project


compute-floating-ips Nova
images-v1 Glance
volume Nova
======================== ====================

Object Component Capabilities

======================== ====================
Capability Name Associated Project


objectstore-object Swift
======================== ====================

Advisory Capabilities


None.

Deprecated Capabilities


None.

Removed Capabilities


None.

Designated Sections


The following designated sections apply to the same releases as
this specification.

  • Nova is by default designated except scheduler, filter, drivers, API
    extensions and networking.
  • Glance designated sections are the API implementation code and domain
    model.
  • Swift designated sections are proxy server, object server, container
    server, account server and select middleware (complete list provided by
    community in linked json document).

Advisory Designated Sections


None.

Functional Information
======================
Format: RestructuredText
Layout: 1.0

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt

Rob, I made a few cleanups: https://review.openstack.org/#/c/162655/2

?shep
On Mar 9, 2015, at 10:21 AM, Rob Hirschfeld > wrote:

DefCore,

I've managed to review Van's initial 2015.03 specs and post the for broader review into our shiny new OpenStack/DefCore repo!

We're a little out of order because we have BOTH content and format to review. Once this is approved, I'll create the next draft for review.

Here's the link for review > https://review.openstack.org/#/c/162655/

I'm including the RST here for easy review, BUT ONLY THE ONLINE ONES COUNT.

OpenStack DefCore 2015.03
=================================

Status: Approved
Replaces: 2014.07

This document outlines the mandatory and advisory capabilities
required to exist in a software installation in order to be
eligible to use marks controlled by the OpenStack Foundation.

This document supersedes the companion JSON version.

Releases Covered


Applies to Havana, Icehouse

Platform Components


Required: Compute and Object
Advisory: None
Deprecated: None
Removed: None

Compute Component Capabilities

======================== ====================
Capability Name Associated Project


compute-auth Nova
compute-flavors Nova
compute-images Nova
compute-instance-actions Nova
compute-keypairs Nova
compute-quotas Nova
compute-servers Nova
compute-volume Nova
images-v2 Glance

Advisory Capabilities


======================== ====================
Capability Name Associated Project


auth-token Keystone
compute-servers-metadata Nova
======================== ====================

Deprecated Capabilities


None.

Removed Capabilities


======================== ====================
Capability Name Associated Project


compute-floating-ips Nova
images-v1 Glance
volume Nova
======================== ====================

Object Component Capabilities

======================== ====================
Capability Name Associated Project


objectstore-object Swift
======================== ====================

Advisory Capabilities


None.

Deprecated Capabilities


None.

Removed Capabilities


None.

Designated Sections


The following designated sections apply to the same releases as
this specification.

  • Nova is by default designated except scheduler, filter, drivers, API extensions and networking.
  • Glance designated sections are the API implementation code and domain model.
  • Swift designated sections are proxy server, object server, container server, account server and select middleware (complete list provided by community in linked json document).

Advisory Designated Sections


None.

Functional Information
======================
Format: RestructuredText
Layout: 1.0

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

[OpenStack-DefCore] Capabilities meeting today

Hi everyone,

I have had a number of people email me saying that they are not able to make a meeting today. I am planning to hold the meeting at the normal time (in about 25 mins), but the meeting will probably be shortened unless there is a good group of people attending.

Thanks,
Van


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Reminder: meeting tomorrow @ 9am PT

Details on https://etherpad.openstack.org/p/DefCoreScale.7

Agenda is to review the board action from 3/3 and work on Process materials.

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Summary from 3/13 Meeting - let's have some Pi & Patches


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] no meeting today (Sunday)


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] code changes in defcore

Added a .gitreview file. This is essential for allowing others to contribute via the normal OpenStack methods:

https://review.openstack.org/164867

Updated the tests list for objectstore-object capability to include some Swift in-tree functional tests.

https://review.openstack.org/#/c/164865

--John


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] First draft of "THE PROCESS" for DefCore review

All,

https://review.openstack.org/#/c/165216/

It's finally here.... the initial Gerrit patch for the DefCore process!
This represents over 18 months of revisions and reviews with
considerable progress made during the last face to face. Special thanks
to Egle for helping get the text worked out and Sean & Chris for the
regrouping into the phases for clarification.

This document had many authors and I'm looking forward to their reviews
on the patch.

Thanks

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Re: [OpenStack-DefCore] Invitation: DefCore Scale.8 [hosted by Egle] @ Wed Mar 18, 2015 New Time: 1 pm Central/ 11 am Pacific

Hello Everyone,

I have to move this meeting, and Van has graciously agreed to combine this meeting with the capabilities meeting. Tomorrow, March 18th, we will meet for one hour at 1pm CDT (11am PDT).

Call-in information:

855.600.7225 (primary call-in)
212.231.7004 (secondary call-in)

4625040# (conference code)

https://etherpad.openstack.org/p/DefCoreScale.8

Thank you,

Egle

Date: Fri, 6 Mar 2015 15:57:39 +0000
Subject: Invitation: DefCore Scale.8 [hosted by Egle] @ Wed Mar 18, 2015 11am - 12pm (Rob Hirschfeld)
From: rob@rackn.com
To: ushnishtha@hotmail.com; defcore-committee@lists.openstack.org

more details »
DefCore Scale.8 [hosted by Egle]WhenWed Mar 18, 2015 11am – 12pm Central TimeWheresee https://etherpad.openstack.org/p/DefCoreScale.8 (map)CalendarRob HirschfeldWho•Rob Hirschfeld - organizer•Egle Sigler•defcore-committee@lists.openstack.orgGoing? Yes - Maybe - No more options »Invitation from Google Calendar
You are receiving this courtesy email at the account ushnishtha@hotmail.com because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.
_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore.8

Calendar

Egle Sigler has sent you an invitation to "DefCore.8"

Hello Everyone,

I have to move this meeting, and Van has graciously agreed to combine this meeting with the capabilities meeting. Tomorrow, March 18th, we will meet for one hour at 1pm CDT (11am PDT).

Call-in information:
855.600.7225 (primary call-in)
212.231.7004 (secondary call-in)
4625040# (conference code)

https://etherpad.openstack.org/p/DefCoreScale.8

Thank you,

Egle

When: Wednesday, March 18, 2015 1:00PM - 2:00PM
Location: https://etherpad.openstack.org/p/DefCoreScale.8
This event occurs in (UTC-06:00) Central Time (US & Canada)


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Updated Invitation: DefCore Scale.8 [hosted by Egle] @ Wed Mar 18, 2015 1am - 2am (Rob Hirschfeld)

This event has been changed.

Title: DefCore Scale.8 [hosted by Egle]
When: Wed Mar 18, 2015 1am - 2am Central Time (changed)
Where: see https://etherpad.openstack.org/p/DefCoreScale.8
Calendar: Rob Hirschfeld
Who:
* Rob Hirschfeld - organizer
* Egle Sigler
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=OTl0cnBsYjZkamNnbmhraGRrcDU5czk4N2sgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTZlZGRjYmE5N2Y2N2ExNGMzMmYwNzU0NDgzNDZjMWM0NDYzOTViNDQ&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future notifications for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Canceled Event: DefCore Scale.8 [hosted by Egle] @ Wed Mar 18, 2015 1am - 2am (Rob Hirschfeld)

This event has been canceled and removed from your calendar.

Title: DefCore Scale.8 [hosted by Egle]
When: Wed Mar 18, 2015 1am - 2am Central Time
Where: see https://etherpad.openstack.org/p/DefCoreScale.8
Calendar: Rob Hirschfeld
Who:
* Rob Hirschfeld - organizer
* Egle Sigler
* defcore-committee@lists.openstack.org

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future notifications for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore.8 meeting notes and action items for you

Hello Everyone,

We just finished our combined defcore + defcore capabilities meeting. Thanks to everyone that attended and provided feedback, notes from the meeting are bellow.

Action items for everyone interested in DefCore:
1. Review the initial draft for the process and provide feedback: https://review.openstack.org/#/c/165216
2. Tell us how many core reviewers we should have for openstack/defcore project. During the meeting, we talked about having a smaller group of core reviewers. Right now, core reviewers are myself, Rob Hirschfeld, and Chris Hoge. If you think the group should be larger, list your reasons. We do have additional volunteers for core reviewers.

Thank you,

Egle

Meeting Notes:
https://etherpad.openstack.org/p/DefCoreScale.8

Note: Today's meeting will be combined with the DefCore capabilities meeting.

AgendaFeedback on Initial draft of the DefCore Process ( https://review.openstack.org/#/c/165216 )Core reviewers for defcore: https://review.openstack.org/#/admin/groups/uuid-ad95fb605fa544dab35712194df7faaa10ec7a22,membersReminder: submit/discuss tests that should be flagged

Roll Call:Egle Sigler (Co-Chair, Rackspace)Chris Lee (DreamHost)Mark T. Voelker (VMware)Jim Meyer (HP)Carol Barrett (Intel)Will Auld (Intel)Catherine Diep (IBM)Vince Brunssen (IBM)Van Lindberg (Rackspace)Adrian Otto (Rackspace)
Notes:
Definition for designated sections missing, they are in the lexicon.rst
file. Need to iterate on the definition more before going in. [1]
Core reviewers will appoint other core reviewers. Take it to the
mailing list. Propose a small list. Chris Lee from dreamhost
volunteered. Van L is also willing. Jim and Mark also happy to be a reviewers and happy to be excluded. Vince Brunssen (IBM) would also be willing to be a core reviewer. For .03 tests, See decision below. Question about Foundation requirements, C1.3 and C2. For section C1.4, should clearly label the published self-tests as unreviewed. Rocky would like release management items in the process.
Decision on UUIDs vs Fully-Qualified names (FQNs):FQNs will be used for 2015.03The
question of FQNs vs UUIDs is re-evaluated for each spec release until
the social and technical issues with UUIDs are resolved (or UUIDs are
dropped)When UUIDs are adopted, there is a major version bump for the json spec.UUID related bug filed: https://bugs.launchpad.net/tempest/+bug/1433700
[1] Here's the snip from https://review.openstack.org/#/c/165216/3/lexicon.rst: (note: please comment in Gerrit, not here) Mark T. Voelker 18 Mar 2015 10:36a
Shamail had a good suggestion that we add a definition of designated
sections here, but I'm not sure that has been completely worked out.
Vaguely, we have something like this (pulling liberally from some of
Rob's earlier slides and modifying slightly since the integrated release
is on the way out):Designated
Sections - portions of the OpenStack codebase that must be used in
order to meet the OpenStack trademark. Designated sections fulfill one
or more of three criteria: 1) they provide the project-external REST
API; 2) are shared and provide common functionality for all options; 3)
implement logic that is critical for cross-platform operation.
Designated sections must exist in the OpenStack gerrit namespace and
have corresponding tests. Code that meets the following criteria will
not be considered designated: provides vendor-specific functionality,
are explicitly intended by the project maintainers to be replaceable,
extend the project REST API in a new or different way, or code that is
being deprecated.That's a bit wordy compared to the other definitions here, but it's a start. What do folks think?

                  _______________________________________________

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Regarding idempotent_id and test identification

There’s been a bit of discussion about how to uniquely identify
tests since the idempotent_id patch landed in Tempest. I think
it’s important to clarify what the patch accomplished, and how
we can use it within the Defcore framework to identify tests.

The idempotentids give us a way to track a function that
provides a test. Within Tempest, each function is meant to
test one kind of behavior, but it’s possible for that behavior to
be run in different modes. For example, some networking tests
run in both an IPv4 and IPv6 mode. This is accomplished by
subclassing, which will create a new test name (distinct from
the function name and expanded path*) for that test. This means
that there is not a 1:1 relationship between functions and test
names. It’s one of the reasons that the name ‘idempotent
id’
was used instead of ‘uuid’.

Now, at first glance this seems like it doesn’t help us in our goal
of tracking tests through refactoring. After a number of discussions
with members of the community about testing I don’t think that
this is necessarily the case. A unique identifier already exists for
a given test: the test name. Although it may be pedantic I
would argue that changing a test name makes it a different test,
whether or not it actually changes in behavior.

What we have is two identifiers. A stable ‘idempotent_id’ that we can
use to track functionality, and possibly unstable test names that
uniquely identify the test we want to run. When this is combined with
the date of capability approval, which can be matched to a github
hash, this gives an exact representation of the tests that need to
be run for compatibility. It even gives us a means to parse the
Tempest tree and determine the latest and earliest points in time
that the Tempest tree can be reasonably applied to a Defcore
capabilities release.

Within our process we can now track three things. The functionality
which may be refactored to new locations but is identified by
idempotentid, and the test name which may also change but
will have a stable idempotent
id associated with it, and the
Tempest git hash that tells us the point in time the capabilities
were defined in relation to the tests.

Technically I don’t think that trying to match unique identifiers to
tests is a worthwhile problem to try and solve. How do you
distinguish between a refactoring and a new test? How do you
guarantee that generated ids will actually be stable across
refactoring without being disturbed by possible new subclassing?
If feels like a big problem to solve for what we get back, and the
tools we now have in place give us much more flexibility
and power than we even had just a few weeks ago.

-Chris

  • the unittest/testtools framework calls it the test_id, which the
    expanded path of the test method to which the attrs are
    appended. It might be worthwhile to use this expanded name as
    the defcore test name to help ease automation. Right now we think
    of the test name as just the function name.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Reminder: DefCore Scale.9 on Wed 3/25 @ 9 PT

https://etherpad.openstack.org/p/DefCoreScale.9

DefCore Scale.9

2015, March 25 @ 9am PT

Agenda

  • Approve the DefCore Process Draft
    (https://review.openstack.org/#/c/162655/), Discuss Next Steps
  • Review and Prepare 2015.next for April Board Meeting
  • Plan for moving additional items into OpenStack/DefCore repo
  • Discuss UUID vs Test Names as ID

Conference Info:

Join the meeting: https://join.me/480-000-531

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code:
480-000-531

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 480-000-531#

International: https://join.me/intphone/480000531/0

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi Folks,

I realized after the meeting today that we were so involved in the discussion that we didn’t jot a lot of it down on the etherpad[1]. I’ve taken a shot at summarizing the discussion at the bottom of the pad—please feel free to augment/correct/continue the discussion over email.

The initial draft of the process doc has now been merged [2]. Please note that it is still explicitly in “draft” status[3]. We’ll take up individual points that need more discussion (such as the JSON/RST authority question) as individual gerrit reviews before the status changes to “approved”.

[1] https://etherpad.openstack.org/p/DefCoreScale.9
[2] https://review.openstack.org/#/c/165216/
[3] http://git.openstack.org/cgit/openstack/defcore/tree/process/2015A.rst#n4

At Your Service,

Mark T. Voelker
OpenStack Architect

On Mar 23, 2015, at 4:51 PM, Rob Hirschfeld rob@zehicle.com wrote:

https://etherpad.openstack.org/p/DefCoreScale.9

DefCore Scale.9

2015, March 25 @ 9am PT

Agenda

  • Approve the DefCore Process Draft (https://review.openstack.org/#/c/162655/), Discuss Next Steps
  • Review and Prepare 2015.next for April Board Meeting
  • Plan for moving additional items into OpenStack/DefCore repo
  • Discuss UUID vs Test Names as ID

Conference Info:

Join the meeting: https://urldefense.proofpoint.com/v2/url?u=https-3A__join.me_480-2D000-2D531&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=s3Cvu5Gxh9yqPMbpe78d9Cq9aH3CPAPSmsGZDFzeR28&s=KtX59dDopOPWkTGrGGFZRHwoMkfhP9JNI4aFJJEIFPA&e=
On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code: 480-000-531

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 480-000-531#

International: https://urldefense.proofpoint.com/v2/url?u=https-3A__join.me_intphone_480000531_0&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=s3Cvu5Gxh9yqPMbpe78d9Cq9aH3CPAPSmsGZDFzeR28&s=VI3E6FrWS6rq3ss3EjOgTcgNcuKk3eq8170hUGmWetY&e=
--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
https://urldefense.proofpoint.com/v2/url?u=http-3A__robhirschfeld.com&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=s3Cvu5Gxh9yqPMbpe78d9Cq9aH3CPAPSmsGZDFzeR28&s=vaAbXrRkAJAHK_PInNtZRN_b2umi9fWHWXeluWTBJZI&e= twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] How to Deal With Overlapping Capabilities

Folks,

Per discussion at today’s DefCore capabilities meeting, I’ve tentatively added an agenda item for the DefCore Scale.10 meeting next week (I’m fine with bumping it if we’ run short on time). Egle suggested that we bring this up on the ML ahead of time so folks can be prepared to discuss it and/or start the discussion here on the ML first.

One of the questions I’m hearing a lot from operators and vendors about DefCore is: how will DefCore handle situations where there are overlapping capabilities between OpenStack components? One example of this is networking: today we have no networking constructs in our capabilities lists even though some form of networking would logically be considered a fundamental part of an OpenStack cloud. This is partly because there are two models for networking in OpenStack today: nova-net and Neutron (both of which were in the integrated release for years). Both are widely enough deployed that it wouldn’t make sense for us to list one and not the other (thus restricting several long-time clouds from being able to use the trademark) but we also don’t have an “either/or” concept as of now and it wouldn’t be practical to expect clouds/products to supply both capabilities either.

With the new tagging model of governance (e.g. the “big tent”) we may increasingly see overlap in the future, so I think it’s worth taking a bit of time to think about what our strategy might look like going forward. Please see notes here for additional color…feel free to comment or we can discuss the next time we have an opening during a DefCore meeting:

https://etherpad.openstack.org/p/DefCoreScale.10

At Your Service,

Mark T. Voelker
OpenStack Architect


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

On 03/25/2015 03:54 PM, Mark Voelker wrote:
Both are widely enough deployed that it wouldn’t make sense for us to list one and not the other (thus restricting several long-time clouds from being able to use the trademark) but we also don’t have an “either/or” concept as of now and it wouldn’t be practical to expect clouds/products to supply both capabilities either.

I'd suggest that we have the Components concept for this. It's perfectly
reasonable to have the Nova-Net and Neutron as Components. Components
have distinct lists of capabilities that could overlap (e.g.: they
should all require Keystone capabilities). From that perspective, we
also do have the flexibility to define the Platform as requiring
Nova-Net or Neutron.

That type of "or" can be accommodated at the Component/Platform level
without any new language (but may need some tweaking in the JSON schema
where we define required components).


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Suggestion for Meeting with DefCore on Process

Thierry,

The first draft of the DefCore process landed today:
http://git.openstack.org/cgit/openstack/defcore/tree/process/2015A.rst

Naturally, we are using Gerrit for discussion about individual points;
however, I'd like to suggest an interactive review/Q&A meeting (with
voice/shared screen) to give the TC and DefCore a chance to discuss the
draft.

Our objective is to ratify this process at the May Board/TC join
session. Both bodies must approve as required in the revised by-laws.

I'm thinking of some time during the week of 4/6. Also, DefCore meets
weekly on Wednesday at 9 PT for process discussion and 11 PT for
capabilities review.

Thanks,

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Rob Hirschfeld wrote:
The first draft of the DefCore process landed today:
http://git.openstack.org/cgit/openstack/defcore/tree/process/2015A.rst

Naturally, we are using Gerrit for discussion about individual points;
however, I'd like to suggest an interactive review/Q&A meeting (with
voice/shared screen) to give the TC and DefCore a chance to discuss the
draft.

We can definitely dedicate some meeting time to discuss the process. It
would be good to circulate the process before, and clarify some of the
terminology for those of us that are not familiar with it ("guidelines",
"designated sections"...)

Our objective is to ratify this process at the May Board/TC join
session. Both bodies must approve as required in the revised by-laws.

The revised by-laws are still not on the website, but if I remember
correctly the new wording, the Technical Committee and the Board of
Directors just need to agree on the procedure for changing the contents
of the "OpenStack TC Approved Release", in particular changes that would
remove software that is used in Trademark Designated OpenStack Software.
I don't remember we have to formally approve the Defcore process itself ?

So imho most of the work is for the TC to define the tc-approved-release
tag(s), and propose tag deprecation rules (rules to apply for when the
tag is removed) that are acceptable to Defcore and the BoD, so as to not
adversely affect the trademark programs.

To come back to the Defcore process, as I mentioned to you earlier it is
still unclear where the "TC-approved release" (that the bylaws mandate
the TC defines) is used in the Defcore process. Is it at the D3.2 level
? If yes, I would suggest you reuse the bylaws terminology there to
avoid confusion...

I'm thinking of some time during the week of 4/6. Also, DefCore meets
weekly on Wednesday at 9 PT for process discussion and 11 PT for
capabilities review.

We could schedule it for the April 7th TC meeting.
Regards,

--
Thierry Carrez (ttx)


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] First Flagged Tests > please review

DefCore,

We have a patch to flag tests due to a tempest bug. Since this is our
FIRST flagged test review, I'd like people to check it out so that we're
comfortable with the process before it goes in.

See https://review.openstack.org/#/c/167450/

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Canceled: DefCore capabilities

This one capabilities meeting has been extended to try to score as many capabilities as possible.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore capabilities

This one capabilities meeting has been extended to try to score as many capabilities as possible.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Reminder: DefCore Scale.10 Tomorrow (Wed) @ 9 PT

https://etherpad.openstack.org/p/DefCoreScale.10
https://www.google.com/url?q=https%3A%2F%2Fetherpad.openstack.org%2Fp%2FDefCoreScale.10&ust=1427832740623000&usg=AFQjCNFGNw0SHUSF6FEtkiHKJFt0-Yakcg

DefCore Scale.10

2015, April 1 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.9
Following: https://etherpad.openstack.org/p/DefCoreScale.11

Call in Information: TBD

Summary: TBD

Agenda

  • Review and Prepare 2015.next for April Board Meeting

  • Plan for moving additional items into OpenStack/DefCore repo
  • DefCore & TC Interlock
  • Discuss UUID vs Test Names as ID
  • Initial discussion about API additions?
  • http://lists.openstack.org/pipermail/openstack-dev/2015-March/059765.html
  • "What I'm suggesting is that Defcore should not just specify which API
    features need to be supported, but also specify that nonstandard API
    features must not be added to the APIs its covering." --Jeremy Stanley
  • What to do about overlapping capabilities (see below)

Roll Call


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

sorry, forgot the call in details:

Call in Information:

 https://etherpad.openstack.org/p/DefCoreScale.10

Join the meeting: https://join.me/933-636-202

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code:
933-636-202

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 933-636-202#

On 03/31/2015 11:13 AM, Rob Hirschfeld wrote:
https://etherpad.openstack.org/p/DefCoreScale.10
https://www.google.com/url?q=https%3A%2F%2Fetherpad.openstack.org%2Fp%2FDefCoreScale.10&ust=1427832740623000&usg=AFQjCNFGNw0SHUSF6FEtkiHKJFt0-Yakcg

DefCore Scale.10

2015, April 1 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.9
Following: https://etherpad.openstack.org/p/DefCoreScale.11

Call in Information: TBD

Summary: TBD

Agenda

  • Review and Prepare 2015.next for April Board Meeting

  • Plan for moving additional items into OpenStack/DefCore repo
  • DefCore & TC Interlock
  • Discuss UUID vs Test Names as ID
  • Initial discussion about API additions?

  • http://lists.openstack.org/pipermail/openstack-dev/2015-March/059765.html
  • "What I'm suggesting is that Defcore should not just specify which
    API features need to be supported, but also specify that nonstandard
    API features must not be added to the APIs its covering." --Jeremy Stanley
  • What to do about overlapping capabilities (see below)

Roll Call


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Scale.10 Notes

Following: https://etherpad.openstack.org/p/DefCoreScale.10

Summary:

  • Great discussions about numerous topics - will show up on ML and as
    patches, so watch Gerrit!
  • Scheduled single topic meeting to reviiew process on Tuesday 4/7 @ 9
    PT > https://etherpad.openstack.org/p/DefCoreScale.10B
  • Recommending 2015.next with addition of Juno to BoD for 4/2 approval
  • Agreed to make some changes to the JSON Schema for 2015.next after 4/2.

Agenda

Roll Call

Mark T. Voelker (VMware)
Vince Brunssen (IBM)
Carol Barrett (Intel)
Rob HIrschfeld (Co-Chair, RackN)
Will Auld (Intel)
Chris Hoge (OpenStack Foundation)
Egle Sigler (Co-Chair, Rackspace)
Van Lindberg (Rackspace)
Kevin Carter (Rackspace)
Jim Meyer (HP) (thanks!)
Mark Atwood (HP)

What to do about overlapping capabilities
=================================
* We’ve generally shied away from “picking winners” where there is
overlapping functionality between two OpenStack components by simply not
including either one in our capabilities lists.
* Example: today there are two major networking models in
OpenStack—Neutron and nova-net. Neither is included in DefCore
capabilities in spite of the fact that you need networking to run a
cloud and both have been present since pretty early days of OpenStack.
There is some consensus that nova-net will likely eventually be
deprecated and replaced by Neutron, though this has been postponed more
than once. However in the meantime:
* We can’t add Neutron capabilities as this would disqualify the
not-small number of clouds running nova-net (e.g. it is “widely deployed”).
* We can’t add nova-net capabilities as this would disqualify the
not-small number of clouds running Neutron (e.g. it is also “widely
deployed”).
* We can’t say “you must provide either nova-net capability or
Neutron capability” because we have no concept of “either/or” in DefCore
today.
* We can’t include both because the two are essentially mutually
exclusive in an operating cloud.
* This situation may occur more often in the future with the
tagging initiative taken up by the TC recently which seeks in part to
have a “bigger tent” of projects in OpenStack. Indeed, several
contributors expressed “internal competition” as a motivator for the new
model.
* As a strawman: it is not unreasonable to think that
Ceilometer, Monasca, and/or StackTach might one day all be in the
OpenStack namespace and provide some overlapping functionality. It is
also not unreasonable to think that multiple of these might become
fairly widely deployed, much like Neutron/nova-net today.
* How should DefCore address these scenarios?
* Do we want to always force ourselves to choose one project’s
capabilities over the others?
* If so: are we choosing Neutron or nova-net? =)
* Do we include none of the overlapping components in DefCore
until there’s a clear winner in terms of user acceptance?
* Basically what we do today.
* Neutron has been in the integrated release (or “core” as
it was then known) since Folsom but we apparently still don’t have a
winner after nearly 3 years…is it really ok not to have networking
capabilities as part of DefCore? This seems to expose us to a situation
where a cloud/vendor/etc might use something completely non-OpenStack to
provide networking capability and still be able to call itself an
"OpenStack Powered Platform".
* Do we want to consider having a “must provide capability x OR
capability y” construct?
* Is this too slippery a slope?
* This would also entail having an "either/or" construct
for designated sections
* Do we have a required capability that can be achieved by
either of two projects and describe just the tests in an either/or
construct?
* Example: “create and attach an IP address to an instance
for outside-world connectivity” is something that both nova-net and
Neutron can do, but each has it’s own tests for this.
* This would also entail having an "either/or" construct
for designated sections
* Other option?
* v2/v3 for Keystone. What tests to choose? Need an -or- condition?
* if targetting >= kilo I say v3. (currently defcore applies to two
latest releses, so overlap will happen Juno/Kilo) maybe we use a
small(er) sub-set of tests and target only v3 for both Juno/Kilo. (v3 is
deployed everywhere unless disabled in api-paste.ini).
ML Thread:
http://lists.openstack.org/pipermail/defcore-committee/2015-March/000665.html
Suggestions about how this might look in practice in our artifacts
(some unanswered questions there yet):
http://lists.openstack.org/pipermail/defcore-committee/2015-March/000671.html

Community Review of Process

  • Do we need a DefCore interactive review?+1+1+1+1+1+1

    • Tenative - Tuesday April 7 11am-1pm CDT San Antonio, TX
      People who can join in person:
      Egle Sigler
      Rob Hirschfeld
      Vince Brunssen
      People who can call in:
      Chris Hoge
      Jim Meyer (2nd hour)
      Carol Barrett
      Will Auld (2nd hour)
      Agenda
      Review Process Doc
      Figure out plan to move docs into DefCore repo
  • TC interactive review? +1
  • Community "open review" meeting April 13th ish+1 +0 (will be in China
    that week)

Current Defcore Code Review Links

https://review.openstack.org/#/c/169799/
https://review.openstack.org/#/c/169655/
https://review.openstack.org/#/c/169021/
https://review.openstack.org/#/c/167450/
https://review.openstack.org/#/c/169833/

ACTION > Rob will recommend 2015.next for approval on 4/2 BoD meeting

Changes JSON format (to become v1.2)

ACTION > Pulls for Flagged Test Reason
https://review.openstack.org/#/c/169833/ < Catherine's previously-merged
patch for 2015.03 applied to 2015.next
DISCUSSION > Pulls for to make it Version ++
Moving this to a DefCore Process discussion
Chris to do a pull request for discussion
ACTION > Pulls to include Designated Section

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

We are going over the next set of capabilities, and this is 1.5 hour meeting.
Join us if you can!1-855-600-7225, code 4625040 https://docs.google.com/spreadsheet/ccc?key=0Ags6GY_6T6qqdDBFOUNfdGs1VF85NmU3WjZXeFd3bGc#gid=9https://etherpad.openstack.org/p/defcore-capabilities-apr-01-2015
Thank you,
Egle _______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Interactive Review

Hello Everyone,

Today during our DefCore meeting we agreed to hold a separate meeting for doing interactive review of the DefCore process. Etherpad for the meeting: https://etherpad.openstack.org/p/DefCoreScale.10B

If you can join us in person in San Antonio, please let me know so that we can plan accordingly.

For remote participants, we will send out a google hangout link on the day of the meeting.

Thank you,

Egle Sigler


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Defcore Moving to Implementation!

Good people of defcore,

I’m excited to announce that all of your hard work is paying off, and we at the Foundation are now operationally executing on the new requirements approved by the board as 2015.03 ! What does this mean?

1) We are communicating the new, board approved requirements on this page: openstack.org/interop http://openstack.org/interop (right now it’s a just hand curated text in a table, but in the near future we’ll pull the capabilities and designated sections programmatically from the json, the single source of truth).

2) Going forward, all new licensees of the “OpenStack Powered” program will be required to meet these specs, including tests which we (chris hoge specifically) will be validating.

3) At this time, we are encouraging, though not requiring, existing licensees for existing OpenStack Powered products in the marketplace (openstack.org/marketplace http://openstack.org/marketplace) to run the tests and re-sign the agreements. This is something we aren’t going to rush into, the primary focus is on new products, which we expect to see many of as we approach the Vancouver summit. We would like to get all of the public clouds validated under the new model as quickly as possible, though, since those tend to be more continuously delivered, and are a key target for developers.

We started communicating these changes to relevant companies via an open marketing meeting yesterday. The recording, slides, and relevant pages are below:

Thanks again for everyone’s hard work! We are finally able to put it to good use.

Mark_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Fantastic news! Thank you for the details and update.

I'm looking forward to celebrating the first vendors to complete the
process!

On Thu, Apr 2, 2015 at 10:23 AM, Mark Collier mark@openstack.org wrote:

Good people of defcore,

I’m excited to announce that all of your hard work is paying off, and we
at the Foundation are now operationally executing on the new requirements
approved by the board as 2015.03 ! What does this mean?

1) We are communicating the new, board approved requirements on this page:
openstack.org/interop (right now it’s a just hand curated text in a
table, but in the near future we’ll pull the capabilities and designated
sections programmatically from the json, the single source of truth).

2) Going forward, all new licensees of the “OpenStack Powered” program
will be required to meet these specs, including tests which we (chris hoge
specifically) will be validating.

3) At this time, we are encouraging, though not requiring, existing
licensees for existing OpenStack Powered products in the marketplace (
openstack.org/marketplace) to run the tests and re-sign the agreements.
This is something we aren’t going to rush into, the primary focus is on new
products, which we expect to see many of as we approach the Vancouver
summit. We would like to get all of the public clouds validated under the
new model as quickly as possible, though, since those tend to be more
continuously delivered, and are a key target for developers.

We started communicating these changes to relevant companies via an open
marketing meeting yesterday. The recording, slides, and relevant pages are
below:

Thanks again for everyone’s hard work! We are finally able to put it to
good use.

Mark


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--
Rob


Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@rackn.com)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Board approved 2015.04 !

All,

Patch: https://review.openstack.org/#/c/170276/

we're ready to take patches against 2015.next for designated sections
and flag reasons.

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Review in SATX @ Tue Apr 7, 2015 11am - 1pm (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Review in SATX
When: Tue Apr 7, 2015 11am - 1pm Central Time
Video call: https://plus.google.com/hangouts/_/rackn.com/defcore
https://plus.google.com/hangouts/_/rackn.com/defcore?hceid=cm9iQHJhY2tuLmNvbQ.pqi0bmnvnnfamiaad303lpor8c
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=cHFpMGJtbnZubmZhbWlhYWQzMDNscG9yOGMgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTBkYjY2N2FmNWZhMzJmY2I4ODhhYjk5ZDI0MWE4ZjY3MjZhYjcyYTk&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Join us if you can:
https://plus.google.com/hangouts/_/rackn.com/defcore
1-716-293-5988 #36753

https://etherpad.openstack.org/p/DefCoreScale.10B

Date: Mon, 6 Apr 2015 23:23:04 +0000
From: rob@rackn.com
To: defcore-committee@lists.openstack.org
Subject: [OpenStack-DefCore] Invitation: DefCore Review in SATX @ Tue Apr 7, 2015 11am - 1pm (rob@rackn.com)

more details »
DefCore Review in SATXWhenTue Apr 7, 2015 11am – 1pm Central TimeVideo callhttps://plus.google.com/hangouts/_/rackn.com/defcoreCalendarrob@rackn.comWho•Rob Hirschfeld - organizer•defcore-committee@lists.openstack.orgGoing? Yes - Maybe - No more options »Invitation from Google Calendar
You are receiving this courtesy email at the account defcore-committee@lists.openstack.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee _______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Patches for Designated Sections & Missing Info

All,

I submitted 2 patches today that spanned all three of the guidelines.

1) Add Designated Sections - https://review.openstack.org/#/c/170973/
2) Add project information to capabilities (needed for the EST) -
https://review.openstack.org/#/c/170966/

Reviews welcome. We will likely try to get them merged before
Wednesday's DefCore meeting (if not sooner)

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Scale.10B Consensus Items Posted for Review

Folks,

At today’s extended DefCore Scale.10B meeting we spent most of our time iterating through the process doc (still in draft) to make improvements. Items that were subject of some debate will be discussed in individual patch sets, but there were a number of small fixes/clarifications/modifications that had wide consensus from those present. In the interest of saving some time, we decided to propose these non-controversial items as a single patch. I’ve posted those changes here:

https://review.openstack.org/#/c/171335/

After I got that one posted, discussion with Chris on flagged tests got me looking at the lexicon document and I realized it has a missing line break that made two definitions appear as one…I’ve also posted a trivial patch for that here:

https://review.openstack.org/#/c/171338/

At Your Service,

Mark T. Voelker
OpenStack Architect
+1 (970) 203-4974


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Thank you Mark for submitting the changes!
We had a great meeting today with lots of discussion, thanks everyone for your time and input. Please review Mark's changes, if there are no additional feedback on them, we will merge them tomorrow after our regularly scheduled meeting at 9 AM PST/ 11 AM CST.
Thank you,
Egle

From: mvoelker@vmware.com
To: defcore-committee@lists.openstack.org
Date: Tue, 7 Apr 2015 19:27:20 +0000
Subject: [OpenStack-DefCore] Scale.10B Consensus Items Posted for Review

Folks,

At today’s extended DefCore Scale.10B meeting we spent most of our time iterating through the process doc (still in draft) to make improvements. Items that were subject of some debate will be discussed in individual patch sets, but there were a number of small fixes/clarifications/modifications that had wide consensus from those present. In the interest of saving some time, we decided to propose these non-controversial items as a single patch. I’ve posted those changes here:

https://review.openstack.org/#/c/171335/

After I got that one posted, discussion with Chris on flagged tests got me looking at the lexicon document and I realized it has a missing line break that made two definitions appear as one…I’ve also posted a trivial patch for that here:

https://review.openstack.org/#/c/171338/

At Your Service,

Mark T. Voelker
OpenStack Architect
+1 (970) 203-4974


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] RST generator from JSON

All,

Please try to use the RST generator in
https://review.openstack.org/#/c/171463/

To use the utility, simply to 'tools/jsonToRst.py 2015.04.json'

The output does NOT include the designated sections (those are not in
the official JSON yet).

If this looks good, I'd like to be able to switch to using the generator
ASAP for consistency.

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Meeting - Scale.11 Summary

https://etherpad.openstack.org/p/DefCoreScale.11

Next meeting 4/15 @ 9 PT.

Summary

DefCore Scale.11

2015, April 8 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.10
Special Meeting: https://etherpad.openstack.org/p/DefCoreScale.10B
Following: https://etherpad.openstack.org/p/DefCoreScale.12
DefCore Patches:
https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Roll Call

  • Rob HIrschfeld - CoChair, RackN
  • Egle Sigler CoChair, Rackspace
  • Sam Danes (Rackspace)
  • Mark T. Voelker (VMware)
  • Chris Hoge (OpenStack Foundation)
  • Vince Brunssen (IBM)
  • Carol Barrett (Intel)
  • Rochelle Grober (huawei)
  • Catherine Diep (IBM)

Agenda

DefCore Artifacts

https://github.com/stackforge/refstack/tree/master/defcore
https://wiki.openstack.org/wiki/Governance/DefCoreCommittee

Moving board approved materials from Wiki to Gerrit

Question> should we move the wiki materials over?
ANSWER
Keep the Wiki but move the static content to Gerrit
Wiki has project overview
Question> board approved items or everything?
ANSWER> Board approved & committee list & duplicated information
Question> who would do it? does it need to be before Vancouver?
ANSWER - Chris (Important Artifacts 5-7) & Mark (Important Artifacts
1-4) will move item from "artifacts list"
ACTION remove DefCore items from Refstack.

Patches List

https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Discussion of schema change

https://review.openstack.org/#/c/171427
Deadline for next week - discuss on patch

Community Meeting

How to cover all the material??

Who is the audience? It's the people who have questions about the
objectives of DefCore

Objective > why should you read this doc?

Agenda:
* Background on DefCore - very short 10 minutes
* short description
* why board process- where community
*
* Interop AND Trademark - why it's both - 5 minutes
* Vendors AND Community - balancing the needs - 5 minutes
* Mechanics
* testing & capabilities - 5 minutes
* self testing & certification - 5 minutes
* platform & components & trademark - 5 minutes
* Quick overview of the the Process (to help w/ reviewers) - 15 minutes
* How to get involved (Gerrit) - 5 minutes

ACTION > Create google presentation that's open to DefCore for review
9 or 10 slides

SOCIALIZE > Tuesday 4/21 8am & 8pm presentations.
Join.me for audio
OpenStack General List, Dev, Foundation, Prod Group, Marketing,
operators, users

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Strawperson draft of A3 Designated Sections in 2015A

All,

I took a pass at the details for the missing section: please review
https://review.openstack.org/#/c/170973/

To review convenience, here's what I added:

A3. PTLs Recommend Changes to Designated Sections

  1. Designated Sections will not be removed without being deprecated
    in the
    previous Guideline.
  2. Designated Sections will not be added without being advisory in the
    previous Guideline.
  3. DefCore coordinates with technical leadership to define advisory
    sections
    for projects that have advisory or required capabilities.
  4. Designated Sections may be sufficiently defined for Guidelines using
    general descriptions that outline the intent of the technical
    leadership.
  5. DefCore will present A3.4 descriptions to the Board for approval.
  6. Technical leadership may, but is not required, to provide more
    specific
    details describing the Designated Sections for a project.
  7. Designated sections will be included in the JSON Guideline.

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Rob,

I took a pass at the details for the missing section: please review https://review.openstack.org/#/c/170973/

I think you meant:

https://review.openstack.org/#/c/172182/

=)

At Your Service,

Mark T. Voelker
OpenStack Architect

On Apr 9, 2015, at 3:40 PM, Rob Hirschfeld rob@zehicle.com wrote:

All,

I took a pass at the details for the missing section: please review https://review.openstack.org/#/c/170973/

To review convenience, here's what I added:

A3. PTLs Recommend Changes to Designated Sections

  1. Designated Sections will not be removed without being deprecated in the
    previous Guideline.
  2. Designated Sections will not be added without being advisory in the
    previous Guideline.
  3. DefCore coordinates with technical leadership to define advisory sections
    for projects that have advisory or required capabilities.
  4. Designated Sections may be sufficiently defined for Guidelines using
    general descriptions that outline the intent of the technical leadership.
  5. DefCore will present A3.4 descriptions to the Board for approval.
  6. Technical leadership may, but is not required, to provide more specific
    details describing the Designated Sections for a project.
  7. Designated sections will be included in the JSON Guideline.

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
https://urldefense.proofpoint.com/v2/url?u=http-3A__robhirschfeld.com&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=setvtV1wmxQrgoBO-_qk2E9JzHnWq248pOR1_kngctQ&s=yU69x_PUdIpaSi_8H-BKG1yPc7g0DLPF2Xmth2uKbI4&e= twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Artifact Migration: Formatting Questions

Hello DefCore,

At this week’s Scale.11 meeting, we decided to move some existing artifacts out of the wiki and into Gerrit in order to ensure better control over changes [1]. I volunteered to migrate a few of the items and have begun working on doing so. One item we didn’t decide on during the meeting was how to format these artifacts when migrating them into source control. Since we’ve used RST for most of our other human-readable documents, I took the liberty of re-writing the first artifact in RST so we can see if that’s the format we want to go forward with for these. I’ve submitted it as a patch this afternoon [2] for folks to have a look at. I’m generally of the opinion that RST works fine for these documents, but would like to hear from others. As noted in the commit message, there are a couple of trivial rendering changes involved, but the content is the same.

I know that some folks also prefer to read RST documents in rendered form via our mirror on GitHub, so I’ve also posted the patch to my GitHub account [3] for those who’d like to see how GitHub renders it. There’s one additional change that’s noticeable when viewing the GitHub rendering of the RST. The original document has an enumerated list of principles, and each principle in the list has several sub-items. In the original wiki, both the top-level and sub-level items are enumerated using digits (and I’ve retained that formatting). However, GitHub’s rendering engine displays the sub-level items as lowercase roman numerals. Otherwise, the rendering looks pretty close to what’s in the wiki.

Please have a look at the review [2] and let me know what you think…if we can reach consensus on the formatting quickly, I’ll push the remainder of the items on my plate shortly.

[1] https://etherpad.openstack.org/p/DefCoreScale.11
[2] https://review.openstack.org/172186
[3] https://github.com/markvoelker/defcore/blob/migrate_artifacts/coredefintion/CoreDefinition.rst

At Your Service,

Mark T. Voelker
OpenStack Architect


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Thank you Mark for starting the migration! I think RST is good, unless someone has a valid reason why it should be in a different format.
Thank you,
Egle

From: mvoelker@vmware.com
To: defcore-committee@lists.openstack.org
Date: Thu, 9 Apr 2015 19:52:21 +0000
Subject: [OpenStack-DefCore] Artifact Migration: Formatting Questions

Hello DefCore,

At this week’s Scale.11 meeting, we decided to move some existing artifacts out of the wiki and into Gerrit in order to ensure better control over changes [1]. I volunteered to migrate a few of the items and have begun working on doing so. One item we didn’t decide on during the meeting was how to format these artifacts when migrating them into source control. Since we’ve used RST for most of our other human-readable documents, I took the liberty of re-writing the first artifact in RST so we can see if that’s the format we want to go forward with for these. I’ve submitted it as a patch this afternoon [2] for folks to have a look at. I’m generally of the opinion that RST works fine for these documents, but would like to hear from others. As noted in the commit message, there are a couple of trivial rendering changes involved, but the content is the same.

I know that some folks also prefer to read RST documents in rendered form via our mirror on GitHub, so I’ve also posted the patch to my GitHub account [3] for those who’d like to see how GitHub renders it. There’s one additional change that’s noticeable when viewing the GitHub rendering of the RST. The original document has an enumerated list of principles, and each principle in the list has several sub-items. In the original wiki, both the top-level and sub-level items are enumerated using digits (and I’ve retained that formatting). However, GitHub’s rendering engine displays the sub-level items as lowercase roman numerals. Otherwise, the rendering looks pretty close to what’s in the wiki.

Please have a look at the review [2] and let me know what you think…if we can reach consensus on the formatting quickly, I’ll push the remainder of the items on my plate shortly.

[1] https://etherpad.openstack.org/p/DefCoreScale.11
[2] https://review.openstack.org/172186
[3] https://github.com/markvoelker/defcore/blob/migrate_artifacts/coredefintion/CoreDefinition.rst

At Your Service,

Mark T. Voelker
OpenStack Architect


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Change from RST to JSON as source of truth

All,

Last night we accepted a simple DefCore RST generator script that allows
us to create the RST files from the JSON files.

As discussed, we want to have the JSON file be the "source of truth."
In keeping with that objective, I've used the generator to recreate the
RST files and replace the hand generated ones.

Since 2015.next is not complete, I removed it's RST file.

Here's the patch for review: https://review.openstack.org/#/c/172577/

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Scale.12 @ Wed Apr 15, 2015 11am - 12pm (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Scale.12
https://etherpad.openstack.org/p/DefCoreScale.12

Join the meeting: https://join.me/103-793-981

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 103-793-981

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
United States - San Francisco, CA +1.415.655.0381
Access Code 103-793-981#

Other international numbers available (https://join.me/intphone/103793981/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1429113600000/1429117200000)

When: Wed Apr 15, 2015 11am - 12pm Central Time
Where: https://etherpad.openstack.org/p/DefCoreScale.12
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* ushnishtha@hotmail.com
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=a2g2YWFzMWtpbXFpaG1wMDdkNDE0aTNsNDQgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTYzMTljMmVjZDMwNzM5NzgwYzRmNTIwNmE0YTY4NTg2YjMzODUzOGM&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Scale Meeting 12 - wiki down, here's the call in info

Join the meeting: https://join.me/103-793-981

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 103-793-981

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
United States - San Francisco, CA +1.415.655.0381
Access Code 103-793-981#

Other international numbers available
(https://join.me/intphone/103793981/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1429113600000/1429117200000)

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Work Session on Preso @ Fri Apr 17, 2015 9am - 10am (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Work Session on Preso
working on
https://docs.google.com/presentation/d/1QG765Hq37hPAmBkJlFHWyn2vXG_jaVu6iKTtrzIvlME/edit

You have been invited to a join.me online meeting

Join the meeting: https://join.me/641-284-583

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 641-284-583

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - San Francisco, CA +1.415.655.0381
Access Code 641-284-583#

Other international numbers available (https://join.me/intphone/641284583/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1429279200000/1429282800000)

When: Fri Apr 17, 2015 9am - 10am Central Time
Where: https://join.me/641-284-583, +1.415.655.0381 Access Code:
641-284-583#
Video call: https://plus.google.com/hangouts/_/rackn.com/defcore-rob
https://plus.google.com/hangouts/_/rackn.com/defcore-rob?hceid=cm9iQHJhY2tuLmNvbQ.79e4h9u30p9g92h1nridlm9j7g
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NzllNGg5dTMwcDlnOTJoMW5yaWRsbTlqN2cgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWQ2NWE5OTVhNTNkN2IxMmM2ZDU2MDU0Nzg5MDViMjM0NDVkZmMwMzY&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Community Review #1/2 @ Tue Apr 21, 2015 8am - 9am (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Community Review #1/2
You have been invited to a join.me online meeting

Join the meeting: https://join.me/874-029-687

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 874-029-687

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
United States - San Francisco, CA +1.415.655.0381
Access Code 874-029-687#

Other international numbers available (https://join.me/intphone/874029687/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1429621200000/1429624800000)

When: Tue Apr 21, 2015 8am - 9am Central Time
Where: https://join.me/874-029-687, see conference numbers in the invitation
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=MHZsaThvbjdrazYzc3BxaDYzMmt2bGw4c2cgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWE5YjQ1MDdjODBmM2QwZTg5OWYyNWJlYmNlZjc1ZDY5NGQwZWNlMjg&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore 12 notes & Friday 9am PT working session (details in notes) & Community Sessions 4/21

DefCore Scale.12

**** WE NEED HELP ADVERTISING THE DEFCORE COMMUNITY SESSIONS ****

Send people to https://etherpad.openstack.org/p/DefCoreScale.Community

Summary

  • We reviewed the status of the 2015A Process and felt that we're on
    track for Board approval in Vancouver
  • We are holding community meetings on 4/21 at 8 & 8 (working on
    presentation 4/17 @ 9 PT)
  • We are discussing processes to make sure that we can manage & track
    tests in a consistent way
  • We are working on an update to the 2015.next schema that reflects
    these discussions

2015, April 15 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.11
Following: https://etherpad.openstack.org/p/DefCoreScale.13

Roll Call

 Chris Hoge (OpenStack Foundation)

 Van Lindberg (Rackpace)

 Alan Clark (SUSE)

 Rocky Grober (Huawei)

 Vince Brunssen (IBM)

 Catherine Diep (IBM)

 Egle Sigler (Co-Chair, Rackspace)

 Rob HIrschfeld (Cochair, RackN)

Agenda

 TC meeting feedback

 DefCore presentation decks

 2015.next update

 Identity tests for 2015.05 https://review.openstack.org/#/c/169655/

 Update to JSON Schema https://review.openstack.org/#/c/171427/

 Add RST validator to repository (tox test) 

https://review.openstack.org/#/c/172497/

 Which issues to defer until after Vancover

TC review

  • Some process questions around testing
  • Largely positive feedback

Defcore Presentation Decks

https://docs.google.com/presentation/d/1QG765Hq37hPAmBkJlFHWyn2vXG_jaVu6iKTtrzIvlME/edit
Friday April 17 9 AM PDT Work Session https://join.me/641-284-583

Tuesday April 21 8 AM CDT
Tuesday April 21 8 PM CDT

See https://etherpad.openstack.org/p/DefCoreScale.Community

2015.next update

Items from previous meeting

 Reassociation of tests with capabilities

 What to do about test and capability drift

 Identify source upstream

 Use upstream tag, other SHA

 2015.next identifying upstream repository by commit SHA

 Moving tests into appropriate capabilities, deleting capabilities 

without tests

 More granularity to add tests over time

 Match tests to capabilities

 Test exists for at least one cycle of standard

 Not necessary to be advisory, but needs to have some existence.

 Adding tests needs to happen through Gerrit.

Spent 20 minutes talking about Guideline Schema changes

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Updated Invitation: DefCore Work Session on Preso @ Fri Apr 17, 2015 11am - 12pm (rob@rackn.com)

This event has been changed.

Title: DefCore Work Session on Preso
working on
https://docs.google.com/presentation/d/1QG765Hq37hPAmBkJlFHWyn2vXG_jaVu6iKTtrzIvlME/edit

You have been invited to a join.me online meeting

Join the meeting: https://join.me/641-284-583

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 641-284-583

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - San Francisco, CA +1.415.655.0381
Access Code 641-284-583#

Other international numbers available (https://join.me/intphone/641284583/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1429279200000/1429282800000)

When: Fri Apr 17, 2015 11am - 12pm Central Time (changed)
Where: https://join.me/641-284-583, +1.415.655.0381 Access Code:
641-284-583#
Video call: https://plus.google.com/hangouts/_/rackn.com/defcore-rob
https://plus.google.com/hangouts/_/rackn.com/defcore-rob?hceid=cm9iQHJhY2tuLmNvbQ.79e4h9u30p9g92h1nridlm9j7g
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NzllNGg5dTMwcDlnOTJoMW5yaWRsbTlqN2cgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWQ2NWE5OTVhNTNkN2IxMmM2ZDU2MDU0Nzg5MDViMjM0NDVkZmMwMzY&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi Everyone,
Call in: +1.415.655.0381 Access Code: 641-284-583#JoinMe screen share: https://join.me/101-717-995
We are using Etherpad from Wednesday's meeting: https://etherpad.openstack.org/p/DefCoreScale.12Google doc: https://docs.google.com/presentation/d/1QG765Hq37hPAmBkJlFHWyn2vXG_jaVu6iKTtrzIvlME/edit
Thank you!
Egle

Date: Fri, 17 Apr 2015 02:29:22 +0000
From: rob@rackn.com
To: defcore-committee@lists.openstack.org
Subject: [OpenStack-DefCore] Updated Invitation: DefCore Work Session on Preso @ Fri Apr 17, 2015 11am - 12pm (rob@rackn.com)

This event has been changed. more details »
DefCore Work Session on Presoworking on https://docs.google.com/presentation/d/1QG765Hq37hPAmBkJlFHWyn2vXG_jaVu6iKTtrzIvlME/editYou have been invited to a join.me online meeting

Join the meeting: https://join.me/641-284-583

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 641-284-583

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - San Francisco, CA +1.415.655.0381
Access Code 641-284-583#

Other international numbers available (https://join.me/intphone/641284583/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required.

Start time by time zones (https://join.me/timezone/1429279200000/1429282800000)

WhenChanged: Fri Apr 17, 2015 11am – 12pm Central TimeWherehttps://join.me/641-284-583, +1.415.655.0381 Access Code: 641-284-583# (map)Video callhttps://plus.google.com/hangouts/_/rackn.com/defcore-robCalendarrob@rackn.comWho•Rob Hirschfeld - organizer•defcore-committee@lists.openstack.orgGoing? Yes - Maybe - No more options »Invitation from Google Calendar
You are receiving this courtesy email at the account defcore-committee@lists.openstack.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee _______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Scale 13 @ Wed Apr 29, 2015 11am - 12pm (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Scale 13
Etherpad: https://etherpad.openstack.org/p/DefCoreScale.13

Jou have been invited to a join.me online meeting

Join the meeting: https://join.me/557-199-373

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 557-199-373

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
United States - San Francisco, CA +1.415.655.0381
Access Code 557-199-373#

Other international numbers available (https://join.me/intphone/557199373/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1430341200000/1430344800000)

When: Wed Apr 29, 2015 11am - 12pm Central Time
Where:
https://etherpad.openstack.org/p/DefCoreScale.13https://join.me/557-199-373,
see conference numbers in the invitation
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* ushnishtha@hotmail.com
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=ZzU2YjFzcTVldGlmMDA4cGNkMGU5aXFrNm8gZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWQ3MWUyNzBlMTY4NzU2YTQ2NmUyOTA2NWZjM2Y1ZjhkMDBjNGE0Nzk&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Updated Invitation: DefCore Scale 13 @ Wed Apr 22, 2015 11am - 12pm (rob@rackn.com)

This event has been changed.

Title: DefCore Scale 13
Etherpad: https://etherpad.openstack.org/p/DefCoreScale.13

Jou have been invited to a join.me online meeting

Join the meeting: https://join.me/557-199-373

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 557-199-373

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
United States - San Francisco, CA +1.415.655.0381
Access Code 557-199-373#

Other international numbers available (https://join.me/intphone/557199373/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1430341200000/1430344800000)

When: Wed Apr 22, 2015 11am - 12pm Central Time (changed)
Where:
https://etherpad.openstack.org/p/DefCoreScale.13https://join.me/557-199-373,
see conference numbers in the invitation
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* ushnishtha@hotmail.com
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=ZzU2YjFzcTVldGlmMDA4cGNkMGU5aXFrNm8gZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWQ3MWUyNzBlMTY4NzU2YTQ2NmUyOTA2NWZjM2Y1ZjhkMDBjNGE0Nzk&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Scale 14 @ Wed May 27, 2015 11am - 12pm (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Scale 14
https://etherpad.openstack.org/p/DefCoreScale.14

You have been invited to a join.me online meeting

Join the meeting: https://join.me/258-670-003

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 258-670-003

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
Access Code 258-670-003#

Other international numbers available (https://join.me/intphone/258670003/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1430928000000/1430931600000)

When: Wed May 27, 2015 11am - 12pm Central Time
Where:
https://etherpad.openstack.org/p/DefCoreScale.13https://join.me/258-670-003,
+1.860.970.0010 Access Code: 258-670-003#
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* ushnishtha@hotmail.com
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NmRjOGk0bXBvN2E3MWVscGU4NDJzdHU0YWcgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWFmN2UyYWJlNTJjMDI3OTc3N2QxNGVmZGY1NzNkM2I5Mjg2NDQwNmE&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Updated Invitation: DefCore Scale 14 @ Wed Apr 29, 2015 11am - 12pm (rob@rackn.com)

This event has been changed.

Title: DefCore Scale 14
https://etherpad.openstack.org/p/DefCoreScale.14

You have been invited to a join.me online meeting

Join the meeting: https://join.me/258-670-003

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 258-670-003

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
Access Code 258-670-003#

Other international numbers available (https://join.me/intphone/258670003/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1430928000000/1430931600000)

When: Wed Apr 29, 2015 11am - 12pm Central Time (changed)
Where:
https://etherpad.openstack.org/p/DefCoreScale.13https://join.me/258-670-003,
+1.860.970.0010 Access Code: 258-670-003#
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* ushnishtha@hotmail.com
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NmRjOGk0bXBvN2E3MWVscGU4NDJzdHU0YWcgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWFmN2UyYWJlNTJjMDI3OTc3N2QxNGVmZGY1NzNkM2I5Mjg2NDQwNmE&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Scale 13 meeting summary

Thank you everyone for joining today, sorry for initial technical issues. Here are the notes from todays meeting:https://etherpad.openstack.org/p/DefCoreScale.13

DefCore Scale.13 2015, April 22 @ 9am PTPrevious: https://etherpad.openstack.org/p/DefCoreScale.12Following: https://etherpad.openstack.org/p/DefCoreScale.14Jou have been invited to a join.me online meeting Join the meeting: https://join.me/557-199-373 On a computer, use any browser with Flash. Nothing to download. On a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 557-199-373 Join the audio conference: Dial a phone number and enter access code, or connect via internet. By phone: United States - Hartford, CT +1.860.970.0010 United States - San Francisco, CA +1.415.655.0381 Access Code 557-199-373# Other international numbers available (https://join.me/intphone/557199373/0) By computer via internet: Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required. Start time by time zones (https://join.me/timezone/1430341200000/1430344800000) # Roll Call Rocky Grober (Huawei) Vince Brunssen (IBM) Egle Sigler (Rackspace, Co-Chair) Catherine Diep (IBM) Chris Hoge (OpenStack Foundation) Mark T. Voelker (VMware)# AgendaSessions for OpenStack Summit VancouverIdentity ComponentSchema UpdateUpdate Defcore Committee Governance Page2014.04 Testing Support DocumentsLock down 2015A# Sessions for OpenStack Summit Vancouver* DefCore Panel on Monday May 18, 2:00-2:40 http://sched.co/2qSl* Tempest testing session Tuesday May 19, 11:15 - http://sched.co/2qcz* Town Hall Meeting Wednesday May 20, 10:30-11:00, East Bld, Parkview Terrace 1 (holds 200, theater)* Working Session Wednesday May 20, 11:00-11:40, East Bld, Room 12 (holds 100, theater)* Working Session Wednesday May 20, 11:50-12:30, East Bld, Room 12 (holds 100, theater)Other options available, for M,T,W,Th# Identity Componenthttps://review.openstack.org/#/c/169655"I don't think identity is a new component - it's a capability that's required for both compute and object. If you feel strongly about this, we need to make sure it's discussed at DefCore or made as a request from the Foundation."Action: remove component designation# Schema UpdateDefering update to post Vancouverhttps://review.openstack.org/#/c/171427/Action prep # Update Defcore Committee Governance Pagehttps://wiki.openstack.org/wiki/Governance/DefCoreCommitteeACTION Mark to update pages and links# 2014.04 Testing Support Documentshttps://review.openstack.org/#/c/176147/# Lock Down 2015Ahttps://github.com/openstack/defcore/blob/master/process/2015A.rsthttps://review.openstack.org/#/c/173915/Any final comments, suggestions welcome. If no more feedback, will merge tomorrow.####Action item: have exact dates for submissions of tests (Chris is looking into having dates/timelines for test submission put on interop page).

                  _______________________________________________

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Cleaning Up The Wiki

Hello DefCore,

At last week’s DefCore meeting [1] I took an AI to go through the DefCore wiki page [2] and make a first pass at cleaning it up now that we’ve successfully moved a bunch of content into Gerrit. I’ve made some edits to update links, add meeting info, and a few cosmetic fixes. One of the remaining tasks is to clean up the Participants section. Currently there are (quite outdated) lists of committee members from the board and outside the board, subcommittees (are these even still active?) and former members. Editing public lists that include people’s names can be a touchy subject, so I thought I’d suggest changes here on the list to solicit some feedback before I go change things on the web. I think a good start would be to:

1.) Remove the subcommittee and former/inactive participant lists. I’m not sure these are really useful/relevant any longer.
2.) Merge the participant and board member lists into a single list of current participants (and designate co-chairs board members with a callout).
3.) Add links beside each name to the person in question’s community bio [3] (which may contain useful contact info such as IRC nics and social media handles).

The tricky bit here is that AFAIK, there is no actual criteria for “committee membership” but we still want people reading the page to know who they can reach out to if they’re interested in DefCore. Since we have no formal membership criteria, compiling a list of names is somewhat arbitrary. We have a couple of options here: we could include just the DefCore chairs (which is easy to keep up to date and the only folks who have a “formal” longstanding role and helps onlookers get in touch with the committee), or we can change the list to reflect who is regularly participating today and try to keep it current. I’ll take a stab at compiling a list here for the sake of discussion based on names I see showing up on meeting etherpads, gerrit reviews, F2F roll calls, etc over the past several months with some degree of regularity. Please don’t feel slighted if I’ve missed a name or included one that shouldn’t be here—this is a bit arbitrary and should be considered a first pass. =)

Current Participants
* Rob Hirschfeld (board member, co-chair)
* Egle Sigler (board member, co-chair)
* Will Auld
* Carol Barrett
* Vince Brunssen
* Russell Bryant
* Kevin Carter
* Catherine Diep
* Rocky Grober
* Chris Hoge
* Chris Lee
* Van Lindberg (board member)
* Jim Meyer
* Adrian Otto
* Sean Roberts
* Shamail Tahir
* Mark Voelker

Do we want to try to keep a participant roster on the wiki? If so, does this list look correct?

[1] https://etherpad.openstack.org/p/DefCoreScale.13
[2] https://wiki.openstack.org/wiki/Governance/DefCoreCommittee
[3] For example, mine is: https://www.openstack.org/community/members/profile/54

At Your Service,

Mark T. Voelker
OpenStack Architect


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] [PTLs] [Defcore] [Users] - OSPod is headed to Vancouver!

For those of you who don’t me, I’m Niki Acosta with Cisco (formerly Metacloud & Rackspace.) I co-host an OpenStack-focused Podcast with Jeff Dickey of Redapt. (You can see previous podcast guests & videos herehttp://www.nextcast.net/openstackpod/ or download the podcasts herehttps://itunes.apple.com/us/podcast/an-openstack-podcast/id913351029?mt=2.)

Thanks to the generosity of the foundation, we’ve secured two blocks in the podcasting lounge to bring OSPod to the summit. Based on feedback from previous guests and listeners, and we’re looking to fill 20 to 25 minute slots with:

PTLs – to get updates on key projects
Users – SuperUsers and those running OS in production – would love to hear from companies nominated for this years' SuperUser awards: Comcast, Walmart eCommerce, eBay, National Supercomputer Center
Those involved in key initiatives (Big Tent, DefCore, etc)

We have a total of 24 slots available.
The blocks are available on Monday and Thursday from 1pm-6pm. The sessions will be recorded and posted on YouTube and audio will be posted as a podcast download. If you’d like to participate, please fill out the short form here: http://bit.ly/1bM635V

If we can’t fit you in during the summit, we will keep your info on hand for opportunities to be a guest on the regular podcast schedule after the summit.

If you have any questions, please message me off list at nikacost@cisco.com
We look forward to seeing some of y’all in Vancouver!

[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_02.png?ct=1416252642374]

Niki Acosta
Cloud Evangelist
Cisco.comhttp://www.cisco.com/
nikacost@cisco.comnikacost@cisco.com
@nikiacosta

[http://www.cisco.com/assets/social_media_icons/twitter-16x16.png]<http://www.twitter.com/nikiacosta

[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Please click herehttp://www.cisco.com/web/about/doing_business/legal/cri/index.html for Company Registration Information.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Scale.15 @ Wed May 6, 2015 11am - 12pm (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Scale.15
https://etherpad.openstack.org/p/DefCoreScale.15

Recommend 2015.next & 2015A for board
Refstack Demo

You have been invited to a join.me online meeting

Join the meeting: https://join.me/627-874-520

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app and enter meeting code:
627-874-520

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
Access Code 627-874-520#

Other international numbers available

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones

When: Wed May 6, 2015 11am - 12pm Central Time
Where: https://join.me/627-874-520
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=aml1ZGRxcmcwNmdxb2J1cnBpNGIya3JpZmsgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWQ3Yzk0ZDY3ZGEwYzcyYTYxNmYyMWUyNGIzNDEyMjNiOWI5Zjk2YjE&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Scale 15 notes: asking for DefCore to recommend Guideline & Process NEXT WEEK

https://etherpad.openstack.org/p/DefCoreScale.14

ACTION ITEM: Please give final review of process 2015A!
http://bit.ly/defcore2015a

Summary

  • We are going to cleanup the rosters for DefCore - we'll send out a
    link for you to review your membership current & historical
  • Planned for presentations at the Summit. Expanded speakers for Monday
    Session: Rocky, Catherine, Egle, Mark, Chris are panelists, Rob will
    moderate
  • Advanced 2 patches - notable patch is 2015A.A3 about technical
    leadership participation
  • Identified that we need PTL input on Keystone Designated Sections
  • Agreed next meeting will be to recommend items for Board review in
    Vancover

Full Body:

DefCore Scale.14

2015, April 29 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.13
Following: https://etherpad.openstack.org/p/DefCoreScale.15

Summary

  • We are going to cleanup the rosters for DefCore - we'll send out a
    link for you to review your membership current & historical
  • Planned for presentations at the Summit. Expanded speakers for Monday
    Session: Rocky, Catherine, Egle, Mark, Chris are panelists, Rob will
    moderate
  • Advanced 2 patches - notable patch is 2015A.A3 about technical
    leadership participation
  • Identified that we need PTL input on Keystone Designated Sections
  • Agreed next meeting will be to recommend items for Board review in
    Vancover

Roll Call

Mark T. Voelker (VMware)
Rob Hirschfeld
Rocky Grober (Huawei)
Chris Hoge (OpenStack Foundation)
Catherine Diep (IBM)
Carol Barrett (Intel)
Alan Clark

Agenda

  • Prep for Summit
  • Review Patches
  • Membership
  • Schema Update

Membership Discussion

Three named roles in DefCore > Chair Year 1 (Board), Chair Year 2
(Board), Secretary (Foundation)
Formal Votes: are Board Members only (unless concensus)

https://wiki.openstack.org/wiki/Governance/DefCoreCommittee

DECiSION: Members can continue to self add, review start of cycle
ACTION: Membership policy header by Rob
ACTION: We will clean up existing membership. People will review.

DefCore Session

Three Talks
* Chris & Catherine - Tempest Talk [Tuesday @ 11:15]

  • Round Table - Egle & Rob [Monday @ 2]

    • Speakers - Alan, Sean, Egle, Rob
    • Moderated Panel
    • Audience is users & vendors
    • Topics
    • Vision from the Board, why was DefCore created (very short, vision
      oriented pitch)

      • Very brief intro -> minimal on the HOW
      • Vendor process - how it works & who
      • What will be hard
      • What is the impact going to be
      • Further topics for next cycle - [API only, A or B compoents,
        non-Tempest]
        ** re-enforce the Foundation announcements made at the Summit
        ** business aspect (impact, benefit, vision)
      • Call to participate
  • Townhall & Working Sessions (Wed AM)

    • get work done
    • frame out big discussion items

Reviews

https://review.openstack.org/#/c/173915/4

Agenda 15

  • Refstack Demo
  • 2015.next recommendation formal
  • 2015A recommendation formal

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Appeal on compute resize tests

All,

I reviewed and tried out the 2015.04 list of required tests [0]. All tests
work fine for me, with one exception: there are four tests in the list
specific to the compute feature "resize".

The current implementation of resize in nova libvirt driver uses ssh to
transfer volumes in case of non-shared storage. This requires password-less
ssh access between all compute nodes in the cloud.

Resize is disabled by default in the HP Helion OpenStack distribution,
because of the security concerns associated with having password-less ssh
access between most nodes in the cloud.

There is a blueprint [1] open to address the issue, but until that's
implemented I would like to suggest for the resize tests to be added to the
flagged list.

I added an item to the agenda [2] of tomorrow's meeting at 9am to discuss
about this, but I wanted to reach out to the DL prior to that to possibly
reach a wider audience and provide some background before the meeting.

andrea


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

And the links:

[0]
http://git.openstack.org/cgit/openstack/defcore/tree/2015.04/2015.04.required.txt
[1] https://blueprints.launchpad.net/nova/+spec/migrate-libvirt-volumes
[2] https://etherpad.openstack.org/p/DefCoreScale.15

On Tue, May 5, 2015 at 1:58 PM Andrea Frittoli andrea.frittoli@gmail.com
wrote:

All,

I reviewed and tried out the 2015.04 list of required tests [0]. All tests
work fine for me, with one exception: there are four tests in the list
specific to the compute feature "resize".

The current implementation of resize in nova libvirt driver uses ssh to
transfer volumes in case of non-shared storage. This requires password-less
ssh access between all compute nodes in the cloud.

Resize is disabled by default in the HP Helion OpenStack distribution,
because of the security concerns associated with having password-less ssh
access between most nodes in the cloud.

There is a blueprint [1] open to address the issue, but until that's
implemented I would like to suggest for the resize tests to be added to the
flagged list.

I added an item to the agenda [2] of tomorrow's meeting at 9am to discuss
about this, but I wanted to reach out to the DL prior to that to possibly
reach a wider audience and provide some background before the meeting.

andrea


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] reminder: meeting today (Refstack Demo, Approvals before Board)

DefCore Scale.15

2015, May 6 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.15
Following: https://etherpad.openstack.org/p/DefCoreScale.16

 You have been invited to a join.me online meeting


 Join the meeting: https://join.me/627-874-520


 On a computer, use any browser with Flash. Nothing to download.

 On a phone or tablet, launch the join.me app (https://join.me/app) 

and enter meeting code:627-874-520

 Join the audio conference:

 Dial a phone number and enter access code, or connect via internet.


 By phone:

 United States - Hartford, CT +1.860.970.0010

 Access Code 258-670-003#


 By computer via internet:

 Join the meeting, click the phone icon and select 'Call via 

internet'. A small download might be required.

Agenda 15

  • Refstack Demo
  • Appeal of compute resize tests
  • 2015.next recommendation formal
  • 2015A recommendation formal
  • Implicit test requirements and public cloud testing

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi, all. Apologies for my frequent absence of late, and for an inability to make it to today's meeting. I'll break this streak next week; I tell you this so no one keels over from the shock.

I wanted to check in and see if I'm specifically needed to address the compute resize tests appeal. If so, are we able to address that next week?

--j

On May 6, 2015, at 7:43 AM, Rob Hirschfeld rob@zehicle.com wrote:

DefCore Scale.15

2015, May 6 @ 9am PT

Previous: https://etherpad.openstack.org/p/DefCoreScale.15
Following: https://etherpad.openstack.org/p/DefCoreScale.16

You have been invited to a join.me online meeting

Join the meeting: https://join.me/627-874-520

On a computer, use any browser with Flash. Nothing to download.

On a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code:627-874-520

Join the audio conference:

Dial a phone number and enter access code, or connect via internet.

By phone:

United States - Hartford, CT +1.860.970.0010

Access Code 258-670-003#

By computer via internet:

Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required.

Agenda 15

  • Refstack Demo
  • Appeal of compute resize tests
  • 2015.next recommendation formal
  • 2015A recommendation formal
  • Implicit test requirements and public cloud testing

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Meeting Code: https://join.me/627-874-520

This is the correct bridge for today Join the meeting:
https://join.me/627-874-520

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

By Phone: Dial this number:+1.813.769.0500 Conference ID:627-874-520

Date: Wed, 6 May 2015 11:07:18 -0500
From: rob@rackn.com
To: defcore-committee@lists.openstack.org
Subject: [OpenStack-DefCore] Meeting Code: https://join.me/627-874-520

This is the correct bridge for today Join the meeting:
https://join.me/627-874-520

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Scale.16 [FINAL MEETING THIS CYCLE] @ Wed May 13, 2015 11am - 12pm (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Scale.16 [FINAL MEETING THIS CYCLE]
https://etherpad.openstack.org/p/DefCoreScale.16

You have been invited to a join.me online meeting

Join the meeting: https://join.me/380-962-402

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 380-962-402

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
Access Code 380-962-402#

Other international numbers available (https://join.me/intphone/380962402/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1431532800000/1431536400000)

When: Wed May 13, 2015 11am - 12pm Central Time
Where: https://etherpad.openstack.org/p/DefCoreScale.16 (call in details
https://join.me/380-962-402)
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* ushnishtha@hotmail.com
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=bThpMDBvajZnbmNocXJlbjY2MWFqMWxwNm8gZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbWNkZWFlNGE1MWEyNWQ5ZTRiNWVmZjQwNGYxNzVmNzFkOTEyZTk1MDI&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] May Board Report Draft

DefCore,

You are invited to review our draft report for the 2015 May Board meeting.

https://docs.google.com/document/d/12kUWSWt55Ju-okgfEbPt9AH-8UzaQoO_2KzSOHl5Sg0/edit?usp=sharing

DefCore Board Report
Meeting May 17, 2015
Rob Hirschfeld & Egle Sigler Co-Chairs

20 minutes

Process 2015A Discussion [5 mins. WARNING MINIMAL TIME]
2015.04/03 Update [5 mins WARNING MINIMAL TIME]
2015.05 Guideline Approval [5 mins]
Next Cycle Objectives [5 mins]

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Before 2015.05 goes up for Board approval, we need to finalize the releases covered by the guideline [1]. The 2015.04 spec covered Havana, Icehouse, and Juno [2], so I’ve posted a patch [3] to drop Havana and add Kilo. However there’s been some discussion in another review [4] about whether we should cover two releases or three going forward. I don’t have particularly strong feelings either way, so I would welcome discussion on the new patch [3] so we can get to consensus.

[1] https://github.com/openstack/defcore/blob/master/2015.next.json#L7
[2] https://github.com/openstack/defcore/commit/dc9dce4bcbe165967bef8394b6d5b3cdd1535df5
[3] https://review.openstack.org/#/c/181372/
[4] https://review.openstack.org/#/c/181137/

At Your Service,

Mark T. Voelker
OpenStack Architect

On May 7, 2015, at 5:35 PM, Rob Hirschfeld rob@zehicle.com wrote:

DefCore,

You are invited to review our draft report for the 2015 May Board meeting.

https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_12kUWSWt55Ju-2DokgfEbPt9AH-2D8UzaQoO-5F2KzSOHl5Sg0_edit-3Fusp-3Dsharing&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=znDq0m4Bb3X4F17krVc50lf9Ayh55uxGmLjS7vJbkfE&s=bs936MKSr-Aeu_O42vFGkonlbwgeXwZmVvtqIObP1-g&e=

DefCore Board Report
Meeting May 17, 2015
Rob Hirschfeld & Egle Sigler Co-Chairs

20 minutes

Process 2015A Discussion [5 mins. WARNING MINIMAL TIME]
2015.04/03 Update [5 mins WARNING MINIMAL TIME]
2015.05 Guideline Approval [5 mins]
Next Cycle Objectives [5 mins]

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
https://urldefense.proofpoint.com/v2/url?u=http-3A__robhirschfeld.com&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=znDq0m4Bb3X4F17krVc50lf9Ayh55uxGmLjS7vJbkfE&s=HGlVKWefqiHujd7zm1QlzYeUsVUFOYoVgf3WEGc18aQ&e= twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Scale.16 [FINAL MEETING THIS CYCLE]

You have been invited to a join.me online meeting \n \nJoin the meeting: https://join.me/380-962-402 \n \nOn a computer, use any browser with Flash. Nothing to download. \nOn a phone or tablet, launch the join.me app (https://join.me/app) and enter meeting code: 380-962-402 \n \nJoin the audio conference: \nDial a phone number and enter access code, or connect via internet. \n \nBy phone: \nUnited States - Hartford, CT +1.860.970.0010 \nAccess Code 380-962-402# \n \nOther international numbers available (https://join.me/intphone/380962402/0) \n \nBy computer via internet: \nJoin the meeting, click the phone icon and select 'Call via internet'. A small download might be required. \n \nStart time by time zones (https://join.me/timezone/1431532800000/1431536400000) \n \n_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Flagged Test reviews and IRC channel

Hello Everyone,
As the summit is getting closer, we are getting more requests for flagged tests. We reviewed a few in our last meeting, but we have more. If you have a chance, please review the flagged test PRs https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z and provide any feedback you might have.
Also, if you are on IRC, join us on #defcore channel. https://wiki.openstack.org/wiki/IRC
Thank you!
Egle

                  _______________________________________________

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore, Tests, and Flagged Tests Discussion

Calendar

Egle Sigler has sent you an invitation to "DefCore, Tests, and Flagged Tests Discussion"

Please call 1-800-285-8764
Code: 4507

Sorry for the short notice, but we are having lots of discussions on IRC, lets talk in person.
Etherpad for notes: https://etherpad.openstack.org/p/DefCoreScale.15A

Thank you,

Egle

When: Friday, May 8, 2015 3:00AM - 4:00AM
Location: 1-800-285-8764 Code: 4507
This event occurs in (UTC-06:00) Central Time (US & Canada)


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Calendar

Egle Sigler has updated information for "DefCore, Tests, and Flagged Tests Discussion"

Please call 1-800-285-8764
Code: 4507

Sorry for the short notice, but we are having lots of discussions on IRC, lets talk in person.
Etherpad for notes: https://etherpad.openstack.org/p/DefCoreScale.15A

Thank you,

Egle

When: Friday, May 8, 2015 3:00PM - 4:00PM
Location: 1-800-285-8764 Code: 4507
This event occurs in (UTC-06:00) Central Time (US & Canada)


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Scale.16 [FINAL MEETING THIS CYCLE] @ Wed May 13, 2015 9am - 10am (stefano@openstack.org)

You have been invited to the following event.

Title: DefCore Scale.16 [FINAL MEETING THIS CYCLE]
You have been invited to a join.me online meeting

Join the meeting: https://join.me/380-962-402

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 380-962-402

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Hartford, CT +1.860.970.0010
Access Code 380-962-402#

Other international numbers available (https://join.me/intphone/380962402/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1431532800000/1431536400000)

When: Wed May 13, 2015 9am - 10am Pacific Time
Where: join.me/380-962-402, +1.860.970.0010 Access Code: 380-962-402#
Calendar: stefano@openstack.org
Who:
* Stefano Maffulli - organizer
* Rob Hirschfeld
* ushnishtha@hotmail.com
* defcore-committee@lists.openstack.org
* rob_hirschfeld@dell.com

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=OWhzNzRlNzhudmNzM2VwNnVwMjQxdmNra2sgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MjEjc3RlZmFub0BvcGVuc3RhY2sub3JnOWVmNDgxYzg3YWU2NGI1M2RlY2JjMDAxN2ZkYWI5MTZlYmUzNzBlNQ&ctz=America/Los_Angeles&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] New IRC channel #openstack-defcore

Hello Everyone,
Infra was kind enough to point out that our newly popular IRC channel was not being logged and does not follow the naming convention for other OpenStack channels.
We are moving to a new and logged channel. Please join us in #openstack-defcore
Thank you,Egle

                  _______________________________________________

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Bonus meeting summary

Hello Everyone,

Thanks to everyone that attended today's last minute bonus meeting. I am very glad to see the community getting more and more engaged in the DefCore process. We had some discussions about current tests and current process, and Mark Voelker has done excellent job documenting some of the discussions and decisions on PR bellow.
https://review.openstack.org/#/c/181280/
It was pointed out that 2015.04 covers Havana, Icehouse, and Juno [1], but the import task code didn't land until Icehouse. Thus, in Havana there's no way to create images without using the create API.However, it was also pointed out that the test's intent is to test listing an image, and creating images happens to be part of the setup for the test. The test could conceivably be set up differently so that it only tests the ability to list images, but it's a tricky proposition. E.g. if you have it list tests first, you also need to tell it exactly what images to expect (e.g. it should fail if it sees images in the list that don't exist or doesn't see images that do exist).It can also be argued that many folks expected the image create API to be "core" and that tests should be able to rely on a "core" API. However, no explicit test of that API exists in DefCore today and I'm not seeing any evidence that this API was ever deliberately meant to be tested. IMHO this seems like an oversight (remember that DefCore is essentially in it's infancy here and there are probably a lot of other things that need to be added yet as well) and I would be inclined to support a patch adding a test for it to DefCore, but none does exist today. Personally, I'd like to hear from the Glance PTL/cores about this since they allowed the (apparently broken? For several releases?) import task workflow in and therefore created an alternative to the create API (the argument was also made that it's difficult to discover that the create image API has been disallowed/disabled/blocked which puts end users in a place where they have to try, fail, and then try the import task route....which is also what Tempest would probably have to do for tests like this).Lastly, several of us discussed this afternoon that while this is very likely something we want to revisit for the next iteration of DefCore (ETA: this fall), we're inclined to be leniant for now given that DefCore is sort of in "catch-up" mode (we've had a couple of approved specs of the past months in order to get several releases covered). Once 2015.05 is done, we'll have Kilo covered and therefore the next iteration of DefCore will have a substantially longer feedback period for discussions like this to happen (refer to [2] for a timeline of what this will look like). In the interim most of us are inclined to be more inclusive of real-world situations so that we as a community can discuss controversial items like this.
Additionally, Mark has created a hacking HACKING.rst file for the DefCore repository which provides rules for incoming changes in order to make contributor's lives easier. Please review the patch: https://review.openstack.org/#/c/181489/
Etherpad for the bonus meeting: https://etherpad.openstack.org/p/DefCoreScale.15A
Please let us know if you have any questions or feedback!
Thank you,Egle

                  _______________________________________________

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore 2015 Panel at Vancouver Summit

http://sched.co/2qSl

This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.

DefCore sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."

Our mission is to define "OpenStack Core" as chartered by the by-laws and guided by Governance/CoreDefinitionhttps://wiki.openstack.org/wiki/Governance/CoreDefinition

[OpenStack-DefCore] DefCore - Town Hall Session

http://sched.co/3HKn

The "Working Group Meetings" track is designed to give OpenStack community working groups, committees and teams, space to gather and collaborate. Everyone is welcome to attend, whether you are currently participating on the team or interested in getting involved.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore - Working Session 1

http://sched.co/3HJr

DefCore working session 1


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Working Session 2

http://sched.co/3HJx

DefCore session 2


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Scale 16 Summary - moving to new schema/capabilities for 2015.05!

DefCore Scale.16

2015, May 13 @ 9am PT

https://etherpad.openstack.org/p/DefCoreScale.16

Previous: https://etherpad.openstack.org/p/DefCoreScale.15
Bonus meeting: https://etherpad.openstack.org/p/DefCoreScale.15A
Next: https://etherpad.openstack.org/p/DefCore

Following: SUMMIT! next cycle to be named

Summary

  • DECIDED > Move forward with new schema for Board approval
  • DECIDED > Present finer grained capabilities for Board approval
  • DECIDED > Flagged tests in 2015.next will NOT be included in 2015.05
    by default
  • DECIDED > Next cycle will be called "Flag"
  • We reviewed and set questions for the Summit Panel & Workshop Agenda
  • We moved to the #openstack-defcore IRC channel and integrated it into
    OpenStack process

Roll Call

Egle Sigler (Co-chair, Rackspace)
Rob Hirschfeld (Co-chair, RackN)
Rocky Grober (Huawei)
Monty Taylor (HP)
Chris Lee (DreamHost)
Chris Hoge (OpenStack Foundation)
Carol Barrett (Intel)
Catherine Diep (IBM)
Jim Meyer (HP)
Will Auld (Intel)
Shamail Tahir (EMC)
Mark T. Voelker (VMware)

Agenda 16

Next Cycle

Candidates
* Flag +1 +1+1+1+1+1+1 [WINNER]
* Feather
* Thorn

Summit Discussion

Three Talks
* Chris & Catherine - Tempest Talk [Tuesday @ 11:15]

  • Round Table - Egle & Rob [Monday @ 2]

    • Speakers - Alan, Sean, Rob
    • Moderated Panel: Egle, Catherine, Rocky, Mark V, Chris H
    • Audience is users & vendors
    • Topics > 5 minute overview by Rob (what is DefCore), 5 minutes for
      questions
    • Round Table Answers to...

    MAX 6 QUESTIONS! Allows for 1 minutes ANSWERS [30 mins = 5 people x 6
    questions = 1 MIN]
    Think we should go w/ 5 questions - it'll be v hard for people to
    keep their answers to 1 min... Agree. Have five, expect to use top
    three. Invite one or two from audience?(+1) +1
    I can put them on the screen so people see them in advance - if the
    panel chooses 4 then we'll have more time to cover all 6.

Why did you think it was an important effort?+1+1
What was the hardest thing about getting DefCore approved?
How will it change OpenStack in the next 6 months? 6 years?+1+1+1
Is DefCore vanilla OpenStack? +1
What are the next hard problems in front of DefCore?+1+1
What happens if DefCore fails?

BONUS QUESTION > which project/capability should be next component?

Community Workshop

Agenda:
* Background / Intro
* Schedule for DefCore meetings (combine all meetings)
* Topics for Flag cycle -> networking, flags, non-tempest tests
* Community Adoption
* Refstack integration & use
* Training and materials
* Process for flagging & review of flags
* Other non-tempest tests, tests for APIs
* Identify gaps & challenges that we can to ask for technical help
* How to strenghten the relationship between DefCore committee and
technical community
* Cross project session at summits for Defcore (part of
the solution)

Previous List:
* What is DefCore
* Cycle Priorities
* Networking Capabilities
* Tempest & Testing Challenges
* How to limit/bound test flagging

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] How to Configure your Cloud and Tempest for Interoperability Testing

Tuesday May 19, 2015 11:15am - 11:55am
Room 205/206/207https://openstacksummitmay2015vancouver.sched.org/venue/Room+205%2F206%2F207

One of the most important promises of OpenStack is compatability and interoperability between private and public clouds. You can check how compliant your OpenStack deployment is by running Tempest against it and comparing the results to a known set of capabilities, like those listed by Defcore.

However, configuring Tempest, and configuring your cloud to work with Tempest, can be challenging for operators. In this talk we will show how you can use the refstack-client to automate your Tempest installation, what users and networks need to be in your cloud for testing, and the essential parameters to set in you tempest.conf to have a successful run.

The aim is to take the confusion and mystery out of Tempest and help you make interoperability testing a powerful tool for your operations toolkit.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Schema 1.3 Update for 2015.next.json

All,

Chris and I worked on the Guideline schema today and found that we could
accommodate the changes for IDs and Flags WITHOUT BREAKING the current
1.2 schema parsing.

Please review the following patch: https://review.openstack.org/#/c/185158/

This patch adds/changes the schema in minor ways that will allow us to
move flagging below the tests. To accomplish this, we've pulled all the
flagged tests (we put them in another file for safe keeping).

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Polls for New Meeting Times

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi folks,

At the DefCore working sessions during the OpenStack Summit, I took an action item to send out a SurveyMonkey poll to help determine an optimal meeting time for the Flag cycle. For those who are new to DefCore, please note that we’ve traditionally held two separate meetings each week: a capabilities meeting (during which we score potential new capabilities and tests to be added to the DefCore battery) and a process meeting (during which we discuss most everything else). I’ve created two separate polls for these meetings so that you can answer for the meeting or meetings you plan to attend. As a reminder, if there’s substantial demand by regular attendees we’ll try to work out a staggered meeting schedule so that everyone gets a chance to participate.

Both polls will close on Friday, May 29 at 18:00 PDT.

Poll for Flag cycle process meetings:
https://www.surveymonkey.com/s/LVSK3XL

Poll for Flag cycle capabilities meetings:
https://www.surveymonkey.com/s/LVP8CJ9

On a final note, there was some concern expressed that folks in some parts of the world may not be able to access some survey tools. We believe that Survey Monkey should be widely available, but if you are unable to access the polls, please feel free to email me directly and I’ll be happy to provide an alternate method of making your opinion heard.

At Your Service,

Mark T. Voelker
OpenStack Primate Pollster (Plausibly)

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVYOXPAAoJELUJLUWGN7Cbp5MP/3QvjE12J/XSZ4Uibzggs5uw
S3EdOhXS407qm1zSHEmzNnzY2rj/5/M8R981s8U7R4Bn5bFpWCsBrqCHQhmdXXO8
Z/MoXz2XsHtu4MFQqS73qDIH0clREYAwmPpCXSE6/K8fTZHADGAHUlDd6nWXI0pA
u5+83oxntTNdLNqm/6Z6RFjKWZe6MRyc7b57Ma8xv0T5lrGe+Rnu1M/lddrFV2tz
99K8pNwP2oFEOqHplS7RI5WUn0qcnloVjMAplgD0Ye5ZW6n2BWbJFdVsQBQnqKwy
zVLs3ZXk3nh8Gf18wkU6rhMwe3nr5qHm5LxqrQfqQ7m8x38icu1b4NEkNRgStc40
MCMhrP9yJUukON6u5VcRMD5/TjDDxeNWS7OGMMLfhWS5kgvdZ+DY2XV3ec7Vaa/A
bS7SSJ0dQQhyD9SM22nBSrtoF4X/PXskXUvNtlXm6+1W0bZvFug6yF8CFtSK5Rgx
nRqG/QSt/MbOac/5+5b+49ZkeGPC21gnvzdfdKqOQwqYV6zDWAh9SoSIcIT+vju1
KpNFbVFrTSlPlJFvo6UyFa/ukwmUKpRvnmk6WpxO0ErBC8doioZT9zrMPf99GBB7
PY1oaQUrsGiMMJEiqIK6lPODgUE9dZgtaH0epaMKUNkW+zcPYYloYB5OPEP5qKVp
IVA8PqYmoZuwlzdeYTUZ
=ePnp
-----END PGP SIGNATURE-----


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi Mark,

I thought we were going to combine capabilities and flags meetings this
cycle. Did we decide to keep them separate for the time being (hence the
two surveys)?

Thanks,
Shamail

On Sat, May 23, 2015 at 4:40 PM, Mark Voelker mvoelker@vmware.com wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi folks,

At the DefCore working sessions during the OpenStack Summit, I took an
action item to send out a SurveyMonkey poll to help determine an optimal
meeting time for the Flag cycle. For those who are new to DefCore, please
note that we’ve traditionally held two separate meetings each week: a
capabilities meeting (during which we score potential new capabilities and
tests to be added to the DefCore battery) and a process meeting (during
which we discuss most everything else). I’ve created two separate polls
for these meetings so that you can answer for the meeting or meetings you
plan to attend. As a reminder, if there’s substantial demand by regular
attendees we’ll try to work out a staggered meeting schedule so that
everyone gets a chance to participate.

Both polls will close on Friday, May 29 at 18:00 PDT.

Poll for Flag cycle process meetings:
https://www.surveymonkey.com/s/LVSK3XL

Poll for Flag cycle capabilities meetings:
https://www.surveymonkey.com/s/LVP8CJ9

On a final note, there was some concern expressed that folks in some parts
of the world may not be able to access some survey tools. We believe that
Survey Monkey should be widely available, but if you are unable to access
the polls, please feel free to email me directly and I’ll be happy to
provide an alternate method of making your opinion heard.

At Your Service,

Mark T. Voelker
OpenStack Primate Pollster (Plausibly)

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVYOXPAAoJELUJLUWGN7Cbp5MP/3QvjE12J/XSZ4Uibzggs5uw
S3EdOhXS407qm1zSHEmzNnzY2rj/5/M8R981s8U7R4Bn5bFpWCsBrqCHQhmdXXO8
Z/MoXz2XsHtu4MFQqS73qDIH0clREYAwmPpCXSE6/K8fTZHADGAHUlDd6nWXI0pA
u5+83oxntTNdLNqm/6Z6RFjKWZe6MRyc7b57Ma8xv0T5lrGe+Rnu1M/lddrFV2tz
99K8pNwP2oFEOqHplS7RI5WUn0qcnloVjMAplgD0Ye5ZW6n2BWbJFdVsQBQnqKwy
zVLs3ZXk3nh8Gf18wkU6rhMwe3nr5qHm5LxqrQfqQ7m8x38icu1b4NEkNRgStc40
MCMhrP9yJUukON6u5VcRMD5/TjDDxeNWS7OGMMLfhWS5kgvdZ+DY2XV3ec7Vaa/A
bS7SSJ0dQQhyD9SM22nBSrtoF4X/PXskXUvNtlXm6+1W0bZvFug6yF8CFtSK5Rgx
nRqG/QSt/MbOac/5+5b+49ZkeGPC21gnvzdfdKqOQwqYV6zDWAh9SoSIcIT+vju1
KpNFbVFrTSlPlJFvo6UyFa/ukwmUKpRvnmk6WpxO0ErBC8doioZT9zrMPf99GBB7
PY1oaQUrsGiMMJEiqIK6lPODgUE9dZgtaH0epaMKUNkW+zcPYYloYB5OPEP5qKVp
IVA8PqYmoZuwlzdeYTUZ
=ePnp
-----END PGP SIGNATURE-----


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--
Thanks,
Shamail Tahir
Cloud Architect, EMC
t: @ShamailXD
tz: Eastern Time


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] FW: [Glance] Liberty Priorities

Here is the pointer to Rackspace Glance priorities.

From my source in Glance, there's a storm a brewin' in Glance Town.

It looks like the Rackspace team will be focusing on the "traditional" Glance functionality/purpose and not the artifact work. Looks to be lots of performance and reliability work. This is extremely important work to land in Glance from what I can infer. I think this work is important for both the product wg and Defcore to be aware of.

--Rocky

From: Jesse Cook [mailto:jesse.cook@RACKSPACE.COM]
Sent: Tuesday, May 26, 2015 10:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Glance] Liberty Priorities

I created an etherpad with priorities the RAX team I work on will be focusing on based on our talks at the summit: https://etherpad.openstack.org/p/liberty-priorities-rax. Input, guidance, feedback, and collaboration is not just welcome, it is encouraged and appreciated.

Thanks,

Jesse


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] No Meeting on May 27th, Reminder to vote, and Notes

Hello Everyone,

Was great to see/meet everyone last week, lots of good conversations about DefCore. We will not have a meeting this week, but we need you to vote on the new meeting time. See Mark's email:http://lists.openstack.org/pipermail/defcore-committee/2015-May/000781.htmlPolls:Process meeting poll:https://www.surveymonkey.com/s/LVSK3XLCapabilities meeting poll:https://www.surveymonkey.com/s/LVP8CJ9We did talk of combining the two meetings together. We will make a final decision based on the poll results, so please vote!
Here are the notes from working sessions last week:https://etherpad.openstack.org/p/DefCoreFlag.1# DefCore Flag.12015, May 20 @ 10:30am PDTPrevious: https://etherpad.openstack.org/p/DefCoreScale.16Next: https://etherpad.openstack.org/p/DefCoreFlag.2IRC: #openstack-defcoreWiki: https://wiki.openstack.org/DefCoreAttendees:Egle Sigler (Co-Chair, Rackspace)Rob Hirschfeld (Co-Chair, RackN)Mark T. Voelker (VMware)Jim Meyer (HP)Paul Holland (HP)Catherine Diep (IBM)Britt Houser (Cisco)Tom Francis (Cisco)Xiao Hu Gao (Cisco)Jerry Wong (cisco)James Downs (Walmartlabs)Sam Danes (Rackspace)Rick Lopez (Rackspace)Robert Collins (HP)Shamail Tahir (EMC)Chris Lee (DreamHost)Van Lindberg (Rackpace)Paul Voccio (Rackspace)Blake Devcich (Cray)Tyler Lastovich (Cray)Rochelle Grober (Huawei)Ray Nugent (OPNFV)Agenda:Background / IntroSchedule for DefCore meetings (combine all meetings)Topics for Flag cycle -> networking, flags, non-tempest testsCommunity AdoptionRefstack integration & useTraining and materialsProcess for flagging & review of flagsTypes of flags: broken test, broken code (e.g. resize), and reasonable disagreement. Others?Other non-tempest tests, tests for APIsIdentify gaps & challenges that we can to ask for technical helpI'm happy to help with that anytime (lifeless)How to strenghten the relationship between DefCore committee and technical communityCross project session at summits for Defcore (part of the solution)Mid-Cycle F2F?Translations#Questions?Is there concern that DefCore will symbolize features that are stable? i.e. people won't stand up X in production until its in DefCore?That's partly why Rob has been going to great pains to say that DefCore is a trailing indicator. =) We generally encourage people to read & understand the criteria for something being core: https://github.com/openstack/defcore/blob/master/process/CoreCriteria.rst There are several criteria, one of which is "widely deployed".I think lagging will be key. If it gets too close, then people will use DefCore as Bellweather for a component instead of Tim Bell. =P (that's what makes it a Bellweather? ;-) =)"widely deployed" will be defined by results coming from refstack. (sample data at http://refstack.net)How are the tests run on a cloud in production?DefCore tests run in non-admin.tenantsFor distributions, how to apply the DefCore label? Some configs will be DefCore compliant, others will not be.If the distro can be deployed in DeCore compliant manner, then get logo. After that is customer choice.#Refence materials: Mailing list: bit.ly/DefCoreList Wiki: https://wiki.openstack.org/wiki/Governance/DefCoreCommittee Wiki You Can Remember: https://wiki.openstack.org/DefCore OpenStack Interop: http://www.openstack.org/brand/interop/ DefCore repository, all documents go through Gerrit process: https://github.com/openstack/defcore Process doc: https://github.com/openstack/defcore/blob/master/process/2015A.rst Rob's Book of blogs on DefCore, covers a lot of history and decision making: http://robhirschfeld.com/tag/defcore/ Slides: http://www.slideshare.net/rhirschfeld/community-defcore-presentation Recorded presentation, DefCore community review: http://t.co/HqvvKPDa6L http://robhirschfeld.com/2014/05/01/defcore-capabilities-selection/ IRC: Join #openstack-defcore on Freenode IRC Current guidelines: https://github.com/openstack/defcore/blob/master/2015.05.json https://github.com/openstack/defcore/blob/master/2015.05.rstWhere can we find documentation on process for submitting test results? http://www.openstack.org/brand/interop/#Discussionsare we not worried that people will fork openstack rather then go through the DefCore process?DefCore process is very straightforward for people who just want to get an "OpenStack-powered Compute/Object/etc" logo to use with their product. The only part of the process that is really complicated is if someone (a vendor, distributor, etc) wants to influence the direction of DefCore by changing which tests are used, adding new capabilities or platforms, etc. and about the worrying about forking, I think that's one of the purposes of defcore. Defcore is creating the interoperability.Good way to find common times: http://worldchatclock.com/ Proposed new time: 2 pm pacific or 3pm pacific#Todo: Email to general mailing lists about DefCore: how to join, where to findWiki redirect something to /defcore, so it is easier to find [DONE]Send out a survey monkey with times (Mark V. volunteered) Midcycle meeting for DefCore (within 6 weeks)??Thank you!Egle _______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Meeting Format: IRC/Phone?

Hello Everyone,
Hopefully everyone has already voted on the new time for DefCore meetings! If not, please do so now:Both polls will close on Friday, May 29 at 18:00 PDT.

Poll for Flag cycle process meetings:
https://www.surveymonkey.com/s/LVSK3XL

Poll for Flag cycle capabilities meetings:
https://www.surveymonkey.com/s/LVP8CJ9Previously, we always held meetings over the phone/join.me tool. Right now we are talking about switching to IRC meetings. As soon as we set the new time, we will send out calendar invites, and next week we will try meeting on an IRC channel.What is your opinion on the meeting format? Let me know if IRC meeting would prevent you from attending. Also let me know if phone/join.me meetings would prevent you from attending.Thank you very much,Egle

                  _______________________________________________

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

I would prefer IRC.

On Thu, May 28, 2015 at 9:07 PM Egle Sigler ushnishtha@hotmail.com wrote:

Hello Everyone,

Hopefully everyone has already voted on the new time for DefCore meetings!
If not, please do so now:

Both polls will close on Friday, May 29 at 18:00 PDT.

Poll for Flag cycle process meetings:https://www.surveymonkey.com/s/LVSK3XL

Poll for Flag cycle capabilities meetings:https://www.surveymonkey.com/s/LVP8CJ9

Previously, we always held meetings over the phone/join.me tool. Right now we are talking about switching to IRC meetings. As soon as we set the new time, we will send out calendar invites, and next week we will try meeting on an IRC channel.

What is your opinion on the meeting format? Let me know if IRC meeting would prevent you from attending. Also let me know if phone/join.me meetings would prevent you from attending.

Thank you very much,

Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.2 10 AM CST / 15:00 UTC

Hello Everyone,

Thanks to everyone that filled out the time surveys and provided feedback on IRC/phone meetings. For now, we will try IRC meetings, alternating weeks at different times.

Odd week, starting tomorrow: 15:00 UTC or 10 AM CST
Even week, starting next week: 01:00 UTC or 8 PM CST

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.2

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-defcore

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi Folks,

I’ve added some notes to the ether pad for Flag.2 on the rationale for the new meeting times:

Basically the plan is to combine the process/capabilities meetings, do them on IRC, and hold them on an alternate-week schedule that will hopefully be reasonably friendly for our global respondents. I’ve included links to the survey data there as well for those who are curious. We’ll try out this new meeting structure for roughly a month and then pause at the July 8th meeting to discuss if it’s working out or if we need to reconsider.

At Your Service,

Mark T. Voelker
OpenStack Architect
+1 (970) 203-4974

On Jun 2, 2015, at 12:48 PM, Egle Sigler egle.sigler@rackspace.com wrote:

Hello Everyone,

Thanks to everyone that filled out the time surveys and provided feedback on IRC/phone meetings. For now, we will try IRC meetings, alternating weeks at different times.

Odd week, starting tomorrow: 15:00 UTC or 10 AM CST
Even week, starting next week: 01:00 UTC or 8 PM CST

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.2

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-defcore

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.2 Wednesday 10 AM CST / 15:00 UTC

Hello Everyone,

Thanks to everyone that filled out the time surveys and provided feedback on IRC/phone meetings. For now, we will try IRC meetings, alternating weeks at different times.

Odd week, starting tomorrow: 15:00 UTC or 10 AM CST
Even week, starting next week: 01:00 UTC or 8 PM CST

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.2

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.3 Meeting Invite Wed. 8 PM CST/Thursday 01:00 UTC

Hello Everyone,

This week we are having our meeting at 8 PM CST (Wednesday) / 01:00 UTC (Thursday). We are trying out the alternating meeting times to better accommodate people in different time zones. If we do not get enough participation at this time slot, we will re-evaluate the time.

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.3

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Minutes from last week's meeting: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-03-15.01.html
Minutes (text): http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-03-15.01.txt
Log: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-03-15.01.log.html

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Notes from last meeting:

Summary

  • First IRC meeting!
  • Plan for mid-cycle meetup (discuss agenda, location and timing)
  • Discuss v1.3 schema change (will close in 48 hours)
  • Plan to subdivide capabilities in .next json
  • Kick off "when to flag tests" discussion - will submit patch with ideas
  • Start long term discussion about adding Interop focused tests

Agenda for next to save clicking the link....

Agenda,

  • agenda
  • mid-cycle planning
  • v1.3 schema
  • capabilities subdivisions into v1.3
  • review hacking file (flag tests)
  • strategic test planning
  • capabilities review (or planning for it)
  • review of backlog

On 06/09/2015 12:14 PM, Egle Sigler wrote:
Hello Everyone,

This week we are having our meeting at 8 PM CST (Wednesday) / 01:00
UTC (Thursday). We are trying out the alternating meeting times to
better accommodate people in different time zones. If we do not get
enough participation at this time slot, we will re-evaluate the time.

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.3

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client:
http://webchat.freenode.net/?channels=openstack-meeting-4

Minutes from last week’s meeting:
http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-03-15.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-03-15.01.txt
Log:
http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-03-15.01.log.html

Meetbot quick reference guide:
http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Voting for DefCore mid-cycle date and time

Hello Everyone,
We are planing on having 2 day DefCore mid-cycle soon, and have narrowed down to 3 possible times/locations. Please select all options that would work for you.http://doodle.com/karnnaxfrefumneb
There is a forth option for those that would like to attend, but will not travel. We will do our best to enable remote participation.

Let me know if you have any questions or concerns.
-Egle _______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Way to use "OpenStack Powered" mark

Hi,

I have a question about the way to use "OpenStack Powered" mark.
Maybe this question is stupid, and sorry if so.

According to https://www.openstack.org/news/view/59/two-milestones-mark-the-beginning-of-the-openstack-interoperability-era
, 14 companies have already gotten the mark by passing the
interoperability testing.
Our company will provide system integration services for building
private cloud environments for customers.
These clouds will be based on OpenStack distributions which have
already gotten the mark.
In this situation, can we use "OpenStack powered" mark when
advertising our integration services?
Or do we need to pass the interoperability testing by ourselves?

Thanks
Ken'ichi Ohmichi


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hello Ken'ichi Ohmichi,
I think to use OpenStack logo/trademark for commercial purposes you have to have a signed agreement with the OpenStack Foundation. I would suggest you contact them directly.
Here is the branding guide: http://www.openstack.org/brand/Interop website: http://www.openstack.org/brand/interop/
To view a list of companies
Thank you,Egle

Date: Thu, 11 Jun 2015 17:57:07 +0900
From: ken1ohmichi@gmail.com
To: defcore-committee@lists.openstack.org; masayuki.igawa@gmail.com
Subject: [OpenStack-DefCore] Way to use "OpenStack Powered" mark

Hi,

I have a question about the way to use "OpenStack Powered" mark.
Maybe this question is stupid, and sorry if so.

According to https://www.openstack.org/news/view/59/two-milestones-mark-the-beginning-of-the-openstack-interoperability-era
, 14 companies have already gotten the mark by passing the
interoperability testing.
Our company will provide system integration services for building
private cloud environments for customers.
These clouds will be based on OpenStack distributions which have
already gotten the mark.
In this situation, can we use "OpenStack powered" mark when
advertising our integration services?
Or do we need to pass the interoperability testing by ourselves?

Thanks
Ken'ichi Ohmichi


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Question about "YYYY.MM" directories

Hi everyone,

Excuse me, I have a humble question about DefCore.

I'm worried about which commit of tempest do I use for "2015.05.json".
When will the "2015.05" directory be made in github?
I couldn't find the document about "YYYY.MM" directories cycle.

Regards,
Honjo


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Running Tempest from head is probably the best way to start out. A number of bugs
have been addressed in the last month or two, and you will likely pass more tests by
drawing from more recent work.

Thanks,
Chris Hoge
Interop Engineer
OpenStack Foundation

On Jun 15, 2015, at 5:21 AM, Rikimaru Honjo honjo.rikimaru@po.ntts.co.jp wrote:

Hi everyone,

Excuse me, I have a humble question about DefCore.

I'm worried about which commit of tempest do I use for "2015.05.json".
When will the "2015.05" directory be made in github?
I couldn't find the document about "YYYY.MM" directories cycle.

Regards,
Honjo


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.4 Meeting Invite Wed. 10 AM CST/ 15:00 UTC

Hello Everyone,

Last week's meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-11-01.02.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.4

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Proposal: Maximum Environment Knowledge to Test Minimum Interoperability

DefCore has two technical conditions for a test to be graded as a
required capability against the DefCore criteria. It needs to access
public endpoints, and not require administrator credentials. While this
helps to ensure that the required APIs and capabilities are actually
callable by any user, it can implicitly place a burden on the end user to
have a number of resources that may not actually be available to them.
For example, API tests that check for tenant isolation require users across
multiple tenants[1]. Tests also may require the implicit existence of
resources such at tenant networks and machine images if administrator
access is not available. Currently the DefCore tests can be run against a
public cloud without administrator access, but it implicitly requires the
existence of

  1. An OpenStack endpoint.
  2. Two guests in seperate tenants.
  3. Two independent machine images.
  4. One public network, or two isolated tenant networks.

The goal of this proposal is to explicitly define a maximum set of
resources that can be used to test interoperability as part of the
DefCore standard. Only tests that use at most the defined resources would
be graded against the DefCore criteria. Ideally, this maximum set of
resources would be an OpenStack cloud endpoint and non-admin user
credentials to access it. However, there are resources that are required
to have an operating cloud, but may need to be set up either by the
provider if admin credentials are needed, or by the user beforehand. As
previously mentioned, two critical resources are a network and a machine
image.

My list of proposed resources is:
1. OpenStack Endpoint: This public API endpoint to test against.
2. Guest user credentials: Login credentials for the endpoint.
3. Network ID: The ID or name of a network available to the user to
attach virtual machines to.
4. Image ID: The ID or name of a bootable machine image.

That list is smaller than the implicit list required by Tempest, and
represents the most basic resources needed for launching generic and
portable applications across OpenStack clouds. By testing APIs against
this standard, we can help to establish a set of common calls that will
be used as a foundation for portable applications that run on top of
OpenStack. One of the benefits of this approach would allow users to
quickly configure Tempest to test their clouds using a tool like the now
abandoned TCup, or even a web service that can automatically test clouds
remotely.

The maximum resources aren't intended to fully test the correctness of an
OpenStack cloud. Indeed, one might want to ensure that a cloud is
providing tenant isolation and resource protection. Nothing precludes
this testing, and DefCore should continue to encourage collection of and
reporting on all API test results to identify widely deployed
capabilities.

In support of interoperability, DefCore and Tempest should also map tests
to API calls. While a DefCore capability tells you what functionlity
exists in a cloud, it provides no guidance on how to access that
functionality. Focusing on tests rather than APIs gave us an easy way to
bootstrap the testing process, but at the expense of obfuscating the path
for application developers to know which APIs match to capabilities for
building portable applications.

My proposal is to define these resources as a future standard and begin
by identifying existing tests that meet the standard. Then begin to phase
out tests that don't meet the standard by working with the QA team to
write new tests to match the capabilities, and drop required capabilites
that don't meet the standard. One year should be sufficient for a
complete and non-disruptive transition.

-Chris

[1] For example, testcreatekeypairinanaltusertenant


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi Chris,

I've added some comments and feedback in line. I'm still learning the ropes so if I'm asking questions that may have already been discussed and resolved, my appologies:

DefCore has two technical conditions for a test to be graded as a required capability >>against the DefCore criteria. It needs to access public endpoints, and >>not require administrator credentials.

At least for Compute, the "admin"-ness of a capability is set in the policy configuration of the service (http://docs.openstack.org/juno/config-reference/content/section_nova-policy.json.html). Given this flexibility, who then becomes the person to judge what functionality is expected to be admin only? Would this be the responsiblity of the individual PTLs or another group?

While this helps to ensure that the required APIs and capabilities are actually callable by >>any user, it can implicitly place a burden on the end user to have a number of resources >>that may not actually be available to >>them.
For example, API tests that check for tenant isolation require users >>across
multiple tenants[1].

The test in question is part of the authorization suite of tests. Does security testing fall under the umbrella of interoperability?

Tests also may require the implicit existence >>of
resources such at tenant networks and machine images if administrator
access is not available. Currently the DefCore tests can be run against a public cloud >>without administrator access, but it implicitly requires the existence >>of 1. An OpenStack endpoint. 2. Two guests in seperate tenants. 3. Two independent >>machine images. 4. One public network, or two isolated tenant networks.

The networks portion concerns me because these are all assumptions that are built into the tests, which may or may not reflect realistic environments. If the capability being tested requires a network, should it matter whether it is a public or isolated network? If the type of network has no bearing on the outcome of test, wouldn't a test that auto-configures itself based on discovery be more reliable?

The goal of this proposal is to explicitly define a maximum set of resources that can be >>used to test >>interoperability as part of the DefCore standard. Only tests that use at most the defined >>resources would be graded against the DefCore criteria. Ideally, this maximum set of >>resources would be an OpenStack cloud endpoint and non-admin user credentials to >>access it. However, there are resources that are required to have an operating cloud, but >>may need to be set up either by the provider if admin credentials are needed, or by the >>user beforehand. As previously mentioned, two critical resources are a network >>and a machine image. My list of proposed resources is: 1. OpenStack Endpoint: This >>public API endpoint to test against. 2. Guest user credentials: Login credentials for the >>endpoint. 3. Network ID: The ID or name of a network available to the user to attach >>virtual machines to. 4. Image ID: The ID or name of a bootable machine image.

I really like the idea of coming up with a minimum set of data required for any DefCore selected test as it provides a guideline for what assumptions the test can make.
The one part that I would add is that if you already have a valid endpoint and user credentials, the rest of the data is auto-discoverable by querying the public API for the related services as that user. I keep coming back to the idea of auto-discoverability because it has the possibility of greatly reducing friction and pushback due to fustration configuring the test suite.

While a DefCore capability tells you what functionlity exists in a cloud, it provides no >>guidance on how to access that functionality. Focusing on tests rather than APIs gave us >>an easy way to bootstrap >>the testing process, but at the expense of obfuscating the path for application developers >>to know which APIs match to capabilities for
building portable applications. My proposal is to define these resources as a future >>tandard and begin by identifying existing tests that meet the standard. >>Then begin to phase out tests that don't meet the standard by working with the QA team >>to write new tests to match the capabilities, and drop required capabilites that don't meet >>the standard.

My challenge with this portion is that we're trusting the tests, which exist outside of DefCore, to be atomic in nature and that they stay that way. Without constant manual reviews, it would seem like some type of DefCore gating job would be more efficient to ensure only the expected application paths are being traversed. This also creates a burden on functional testers to work within the boundaries of both application testing and compatibility testing, which I could see leading to duplicate test development to meet the requirements both for their project team and compatibility testing as well.

My other concern is that unit test based tests are not always the best tool to describe an expected behavior or experience. Their strong suite is validate very specific outcomes, which do not always translate well back to a user experience.

If the goal is to have a set of tests that clearly define expectations of behavior, I could see behavior driven development style of testing being much more explicit about what functionality is being tested and what the expected outcomes should be ( http://heynemann.github.io/pyvows/ and http://pythonhosted.org/behave/ are runners I've worked with in the past). I've spent a lot of time over the past several years trying to shoehorn rich, descriptive tests into unittest-style frameworks, and at the best it works just good enough. I'm not suggesting BDD as a solution, but more to better understand the problem that is trying to be solved.

Thanks,

Daryl


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Future of the Nova API

Hi,

I think its worth sharing the news on our current plans for the future
of the Nova API.

So Nova's v2 API is our first API (its v1.1 that was renamed, based on
the API for the Rackspace First Gen Cloud offering (aka slicehost)).

A few years back, we started to create v3 API, but a long while after
realised we would never be able to quickly delete the v2 API, so we
killed v3, and after much hard thinking we agreed a way to more easily
evolve the v2 API (re-using lots of the code from the v3 effort), in a
way thats more interoperable, and will better support the rich
ecosystem around the Nova API. At the end of kilo we finally have the
initial code passing all tempest tests, but there is a lot more work
to get over the finish line on this effort.

For more details see this awesome blog on the topic:
https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/

Let me know if there are any questions. I am happy to answer them.

Thanks,
John


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Image APIs in Glance and Nova

Hi,

So this was raised in the cross project meeting, and thank you for that.

I keep mentioning use cases, so here we go...
* create from cloud base image for ubuntu 12.04
* above but with boot from volume
* create a snapshot
* download snapshot
* upload image into another openstack cloud
* boot server from uploaded image

Now, at a higher level:
* user does above using custom script for Cloud A and Cloud B
* user keeps to just the APIs that are defcore tested
* user gets access to Cloud C and Cloud D
* user wants to point script at new clouds, and everything should just work

So I think thats where we want to be. Now lets dig in...

To list images, the user could:
* use nova to list images (stable, but project wants to delete it)
* use glance v1 (should never be exposed to end users, was designed as
internal only API)
* use glance v2 (only just released, not really deployed anywhere)

For the


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

For the... ?

Is there more? :)

On Wed, Jun 17, 2015 at 10:56 AM, John Garbutt john@johngarbutt.com wrote:
Hi,

So this was raised in the cross project meeting, and thank you for that.

I keep mentioning use cases, so here we go...
* create from cloud base image for ubuntu 12.04
* above but with boot from volume
* create a snapshot
* download snapshot
* upload image into another openstack cloud
* boot server from uploaded image

Now, at a higher level:
* user does above using custom script for Cloud A and Cloud B
* user keeps to just the APIs that are defcore tested
* user gets access to Cloud C and Cloud D
* user wants to point script at new clouds, and everything should just work

So I think thats where we want to be. Now lets dig in...

To list images, the user could:
* use nova to list images (stable, but project wants to delete it)
* use glance v1 (should never be exposed to end users, was designed as
internal only API)
* use glance v2 (only just released, not really deployed anywhere)

For the


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.5 Meeting Invite Wed. 8 PM CST/Thursday 01:00 UTC

Hello Everyone,

This week we are having our meeting at 8 PM CST (Wednesday) / 01:00 UTC (Thursday). We are trying out the alternating meeting times to better accommodate people in different time zones. If we do not get enough participation at this time slot, we will re-evaluate the time.

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.5

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Minutes from last meeting: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-17-15.01.html

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore mid-cycle save the date

Hello Everyone,

We are planning on having DefCore mid-cycle in Austin, TX on July 29-30th. Right now we do not have the details for exact location in Austin, but the dates should be firm.
We will work on accommodating remote participation as well.

More details to come as the date gets closer.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] QA addresses one of the major DefCore issues

Yay!

-----Original Message-----
From: David Kranz [mailto:dkranz@redhat.com]
Sent: Thursday, June 18, 2015 11:14
To: OpenStack Development Mailing List
Subject: [openstack-dev] [qa] Status of account creds in the [identity] section of tempest.conf

We had a discussion about this at the qa meeting today around the
following proposal:

tl;dr The test accounts feature provides the same functionality as the
embedded credentials. We should deprecate the account information
embedded directly in tempest.conf in favor of test-accounts, and remove
those options at the beginning of the M cycle. We would also rework the
non-isolated jobs to use parallel test accounts, with and without admin
creds. Starting now, new features such as cleanup and tempest config
will not be required to work well (or at all) if the embedded creds are
used instead of test accounts.

We have (at least) three use cases that are important, and we want
tempest to work well with all of them, but that means something
different in each case:

  1. throw-away clouds (ci, gate)
  2. test clouds
  3. production clouds

For (1), the most important thing is that failing tests not cause false
negatives in other tests due to re-using a tenant. This makes tenant
isolation continue to be a good choice here, and requiring admin is not
an issue. In a perfect world where tempest never left behind any
resources regardless of an error at any line of code, test accounts
could be used. But we are probably a long way from that.

For (3), we cannot use admin creds for tempest runs, and test accounts
with cleanup allow parallel execution, accepting the risk of a leak
causing a false negative. The only way to avoid that risk is to stamp
out all leak bugs in tempest.

For (2), either isolation or test accounts with cleanup can be used

The tempest.conf values are not used in any of these scenarios. Is there
a reason they are needed for anything?

-David


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


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Expanding identity-auth capability

Hi,

Right now, "identity-auth" capability has only 2 approved tests. I'm
working on a task to investigate the Identity API and expand its coverage
for non-admin user. As a result, we already have a couple patches on review:

Expanded assertion in testcreatetoken for keystone v2, v3

https://review.openstack.org/#/190123
https://review.openstack.org/#/c/190123/

Added testlisttenant non-admin test to test_tokens.py
https://review.openstack.org/#/192709
https://review.openstack.org/#/c/192709

Any help in furtherance of these tests will be appreciated)

Surprisingly, I have found, that no more positive testcases for base
Identity API can be added without admin rights. It can be considered as an
issue because most of Identity API stays uncovered in this case. Does
anyone have thoughts related to this topic?

From my side, I can say, that this issue can be resolved if refstack user
has admin rights in his domain. But I don't have any ideas, does such
solution is appropriate for defcore/refstack.

Also, I found that we can add non-admin tests for Identity API EC2
extension:

  • non-admin user can create ec2-credentials;

  • non-admin user can get created ec2-credentials;

  • non-admin user can list created ec2-credentials;

  • non-admin user can delete created ec2-credentials;

  • non-admin user can update own password.

Does this API hit defcore/refstack interests?

One another option is to add negative tests for non-admin user:

  • non-admin user cannot create/delete a user/role/endpoint/service/tenant;

  • non-admin user cannot list users/roles.

Have these tests sense for defcore/refstack projects?

--
Best regards,

Ievgeniia Zadorozhna
QA Engineer
Mirantis Inc

[image: OSSV-signature-2015.gif] http://www.openstacksv.com/
Follow the OpenStack Silicon Valley event on Twitter
https://twitter.com/OpenStackSV


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi,

I've already started working on creating tests for Identity API EC2
extension and made a patch set: https://review.openstack.org/#/c/194584/.
Please feel free to give some ideas or feedback)
Thank You!

2015-06-22 17:11 GMT+03:00 Ievgeniia Zadorozhna izadorozhna@mirantis.com:

Hi,

Right now, "identity-auth" capability has only 2 approved tests. I'm
working on a task to investigate the Identity API and expand its coverage
for non-admin user. As a result, we already have a couple patches on review:

Expanded assertion in testcreatetoken for keystone v2, v3

https://review.openstack.org/#/190123
https://review.openstack.org/#/c/190123/

Added testlisttenant non-admin test to test_tokens.py
https://review.openstack.org/#/192709
https://review.openstack.org/#/c/192709

Any help in furtherance of these tests will be appreciated)

Surprisingly, I have found, that no more positive testcases for base
Identity API can be added without admin rights. It can be considered as an
issue because most of Identity API stays uncovered in this case. Does
anyone have thoughts related to this topic?

From my side, I can say, that this issue can be resolved if refstack user
has admin rights in his domain. But I don't have any ideas, does such
solution is appropriate for defcore/refstack.

Also, I found that we can add non-admin tests for Identity API EC2
extension:

  • non-admin user can create ec2-credentials;

  • non-admin user can get created ec2-credentials;

  • non-admin user can list created ec2-credentials;

  • non-admin user can delete created ec2-credentials;

  • non-admin user can update own password.

Does this API hit defcore/refstack interests?

One another option is to add negative tests for non-admin user:

  • non-admin user cannot create/delete a user/role/endpoint/service/tenant;

  • non-admin user cannot list users/roles.

Have these tests sense for defcore/refstack projects?

--
Best regards,

Ievgeniia Zadorozhna
QA Engineer
Mirantis Inc

[image: OSSV-signature-2015.gif]
Follow the OpenStack Silicon Valley event on Twitter
https://twitter.com/OpenStackSV

--
Best regards,

Ievgeniia Zadorozhna
QA Engineer
Mirantis Inc

[image: OSSV-signature-2015.gif]
Follow the OpenStack Silicon Valley event on Twitter


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Expanding compute capabilities

Hi,

I am in progress of investigating the Compute API for expanding the
coverage of api/compute tests for non-admin user and creating more tests.
After the investigation of Compute API and existing tests in tempest, as a
result, we can add some tests to following capabilities:

  • compute-volume:

    • test list snapshots;
    • test list details for snapshots;
    • test create snapshot;
    • test delete snapshot;
    • test show snapshot.
  • compute-servers:

    • test get spice console (if it is enabled on public clouds).

Also, since users can create networks in their own tenants, I want to
propose to add in api/compute/testtenantnetworks.py the following tests
that use “os-tenant-networks” compute extension in the API requests:
* test create project network;
* test delete project network.

The current status of api/compute/testtenantnetworks.py tests suite is
that it has only 2 tests (listtenantnetworks, gettenantnetwork), so if
users can manipulate their networks we can expand the coverage by adding
more actions with tenant networks.
These tests don't belong to any capability right now so maybe new
capability should be created.

Please share your thoughts about, which of these tests can be useful for
defcore project?

I'll continue looking for more non-admin compute API requests that are not
covered in tempest yet. If you have any additional information or ideas
please feel free to share.

--
Best regards,

Ievgeniia Zadorozhna
QA Engineer
Mirantis Inc

[image: OSSV-signature-2015.gif] http://www.openstacksv.com/
Follow the OpenStack Silicon Valley event on Twitter
https://twitter.com/OpenStackSV


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi Levgeniia,

If you’re not already familiar with DefCore’s Core Criteria, I’d suggest having a look at:

https://github.com/openstack/defcore/blob/master/process/CoreCriteria.rst

That should give you a better picture of what capabilities would make good candidates for Core. It might be useful for you to step through some items you think are candidates for Core and do a mock scoring of each one so you can see for yourself how they stack up against those criteria. So, for example: you mention the spice console test. I find that it’s often useful to do a quick “first pass” using the four criteria groups, and then drill into each group’s individual criteria if things look promising. If we were to consider including this capability in Core, we’d ask if it:

1.) Shows Proven Usage: probably not. Specifically this would likely fall down on the “Widely Deployed” criteria. You mentioned that you had questions about whether it was enabled in public clouds, and moreover it’s only supported on KVM (x86) and QEMU according to the Nova hypervisor support matrix [1], so it’s very unlikely to meet the bar here.

2.) Aligns With Technical Direction: probably not. While it’s something nova has supported for some time and will likely continue to support, the Nova community has made SPICE a “choice” of console implementation according to the hypervisor support matrix [1]. That is, Nova backends are required to support some form of console access and SPICE is merely one of those options (other implementations like a serial console are possible as well). Thus, the technical community doesn’t seem to feel that SPICE support is important for all Nova implementations.

3.) Plays Well With Others: Maybe. It is documented. There is a degree of discoverability in that you can at least specify in a POST request that you want a spice console, although it’s sort of a try-catch situation. It wasn’t required in the past (but that’s ok; we have to introduce new capabilities sometime).

4.) Takes A System View: probably not. Other tests that are required are very unlikely to require a working SPICE console today, and similar functionality can be had from other console implementations.

So based on that quick pass at scoring I would imagine that the get spice console test is probably not a good candidate for DefCore. If some of these had looked promising I might take more time to evaluate individual criteria within those four groups, but in this case it seems pretty clear cut. I would suggest that you do a quick pass on the other items you’ve listed here to see how they stack up—that may help prune your list a bit.

[1] http://docs.openstack.org/developer/nova/support-matrix.html#console_spice

At Your Service,

Mark T. Voelker

On Jun 23, 2015, at 6:42 AM, Ievgeniia Zadorozhna izadorozhna@mirantis.com wrote:

Hi,

I am in progress of investigating the Compute API for expanding the coverage of api/compute tests for non-admin user and creating more tests.
After the investigation of Compute API and existing tests in tempest, as a result, we can add some tests to following capabilities:

  • compute-volume:

    • test list snapshots;
    • test list details for snapshots;
    • test create snapshot;
    • test delete snapshot;
    • test show snapshot.
  • compute-servers:

    • test get spice console (if it is enabled on public clouds).

Also, since users can create networks in their own tenants, I want to propose to add in api/compute/testtenantnetworks.py the following tests that use “os-tenant-networks” compute extension in the API requests:
* test create project network;
* test delete project network.
The current status of api/compute/testtenantnetworks.py tests suite is that it has only 2 tests (listtenantnetworks, gettenantnetwork), so if users can manipulate their networks we can expand the coverage by adding more actions with tenant networks.
These tests don't belong to any capability right now so maybe new capability should be created.

Please share your thoughts about, which of these tests can be useful for defcore project?

I'll continue looking for more non-admin compute API requests that are not covered in tempest yet. If you have any additional information or ideas please feel free to share.

--
Best regards,

Ievgeniia Zadorozhna
QA Engineer
Mirantis Inc

Follow the OpenStack Silicon Valley event on Twitter


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Looking at capabilities subdivisions - MISSING TESTS?

All,

I was looking at the capabilities subdivision lists [1] to see if I
could get that done before the meeting tomorrow (which I will miss).

In reviewing the first item, I found that the spreadsheet has a lot more
tests than we currently are tracking in the guideline.

For example, "compute-auth" has 4 tests currently, but the 10 new
divisions [2] have 28.

That presents some items for consideration
1. we have a lot more tests coming that will impact users of the
guideline (RE potential flags)
2. it will require automation to make the change effectively (as Chris
Hoge pointed out)
3. I don't know how to track which tests we have chosen to omit based on
D302
4. we'll need people to review this pretty carefully!

Even if we don't subdivide the capabilities, we will need to bring in
these tests.

Rob

Notes:

[1]
https://docs.google.com/spreadsheets/d/15Fkt2n95WPPe7CYH-0WIKz3dhMeW3FW2gl5aSlamEeY/edit#gid=561264013
[2] compute-auth-[change | create | delete | get | list | reboot |
rebuild | resize | set | update ]


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Subdivision of capabilities patch:

https://review.openstack.org/#/c/194975/1 https://review.openstack.org/#/c/194975/1

Work in progress. It only captures existing tests for next, reorganizing them.

On Jun 23, 2015, at 9:46 PM, Rob Hirschfeld rob@zehicle.com wrote:

All,

I was looking at the capabilities subdivision lists [1] to see if I could get that done before the meeting tomorrow (which I will miss).

In reviewing the first item, I found that the spreadsheet has a lot more tests than we currently are tracking in the guideline.

For example, "compute-auth" has 4 tests currently, but the 10 new divisions [2] have 28.

That presents some items for consideration
1. we have a lot more tests coming that will impact users of the guideline (RE potential flags)
2. it will require automation to make the change effectively (as Chris Hoge pointed out)
3. I don't know how to track which tests we have chosen to omit based on D302
4. we'll need people to review this pretty carefully!

Even if we don't subdivide the capabilities, we will need to bring in these tests.

Rob

Notes:

[1] https://docs.google.com/spreadsheets/d/15Fkt2n95WPPe7CYH-0WIKz3dhMeW3FW2gl5aSlamEeY/edit#gid=561264013
[2] compute-auth-[change | create | delete | get | list | reboot | rebuild | resize | set | update ]


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.6 Meeting Invite Wed. 10 AM CST/ 15:00 UTC

Hello Everyone,

Last meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-06-25-01.00.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.6

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Please confirm DefCore mid-cycle attendance

Hello Everyone,

We need to know how many people are planning to attend DefCore mid-cycle in Austin, TX, July 29-30th.
Please fill out the doodle http://doodle.com/2k9miynqxmnfzpta

Thank you very much!

-Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore mid-cycle info and dietary restrictions poll

Update: IBM is very kind to host us at their Austin office, and they will also provide lunch on both days.

Please fill out this poll for any dietary restrictions:
http://doodle.com/gsdq767e7chmc8in

Location:
We will be in building 908 at the IBM complex in North Austin.

IBM
11501 Burnet Rd
Austin, TX 78758

IBM host: Vince Brunseen

Agenda will follow, but for planning purposes, plan to start each day at 9AM CST time.

Thank you,

Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore MidCycle Agenda Planning Meeting Invitation Thursday, July 2, 3 PM CST

Hello Everyone,

To prepare for the upcoming mid cycle, we need to discuss the agenda. If you can, please join us at 3 PM CST via join.me or call in.
Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.MidCycle

Join the meeting: https://join.me/956-223-881

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me apphttps://join.me/app and enter meeting code: 956-223-881

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Atlanta, GA +1.404.801.3225
United States - Camden, DE +1.302.202.5900
United States - Detroit, MI +1.734.746.0035
United States - Hartford, CT +1.860.970.0010
United States - Los Angeles, CA +1.213.226.1066
United States - New York, NY +1.646.307.1990
United States - San Francisco, CA +1.415.655.0381
United States - Saugus, MA +1.781.666.2350
United States - Tampa, FL +1.813.769.0500
United States - Washington, DC +1.202.602.1295
Access Code 956-223-881#

Other international numbers availablehttps://join.me/intphone/956223881/0

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required.

Start time by time zoneshttps://join.me/timezone/1435867200000/1435870800000


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Mid-Cycle Day 1

IBM is very kind to host us at their Austin office, and they will also provide lunch on both days.

Location:
We will be in building 908 at the IBM complex in North Austin.

IBM
11501 Burnet Rd
Austin, TX 78758

IBM host: Vince Brunseen
Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.MidCycle

Etherpad has descriptions for each item as well, if you would like more information on each agenda item.

Day 1 Agenda

  • 9:30 am Intros / Review
  • General Interop & Relationships
  • Foundation Update
  • 12:30 Lunch
  • Resolving "AND vs OR" questions for interop
  • RefStack Discussion
  • How do you promote a component into the platform (missing process?)
  • Prep-Day 2: goals for synch-meeting
  • 6 pm wrap up
  • Team Dinner - Rob to make reservation

Day 2 Agenda

Updated building.

IBM is very kind to host us at their Austin office, and they will also provide lunch on both days.

Location:
We will be in building 908 at the IBM complex in North Austin.

IBM
11501 Burnet Rd
Austin, TX 78758

IBM host: Vince Brunseen, if any issues, call him: 512-773-3435
Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.MidCycle

Etherpad has descriptions for each item as well, if you would like more information on each agenda item.

Day 1 Agenda

  • 9:30 am Intros / Review
  • General Interop & Relationships
  • Foundation Update
  • 12:30 Lunch
  • Resolving "AND vs OR" questions for interop
  • RefStack Discussion
  • How do you promote a component into the platform (missing process?)
  • Prep-Day 2: goals for synch-meeting
  • 6 pm wrap up
  • Team Dinner - Rob to make reservation

Day 2 Agenda

[OpenStack-DefCore] DefCore Mid-Cycle Day 2

IBM is very kind to host us at their Austin office, and they will also provide lunch on both days.

Location:
We will be in building 908 at the IBM complex in North Austin.

IBM
11501 Burnet Rd
Austin, TX 78758

IBM host: Vince Brunseen
Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.MidCycle

Etherpad has descriptions for each item as well, if you would like more information on each agenda item.

Day 2 Agenda

  • 9:30 am Review Agenda
  • Glance & Nova w/ PTLs
  • Networking Interop w/ PTLs
  • 12:30 Lunch
  • Patch Backlog Catch-up
  • Strategic Test Planning
  • 2016.01 Planning
  • 6 pm wrap up

Previous day agenda:

  • 9:30 am Intros / Review
  • General Interop & Relationships
  • Foundation Update
  • 12:30 Lunch
  • Resolving "AND vs OR" questions for interop
  • RefStack Discussion
  • How do you promote a component into the platform (missing process?)
  • Prep-Day 2: goals for synch-meeting
  • 6 pm wrap up
  • Team Dinner - Rob to make reservation

    Defcore-committee mailing list
    Defcore-committee@lists.openstack.org
    http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Updated building.

IBM is very kind to host us at their Austin office, and they will also provide lunch on both days.

Location:
We will be in building 904 at the IBM complex in North Austin.

IBM
11501 Burnet Rd
Austin, TX 78758

IBM host: Vince Brunseen if any issues, call him: 512-773-3435
Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.MidCycle

Etherpad has descriptions for each item as well, if you would like more information on each agenda item.

Day 2 Agenda

  • 9:30 am Review Agenda
  • Glance & Nova w/ PTLs
  • Networking Interop w/ PTLs
  • 12:30 Lunch
  • Patch Backlog Catch-up
  • Strategic Test Planning
  • 2016.01 Planning
  • 6 pm wrap up

Previous day agenda:

  • 9:30 am Intros / Review
  • General Interop & Relationships
  • Foundation Update
  • 12:30 Lunch
  • Resolving "AND vs OR" questions for interop
  • RefStack Discussion
  • How do you promote a component into the platform (missing process?)
  • Prep-Day 2: goals for synch-meeting
  • 6 pm wrap up
  • Team Dinner - Rob to make reservation

    Defcore-committee mailing list
    Defcore-committee@lists.openstack.org
    http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.7 Meeting Invite Wed. 8 PM CST/Thursday 01:00 UTC

Hello Everyone,

This week we are having our meeting at 8 PM CST (Wednesday) / 01:00 UTC (Thursday). We are trying out the alternating meeting times to better accommodate people in different time zones. If we do not get enough participation at this time slot, we will re-evaluate the time.

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.7

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Minutes from last meeting: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-07-01-15.00.html
Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Is auth-token test "required" in "2015.05"?

Hello Everyone,

I'm worried about the definition of Defcore.

Following page says auth-token test is required for "Compute" in "2015.05".
http://www.openstack.org/brand/interop/

But, auth-token test for "Compute" is "advisory" in "2015.05.json" on github.

Which one is correct?
(Is above page old?)

  • quote from "2015.05.json"
    > "components": {
    > "compute": {
    > "required": [
    > "identity-auth",
    > "compute-auth",
    > "compute-flavors",
    > "compute-images",
    > "compute-instance-actions",
    > "compute-keypairs",
    > "compute-quotas",
    > "compute-servers",
    > "compute-volume",
    > "images-v2"],
    > "advisory": [
    > "auth-token",

Regards, Honjo


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Honjo,

The github version is the approved and authoritative document. Thanks
for bringing this to our attention.

It should be promoted to required for the 2015.07 guideline.

Rob

On 07/07/2015 09:11 PM, Rikimaru Honjo wrote:
Hello Everyone,

I'm worried about the definition of Defcore.

Following page says auth-token test is required for "Compute" in "2015.05".
http://www.openstack.org/brand/interop/

But, auth-token test for "Compute" is "advisory" in "2015.05.json" on github.

Which one is correct?
(Is above page old?)

  • quote from "2015.05.json"
    > "components": {
    > "compute": {
    > "required": [
    > "identity-auth",
    > "compute-auth",
    > "compute-flavors",
    > "compute-images",
    > "compute-instance-actions",
    > "compute-keypairs",
    > "compute-quotas",
    > "compute-servers",
    > "compute-volume",
    > "images-v2"],
    > "advisory": [
    > "auth-token",
    Regards, Honjo


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Today's Meeting Notes

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.7

Minutes: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-07-09-01.00.html

A special thanks to those of you who signed up to help start working on identifying capability candidates for the next Guideline (see etherpad and meeting logs above); it’s great to have owners who can start working on things. We’ll talk more about that in Austin. See you there!

Thanks also to those of you who did (or are doing as I type this) reviews on the list of patches in the etherpad…we should be able to clear a chunk of the backlog before the midcycle.

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] New patch set for HACKING.rst file, aka change 188661

Patchset #11* is now available to review at your pleasure.

Here’s a good diff link: https://review.openstack.org/#/c/188661/9..11/HACKING.rst https://review.openstack.org/#/c/188661/9..11/HACKING.rst

—j

All, Please review. I'd like to get this patch landed on Wednesday.
On Jul 11, 2015 5:51 PM, "Jim Meyer" jim@geekdaily.org wrote:

Patchset #11* is now available to review at your pleasure.

Here’s a good diff link:
https://review.openstack.org/#/c/188661/9..11/HACKING.rst

—j

  • Please ignore patchset #10, in which I forget to fix links and make a
    copy-paste error.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Meeting Time Checkup

Hi folks,

As most of your recall, at the beginning of the Flag cycle we set a new meeting schedule so that we have alternating-week meeting times [1]. One of the goals of doing so was to invite more global participation in DefCore by having meeting times that were more doable for folks in various locales around the world. When we adopted that schedule, we set ourselves a checkpoint to review and see if the schedule was having it's intended effect or whether further tweaks might be necessary. Last week's meeting was that checkpoint, and we initiated the discussion there [2]. However we wanted to bring this up on the ML as well so folks unable to attend the meeting had a chance to chime in.

Generally speaking, the current alternating schedule seems to be working out reasonably well: we are seeing slightly less attendance during the 01:00 UTC slot but generally we've still got plenty enough of a quorum to get things done. We're often seeing a person or two from AsiaPac join during that slot. The 15:00 UTC slot seems better attended (and is generally more convenient for the North America-based folks) and we've also occasionally had an attendee or two from Europe during that time.

On the downside, we aren't really seeing a lot of routine attendance from individuals based outside of North America. That may be ok--over time we expect to see a lot of folks join us briefly to discuss a matter of importance to them like a flag or a problematic test and then drop off again, and right now the majority of those who are most involved in routine DefCore work happen to be based in North America. We want to be amenable and inviting to those occasional visitors and prospective new active members even if it makes for a slightly less convenient schedule for the majority of us. However if there are folks that would like to be routine participants that we're excluding somehow, now would be a good time to pipe up and let us know why the current times aren't working out for you.

Absent major objections, I think the general feeling is that the current schedule is working out well enough to keep.

[1] https://etherpad.openstack.org/p/DefCoreFlag.2
[2] https://etherpad.openstack.org/p/DefCoreFlag.7

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

All,

Now that we've started IRC and split times, I don't see that we have any
real way to reverse the practice without the perception of limiting
collaboration.

Both are workable for me; however, I find the IRC meetings less productive
and the split times been a net loss in participation. As co-chair I am
voicing this position to give others a chance to express similar opinions.

Rob

On Mon, Jul 13, 2015 at 9:46 AM, Mark Voelker mvoelker@vmware.com wrote:

Hi folks,

As most of your recall, at the beginning of the Flag cycle we set a new
meeting schedule so that we have alternating-week meeting times [1]. One
of the goals of doing so was to invite more global participation in DefCore
by having meeting times that were more doable for folks in various locales
around the world. When we adopted that schedule, we set ourselves a
checkpoint to review and see if the schedule was having it's intended
effect or whether further tweaks might be necessary. Last week's meeting
was that checkpoint, and we initiated the discussion there [2]. However we
wanted to bring this up on the ML as well so folks unable to attend the
meeting had a chance to chime in.

Generally speaking, the current alternating schedule seems to be working
out reasonably well: we are seeing slightly less attendance during the
01:00 UTC slot but generally we've still got plenty enough of a quorum to
get things done. We're often seeing a person or two from AsiaPac join
during that slot. The 15:00 UTC slot seems better attended (and is
generally more convenient for the North America-based folks) and we've also
occasionally had an attendee or two from Europe during that time.

On the downside, we aren't really seeing a lot of routine attendance
from individuals based outside of North America. That may be ok--over time
we expect to see a lot of folks join us briefly to discuss a matter of
importance to them like a flag or a problematic test and then drop off
again, and right now the majority of those who are most involved in routine
DefCore work happen to be based in North America. We want to be amenable
and inviting to those occasional visitors and prospective new active
members even if it makes for a slightly less convenient schedule for the
majority of us. However if there are folks that would like to be routine
participants that we're excluding somehow, now would be a good time to pipe
up and let us know why the current times aren't working out for you.

Absent major objections, I think the general feeling is that the current
schedule is working out well enough to keep.

[1] https://etherpad.openstack.org/p/DefCoreFlag.2
[2] https://etherpad.openstack.org/p/DefCoreFlag.7

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--
Rob


Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@rackn.com)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Capabilities Meetings for Flag Cycle

Folks,

As many of your recall, at the beginning of this cycle we elected to combine process and capabilities meetings. [1] We've recently discussed revisiting this as we get to the point in the Flag cycle where we begin identifying new capabilities in earnest. [2] This is largely because so far we haven't allocated any real time to identifying new capabilities in meetings, but the agendas have still been pretty packed.

We recently assigned some folks to begin investigating new candidates for scoring [3] and the tentative plan is to use gerrit for the majority of the work, then use meetings to discuss times that fail to gain consensus there. As such we will need to discuss meeting times and when we want to start holding these meetings. I’d suggest that we begin separate capabilities meetings following the midcycle meeting in Austin. That should provide folks with a little time to get oriented and either come with questions and/or comments ready. That will also give us time to work out a few mechanics about how to get candidates scored via Gerrit so we have a process to work from.

I’m open to meeting time suggestions. I’ll note that the as of now I don’t think we have any volunteers based outside North America for identifying scoring candidates [3], but I’d be happy to set up a rotating schedule similar to what we have for our other meetings to make these widely attendable as I imagine there will be good discussions and strong opinions at these things over time.

[1] https://etherpad.openstack.org/p/DefCoreFlag.2
[2] https://github.com/openstack/defcore/blob/master/doc/source/process/2015A.rst
[3] https://etherpad.openstack.org/p/DefCoreFlag.7

At Your Service,

Mark T. Voelker
OpenStack Architect
+1 (970) 203-4974


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Thank you Mark for setting this up. I think starting meetings after midcycle meetup is a great idea. I am available at different times throughout the week. Do you mind sending out a doodle for different time options?
Thanks,
Egle

From: mvoelker@vmware.com
To: defcore-committee@lists.openstack.org
Date: Mon, 13 Jul 2015 14:51:55 +0000
Subject: [OpenStack-DefCore] Capabilities Meetings for Flag Cycle

Folks,

As many of your recall, at the beginning of this cycle we elected to combine process and capabilities meetings. [1] We've recently discussed revisiting this as we get to the point in the Flag cycle where we begin identifying new capabilities in earnest. [2] This is largely because so far we haven't allocated any real time to identifying new capabilities in meetings, but the agendas have still been pretty packed.

We recently assigned some folks to begin investigating new candidates for scoring [3] and the tentative plan is to use gerrit for the majority of the work, then use meetings to discuss times that fail to gain consensus there. As such we will need to discuss meeting times and when we want to start holding these meetings. I’d suggest that we begin separate capabilities meetings following the midcycle meeting in Austin. That should provide folks with a little time to get oriented and either come with questions and/or comments ready. That will also give us time to work out a few mechanics about how to get candidates scored via Gerrit so we have a process to work from.

I’m open to meeting time suggestions. I’ll note that the as of now I don’t think we have any volunteers based outside North America for identifying scoring candidates [3], but I’d be happy to set up a rotating schedule similar to what we have for our other meetings to make these widely attendable as I imagine there will be good discussions and strong opinions at these things over time.

[1] https://etherpad.openstack.org/p/DefCoreFlag.2
[2] https://github.com/openstack/defcore/blob/master/doc/source/process/2015A.rst
[3] https://etherpad.openstack.org/p/DefCoreFlag.7

At Your Service,

Mark T. Voelker
OpenStack Architect
+1 (970) 203-4974


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.8 Meeting Invite Wed. 10 AM CST/ 15:00 UTC

Hello Everyone,

Last meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-07-09-01.00.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.8

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.9 Meeting Invite Wed. 10 AM CST/ 15:00 UTC

Hello Everyone,

During the last meeting, we discussed that there was not enough participation during the 1 UTC time slot. The defcore committee decided to move all the meetings to the 15:00 UTC on Wednesdays. We try to have all the discussions in Gerrit and IRC. If you would like to bring up something during the meeting but are not able to, please let me know and I will do so.

Last meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-07-15-15.00.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.9

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Dinner with OpenStack Board of Directors and the Foundation Staff

Hello Everyone,

If you are attending mid-cycle in Austin, you are also invited to join OpenStack Board of Directors and the Foundation Staff for dinner on July 28th, 5:00-6:30 pm.

Location: Banger's Sausage House & Beer Garden http://bangersaustin.com/
Following the dinner the local Austin user group folks will join us for an informal happy hour to mingle and toast OpenStack's 5th Birthday.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

?Hi All,

It looks like I am stuck at work for a little bit longer and I don't think I will make it up to Austin in time for the dinner tonight.

I will be there tomorrow for the midcycle.

?

Thanks,
Richard Hawkins
Software Developer - Cloud Files (OpenStack Swift)
Rackspace


From: Egle Sigler
Sent: Wednesday, July 22, 2015 4:00 PM
To: Egle Sigler; defcore-committee@lists.openstack.org
Subject: [OpenStack-DefCore] Dinner with OpenStack Board of Directors and the Foundation Staff
When: Tuesday, July 28, 2015 5:00 PM-6:30 PM.
Where: Location: Banger's Sausage House & Beer Garden http://bangersaustin.com/

Hello Everyone,

If you are attending mid-cycle in Austin, you are also invited to join OpenStack Board of Directors and the Foundation Staff for dinner on July 28th, 5:00-6:30 pm.

Location: Banger's Sausage House & Beer Garden http://bangersaustin.com/

Following the dinner the local Austin user group folks will join us for an informal happy hour to mingle and toast OpenStack's 5th Birthday.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Midcycle Info

We are starting now, here is google hangout:

https://plus.google.com/hangouts/_/vmware.com/defcore-sprintEtherpad: https://etherpad.openstack.org/p/DefCoreFlag.MidCycleIRC: #openstack-defcore
thanks,Egle

                  _______________________________________________

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

On Wed, Jul 29, 2015 at 9:56 AM, Egle Sigler ushnishtha@hotmail.com wrote:

We are starting now, here is google hangout:

https://plus.google.com/hangouts/_/vmware.com/defcore-sprint

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.MidCycle

IRC: #openstack-defcore

I can't seem to join the Hangout, did it by chance reach the 10 person
Hangout limit?

thanks,

Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Midcycle dinner tonight

The Blackfin at 6:30pm. The reservation is under Rob Hirschfeld.

http://blackfinnameripub.com/austin/
The Domain
11410 Century Oaks Terrace
Austin, TX 78758

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Re: [OpenStack-DefCore] [Product] Accelerating the Enterprise Adoption of OpenStack

Hi Shamail,

Thanks! I¹ll go ahead and include defcore. One point of clarification:
while having Scenarios to cover various ³reference architectures² is
incredibly valuable, I don¹t want to neglect permission to play Features.
To be a ³Cloud² there are certain things you must be able to do, and I¹m
not convinced that OpenStack is hitting all of them yet (especially in the
area of scale and elasticity). Clearly defining these and exposing them is
really important for us to prosper. Thanks for the helpful feedback. I¹m
looking forward to working with the WG.

Thanks,

Jesse

On 7/30/15, 2:59 PM, "Shamail" itzshamail@gmail.com wrote:

Hi Jesse,

The BDD looks like an interesting concept and it might help us identify
additional user stories for specific themes. I believe that this will
probably fall outside of scope for Product WG for now but, as mentioned,
the resulting user stories from the testing would definitely be something
Product WG would be interested in. The single source of truth for
OpenStack Powered Clouds is indeed DefCore but the focus is on
interoperability versus "reference architectures".

I'm glad you find this group and we definitely look forward to working
with you. Welcome to the team!

Summary workflow:

testing -> review output -> generate bug|user story|blueprint (depending
on the type of finding -> if the resulting change impacts testing of a
widely adopted service then possibly looking into DefCore capability.

Thanks,
Shamail

On Jul 30, 2015, at 11:29 AM, Jesse Cook jesse.cook@RACKSPACE.COM
wrote:

+nikhil

On 7/30/15, 11:28 AM, "Jesse Cook" jesse.cook@RACKSPACE.COM wrote:

+openstack-docs, brianr

On 7/30/15, 11:20 AM, "Jesse Cook" jesse.cook@RACKSPACE.COM wrote:

I recently discovered there was a product working group for OpenStack
and
joined the mailing list today. I've been trying to find a single
source
of truth for the expected behavior of OpenStack Powered Clouds. I've
seen
various things from def core and individual projects, but nothing so
far
that clearly illustrates the overarching expected behavior. I was
wondering if this was a good opportunity and the right place to
discuss
this.

I believe that the OpenStack community and the customers of OpenStack
Powered Clouds could really benefit from defining the expected
behaviors
(both permission to play and key value differentiators). One effective
way to do this is through a business / development process known as
Behavior Driven Development (BDD) [0]. I was wondering if we could use
something like this to document and test the expected performance of
an
OpenStack Cloud using the 1000 node clusters. A quick example of a
feature [1] might look like this:

Feature: Elasticity

In order to briefly leverage the power of the Cloud to do some work,
As an OpenStack Powered Cloud customer
I want to quickly provision a large number of servers, perform some
work, and then destroy them.

Scenario Outline: Build Bursts
Given cell(s)
And each cell has hosts
And each host has free memory
When I request VMs
And each VM will have of RAM
Then every VM will be ready in

  Examples: Performance Criteria
      | cells | hosts | memory | requests | size | time |
      |     1 |  1000 |   100G |     1000 |   2G | 600s |
      |    10 |   100 |   100G |     1000 |   2G | 600s |
      ...

...

[0] https://en.wikipedia.org/wiki/Behavior-driven_development
[1] http://pythonhosted.org/behave/tutorial.html#feature-files

Thanks,

Jesse J. Cook
Compute Team Lead

[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.r
ac
k
cdn.com/signatures/images/rackspace_logo.png]

jesse.cook@rackspace.comjesse.cook@rackspace.com
irc: #compute-eng (gimchi)
mobile: 618-530-0659

https://rackspacemarketing.com/signatyourEmail/

[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.r
ac
k

cdn.com/signatures/images/linkedin.png]https://www.linkedin.com/pub/je
ss
e
-cook/8/292/620>

[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.r
ac
k
cdn.com/signatures/images/google.png]
https://plus.google.com/u/0/+JesseCooks/posts/p/pub

On 7/23/15, 12:01 PM, "Egle Sigler"
<egle.sigler@rackspace.comegle.sigler@rackspace.com> wrote:

Hello OpenStack Community,

I am very excited to let you know that today Rackspace and Intel
announced our plans to form the "OpenStack Innovation Center," which
is
an exciting community-oriented initiative focused on accelerating the
enterprise features and adoption of OpenStack. This initiative
includes:

· Largest OpenStack Developer Cloud - We are building and making
available to the community two 1,000 node clusters to support
advanced,
large-scale and testing of OpenStack. The clusters should be
available
to the community within six months and you can sign up
herehttp://goo.gl/forms/vCkfNBmXm4 to receive updates on this
effort.

· OpenStack Developer Training - We are creating a new training
curriculum designed to onboard and significantly increase the number
of
developers working upstream in the community.

· Joint OpenStack Engineering - Rackspace and Intel developers
will
work together in collaboration with the Enterprise Work Group and
community to eliminate bugs and develop new enterprise features. Both
companies will recruit new developers to help further OpenStack
development.

· OpenStack Innovation Center - The center will be comprised of
Rackspace and Intel developers who will work upstream, using existing
community tools and processes to improve the scalability,
manageability
and usability of OpenStack.

To find out more, please check out the following resources:

Rackspace press

releasehttp://www.rackspace.com/blog/newsarticles/rackspace-collaborat
es
-

with-intel-to-accelerate-openstack-enterprise-feature-development-and-a
do
p
tion/>
Rackspace

bloghttp://www.rackspace.com/blog/rackspace-and-intel-form-the-opensta
ck
-
innovation-center>
Intel

releasehttp://newsroom.intel.com/community/intel_newsroom/blog/2015/07
/2
3

/intel-announces-cloud-for-all-initiative-to-deliver-benefits-of-the-cl
ou
d
-to-more-businesses>
Intel

bloghttps://communities.intel.com/community/itpeernetwork/datastack/bl
og
/
2015/07/23/cloud-for-all>

We look forward to working with you to continue advancing the leading
open source cloud platform and welcome your feedback!

Best regards,

Egle Sigler
Rackspace Principal Architect
OpenStack Foundation Board Member


Product-wg mailing list
Product-wg@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg


Product-wg mailing list
Product-wg@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.10 Meeting Invite Wed. August 12, 10 AM CST/ 15:00 UTC

Hello Everyone,

We had great turnout during our midcycle meet up and accomplished a lot! It was really great to see everyone, thank you for all the work! And thanks to IBM for hosting us.
We will not have a meeting the week of August 5th, our next meeting is on August 12th.

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.10

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

All,

It's also worth reviewing the Gerrit commits for those times because
some of our discussions translated directly into patches to HACKING and
a new 2015B process file for Board approval.

Rob

On 08/02/2015 03:02 PM, Egle Sigler wrote:
Hello Everyone,

We had great turnout during our midcycle meet up and accomplished a
lot! It was really great to see everyone, thank you for all the work!
And thanks to IBM for hosting us.
We will not have a meeting the week of August 5th, our next meeting is
on August 12th.

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.10

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client:
http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide:
http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--

Rob


Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.11 Meeting Invite Wed. August 19, 10 AM CST/ 15:00 UTC

Hello Everyone,
Last meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-08-12-14.59.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.11

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.12 Meeting Invite Wed. August 26, 10 AM CST/ 15:00 UTC

Hello Everyone,
Last meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-08-19-14.59.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.12

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] 2015.07 and compute-servers-change

Good morning!

I asked this on IRC, but I figured I'd get better responses if I emailed
the alias directly.

According to http://refstack.net/#/capabilities, in
compute-servers-change, there's ...

tempest.api.compute.servers.testserveractions.ServerActionsTestJSON.testchangeserver_password

... which, obviously, is used to change the root/admin password of an
instance. I'm curious to find out why that test is included when only
one hypervisor (Xen) supports that operation.[1]

Also, I can't seem to subscribe to this alias. When I try, I get a
mailman error so if you could please reply directly to me as well as the
alias, I would appreciate it.

Thank you!

-Drew

[1]
http://docs.openstack.org/developer/nova/support-matrix.html#operation_set_admin_password


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Just to recap the responses you received on IRC [1] here for posterity:

Previously, each Guideline goes to the Board of Directors with no flags attached to it, and we flag tests once they’ve approved the general Guideline. 2015.07 was just recently approved, so we’re just beginning to see flag requests rolling in. That particular test is one that we’ve flagged in previous Guidelines and have discussed removing entirely [2], but that slipped under the radar and didn’t happen in time for the 2015.07 Guideline submission. It is (IMHO) pretty clearly a bad test to include, so I went ahead and submitted a patch to flag it in 2015.07 and remove it from future Guidelines [3].

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-defcore/%23openstack-defcore.2015-08-20.log.html#t2015-08-20T15:59:48
[2] https://review.openstack.org/#/c/196153/
[3] https://review.openstack.org/215263/

At Your Service,

Mark T. Voelker
OpenStack Architect
+1 (970) 203-4974

On Aug 20, 2015, at 12:17 PM, Drew Fisher drew.fisher@oracle.com wrote:

Good morning!

I asked this on IRC, but I figured I'd get better responses if I emailed
the alias directly.

According to https://urldefense.proofpoint.com/v2/url?u=http-3A__refstack.net_-23_capabilities&d=BQICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=OSW7BJWv1D4K0WyiG0llPtNpfSWvZSPI4OlLRhrpH9k&s=CIlIRC1ar7bWqKVRQefyV_D3U1okiMW1eiC7rwLncdQ&e= , in
compute-servers-change, there's ...

tempest.api.compute.servers.testserveractions.ServerActionsTestJSON.testchangeserver_password

... which, obviously, is used to change the root/admin password of an
instance. I'm curious to find out why that test is included when only
one hypervisor (Xen) supports that operation.[1]

Also, I can't seem to subscribe to this alias. When I try, I get a
mailman error so if you could please reply directly to me as well as the
alias, I would appreciate it.

Thank you!

-Drew

[1]
http://docs.openstack.org/developer/nova/support-matrix.html#operation_set_admin_password


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] On Requiring Vendors to Submit Testbed Data

Hello DefCore,

At the DefCore midcycle sprint in Austin a few weeks ago we kicked off a discussion about requiring vendors to submit information about their testbeds along with their test results when applying for OpenStack Powered (TM) logo status in order to help users understand product requirements for deployable products and available resources on hosted products. The proposed change is here:

https://review.openstack.org/#/c/207209/

We’ve since discussed it a few more times during weekly meetings, including here:

http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-08-12-14.59.log.html#l-108

I had an AI to bring this up on the mailing list again since we don’t seem to be coming to consensus yet. To summarize, the patch states:

"The objective is for users to understand the requirements for deployable products and to know the resources available on hosted products."

It requires vendors to submit information about the storage, virtualization, and network backends, operating systems, number of nodes in the system, network requirements, a “yes/no” as to whether the configuration is “highly available”, whether or not IPv4 and IPv6 are supported, and the Tempest and policy configurations of the system against which the refstack-client was run.

The major objections to the proposal here boil down mostly to two things (see review comments and IRC discussion above for more):

1.) Most of the information being requested has little to do with interoperability from an application deployment point of view, and therefore seems out of place.
2.) The information requested paints an extremely incomplete picture of both product requirements and resources available and therefore fails to accomplish the stated objective.

The latter point is probably the most salient, so I’ll expand on it a bit (again, see links above for fuller comments):

2a.) Many deployable products can be run on a variety of different backends and OS's. Some have different high availability modes, most have more than one reference architectures (which have different minimum requirements and some of which are targeted at specific use cases such as NFV or different environments, e.g. small dev vs large prod). Many permit the use of different backing technologies in different parts of the cloud (for example,I might have one host aggregate backed by local disk and another backed by a SAN, or I might have one region of KVM and another backed by VMware). The environment that a single test run was conducted against will at best capture one possible permutation of factors like these.

2b.) We have always advised in the past that the tests not be run against a production system [1][2] on account of Tempest leaving artifacts in the environment after it finishes. For public cloud or hosted products in particular, this means that the sizing information accompanying submitted test results is very unlikely to reflect “resources available for hosted products”. Public cloud providers may also be reticent to give out sizing information for production anyway as it may be considered sensitive/strategic information, and probably changes very frequently anyway (e.g. if a public cloud starts running low on compute capacity, they’re probably going to simply buy more servers). Here again, some hosted products are customized based on the needs of the customer as well, so sizing is an arbitrary target: the amount of compute/storage/etc I have available may depend on the limits of my credit card.

2c.) The set of information requested here is also probably incomplete with respect to the requirements of many products. For example, a vendor might require a version of the backend hypevisor no lesser than X or greater than Y, or may require a particular type of hardware, or may require a particular other piece of configuration management software. Generally speaking, most vendors have data sheets or HCL’s that provide exactly this type of information for prospective customers—the results of a single test run are unlikely to duplicate them completely and may simply create “multiple sources of truth”, one of which is likely incomplete. Putting my vendor hat on for a moment, I’d hate for the information like this to misrepresent my product’s capabilities. Putting my end user hat on, I’d hate to think I understood product requirements after reading the data, make plans, and then find out that I’ve been given a false impression.

So, all that said, several folks believe that collection of the information required by this patch doesn’t really help us meet the stated objective of the patch. One idea that has been floated as a potentially better way to help customers understand requirements and resources available is to use the OpenStack Marketplace: for example, when a vendor applies to have a listing on the Marketplace, they might be required to submit product requirement information then, or links to existing datasheets/product requirements documents. This strategy would prevent us from being limited to seeing just the particulars of a single test run, and would have the additional benefit that it could potentially apply to all vendors with a Marketplace listing rather than just OpenStack Powered (TM) products. I’ll note that the Marketplace is sort of outside the scope of the DefCore Committee (though vendors who acquire OpenStack Powered (TM) status by adhering to our Guidelines do get a special recognition there). I think that’s actually an advantage as well since as per #1 above, a lot of product requirements and capacity information have little to do with application-level interoperability anyway. I’d prefer that DefCore focus on those concerns first, as we have a lot of work yet to do there.

[1] http://git.openstack.org/cgit/openstack/defcore/tree/2015.04/procedure.rst#n77
[2] http://git.openstack.org/cgit/openstack/defcore/tree/2015.05/procedure.rst#n77

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Meeting tomorrow @ 10 Central

All,

Just a reminder.

Not updated yet, but agenda will be here >
https://etherpad.openstack.org/p/DefCoreFlag.12

Rob

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Guidance on Vendor Registration Process in RefStack

Hello DefCore,

RefStack has recently added features to enable uploading of data with
validated users. Users will first log into RefStack (http://refstack.net/)
with their OpenStack ID to upload their keys. RefStack test result data
then can be uploaded to RefStack server using those keypairs. By default,
the uploaded data are not shared. Authorized users can decide on deleting
or picking to share the results to the community anonymously.

The next steps for RefStack is to implement a vendor registration process
to associate OpenStack users and data to a vendor. RefStack would like
guidance from DefCore on vendor registration specification for the
following items:

Who will be authorized to create a vendor in RefStack?
Who will be authorized to associate an OpenStack user to a vendor ?
Will there be multiple users per vendor?

Your advice on the direction to proceed is greatly appreciated!

Catherine Diep

RefStack PTL
IBM Silicon Valley Laboratory, San Jose, California 95141
cdiep@us.ibm.com, Tel: (408) 463-4352 T/L: 543-4352


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore 13 @ Wed Sep 2, 2015 10am - 11am (rob@rackn.com)

You have been invited to the following event.

Title: DefCore 13
When: Wed Sep 2, 2015 10am - 11am Central Time
Where: https://etherpad.openstack.org/p/DefCoreFlag.13
Video call: https://plus.google.com/hangouts/_/rackn.com/rob
https://plus.google.com/hangouts/_/rackn.com/rob?hceid=cm9iQHJhY2tuLmNvbQ.5cuatgnp8huhfe2oe3tigjr4io
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NWN1YXRnbnA4aHVoZmUyb2UzdGlnanI0aW8gZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTI3NDkyODY3NDBjYzExOWE4OTVhMjM5MGY2NzY1OTI1MDg2NjAxZDA&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at
https://support.google.com/calendar/answer/37135#forwarding


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Meeting Reminder Wed 10 Central

Reminder: Agenda on https://etherpad.openstack.org/p/DefCoreFlag.13

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Flag.14 [INTERACTIVE Capabilities Review] @ Wed Sep 9, 2015 10am - 11am (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Flag.14 [INTERACTIVE Capabilities Review]
You have been invited to a join.me online meeting

Join the meeting: https://join.me/912-870-589

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 912-870-589

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - San Francisco, CA +1.415.655.0381
United States - Hartford, CT +1.860.970.0010
Access Code 912-870-589#

Other international numbers available (https://join.me/intphone/912870589/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1441810800000/1441814400000)

When: Wed Sep 9, 2015 10am - 11am Central Time
Where: https://etherpad.openstack.org/p/DefCoreFlag.14
Video call: https://plus.google.com/hangouts/_/rackn.com/rob
https://plus.google.com/hangouts/_/rackn.com/rob?hceid=cm9iQHJhY2tuLmNvbQ.4en59i0pkbr6mfjccldu2cikqo
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org
* chris@openstack.org
* ushnishtha@hotmail.com

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NGVuNTlpMHBrYnI2bWZqY2NsZHUyY2lrcW8gZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTg1YjliOTE1YzMyODEyZGM4NjFmZDYzZGExZDk3YWRlZWFmN2M5NjI&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at
https://support.google.com/calendar/answer/37135#forwarding


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] [Update] DefCore Flag.14 [INTERACTIVE Capabilities Review]

Call Reminder for Tomorrow - INTERACTIVE, so dial in.

Agenda: https://etherpad.openstack.org/p/DefCoreFlag.14

You have been invited to the following event.

Title: DefCore Flag.14 [INTERACTIVE Capabilities Review]
You have been invited to a join.me online meeting

Join the meeting: https://join.me/912-870-589

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 912-870-589

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - San Francisco, CA +1.415.655.0381
United States - Hartford, CT +1.860.970.0010
Access Code 912-870-589#

Other international numbers available (https://join.me/intphone/912870589/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1441810800000/1441814400000)

When: Wed Sep 9, 2015 10am - 11am Central Time
Where: https://etherpad.openstack.org/p/DefCoreFlag.14
Video call: https://plus.google.com/hangouts/_/rackn.com/rob
https://plus.google.com/hangouts/_/rackn.com/rob?hceid=cm9iQHJhY2tuLmNvbQ.4en59i0pkbr6mfjccldu2cikqo
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org
* chris@openstack.org
* ushnishtha@hotmail.com


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Updated Invitation: DefCore Flag.14 [INTERACTIVE Capabilities Review] @ Wed Sep 9, 2015 10am - 11am (rob@rackn.com)

This event has been changed.

Title: DefCore Flag.14 [INTERACTIVE Capabilities Review]
You have been invited to a join.me online meeting

Join the meeting: https://join.me/912-870-589

On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 912-870-589

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - San Francisco, CA +1.415.655.0381
United States - Hartford, CT +1.860.970.0010
Access Code 912-870-589#

Other international numbers available (https://join.me/intphone/912870589/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1441810800000/1441814400000)

When: Wed Sep 9, 2015 10am - 11am Central Time
Where: https://etherpad.openstack.org/p/DefCoreFlag.14
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org
* chris@openstack.org
* ushnishtha@hotmail.com

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NGVuNTlpMHBrYnI2bWZqY2NsZHUyY2lrcW8gZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTg1YjliOTE1YzMyODEyZGM4NjFmZDYzZGExZDk3YWRlZWFmN2M5NjI&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at
https://support.google.com/calendar/answer/37135#forwarding


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore Flag 15 @ Wed Sep 16, 2015 10am - 11am (rob@rackn.com)

You have been invited to the following event.

Title: DefCore Flag 15
IRC Meeting
When: Wed Sep 16, 2015 10am - 11am Central Time
Where: https://etherpad.openstack.org/p/DefCoreFlag.15
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* chris@openstack.org
* egle.sigler@rackspace.com
* ushnishtha@hotmail.com
* defcore-committee@lists.openstack.org - optional

Your attendance is optional.

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=YWMyYmhvMmthdDk3ZmgzZDluajM0MDRrcjAgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTkxNmJiMzgyNTJkMmQ4NTM5ZDQ1NDg5NDIyYmUyMjk5NGNlM2Q1Y2M&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at
https://support.google.com/calendar/answer/37135#forwarding


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] It's official -- Refstack repositories are now in the openstack repository tree

The move that just completed included moving RefStack.

Yay!

--Rocky

-----Original Message-----
From: James E. Blair [mailto:corvus@inaugust.com]
Sent: Friday, September 11, 2015 5:39 PM
To: OpenStack Development Mailing List
Cc: openstack-infra@lists.openstack.org
Subject: Re: [openstack-dev] Gerrit downtime on Friday 2015-09-11 at 23:00 UTC

corvus@inaugust.com (James E. Blair) writes:

On Friday, September 11 at 23:00 UTC Gerrit will be unavailable for
about 30 minutes while we rename some projects.

Existing reviews, project watches, etc, should all be carried
over.

This has been completed without incident.

Currently, we plan on renaming the following projects:

stackforge/os-ansible-deployment -> openstack/openstack-ansible
stackforge/os-ansible-specs -> openstack/openstack-ansible-specs

stackforge/solum -> openstack/solum
stackforge/python-solumclient -> openstack/python-solumclient
stackforge/solum-specs -> openstack/solum-specs
stackforge/solum-dashboard -> openstack/solum-dashboard
stackforge/solum-infra-guestagent -> openstack/solum-infra-guestagent

stackforge/magnetodb -> openstack/magnetodb
stackforge/python-magnetodbclient -> openstack/python-magnetodbclient
stackforge/magnetodb-specs -> openstack/magnetodb-specs

stackforge/kolla -> openstack/kolla
stackforge/neutron-powervm -> openstack/networking-powervm

And we also moved these:

stackforge/os-ansible-deployment -> openstack/openstack-ansible
stackforge/os-ansible-deployment-specs -> openstack/openstack-ansible-specs

stackforge/refstack -> openstack/refstack
stackforge/refstack-client -> openstack/refstack-client

Thanks to everyone that pitched in to help the move go smoothly.

As a reminder, we expect this to be the last move of projects from
stackforge into openstack before we retire the stackforge/ namespace as
previously announced [1].

-Jim

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/072140.html


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


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Congratulations everyone on RefStack joining the 'big tent'. :-)

On Sep 11, 2015, at 9:30 PM, Rochelle Grober rochelle.grober@huawei.com wrote:

The move that just completed included moving RefStack.

Yay!

--Rocky

-----Original Message-----
From: James E. Blair [mailto:corvus@inaugust.com]
Sent: Friday, September 11, 2015 5:39 PM
To: OpenStack Development Mailing List
Cc: openstack-infra@lists.openstack.org
Subject: Re: [openstack-dev] Gerrit downtime on Friday 2015-09-11 at 23:00 UTC

corvus@inaugust.com (James E. Blair) writes:

On Friday, September 11 at 23:00 UTC Gerrit will be unavailable for
about 30 minutes while we rename some projects.

Existing reviews, project watches, etc, should all be carried
over.

This has been completed without incident.

Currently, we plan on renaming the following projects:

stackforge/os-ansible-deployment -> openstack/openstack-ansible
stackforge/os-ansible-specs -> openstack/openstack-ansible-specs

stackforge/solum -> openstack/solum
stackforge/python-solumclient -> openstack/python-solumclient
stackforge/solum-specs -> openstack/solum-specs
stackforge/solum-dashboard -> openstack/solum-dashboard
stackforge/solum-infra-guestagent -> openstack/solum-infra-guestagent

stackforge/magnetodb -> openstack/magnetodb
stackforge/python-magnetodbclient -> openstack/python-magnetodbclient
stackforge/magnetodb-specs -> openstack/magnetodb-specs

stackforge/kolla -> openstack/kolla
stackforge/neutron-powervm -> openstack/networking-powervm

And we also moved these:

stackforge/os-ansible-deployment -> openstack/openstack-ansible
stackforge/os-ansible-deployment-specs -> openstack/openstack-ansible-specs

stackforge/refstack -> openstack/refstack
stackforge/refstack-client -> openstack/refstack-client

Thanks to everyone that pitched in to help the move go smoothly.

As a reminder, we expect this to be the last move of projects from
stackforge into openstack before we retire the stackforge/ namespace as
previously announced [1].

-Jim

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/072140.html


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


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitation: DefCore 16 [INTERACTIVE] @ Wed Sep 23, 2015 10am - 11am (rob@rackn.com)

You have been invited to the following event.

Title: DefCore 16 [INTERACTIVE]
You have been invited to a join.me online meeting

Join the meeting: https://join.me/587-954-630

On a computer, use any browser. Nothing to download.
On a phone or tablet, launch the join.me app (https://join.me/app) and
enter meeting code: 587-954-630

Join the audio conference:
Dial a phone number and enter access code, or connect via internet.

By phone:
United States - Washington, DC +1.202.602.1295
United States - San Francisco, CA +1.415.655.0381
Access Code 587-954-630#

Other international numbers available (https://join.me/intphone/587954630/0)

By computer via internet:
Join the meeting, click the phone icon and select 'Call via internet'. A
small download might be required.

Start time by time zones
(https://join.me/timezone/1443020400000/1443024000000)

When: Wed Sep 23, 2015 10am - 11am Central Time
Where: https://etherpad.openstack.org/p/DefCoreFlag.16
&https://join.me/587-954-630
Video call: https://plus.google.com/hangouts/_/rackn.com/rob
https://plus.google.com/hangouts/_/rackn.com/rob?hceid=cm9iQHJhY2tuLmNvbQ.g47q4pc2tn799edoud1ge71is0
Calendar: rob@rackn.com
Who:
* Rob Hirschfeld - organizer
* defcore-committee@lists.openstack.org
* chris@openstack.org
* egle.sigler@rackspace.com

Event details:
https://www.google.com/calendar/event?action=VIEW&eid=ZzQ3cTRwYzJ0bjc5OWVkb3VkMWdlNzFpczAgZGVmY29yZS1jb21taXR0ZWVAbGlzdHMub3BlbnN0YWNrLm9yZw&tok=MTMjcm9iQHJhY2tuLmNvbTM3OWU4YWQ3YTMzOTlhYTViYTk5MDIxYzk1YjQyZDM4ZTc5ZTAxYjI&ctz=America/Chicago&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account
defcore-committee@lists.openstack.org because you are an attendee of this
event.

To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at
https://support.google.com/calendar/answer/37135#forwarding


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Question about Negative tests in DefCore

Folks,

Not sure if this is the right forum or if I should bring it up in the next meeting, however, I had a question about the number of Negative tests that are getting included in the DefCore specs. I could soap box on the topic for a while but the short summary is that by their very definition, a negative test is not proving a capability other than a correct response or behavior from a system in a failure condition. They could easily pass and still provide no real visibility into whether or not a capability exists.

For example just to pick a random test, this is one of the tests in the current 2016.next patch for volumes:
"tempest.api.volume.testvolumesnegative.VolumesV2NegativeTest.testcreatevolumewithnonexistentsourcevolid"

Should not be able to create volume with non-existent source volume

vname = datautils.randname('Volume')
metadata = {'Type': 'work'}
self.assertRaises(lib
exc.NotFound, self.client.createvolume,
size='1', source
volid=str(uuid.uuid4()),
displayname=vname, metadata=metadata)

Which means that this test will fail if it couldn't create a volume without passing an ID. This test could just as easily pass or fail for any number of other reasons. If the point of a DefCore test is to prove that Capability XYZ exists as described in an interoperable fashion, this test doesn't really move that point forward. I would think DefCore would want to focus on only positive tests that confirm a specific capability exists, not any given negative test that might only be looking to prove some failure condition.

Thoughts?

Thanks,

Sam

Sam Danes
Architect, Software Development - Test
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]

sam.danes@rackspace.com
mobile: 412.689.1532

https://www.rackspacemarketing.com/signatyourEmail/
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/linkedin.png]<https://www.linkedin.com/in/samueldanes


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Excerpts from Sam Danes's message of 2015-09-24 17:55:37 +0000:

Folks,

Not sure if this is the right forum or if I should bring it up in the next meeting, however, I had a question about the number of Negative tests that are getting included in the DefCore specs. I could soap box on the topic for a while but the short summary is that by their very definition, a negative test is not proving a capability other than a correct response or behavior from a system in a failure condition. They could easily pass and still provide no real visibility into whether or not a capability exists.

For example just to pick a random test, this is one of the tests in the current 2016.next patch for volumes:
"tempest.api.volume.testvolumesnegative.VolumesV2NegativeTest.testcreatevolumewithnonexistentsourcevolid"

Should not be able to create volume with non-existent source volume

vname = datautils.randname('Volume')
metadata = {'Type': 'work'}
self.assertRaises(lib
exc.NotFound, self.client.createvolume,
size='1', source
volid=str(uuid.uuid4()),
displayname=vname, metadata=metadata)

Which means that this test will fail if it couldn't create a volume without passing an ID. This test could just as easily pass or fail for any number of other reasons. If the point of a DefCore test is to prove that Capability XYZ exists as described in an interoperable fashion, this test doesn't really move that point forward. I would think DefCore would want to focus on only positive tests that confirm a specific capability exists, not any given negative test that might only be looking to prove some failure condition.

That test is expecting a NotFound error for the made up volume id
passed to the create_volume call. If any other type of exception
is returned, the test will fail because the error type doesn't
match.

It's just as important to return consistent errors to callers as
it is to have consistent successful behaviors, so we need to continue
to include these sorts of tests.

Doug

[OpenStack-DefCore] DefCore Flag.17 Meeting Invite Wed. September 30, 10 AM CST/ 15:00 UTC

Hello Everyone,
Last meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-08-19-14.59.html http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-09-23-15.02.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.17

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.18 Meeting Invite Wed. October 7, 10 AM CST/ 15:00 UTC

Hello Everyone,
Last meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-09-30-15.00.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.18

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Flag.19 Meeting Invite Wed. October 14, 10 AM CST/ 15:00 UTC

Hello Everyone,
Last meeting summary: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-10-07-15.00.html

Etherpad: https://etherpad.openstack.org/p/DefCoreFlag.19

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] A few threads of note...

Ladies and Gents,

Happy Friday! I’m traveling across the continent today and my inbox overfloweth (so, situation normal =p). I imagine many of you are in the same boat, but I thought I’d call out a couple of threads that you might want to take special note of as they pertain to recent conversations we’ve had about API transitions, capabilities scoring, and interoperable ways of doing things.

On standardizing the catalog format:
http://lists.openstack.org/pipermail/openstack-dev/2015-October/076592.html

On refactoring the glance image import process (including a spec that could use some input):
http://lists.openstack.org/pipermail/openstack-dev/2015-October/076540.html

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Working Draft of Board Report 10-26

All,

Egle and I are working on the 10-26 Board Report. It will not be
complete until we have the 2016.01 draft; however, you are welcome to
review the current material.

Link:
https://docs.google.com/document/d/1uTv4QA-BNHlMdjupngQsmyjit2yNcfmY9sB5OAapmlE/edit?usp=sharing

DefCore Board Report
Meeting October 26, 2015
Rob Hirschfeld & Egle Sigler Co-Chairs

30 minutes

General Updates [5 minutes]
2015B Process Approval [5 minutes]
Draft Review Capabilities Changes for 2016.01 [10 minutes]
Discussion (time permitting) [10 minutes]
    Concerns on Advisory status
    Using DefCore as API police

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] No DefCore IRC meeting this week or the next

Hello Everyone,

No IRC meeting this week, or the next. Next week we will have 2 working sessions in Tokyo, if you are attending the summit, hope to see you there.
If you have any questions, email me or Rob, or find us on IRC in #openstack-defcore channel.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Minutes from Working Session

All -

Great (but too short!) session yesterday. Here's the text for everyone.

We need to pick a new cycle name. Please add/+1 your choices!

Link: https://etherpad.openstack.org/p/DefCoreFlagTokyo

https://etherpad.openstack.org/p/DefCoreFlagTokyo
Agenda for DefCore Tokyo sessions

Refstack design sessions:

Topics:

DID NOT FINISH AGENDA....see Going Forward at end

  • Review decisions made during cycle: Refstack required, all tests
    must be in tempest, no ORs (we don't allow two incompatible APIs)

  • Example: Heat Scoring ( https://review.openstack.org/#/c/216983/ )

  • The heat tests in tempest have stopped evolving for some time now as
    heat's functional and integration tests now live in the heat tree

  • Reconcile a contradiction between defcore consisting of tempest
    compliance tests, and tempest's policy of encouraging projects to
    write functional tests in their own project tree rather than tempest
    itself. (This may be a cross projects topic)

  • Plan major topics for next cycle

  • private vs public

  • more Refstack data

  • additional communication to dev list about changes

  • Naming of next cycle

  • name suggestions:

  • austin (cause next summit is in Austin...)

  • tokyo

  • chicken (as in playing)

  • ring (as in one ring to rule them all) +1

  • sink (as in not floating and kitchen) +1

  • open (as in invitation) +1

  • Review proposed scoring changes

  • API versions and DefCore scoring/advisory/migration process

  • Guideline on Vendor Registration/Affiliation in RefStack
    ( https://review.openstack.org/#/c/226902/ ) . Need Foundation
    inputs.

  • Vendor self-registration at RefStack or vendor name list provided by
    the Foundation

  • Asks from dev community:

  • Frequent rollups to TC and UC

  • Blog posts and mailing list posts to notify and explain:

  • Upcoming discussions

  • Major decisions or other announcements

New to DefCore? Some pointers:

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Is DefCore like Linux Standard Base?

I was reading this:

Debian dropping the Linux Standard Base [LWN.net]
https://lwn.net/Articles/658809/

… and was struck by the parallels behind both the intent of LSB and DefCore (provide assurances around common functionality and interoperability delivered in a distro) as well as implementation (standard trails implementation, etc.). The article is a 5-10 minute read; in the comments, read the first from michaeljt; then pick up near the bottom, starting with the one by criswell, to the end.

I see two interesting ways to angles from which to view this:

  1. LSB was successful at driving convergence for 20+ years and is beginning to die out.
  2. LSB failed to reach effectiveness in 20+ years of trying and is beginning to die out.

The case for #1 seems suspect. The article and comments, as well as the relative lack of applications which successfully adopted LSB as the primary or sole basis of specifying their dependencies, seem to indicate otherwise.

The question here: how is DefCore different, and how will we succeed where LSB failed?

--j


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Meyer, Jim wrote:
[...]
The question here: how is DefCore different, and how will we succeed where LSB failed?

I think LSB failed at incentivizing complying distributions. Basically
you could still call your distro "Linux" even if you didn't follow the
LSB. Defcore can (and does) use trademark programs to incentivize
OpenStack distributions, so we should avoid that.

Also the LSB was only one path to Linux interoperability. There are
various ways to be completely interoperable without complying to the
LSB. It is also no coincidence if LSB is beginning to die out at the
same moment yet another way to interoperate at application bundling
level appears (containers). I would argue that in the OpenStack case,
Defcore is an essential piece of our interoperability story. There are
others pieces (like killing differences in implementation when they
bubble up to the user), but a common set of base services is a key element.

--
Thierry Carrez (ttx)


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.1 Meeting Invite Wed. November 4, 10 AM CST/ 15:00 UTC

Hello Everyone,

Was great to see everyone in Tokyo! Etherpad notes from Tokyo session: https://etherpad.openstack.org/p/DefCoreFlagTokyo

Our next cycle will be called "ring", as in one ring to rule them all.
Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.1

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-4

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.2 Meeting Invite Wed. November 4, 10:30 AM CST/ 16:30 UTC

Hello Everyone,

We needed to adjust the meeting time because of the daylight savings time going away. Hope this new time works for everyone. Please note the change in the meeting room as well, we now will be meeting in #openstack-meeting-2.

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.2

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-2

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

we now will be meeting in #openstack-meeting-2.

…which, as it turns out, isn’t actually an official channel and therefore won’t be logged [1]. =( So let’s see if we can fix that.

I know there was some desire from our chairs and other regular attendees to shoot for 16:00 UTC in the middle of the week, but that won’t work on Wednesday because all channels are taken. Instead, we could switch to Thursday on #openstack-meeting at that time. A few other options I just checked on:

• Tuesday 18:00 UTC (==1pm EST/12pm CST/11am PST) on #openstack-meeting-4
* Tuesday 19:00 UTC (==2pm EST/1pm CST/12pm PST) on #openstack-meeting-4
• Wednesday 15:00 UTC (==10am EST/9am CST/8am PST) on #openstack-meeting-4
• Our old time, but effectively an hour earlier for US folks due to DST change
• Wednesday 19:00 UTC (==2pm EST/1pm CST/12pm PST) on #openstack-meeting
• Thursday 16:00 UTC (==11am EST/10am CST/9am PST) on #openstack-meeting
• Thursday 20:00 UTC (==3pm EST/2pm CST/1pm PST) on #openstack-meeting-alt

I set up a Doodle poll with those options, so please go here to give your availability (please note: the poll may show times in EST by default since UTC isn’t a configurable option, but you can adjust the timezone displayed to your locale by simply clicking the “change” link in the upper righthand corner of the table):

http://doodle.com/poll/nat92xaspeh3i4kh

If you are unable to access Doodle for some reason, simply respond to me via email with your availability and I’ll make sure you get counted.

[1] And, doh, neither us nor infra caught it when we submitted the change. If I remember my history correctly, the second meeting channel created when #openstack-meeting became too crowded was #openstack-meeting-alt, then later #openstack-meeting-3 and #openstack-meeting-4 were added. So, the names are sort of inconsistent which lead to the mistake. My bad.

At Your Service,

Mark T. Voelker

On Nov 10, 2015, at 12:25 AM, Egle Sigler egle.sigler@rackspace.com wrote:

Hello Everyone,

We needed to adjust the meeting time because of the daylight savings time going away. Hope this new time works for everyone. Please note the change in the meeting room as well, we now will be meeting in #openstack-meeting-2.

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.2

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-2

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Example for Hacking Rule - >1 test per Capability

All,

I've updated next.json for the >1 Test per Cap patch for review:
https://review.openstack.org/#/c/233814/

If this looks good, I can make similar changes to 2016.01.json

--

Rob


Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.2 Meeting Invite Wed. November 4, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

We needed to adjust the meeting time because of the daylight savings time going away. Hope this new time works for everyone (same time for most US based people). Please note the change in the meeting room as well, we now will be meeting in #openstack-defcore.

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.2

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-defcore

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hello Everyone,

We needed to adjust the meeting time because of the daylight savings time going away. Hope this new time works for everyone (same time for most US based people). Please note the change in the meeting room as well, we now will be meeting in #openstack-defcore.

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.2

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-defcore

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Meeting times poll

Hello Everyone,

Sorry for the multiple calendar invites to today's meeting, seems like they caused some calendar issues. However, it raised a question which time slot is more convenient, 10:00 CST (16:00 UTC) or 10:30 CST. Since there is only a 30 minute difference, both times might work for you.

Please fill out the doodle poll with times that work for you, this is for 1 hour meeting on Wednesdays:

http://doodle.com/poll/suifaab6i5rxk2p8

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.3 Meeting Invite Wed. November 11, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Note the meeting location: #openstack-defcore.
After voting on Doodle, 10:00 AM CST won out over 10:30 AM CST by a couple votes, so we will continue meeting at 10:00 AM. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.3

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-defcore

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Working session on Tuesday, no meeting this Wedensday

Hello Everyone,

We will not have a meeting this Wednesday, but we will have a working session on Tuesday, at 1 PM CST. We will do it over joinme. We will discuss whether DefCore should require Linux VMs to be bootable, and possible actions. Here is a working document regarding the issue:

https://docs.google.com/document/d/1Q_N93hJ-8WK4C3Ktcrex0mxv4VqoAjBzP9g6cDe0JoY/edit?usp=sharing

Etherpad: https://etherpad.openstack.org/p/DefCoreRing.DecWorkignSession

Joinme link: https://join.me/startrackn

Call by phone: +1.302.202.5900
Conference ID: 546-908-798

If you go to the link, it will have options for calling in from other locations/area codes.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hello Everyone,
Please call in, we are using only phone bridge, no screen sharing. It will keep saying "Waiting for the presenter", but we can talk just fine.

Thank you!
Egle

From: egle.sigler@rackspace.com
When: 1:00 PM - 2:00 PM November 24, 2015
Subject: DefCore Working session on Tuesday, no meeting this Wedensday
Location: https://join.me/startrackn

Hello Everyone,

We will not have a meeting this Wednesday, but we will have a working session on Tuesday, at 1 PM CST. We will do it over joinme. We will discuss whether DefCore should require Linux VMs to be bootable, and possible actions. Here is a working document regarding the issue:

https://docs.google.com/document/d/1Q_N93hJ-8WK4C3Ktcrex0mxv4VqoAjBzP9g6cDe0JoY/edit?usp=sharing
Etherpad: https://etherpad.openstack.org/p/DefCoreRing.DecWorkignSession

Joinme link: https://join.me/startrackn

Call by phone: +1.302.202.5900
Conference ID: 546-908-798

If you go to the link, it will have options for calling in from other locations/area codes.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Working session next Tuesday, no meeting Wedensday, November 25th

Hello Everyone,

We had a really good discussion today, and we will continue this working session next Tuesday, at 3 PM CST. We will do it over joinme. We will discuss whether DefCore should require Linux VMs to be bootable, and possible actions. Here is a working document regarding the issue:

https://docs.google.com/document/d/1Q_N93hJ-8WK4C3Ktcrex0mxv4VqoAjBzP9g6cDe0JoY/edit?usp=sharing

Will continue same Etherpad: https://etherpad.openstack.org/p/DefCoreRing.DecWorkignSession

Joinme link: https://join.me/startrackn

Call by phone: +1.302.202.5900
Conference ID: 546-908-798

If you go to the link, it will have options for calling in from other locations/area codes.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hello Everyone,

Please call in if the screen sharing is not working.

Thank you,
Egle

From: egle.sigler@rackspace.com
When: 3:00 PM - 4:00 PM December 1, 2015
Subject: DefCore Working session next Tuesday, no meeting Wedensday, November 25th
Location: https://join.me/startrackn

Hello Everyone,

We had a really good discussion today, and we will continue this working session next Tuesday, at 3 PM CST. We will do it over joinme. We will discuss whether DefCore should require Linux VMs to be bootable, and possible actions. Here is a working document regarding the issue:

https://docs.google.com/document/d/1Q_N93hJ-8WK4C3Ktcrex0mxv4VqoAjBzP9g6cDe0JoY/edit?usp=sharing
Will continue same Etherpad: https://etherpad.openstack.org/p/DefCoreRing.DecWorkignSession

Joinme link: https://join.me/startrackn

Call by phone: +1.302.202.5900
Conference ID: 546-908-798

If you go to the link, it will have options for calling in from other locations/area codes.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.4 Meeting Invite Wed. December 2, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.4

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.5 Meeting Invite Wed. December 9, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

DefCore topic of the month, if you have not yet had a chance, please review and comment: https://docs.google.com/document/d/1Q_N93hJ-8WK4C3Ktcrex0mxv4VqoAjBzP9g6cDe0JoY/edit?usp=sharing

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.5

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.6 Meeting Invite Wed. December 16, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.6

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.7 Meeting Invite Wed. January 6, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

We held our last meeting of the year today, here are the meeting notes: http://eavesdrop.openstack.org/meetings/defcore/2015/defcore.2015-12-16-16.00.html

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.7

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.8 Meeting Invite Wed. January 13, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Last meeting notes: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-01-06-16.00.html

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.8

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Huawei Juno based distro passes 2015.05; same code fails 2015.07. Incompatible API test change from 2015.05 to 2015.05/07

Hi, folks.

 

This is the email I sent to the interop@openstack.orb and the co-chairs of DefCore.  From today's DefCore meeting, I am posting this to the mailing list for discussion and hopefully resolution.  Mark Voelker said that other vendors had also had the same issue.  TL;DR  a set of Nova tests changed between the time 2015.05 build SHA was captured and the 2015.07 SHA was captured.  The changed tests were intended for the LIberty release, as they were not proposed/merged until after the Kilo release  Kilo release was April; changes to tests were merged June 19 (definitely in the Liberty cycle).

 

Thanks,

--Rocky

 

Below, is more info on Huawei's situation:

 

 

Huawei has a problem we hope you can help us with.  Our FusionSphere 6.0, based on Juno, qualified for  the "interop" OpenStack Powered (tm) program on the 2015.05 DefCore tests.  We are now trying to qualify our Public cloud offering, running the exact same FusionSphere/OpenStack software but cannot pass a subset of the Nova tests.

 

Huawei uses Nova api V2 (not V2.1).  As such, our implementation has "Additional Properties" enabled and used.  These are supposedly valid operations for the Juno release.

 

The tests in question were changed via https://review.openstack.org/#/c/156130.  AdditionalProperties were changed to "False" in all of the tests included in the review.

 

The problem is that Juno was released in October of 2014, with AdditionalProperties (extenstions) allowed in the v2 apis.  The tests were changed for the Kilo release cycle, but affect the Juno releases under the Interop/DefCore/Refstack test selection process because of the nonbranching nature of Tempest. 

 

We think a waiver is appropriate in this situation, as the Huawei code has not changed, yet it now fails API tests that were valid three months earlier.  We think that including the v2 api in the changes in theseDefCore  tests was a mistake, as the discussion below indicates, and that more care needs to be exercised when test changes are made to enforce new behaviors for later release cycles.  We would be happy to demonstrate that our release still passes the failed tests under the older version of those tests that exist in 2015.05. 

 

We have been working diligently to get the certification on our Public Cloud product, and had hoped to qualify/certify before the release of the 2016.01 standards, as our development resources are currently focused on moving our product to a more current  OpenStack release.

 

Please advise us as to how we proceed from here.

 

 

Respectfully,

Rocky Grober and our FusionSphere team

 

an excerpt from one of the changed files:

 

The problem of a backward incompatibility to an API being introduced by test changes was mentioned in one an exchange in comments:

 

afazekas

Mar 17, 2015

Patch Set 31: Code-Review-1

Does not makes sense to prevent additional properties in tempest on something which allows extensions.

Ghanshyam Mann

Mar 18, 2015

Patch Set 31:

@afazekas - Thanks for review.

Actually all schema has been modified to work for all extension (as current tests runs for all extension enable).

As v2 (v2.1) API are frozen, tempest should have additionalProperties False to capture any unwanted changes in those API.

afazekas

Mar 18, 2015

Patch Set 31:

https://wiki.openstack.org/wiki/APIChangeGuidelines

"Adding a property to a resource representation" is generally acceptable.

"Changing or removing a property in a resource representation" OR "Changing the semantics of a property in a resource representation which may be supplied by clients" is generally not acceptable.

We do not need to prevent additional properties.

Ghanshyam Mann

Mar 19, 2015

Patch Set 31:

Yea, those are acceptable and it used to done by adding new extension etc. But as v2 nd v2.1 are frozen and no new extension for thosse. All new attributes etc can be added with microversion only. As it is done for first microversion - https://review.openstack.org/#/c/140313/

Please do let me know if m missing anything on this.

Ken'ichi Ohmichi

Mar 19, 2015

Patch Set 31: Code-Review+2

Yeah, Ghanshyam is right.

As http://lists.openstack.org/pipermail/openstack-dev/2015-February/057613.html , new attributes will be added with microversions and v2(v2.1) should be frozen. So this change is necessary for blocking additional attributes on v2 and v2.1 API.

 

On Jan 6, 2016, at 8:55 PM, Rochelle Grober rochelle.grober@huawei.com wrote:

Hi, folks.

This is the email I sent to the interop@openstack.orb and the co-chairs of DefCore. From today's DefCore meeting, I am posting this to the mailing list for discussion and hopefully resolution. Mark Voelker said that other vendors had also had the same issue.

Thanks for writing in, Rocky. Actually what I said was that this potential issue had been discussed before, but that in 6.5 months this is the first time we’ve actually had someone report it. =) Here are the historical references I provided on the etherpad you originally posted this to yesterday for discussion:

===

I brought this up on the DefCore mailing list in June:

http://lists.openstack.org/pipermail/defcore-committee/2015-June/000849.html

I believe we discussed it some at the midcycle as well after having it on the weekly agenda for a couple of weeks:

https://etherpad.openstack.org/p/DefCoreFlag.5
https://etherpad.openstack.org/p/DefCoreFlag.6
https://etherpad.openstack.org/p/DefCoreFlag.MidCycle

And I believe it’s come up in-channel a couple of times too…one I could put my finger on quickly is here; there are probably others:

http://eavesdrop.openstack.org/irclogs/%23openstack-defcore/%23openstack-defcore.2015-06-24.log.html#t2015-06-24T23:16:06

This originated with an announcement about the change on the openstack-dev list in February:

I’m not sure there was ever a formal statement about it, but I believe generally the consensus from nova-core et al was that vendor modification of API responses (even if they were adding additional info rather than changing or removing info) was never really ok from an interoperability standpoint anyway (and violated the API Change Guidelines per openstack-dev discussion above), and the tempest change was deemed to help make that more clear. There was some discussion [from John Garbutt and Ken’ichi Ohmichi whom I’ve CC'd here] around whether the change should apply to the 2.1 API only (instead of 2.0 and 2.1), but AFAIK the sentiment never really generated enough support for someone to bother submitting a patch to change it in the gate.

On the DefCore side, I recall some discussion that if there were any affected vendors (in 6.5 months this is actually the first time we’ve actually had someone report it) could simply use a version of Tempest that predates the change since we do not currently require a specific version of Tempest (though refstack-client does have a setting that uses a specific Tempest version specified by a SHA by default). I recall warning at the time that this probably wouldn’t work in the long run since bugfixes to Tempest would eventually mandate that a newer version be used (see IRC link above), but again: sentiment seemed to be that since modifying API responses was never going to be interoperable anyway, that might simply be both a stopgap folks could use in the short term and incentive to stop modifying API responses in the longer term.

===

So with that historical context provided: a couple of questions for you.

1.) Is the intent here to ask for a flag on the tests that are failing for you? If so, the most appropriate thing to do may be to open a request via gerrit and we’ll discuss it there.

2.) Also, are you attempting to pass 2015.05 or 2015.07? If the former, have you tried simply rolling back to an earlier Tempest SHA that predates the additionalProperties change as suggested above? I believe there’s a good chance you’d be able to pass 2015.05 by doing so. The additionalProperties change was f0c30bc, so 968f1b3 would be the commit before that.

3.) How are you injecting additional properties into the API responses? E.g. have you changed nova-api code to do so? I ask because the API code (other than extensions) is currently a designated section in both the 2015.05 and 2015.07 guidelines:

https://github.com/openstack/defcore/blob/master/2015.05.json#L540
https://github.com/openstack/defcore/blob/master/2015.07.json#L1468

At Your Service,

Mark T. Voelker

TL;DR a set of Nova tests changed between the time 2015.05 build SHA was captured and the 2015.07 SHA was captured. The changed tests were intended for the LIberty release, as they were not proposed/merged until after the Kilo release Kilo release was April; changes to tests were merged June 19 (definitely in the Liberty cycle).

Thanks,
--Rocky

Below, is more info on Huawei's situation:


Huawei has a problem we hope you can help us with. Our FusionSphere 6.0, based on Juno, qualified for the "interop" OpenStack Powered (tm) program on the 2015.05 DefCore tests. We are now trying to qualify our Public cloud offering, running the exact same FusionSphere/OpenStack software but cannot pass a subset of the Nova tests.

Huawei uses Nova api V2 (not V2.1). As such, our implementation has "Additional Properties" enabled and used. These are supposedly valid operations for the Juno release.

The tests in question were changed via https://review.openstack.org/#/c/156130. AdditionalProperties were changed to "False" in all of the tests included in the review.

The problem is that Juno was released in October of 2014, with AdditionalProperties (extenstions) allowed in the v2 apis. The tests were changed for the Kilo release cycle, but affect the Juno releases under the Interop/DefCore/Refstack test selection process because of the nonbranching nature of Tempest.

We think a waiver is appropriate in this situation, as the Huawei code has not changed, yet it now fails API tests that were valid three months earlier. We think that including the v2 api in the changes in theseDefCore tests was a mistake, as the discussion below indicates, and that more care needs to be exercised when test changes are made to enforce new behaviors for later release cycles. We would be happy to demonstrate that our release still passes the failed tests under the older version of those tests that exist in 2015.05.

We have been working diligently to get the certification on our Public Cloud product, and had hoped to qualify/certify before the release of the 2016.01 standards, as our development resources are currently focused on moving our product to a more current OpenStack release.

Please advise us as to how we proceed from here.


Respectfully,
Rocky Grober and our FusionSphere team

an excerpt from one of the changed files:
<image001.gif>

The problem of a backward incompatibility to an API being introduced by test changes was mentioned in one an exchange in comments:

afazekas
Mar 17, 2015

Patch Set 31: Code-Review-1

Does not makes sense to prevent additional properties in tempest on something which allows extensions.
Ghanshyam Mann
Mar 18, 2015

Patch Set 31:

@afazekas - Thanks for review.

Actually all schema has been modified to work for all extension (as current tests runs for all extension enable).

As v2 (v2.1) API are frozen, tempest should have additionalProperties False to capture any unwanted changes in those API.
afazekas
Mar 18, 2015

Patch Set 31:

https://wiki.openstack.org/wiki/APIChangeGuidelines

"Adding a property to a resource representation" is generally acceptable.

"Changing or removing a property in a resource representation" OR "Changing the semantics of a property in a resource representation which may be supplied by clients" is generally not acceptable.

We do not need to prevent additional properties.
Ghanshyam Mann
Mar 19, 2015

Patch Set 31:

Yea, those are acceptable and it used to done by adding new extension etc. But as v2 nd v2.1 are frozen and no new extension for thosse. All new attributes etc can be added with microversion only.
As it is done for first microversion -

https://review.openstack.org/#/c/140313/

Please do let me know if m missing anything on this.
Ken'ichi Ohmichi
Mar 19, 2015

Patch Set 31: Code-Review+2

Yeah, Ghanshyam is right.

As
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057613.html
, new attributes will be added with microversions and v2(v2.1) should be frozen. So this change is necessary for blocking additional attributes
on v2 and v2.1 API.



Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore mid-cycle date and location selection voting

Hello Everyone,

Please vote on the dates/locations for the mid-cycle. The locations are tentative for now, after the votes come in, we will work on location details.

http://doodle.com/poll/p66ts9hfp6wx75vu

Please let me know if you have any questions.
Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.9 Meeting Invite Wed. January 20, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Last meeting notes: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-01-13-16.00.html

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.9

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Reviewing RefStack Requirements

Hello DefCore Committee,

If you have not had a chance, please review the RefStack requirements document. Commenting is enabled, so even if you are not able to attend tomorrow's meeting in person, your comments will be seen.
https://docs.google.com/document/d/1s_dAIuluztlCC6AZ-WO4_FR2CLje1QyS6kbMxlFHaMk/edit?usp=sharing

Thank you very much!
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] My time ending as DefCore CoChair. DefCore mission remains essential

DefCore,

I want to thank everyone for your support during the last few years as we
worked together accomplish DefCore. This was a hard challenge and I'm
proud of what we built together. I believe our continued efforts are
essential to OpenStack success in the market both for the software and the
ecosystem that we hope to create.

That work is far from over; however, it's time for me to step back and
allow another person to steward the process. Egle, Alan and I all believe
that my replacement does NOT have to be a standing board member. They will
ask the board to confirm that position.

Egle is an amazing leader and has been a tremendous benefit for DefCore but
she cannot do it alone. By design, leading DefCore is a collaborative
effort and I'm looking forward to seeing who you select for the new CoChar.

I will remain involved as needed and continue to both advise DefCore and
serve as historian. My attention is turning from single platform interop
(DefCore) toward cross-platform interop (Hybrid Devops). In that role, I
may be able to bring added perspective into the OpenStack efforts.

Thank you.

Rob
--
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Rob,

Your stewardship will be missed! No doubt DefCore will continue to reap fruits of the seeds you’ve sown for some time to come.

Lee

On Jan 25, 2016, at 10:02 AM, Rob Hirschfeld rob@rackn.com wrote:

DefCore,

I want to thank everyone for your support during the last few years as we worked together accomplish DefCore. This was a hard challenge and I'm proud of what we built together. I believe our continued efforts are essential to OpenStack success in the market both for the software and the ecosystem that we hope to create.

That work is far from over; however, it's time for me to step back and allow another person to steward the process. Egle, Alan and I all believe that my replacement does NOT have to be a standing board member. They will ask the board to confirm that position.

Egle is an amazing leader and has been a tremendous benefit for DefCore but she cannot do it alone. By design, leading DefCore is a collaborative effort and I'm looking forward to seeing who you select for the new CoChar.

I will remain involved as needed and continue to both advise DefCore and serve as historian. My attention is turning from single platform interop (DefCore) toward cross-platform interop (Hybrid Devops). In that role, I may be able to bring added perspective into the OpenStack efforts.

Thank you.

Rob
--
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Updating DefCore CoChair Description in the process document

Hello DefCore,

For the past year, the DefCore Committee has been operating with a lot of input and hard work from the community, with two CoChairs and board oversight. Both me and Rob have been Board members, however, our process documents do not specify that both CoChairs must be board members. After some discussion with Alan Clark (chairman of the foundation) and Rob, we would like to formalize the DefCore as a Working group with Board oversight, with two co-chairs. It is essential that both the board and the community are involved. I am proposing a change to the process document to have one board member as a co-chair and one co-chair elected by the committee/working group.

https://review.openstack.org/#/c/271908/

This is a bit short notice, and I would really appreciate your feedback. If there are no major disagreements, I would like to propose this change during tomorrow afternoon's board meeting for board's approval. Please review and let me know if you have any questions.

Thank you,
Egle Sigler


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.10 Meeting Invite Wed. January 27, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Last meeting notes: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-01-20-16.00.html

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.10

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Please review Board Report for January 26th, 2016

Hello Everyone,

Tuesday afternoon during the board meeting I will be asking for board's approval for 2016A process changes as well as to approve 2016.01.json guidelines. I will be sharing the following report with the board, please review and let me know if you have any questions/comments.

https://docs.google.com/document/d/1D7hM4kJkfS7PNUpmeRmL_CvwoHZS3CW7k6EELgsfaY8/edit?usp=sharing

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore CoChair elections on February 3rd, 2016

Hello DefCore,

Today during the board meeting the board approved 2016.01 guideline as well as the 2016A process document. One of the changes to the process document was changing co-chair description, B4.5: https://github.com/openstack/defcore/blob/master/doc/source/process/2016A.rst

"One DefCore CoChair needs to be elected by DefCore working group. Election quorum is composed of attendees present during the election meeting."

This means we will be electing CoChair during our weekly meeting on February 3rd, 2016 at 10 AM CST. If you have suggestions on election format please let me know.
Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Egle,

Oops, I didn't see the election is on the 3rd. I'll be at that meeting.

Thanks,
Chris

On Jan 26, 2016, at 6:43 PM, Egle Sigler egle.sigler@rackspace.com wrote:

Hello DefCore,

Today during the board meeting the board approved 2016.01 guideline as well as the 2016A process document. One of the changes to the process document was changing co-chair description, B4.5: https://github.com/openstack/defcore/blob/master/doc/source/process/2016A.rst

"One DefCore CoChair needs to be elected by DefCore working group. Election quorum is composed of attendees present during the election meeting."

This means we will be electing CoChair during our weekly meeting on February 3rd, 2016 at 10 AM CST. If you have suggestions on election format please let me know.
Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] CoChair Elections! And DefCore Ring.10 Meeting Invite Wed. February 3, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

During this meeting, we will be electing DefCore CoChair, followed by other agenda items.

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.11

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] CoChair Elections! And DefCore Ring.11 Meeting Invite Wed. February 3, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

During this meeting, we will be electing DefCore CoChair, followed by other agenda items.

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.11

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Rob), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Nominations for DefCore CoChair election are now open

Hello DefCore,

Today during our meeting we discussed the best way to run DefCore CoChair elections, and we are going to follow the model for PTL elections. We will use emails for nominations.

To nominate yourself or someone else: please send an email to defcore-committee@lists.openstack.org mailing list starting now with subject "DefCore CoChair Candidacy", until February 3rd, 8 AM CST (14:00 UTC).
If you are nominating someone else, nominee must reply to the list accepting the nomination by February 3rd, 8 AM CST (14:00 UTC). I will confirm each candidate, if you do not receive confirmation, let me know.

Please include a brief paragraph of why you are running for DefCore CoChair.

Who is eligible to run for CoChair and who will be able to vote:
1. Participants of DefCore meetings: must have participated in at least 3 DefCore meetings in the last 6 months.
2. Submitters of patches to DefCore repository in the last 6 months.

If you were not able to participate in today's meeting, please review the notes regarding elections here: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-01-27-16.00.html

Voting for cochair will start on February 3rd, and end February 10th at 6 AM CST (12:00 UTC). We will use Condorcet method assuming there are more than one nominations.

Let me know if you have any questions.

Thank you,
Egle Sigler


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

All,

I'd like to nominate Mark Voelker as co-chair.

In many ways, he's already been working as a back-up chair during meetings
so the transition would be smooth. He's also proven to have an attention
to detail and process that is important to the role.

Rob
On Wed, Jan 27, 2016 at 12:00 PM Egle Sigler egle.sigler@rackspace.com
wrote:

Hello DefCore,

Today during our meeting we discussed the best way to run DefCore CoChair
elections, and we are going to follow the model for PTL elections. We will
use emails for nominations.

To nominate yourself or someone else: please send an email to
defcore-committee@lists.openstack.org mailing list starting now with
subject “DefCore CoChair Candidacy", until February 3rd, 8 AM CST (14:00
UTC).
If you are nominating someone else, nominee must reply to the list
accepting the nomination by February 3rd, 8 AM CST (14:00 UTC). I will
confirm each candidate, if you do not receive confirmation, let me know.

Please include a brief paragraph of why you are running for DefCore
CoChair.

Who is eligible to run for CoChair and who will be able to vote:
1. Participants of DefCore meetings: must have participated in at least 3
DefCore meetings in the last 6 months.
2. Submitters of patches to DefCore repository in the last 6 months.

If you were not able to participate in today’s meeting, please review the
notes regarding elections here:
http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-01-27-16.00.html

Voting for cochair will start on February 3rd, and end February 10th at 6
AM CST (12:00 UTC). We will use Condorcet method assuming there are more
than one nominations.

Let me know if you have any questions.

Thank you,
Egle Sigler


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore MidCycle Day 1 of 2

Hello DefCore,

Please join us for MidCycle in Austin, TX, March 8-9. Big thanks to IBM for hosting us again!

Location:
IBM Briefing Center (Bldg 904)
11501 Burnet Rd.
Austin, TX 78758

Llano room

Agenda:
https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

-Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Agenda is now updated!

Hello DefCore,

Please join us for MidCycle in Austin, TX, March 8-9. Big thanks to IBM for hosting us again!

Location:
IBM Briefing Center (Bldg 904)
11501 Burnet Rd.
Austin, TX 78758

Llano room

Agenda:
https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

-Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore MidCycle Day 2 of 2

Hello DefCore,

Please join us for MidCycle in Austin, TX, March 8-9. Big thanks to IBM for hosting us again!

Location:
IBM Briefing Center (Bldg 904)
11501 Burnet Rd.
Austin, TX 78758

Llano room

Agenda:
https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

-Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Agenda now updated!

Hello DefCore,

Please join us for MidCycle in Austin, TX, March 8-9. Big thanks to IBM for hosting us again!

Location:
IBM Briefing Center (Bldg 904)
11501 Burnet Rd.
Austin, TX 78758

Llano room

Agenda:
https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

-Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Co-chair: Mark Voelker

Hello DefCore Community,

I am pleased to announce that Mark Voelker is our new co-chair for DefCore. Mark has been very active in the DefCore community, and he is perfect for this role.

Everyone, please help me in congratulating Mark on his new role!

Thank you,
Egle Sigler


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

On Feb 3, 2016, at 12:22 PM, Egle Sigler egle.sigler@rackspace.com wrote:

Hello DefCore Community,

I am pleased to announce that Mark Voelker is our new co-chair for DefCore. Mark has been very active in the DefCore community, and he is perfect for this role.

Everyone, please help me in congratulating Mark on his new role!
Congratulations Mark!!

Thank you,
Egle Sigler


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.12 Meeting Invite Wed. February 10, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Notes from previous meeting: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-02-03-15.59.html
Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.12

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.12 Meeting Invite Wed. February 17, 10:00 AM CST/ 16:00 UTC

Update: No meeting on February 10, 2016, will meet again on February 17th.
Thank you,
Egle

Hello Everyone,

Notes from previous meeting: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-02-03-15.59.html
Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.12

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] No Meeting Tomorrow (February 10)

Hello DefCore,

We are canceling tomorrow's meeting since Chris, myself, and Mark have other commitments. We will resume on February 17th.
In the meantime, if you have any questions or comments, please send us an email or contact via IRC.

Thank you,
Egle Sigler


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Ideas to speed up DefCore's fight for interoperability

Hi,

DefCore, in its current form, is doing a great job of defining things
that should work on all OpenStack deployments. Stopping the divergence
of OpenStack APIs is super important, and this is working.

But I think we are hitting issues with getting projects engaged on
driving forward the cause of interoperability, and its proving tricky
to expand beyond the base set of required operations.

If we look a few years ahead, I would love to see a broad ecosystem of
applications written to run against any certified OpenStack Compute
cloud. In addition, some applications may need some additional
capabilities (configure network routers, needs object storage, etc). I
am thinking about the next generation of this:
http://apps.openstack.org/

I think DefCore can help make that dream become a reality.

To reach that goal more quickly, I think should change direction
slight, and consider these three ideas:

1: Focus on Uses cases

Lets define the use cases application developers need for the above
vision to become reality. Thats helps projects engage with the
problems that need solving. Sometimes the API exists, sometimes there
is a possible workflow to do this in an interoperable way, other times
a new API or APIs might be needed. These patterns can then be used to
create applications that work across all OpenStack certified clouds. I
think the product working group may be able to help.

2: Validating Optional Capabilities

While its important to define "things that should work everywhere" I
think its important to define "if available, it should work the same
way everywhere". This requires that the project APIs work on policy
discovery, so you can tell if an API is available in a particular
deployment or not. Its possible we end up defining the minimum
standard as having one of n choices available (assuming there is a
workflow that lets you pick between them, ideally an abstract API
would hide that complexity, but thats not always possible).

  1. Working with App Developers to test this

One idea to make this all real is to look at the existing apps in the
marketplace app store, and look at ways to make them work with all
certified OpenStack deployments/products. I think this is likely to
involve working out how to bootstrap their images from an existing
base image in that deployment, and then maybe then share that image
with other users of that clouds. (FWIW, I feel importing a full image
avoids any work each cloud has done to optimise their particular
environment, and many other issues). It might be certain apps are
supported on particular certified products, but thats not the aim. The
aim is to get apps that users can run on all certified products.

What do you all think? Does this look like the seeds of a good idea?
Or is there something I am totally missing here?

Thanks,
johnthetubaguy


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi John,

Thanks for writing this up John! A few comments:

On Feb 10, 2016, at 1:25 PM, John Garbutt john@johngarbutt.com wrote:

Hi,

DefCore, in its current form, is doing a great job of defining things
that should work on all OpenStack deployments. Stopping the divergence
of OpenStack APIs is super important, and this is working.

But I think we are hitting issues with getting projects engaged on
driving forward the cause of interoperability, and its proving tricky
to expand beyond the base set of required operations.

I’ll just chime in here to say that with my DefCore hat on, I’m interested to hear feedback from devs on those projects as to why this is. =)

If we look a few years ahead, I would love to see a broad ecosystem of
applications written to run against any certified OpenStack Compute
cloud. In addition, some applications may need some additional
capabilities (configure network routers, needs object storage, etc). I
am thinking about the next generation of this:
http://apps.openstack.org/

I think DefCore can help make that dream become a reality.

To reach that goal more quickly, I think should change direction
slight, and consider these three ideas:

1: Focus on Uses cases

Lets define the use cases application developers need for the above
vision to become reality. Thats helps projects engage with the
problems that need solving. Sometimes the API exists, sometimes there
is a possible workflow to do this in an interoperable way, other times
a new API or APIs might be needed. These patterns can then be used to
create applications that work across all OpenStack certified clouds. I
think the product working group may be able to help.

+1 for considering use cases. This is something I’ve been kicking around a bit myself but haven’t managed to write up yet. I have admittedly not been thinking about looking at use cases through the lens of the Community App Catalog though, for reasons I’ll get to a bit further down. =)

Instead, I’ve been thinking about the use cases for which OpenStack seems to be frequently deployed for today per the user survey (and other industry reports). For those reading along who aren’t familiar, the user survey has some questions about what workloads, frameworks, and stacks are running on top of OpenStack. As an example, the most popular stack in the last survey was the LAMP stack by a large margin, and the most popular workload was “Software dev/test/QA and CI” by a substantial margin. However the findings are sort of…generic?...and therefore a bit tricky to use as actionable intelligence, but are a good starting point nonetheless in that they give us some areas of focus if not specifics. Certainly there are some well known users of OpenStack in the community who can help fill in details of how they’re using OpenStack for those things (our own infra team being one example, and one that we’ve looked at in the past…I know I for one have perused shade’s code more than once, for instance).

That said, I also want to be careful to point out that I’d like for us not to simply focus on use cases people are deploying OpenStack for today, but also what opportunities we’d uncork tomorrow if we solved a few problems. Gauging that involves a little bit of gazing into the old crystal ball, but I think it’s a worthwhile exercise and I’d be happy to hear inputs. Since I’ve already mentioned the user survey, I should also point out that it already has some questions related to what new/emerging tech users are interested in (containers, NFV, PaaS, IoT, etc). Again: sort of generic, but perhaps a starting point.

2: Validating Optional Capabilities

While its important to define "things that should work everywhere" I
think its important to define "if available, it should work the same
way everywhere". This requires that the project APIs work on policy
discovery, so you can tell if an API is available in a particular
deployment or not. Its possible we end up defining the minimum
standard as having one of n choices available (assuming there is a
workflow that lets you pick between them, ideally an abstract API
would hide that complexity, but thats not always possible).

There’s been some discussion around this in the past in a couple of different lights. First, API and policy discoverability has come up as a pain point more than once. At the next DefCore midcycle we’ll be starting to plot out the first report on major barriers to interoperability that we intend to deliver periodically to the TC/UC, and this is one that’s squarely on my candidate list for inclusion.

Second, we’ve also had interest from some in the community in having a sort of comparison matrix of supported features. The OpenStack Powered (TM) logo gives you some level of interoperability at a glance, which is simple and good. But you might also be interested in features that are less frequently included and want to know what clouds/products support them. One concrete example: we had a request a while back to show what products supported EC2 compatibility (and to what degree, by showing a set of test results in RefStack). We’ve also had suggestions that there might need to be a special set of capabilities or even a special logo program for specialized use cases (the most oft-sited one being NFV). That sort of thing kind of gets to the general notion of “if available, it should work the same way AND I have a way to figure out what products support the things I actually need whether regardless of whether they’re ‘core' or not".

To some degree I think those sorts of things haven’t yet come to fruition in part because there’s been a focus on getting a solid set of capabilities to define “core OpenStack” before moving on to adjacent things…but we’re now a good deal further along with that than we were even six months ago (we have advisory networking capabilities for the first time! And etc.), so perhaps it’s time to revisit. Naturally these things don’t come without costs so we’d need to line up some manandwomanpower to help…

/me smiles politely and winks at everyone reading this email

  1. Working with App Developers to test this

One idea to make this all real is to look at the existing apps in the
marketplace app store,

Hmmm.

By my count there’s about 40 Murano packages, 6 Heat templates, and 39 Glance images in the Community App Catalog today. Some of those aren’t really apps in a business-problem-solving sense; they’re things like generic Debian or CentOS images, a Hello World Heat template, or things like MySQL packages that generally would be one part of an application (say, an e-commerce app) rather than a full app of it’s own right. All of the Murano packages are built for Kilo or newer...recall that in the last user survey Juno and Icehouse were still with a few points of Kilo in terms of popularity and were more popular in production environments, so there’s some lag in getting OpenStack releases to production to consider. Murano itself is used in only about 4% of production installs per the last user survey. I also don’t think there’s a good way to see which apps in the catalog are popular and which are rarely ever downloaded. Mapping apps in the Community App Catalog to use cases is also a bit tricky in that many of the packages there are sort of components of a full app or use case…for instance, I can get a Jenkins package from the catalog and I can get a LAMP stack glance image and I can get Chef server Heat template, but I have to cobble those and a few more things together to actually build a CI system to deploy and test the e-commerce app I’m developing (which is all maps back to the aforementioned "Software dev/test/QA and CI” workload from the user survey). Anecdotally, a lot of the customers I’ve worked with over the past few years are building in-house apps on top of their clouds (I’ll mention e-commerce here again…you probably don’t see a lot of the of application code behind your favorite e-tailer’s website in the Community App Catalog, though you might see some of it’s underpinning components like databases, OS images, or CI tools).

All that said: I’m not trying to pick on the Community App Catalog here at all. It’s still in beta, so I’m merely wondering if what’s there today is really a useful indicative set, or if instead it’s something we should revisit when it’s a bit more mature. I think your bigger point, though, is how to get to a place where people want to create the templates/packages/images they contribute to the Community App Catalog to be able to run on more OpenStack clouds and have good guidance on how to do so. That’s a fantastic goal, I’m just not sure if what’s in the app catalog today is the right starting point.

and look at ways to make them work with all
certified OpenStack deployments/products. I think this is likely to
involve working out how to bootstrap their images from an existing
base image in that deployment, and then maybe then share that image
with other users of that clouds. (FWIW, I feel importing a full image
avoids any work each cloud has done to optimise their particular
environment, and many other issues). It might be certain apps are
supported on particular certified products, but thats not the aim. The
aim is to get apps that users can run on all certified products.

I’m curious what the mechanics of this might look like. For example: are you thinking of a sort of CI approach, where when a new app is published to the community app catalog each vendor sets up a CI system that tries to deploy it to their OpenStack Powered (TM) product and reports whether it works or not? Or coming at it from the other direction, perhaps we work out a way to figure out which API’s and other capabilities the app relies on and then compare that to a listing of what each product claims to support? Or perhaps something else?

What do you all think? Does this look like the seeds of a good idea?
Or is there something I am totally missing here?

I think you’ve raised several good points for discussion—thanks!

At Your Service,

Mark T. Voelker

Thanks,
johnthetubaguy


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Voting for DefCore and RefStack talks for the Austin summit

Hello DefCore,

There are a couple talks submitted on DefCore and Refstack, please help us out by voting and promoting them.

Interoperability: The Elephants in the Room & What We're Doing About Them: https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/8645
Making Cloud Interoperability across OpenStack vendors a possibility using RefStack: https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7575

Let us know if you have submitted something else on DefCore or Refstack.
Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Dietary Restrictions for DefCore Midcycle Poll

Hello Everyone,

IBM is very kind to host our DefCore midcycle meeting, and they are also providing lunch on both days. Please indicate whether you have any dietary restrictions. This poll will hide the options from other people in case you don't wish to be public.

http://doodle.com/poll/ewsiepmhv9p6r8e7

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] RefStack development related questions

Hi,

After several recent DevCore meetings some of the questions regarding
development decisions for RefStack were answered however some still
remain. And during yesterday's meeting some more had arisen.
Catherine suggested to write to this list in order to speed up the
process and not wait for the next DefCore meeting so here it is:

  1. Vendors registration information

There was a decision made that Vendor registration will be implemented
in RefStack with subsequent approval by Foundation admins in
corresponding admin interface in RefStack.
During this registration new Vendor-to-be will have to enter some
information related to his/her Organization. In the OpenStack
Marketplace (example:
https://www.openstack.org/marketplace/hosted-private-clouds/unitedstack/uos-managed-private-cloud)
we can see that each Vendor besides the name has at least "about" and
"commitment" filled in. I think some other hidden fields might be of
interest for DefCore as well.

Hence a couple of questions:
A) Would it be possible that RefStack will be used as a source or one of
the sources for new Vendors who want to register?
B) What information about Vendor should RefStack show on Vendor details
page?

Options:
A) The first question (if the answer is potentially yes) means that
we'll have to collect all of the required information for DefCore in
regard to new registering Vendor. We'll need to know what is it then.
If the answer is no then see the second question.

B) The second one - we'll have to show something besides the name and I
think information might as well correspond to what's in Marketplace
because we speak about the same Vendors here. What is it exactly (which
fields) and where to get them - ask user during registration I guess?

  1. Visibility of users registered in RefStack

We understand that the idea is to limit exposure of information.
However, there is a couple of use-cases which we'll have to implement:

Questions:
A) Vendor admin wants to add another admin for the Vendor. How do we
allow him/her to find who to add?
B) Various data we show (Vendors, Clouds, Software, test resuts... etc)
have owners and admins, people responsible for it. The question is how
do we show it if we do?

Options:
A) We've got users in various roles in this regard: Guest, regular User,
officially registered Vendor admin, Foundation admin.
Usual way of choosing something you need to select is to show list with
ability to search through it. That's what I suggest here, obviously.
Who to show it to?
Possibility of adding other users as admins to Vendors is open for
official Vendors admins only (for now). So we can limit access to lists
of all users and search to official Vendors admins and to Foundation admins.

However, there might be another reason to allow showing registered users
even to Guests. The same one which caused showing OpenStack summit
attendees to anyone in the OpenStack site. At least the login name is
displayed, however user can allow more information to be shown.
I'm not sure what reason was there to disclose this information but I
think it can be as good for RefStack. In which case lists of users
should be available to even Guests. Or we can limit it to regular Users.

B) Information about the team managing particular project in launchpad,
or about people responsible for something in OpenStack is usually open
and available. I believe we might want to display something of the kind
for our data, especially official stuff - Vendors, Clouds, Software.
What should it be? What can be shown? Wouldn't it make not listing users
to anyone useless if we show it?

Hope the above is clear enough for discussion and getting some answers
as soon as possible.

Best regards,
Alex Levine


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi Alex,

Thanks for writing this up! Some thoughts inline...

On Feb 18, 2016, at 9:59 AM, Alexandre Levine alexandrelevine@gmail.com wrote:

Hi,

After several recent DevCore meetings some of the questions regarding development decisions for RefStack were answered however some still remain. And during yesterday's meeting some more had arisen.
Catherine suggested to write to this list in order to speed up the process and not wait for the next DefCore meeting so here it is:

  1. Vendors registration information

There was a decision made that Vendor registration will be implemented in RefStack with subsequent approval by Foundation admins in corresponding admin interface in RefStack.
During this registration new Vendor-to-be will have to enter some information related to his/her Organization. In the OpenStack Marketplace (example: https://www.openstack.org/marketplace/hosted-private-clouds/unitedstack/uos-managed-private-cloud) we can see that each Vendor besides the name has at least "about" and "commitment" filled in. I think some other hidden fields might be of interest for DefCore as well.

Hence a couple of questions:
A) Would it be possible that RefStack will be used as a source or one of the sources for new Vendors who want to register?
B) What information about Vendor should RefStack show on Vendor details page?

Options:
A) The first question (if the answer is potentially yes) means that we'll have to collect all of the required information for DefCore in regard to new registering Vendor. We'll need to know what is it then.

I think in an ideal world it would be nice to not have information duplicated between the MarketPlace and RefStack (so conceivably the answer is yes). But given that today information about vendors is housed in the MarketPlace, might we have the opposite situation where a vendor registers with the Marketplace and RefStack uses that data, rather than the reverse? I’m not sure how realistic that is today—Chris Hoge might know better or at least be able to point to the right folks on the Marketplace team, so I’ll leave him to comment.

If the answer is no then see the second question.

B) The second one - we'll have to show something besides the name and I think information might as well correspond to what's in Marketplace because we speak about the same Vendors here. What is it exactly (which fields) and where to get them - ask user during registration I guess?

Here again, it feels like we want to not duplicate information when possible…if we can get the MarketPlace data, great. If not, maybe just a link to the vendor’s MarketPlace entry would suffice.

  1. Visibility of users registered in RefStack

We understand that the idea is to limit exposure of information.
However, there is a couple of use-cases which we'll have to implement:

Questions:
A) Vendor admin wants to add another admin for the Vendor. How do we allow him/her to find who to add?
B) Various data we show (Vendors, Clouds, Software, test resuts... etc) have owners and admins, people responsible for it. The question is how do we show it if we do?

Options:
A) We've got users in various roles in this regard: Guest, regular User, officially registered Vendor admin, Foundation admin.
Usual way of choosing something you need to select is to show list with ability to search through it. That's what I suggest here, obviously.

At the risk of turning this into a UX discussion: I wonder if searching and pick lists are actually necessary? E.g. if I go off the assumptions (please shout if you think these aren’t valid) that:

1.) A vendor admin and another employee of the company who wants to become a vendor admin presumably have an easy way to exchange information outside of RefStack (phone, email, face-to-face in some cases, etc) and likely regularly do so anyway as part of normal company operations. They could easily exchange, for example, OpenStackID’s.

2.) Entering one or more OpenStackID’s into a text field wouldn’t be prohibitively difficult. I could see this being a bit of a pain if we expected a single vendor to have hundreds of vendor admins or if new vendor admins needed to be added en masse very frequently, but I think that’s unlikely to be the case in reality.

If these are true, then I wonder if the simplest thing to do is simply give the vendor admin a text field into which he/she can type one or more OpenStackID’s rather than needing to search/find other users. Thinking about how I’d use this feature with my vendor hat on, this seems like it would be fast and easy to me and it’s something I do with other tools anyway. By way of example: if I want to add Bill to my organization on GitHub I phone/email/IM him to get his GitHub ID and type it into a text box in the GitHub UI. I’m no UI designer though, so feel free to take that as just another opinion. =)

Who to show it to?
Possibility of adding other users as admins to Vendors is open for official Vendors admins only (for now). So we can limit access to lists of all users and search to official Vendors admins and to Foundation admins.

However, there might be another reason to allow showing registered users even to Guests. The same one which caused showing OpenStack summit attendees to anyone in the OpenStack site. At least the login name is displayed, however user can allow more information to be shown.
I'm not sure what reason was there to disclose this information but I think it can be as good for RefStack. In which case lists of users should be available to even Guests. Or we can limit it to regular Users.

We discussed disclosure at the DefCore meeting this week and the general agreement was to err on the side of keeping information private unless there’s a good reason not to, as you alluded to earlier. So with that in mind: is there a use case for anonymous Guests to be able to see this information?

B) Information about the team managing particular project in launchpad, or about people responsible for something in OpenStack is usually open and available. I believe we might want to display something of the kind for our data, especially official stuff - Vendors, Clouds, Software. What should it be? What can be shown? Wouldn't it make not listing users to anyone useless if we show it?

I’d probably invoke the mantra of “what information is actually useful” again here as a general rule, and then tackle individual use cases. For example: if I’m looking at a test result, it’s useful for me to see what vendor and product it belongs to. If I’m looking at information that involves and individual, most systems (including OpenStackID and Launchpad) allow users to restrict what information is shown about them, so I would think linking to OpenStackID pages (e.g. https://openstackid.org/mark.voelker for example, or pulling data from OpenStackID and displaying it) would be a valid way of presenting that which allows users to a degree of control over information disclosure. Make sense?

Hope the above is clear enough for discussion and getting some answers as soon as possible.

Best regards,
Alex Levine

Thanks again Alex!

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.13 Meeting Invite Wed. February 24, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Notes from previous meeting: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-02-17-16.00.html
Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.13

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.14 Meeting Invite Wed. March 2, 10:00 AM CST/ 16:00 UTC

Hello Everyone,

Notes from previous meeting: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-02-24-16.00.html
Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.14

Note the meeting location: #openstack-meeting-3.

Meeting time has been adjusted for the lack of daylight savings. If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Dinner for Tuesday Night

Hello Everyone,

We have a poll to select a restaurant for Tuesday night. Please select 3 restaurants that you would prefer. Voting closes this Wednesday, March 2, at 2pm.
http://doodle.com/poll/x3n9yvdws9miyrck

Thanks Vince for coming up with the list and making the reservations!

Here is the list of restaurants with links and descriptions:
North Italiahttp://www.northitaliarestaurant.com/locations/austin/ - Nice Italian eatery with a nice atmosphere.

Blackfinn Ameripubhttp://blackfinnameripub.com/austin/ - Nice atmosphere with a wide selection of food and drink.

Maggiano'shttp://locations.maggianos.com/texas/austin/78758/10910-domain-dr-/ - Italian fare that is very good. They also have a nice drink menu and bar area.

Copper Restauranthttp://www.copperaustin.com/ - Local place serving local foods. Limited selection on main dishes, but the coffee and dessert menu is huge.

Fleming's Steakhousehttps://www.flemingssteakhouse.com/locations/tx/the-domain/ - A classic steak house

Gloria's Latinhttp://www.gloriascuisine.com/locations/austin-domain.html - Great Tex-Mex and margaritas

Jaspers Austinhttp://www.jaspersaustin.com/ - Steaks, seafood, salads and more. Wide variety in a nice atmosphere.

Kona Grillhttp://www.konagrill.com/locations/austin-tx - Hawaiin inspired fare. Large selection of entrees

Daily Grillhttp://www.dailygrill.com/locations/daily-grill-austin-texas/ - A little bit of everything for everyone. Good atmosphere as well.

McCormick and Schmick'shttp://www.mccormickandschmicks.com/Locations/austin-texas/austin-texas/centuryoaksterrace.aspx - A great steak house with many options for all appetites in a great atmosphere.

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Midcycle Agenda, Take 2

Folks,

Thanks for your input on the midcycle agenda at today’s meeting. I’ve updated the tentative agenda to reflect most of the requests that were made today as well as to accommodate some folks we know will be joining us remotely. The basic flow is now:

1.) We kick off with Scoring sessions on the morning of Day 1. This is stuff we mostly know how to do now, but which absolutely needs doing since we have to produce a Guideline in a few months. So we'll get the blocking and tackling done early and get our juices flowing. Since these are preliminary discussions, this also means that if we have a few folks trickling in late due to travel arrangements, they’ll still have plenty of chances to make their voices heard later in the scoring process.

2.) Once Scoring is done, we move to Strategy sessions in the afternoon of Day 1. These discussions are likely to be more intense and will inform much of our thinking for the remaining sessions in the midcycle, and the timeslot here is more friendly to some folks who’ve expressed an interest in joining us remotely.

3.) On the morning of Day 2, we kick of with sessions on Tests. These conversations are likely to have been influenced by our Strategy discussions on the previous day, but we’ll have had an evening to mull over what we talked about (and/or what we continued to talk about over dinner).

4.) Sandwiching the lunch break (see what I did there?) on Day 2 we’ll have the RefStack sessions, since those should dovetail nicely with Tests.

5.) Following lunch on Day 2 we’ll conclude with the Outcomes sessions (as well as a wrap-up to review action items and some time for parking lot discussions).

I’ve also dropped two sessions from the agenda: the "Publishing DefCore Information and Docs” session (which feels small enough that we could tackle it in any given weekly meeting or even with an ML discussion), and the “Strategy: Levels of Interoperability” session (because I think this will actually end up getting discussed in the “Value from DefCore” session anyway). This gives us a little more flexibility in the schedule, although it’s still a pretty full agenda. You’ll notice a few built-in “fudge time” sessions for each grouping, so we’ll have a little leeway if we need to run over on something or need to take a break.

Please review and let me know if there are any other suggestions before we finalize:

https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

See you in Austin!

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Thank you Mark for working on the agenda. I want to make the following changes though, as follows:
Scoring: move it to Wednesday afternoon. In case we run out of time for other discussions, this is something that we can cover in our regular meetings over IRC. I do think that with such a full agenda time will be at a premium and would like to discuss strategic topics and items we have been putting on the midcycle agenda for a while in person rather than over IRC.
Testing: move it to Tuesday morning. Ideally, this would be on a Tuesday afternoon, but because we cannot get user committee's feedback earlier, I think this will still work. The testing discuss can funnel into strategic discussion very easily.
Outcomes: move it to Wednesday morning, before scoring.

Thank you,Egle

From: mvoelker@vmware.com
To: defcore-committee@lists.openstack.org
Date: Thu, 3 Mar 2016 04:44:35 +0000
Subject: [OpenStack-DefCore] Midcycle Agenda, Take 2

Folks,

Thanks for your input on the midcycle agenda at today’s meeting. I’ve updated the tentative agenda to reflect most of the requests that were made today as well as to accommodate some folks we know will be joining us remotely. The basic flow is now:

1.) We kick off with Scoring sessions on the morning of Day 1. This is stuff we mostly know how to do now, but which absolutely needs doing since we have to produce a Guideline in a few months. So we'll get the blocking and tackling done early and get our juices flowing. Since these are preliminary discussions, this also means that if we have a few folks trickling in late due to travel arrangements, they’ll still have plenty of chances to make their voices heard later in the scoring process.

2.) Once Scoring is done, we move to Strategy sessions in the afternoon of Day 1. These discussions are likely to be more intense and will inform much of our thinking for the remaining sessions in the midcycle, and the timeslot here is more friendly to some folks who’ve expressed an interest in joining us remotely.

3.) On the morning of Day 2, we kick of with sessions on Tests. These conversations are likely to have been influenced by our Strategy discussions on the previous day, but we’ll have had an evening to mull over what we talked about (and/or what we continued to talk about over dinner).

4.) Sandwiching the lunch break (see what I did there?) on Day 2 we’ll have the RefStack sessions, since those should dovetail nicely with Tests.

5.) Following lunch on Day 2 we’ll conclude with the Outcomes sessions (as well as a wrap-up to review action items and some time for parking lot discussions).

I’ve also dropped two sessions from the agenda: the "Publishing DefCore Information and Docs” session (which feels small enough that we could tackle it in any given weekly meeting or even with an ML discussion), and the “Strategy: Levels of Interoperability” session (because I think this will actually end up getting discussed in the “Value from DefCore” session anyway). This gives us a little more flexibility in the schedule, although it’s still a pretty full agenda. You’ll notice a few built-in “fudge time” sessions for each grouping, so we’ll have a little leeway if we need to run over on something or need to take a break.

Please review and let me know if there are any other suggestions before we finalize:

https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

See you in Austin!

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
_______________________________________________
Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Summary of DefCore in CI feedback from previous meeting

Hi folks,

At last week's DefCore meeting, I shared some of the feedback and pain points that I've encountered while running continuous DefCore testing at Rackspace. It was suggested that I summarize the feedback in an etherpad, which I've created this link:

https://etherpad.openstack.org/p/defcore-in-ci-feedback

I wanted to share this feedback as I would be interested to know if similar thoughts and concerns have come up for others as well. I'm looking forward to discussing these and other great topics this week!

Thanks,

Daryl


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Midcycle Notes

Hi All,

Thank you to everyone who made the trip down to Austin (or tuned in remotely) for this week’s DefCore meetup, and special thanks to IBM for hosting us. You can find the raw notes we took during the meeting here in the etherpad:

https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

A few special notes:

1.) Most of the action items we handed out should be in the etherpad if you need a reminder.

2.) We kicked off scoring for the next Guideline with some very preliminary candidates. A schedule has been added to the etherpad—please note we’ll be looking to get scoring wrapped up by the end of the month. As you work through scoring, please post your patches up to the scoring.txt worksheet. [1] If you’d like to look back on past scoring discussions for context, I’ve added pointers in the etherpad to some of the patches from our last round of scoring (I may have missed a few, but you can generally find them with a quick gerrit search).

3.) For those of you in timezones that will be switching to Daylight Savings Time soon, please note that our meeting will remain at 16:00 UTC, which means the meeting will fall an hour later in the workday for you.

[1] http://git.openstack.org/cgit/openstack/defcore/tree/working_materials

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Discussing tests

Hi defcore,

Not sure it’s the right place to discuss about it but I try ;)

I’m using refstack to test our Public Cloud at OVH and I have question about a test which make trouble on our solution.

I run the 2015.07 guidelines.
The test is tempest.api.compute.images.testimages.ImagesTestJSON.testdeletesavingimage.

I saw this test corresponds to the compute-images-delete capability.
I understand that image deletion is required, but why the test is deletion on a saving image?

In this particular case, at OVH we had to patch Glance to forbid deletion if the image is in saving state because of some Ceph issue.
I saw that during the last meetup you talked about "Atomicity of tests », I think that’s what I’m talking about too and I agree that it’s a problem we need to solve.

compute-images-delete is marked as atomic but it’s not from my point of view.

--
Jean-Daniel Bonnetot
http://www.ovh.com
@pilgrimstack


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

My understanding of that test is that it is validating the system behavior being able to delete an image that is not done saving.

As to your question of atomicity, one of the outcomes of the DefCore midcycle is an audit of the existing tests to provide a precise list of what API calls each test makes and what assertions are really being made. The outcome of that audit should help with these types of questions about individual tests.

Daryl

From: Jean-Daniel Bonnetotjean-daniel.bonnetot@corp.ovh.com
Sent: Thursday, March 10, 2016 9:05 AM
To: defcore-committee@lists.openstack.org
Subject: [OpenStack-DefCore] Discussing tests

Hi defcore,

Not sure it’s the right place to discuss about it but I try ;)

I’m using refstack to test our Public Cloud at OVH and I have question about a test which make trouble on our solution.

I run the 2015.07 guidelines.
The test is tempest.api.compute.images.testimages.ImagesTestJSON.testdeletesavingimage.

I saw this test corresponds to the compute-images-delete capability.
I understand that image deletion is required, but why the test is deletion on a saving image?

In this particular case, at OVH we had to patch Glance to forbid deletion if the image is in saving state because of some Ceph issue.
I saw that during the last meetup you talked about "Atomicity of tests », I think that’s what I’m talking about too and I agree that it’s a problem we need to solve.

compute-images-delete is marked as atomic but it’s not from my point of view.

--
Jean-Daniel Bonnetot
http://www.ovh.com
@pilgrimstack


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.15 Meeting Invite Wed. March 16, 11:00 AM CST/ 16:00 UTC

Hello Everyone,

Thanks again for all the work done during the mid-cycle, was great to see everyone!

Due to the daylight saving time, for most this meeting will now be an hour later.

Notes from mid-cycle: https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.15

Note the meeting location: #openstack-meeting-3.

If you can't join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] [Security] List Users in RefStack

The RefStack team would appreciate guidance and recommendation on the
following:

Should any RefStack authenticated user be able to list the users
registered in RefStack?
If the answer is yes, which user information should be returned (full
name, email, OpenID)?
Or ONLY OpenStack Foundation members can list the users in RefStack?

Back ground information:

When a user registers at RefStack, RefStack does not request any user
information input from the user, Instead, RefStack redirects the
registration process to OpenstackId Identity Provider (
https://openstackid.org/ ) and obtains three pieces of user
information ( full name, email, OpenID ) from the OpenstackId Identity
Provider.
OpenstackId Identity Provider ( https://openstackid.org/ ) treats email
as private information. You will not find email or OpenID information
on any member's public profile on
https://www.openstack.org/community/members/ . Furthermore, if you look
at your own profile on https://www.openstack.org/profile/ , you will
find that email information is listed under the "private information"
section.
Since OpenstackId Identity Provider is the source of the user
information of RefStack, RefStack should respect and not relax the
privacy policy set by its source .

Note:
The user information for review.openstack.org seems to be set in
https://review.openstack.org/#/settings/web-identities and not from
OpenstackId Identity Provider.

Catherine Diep
RefStack Project PTL
IBM Silicon Valley Laboratory, San Jose, California 95141
cdiep@us.ibm.com, Tel: (408) 463-4352 T/L: 543-4352


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

In my opinion, listing users should work as follows:

  • Any user can list the users of the organizations (s)he belongs to.

What data to list? Full name+email+OpenID

  • Any Foundation (super-admin) user should be able to list everyone, and
    this should probably be a separate API call from the ones all users have
    available.

What data to list? Full name+email+OpenID+Organizations

Cheers,
Gema

On 14/03/16 22:28, Catherine Cuong Diep wrote:
The RefStack team would appreciate guidance and recommendation on the
following:

  1. Should any RefStack authenticated user be able to list the users
    registered in RefStack?

    • If the answer is yes, which user information should be returned
      (full name, email, OpenID)?
  2. Or ONLY OpenStack Foundation members can list the users in RefStack?

Back ground information:

  1. When a user registers at RefStack, RefStack does not request any
    user information input from the user, Instead, RefStack redirects
    the registration process to OpenstackId Identity Provider (
    https://openstackid.org/ ) and obtains three pieces of user
    information ( full name, email, OpenID ) from the OpenstackId
    Identity Provider.
  2. OpenstackId Identity Provider ( https://openstackid.org/ ) treats
    email as private information. You will not find email or OpenID
    information on any member's public profile on
    https://www.openstack.org/community/members/ . Furthermore, if you
    look at your own profile on https://www.openstack.org/profile/ , you
    will find that email information is listed under the "private
    information" section.
  3. Since OpenstackId Identity Provider is the source of the user
    information of RefStack, RefStack should respect and not relax the
    privacy policy set by its source .

Note:
The user information for review.openstack.org
seems to be set in
https://review.openstack.org/#/settings/web-identities and not from
OpenstackId Identity Provider.

Catherine Diep
RefStack Project PTL
IBM Silicon Valley Laboratory, San Jose, California 95141
cdiep@us.ibm.com, Tel: (408) 463-4352 T/L: 543-4352


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

--
Gema Gomez-Solano gema.gomez-solano@canonical.com
STS, QE https://launchpad.net/~gema
Canonical Ltd. http://www.canonical.com


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Fwd: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

FYI for DefCore folks that might wish to contribute to the discussion as there are ~118 negative tests included in the most recent Board-approved DefCore Guideline. [1]

We discussed negative tests included in the DefCore Guidelines a bit in the past and general consensus has been that it’s reasonable to include negative tests for a Capability since it validates that the “unhappy path” works in an interoperable way just as the “happy path” for an action does. Note that the suggestion here is to move negative tests to the Tempest plugin interface. As we’ve discussed, DefCore can accept in-project-tree tests via the Tempest plugin interface and RefStack will able to run them. Therefore I think if this plan is implemented, it should be mostly non-impacting for us: we can continue including the negative tests we have today, though we may need to do some housekeeping as tests move around (so we should probably keep an eye on the review queues…it would be super helpful to have a heads-up from reviewers on those patches if possible, but we’ll probably find them either way =).

[1] http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json

At Your Service,

Mark T. Voelker

Begin forwarded message:

From: "Ken'ichi Ohmichi" ken1ohmichi@gmail.com
Subject: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest
Date: March 16, 2016 at 9:20:11 PM EDT
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org

Hi

I have one proposal[1] related to negative tests in Tempest, and
hoping opinions before doing that.

Now Tempest contains negative tests and sometimes patches are being
posted for adding more negative tests, but I'd like to propose
removing them from Tempest instead.

Negative tests verify surfaces of REST APIs for each component without
any integrations between components. That doesn't seem integration
tests which are scope of Tempest.
In addition, we need to spend the test operating time on different
component's gate if adding negative tests into Tempest. For example,
we are operating negative tests of Keystone and more
components on the gate of Nova. That is meaningless, so we need to
avoid more negative tests into Tempest now.

If wanting to add negative tests, it is a nice option to implement
these tests on each component repo with Tempest plugin interface. We
can avoid operating negative tests on different component gates and
each component team can decide what negative tests are valuable on the
gate.

In long term, all negative tests will be migrated into each component
repo with Tempest plugin interface. We will be able to operate
valuable negative tests only on each gate.

Any thoughts?

Thanks
Ken Ohmichi


[1]: https://review.openstack.org/#/c/293197/


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


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Is it fine to change test paths of Tempest? (Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest)

Hi Mark,

Thanks for sharing it on Defcore committee :-)

That is off-topic from the original discussion, but I'd like to ask a
question between Tempest and Defcore.

The link[1] as you pointed contains test paths of Tempest like
tempest.api.compute.testauthorization.AuthorizationTestJSON.testcreateserverfailswhentenant_incorrect

Is it acceptable to change these paths from Defcore viewpoint?

[1] contains idempotent_id also which is tagged for each test and
Tempest consumers would be able to use the id instead of the path.
So it seems possible to change the paths in general and sometimes
people propose changing paths for correct ones.
For example, AuthorizationTestJSON could be changed to
AuthorizationTest by removing JSON because now opposite(XML) tests
don't exist in Tempest.

If such change is fine from Defcore viewpoint also, I can agree
confidently with these changes.

Thanks


[1] http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json

2016-03-17 9:20 GMT-07:00 Mark Voelker mvoelker@vmware.com:

FYI for DefCore folks that might wish to contribute to the discussion as there are ~118 negative tests included in the most recent Board-approved DefCore Guideline. [1]

We discussed negative tests included in the DefCore Guidelines a bit in the past and general consensus has been that it’s reasonable to include negative tests for a Capability since it validates that the “unhappy path” works in an interoperable way just as the “happy path” for an action does. Note that the suggestion here is to move negative tests to the Tempest plugin interface. As we’ve discussed, DefCore can accept in-project-tree tests via the Tempest plugin interface and RefStack will able to run them. Therefore I think if this plan is implemented, it should be mostly non-impacting for us: we can continue including the negative tests we have today, though we may need to do some housekeeping as tests move around (so we should probably keep an eye on the review queues…it would be super helpful to have a heads-up from reviewers on those patches if possible, but we’ll probably find them either way =).

[1] http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json

At Your Service,

Mark T. Voelker

Begin forwarded message:

From: "Ken'ichi Ohmichi" ken1ohmichi@gmail.com
Subject: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest
Date: March 16, 2016 at 9:20:11 PM EDT
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org

Hi

I have one proposal[1] related to negative tests in Tempest, and
hoping opinions before doing that.

Now Tempest contains negative tests and sometimes patches are being
posted for adding more negative tests, but I'd like to propose
removing them from Tempest instead.

Negative tests verify surfaces of REST APIs for each component without
any integrations between components. That doesn't seem integration
tests which are scope of Tempest.
In addition, we need to spend the test operating time on different
component's gate if adding negative tests into Tempest. For example,
we are operating negative tests of Keystone and more
components on the gate of Nova. That is meaningless, so we need to
avoid more negative tests into Tempest now.

If wanting to add negative tests, it is a nice option to implement
these tests on each component repo with Tempest plugin interface. We
can avoid operating negative tests on different component gates and
each component team can decide what negative tests are valuable on the
gate.

In long term, all negative tests will be migrated into each component
repo with Tempest plugin interface. We will be able to operate
valuable negative tests only on each gate.

Any thoughts?

Thanks
Ken Ohmichi


[1]: https://review.openstack.org/#/c/293197/


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


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hi Ken,

DefCore test list is using full test path name and not idempotentid due
to the issue reported in https://bugs.launchpad.net/tempest/+bug/1433700 .
As such, any change in the path name or test name will affect the test
list. Currently, DefCore uses "alias" to identify tests with same
idempotent
id . Please see alias description in
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/schema/1.4.rst#n82

Catherine Diep
IBM Silicon Valley Laboratory, San Jose, California 95141
cdiep@us.ibm.com, Tel: (408) 463-4352 T/L: 543-4352
----- Forwarded by Catherine Cuong Diep/San Jose/IBM on 03/17/2016 09:25 PM


From: "Ken'ichi Ohmichi" ken1ohmichi@gmail.com
To: Mark Voelker mvoelker@vmware.com
Cc: "defcore-committee@lists.openstack.org"

Date: 03/17/2016 07:25 PM
Subject: [OpenStack-DefCore] Is it fine to change test paths of Tempest?
(Re: [openstack-dev] [QA][all] Propose to remove negative tests
from Tempest)

Hi Mark,

Thanks for sharing it on Defcore committee :-)

That is off-topic from the original discussion, but I'd like to ask a
question between Tempest and Defcore.

The link[1] as you pointed contains test paths of Tempest like
tempest.api.compute.testauthorization.AuthorizationTestJSON.testcreateserverfailswhentenant_incorrect

Is it acceptable to change these paths from Defcore viewpoint?

[1] contains idempotent_id also which is tagged for each test and
Tempest consumers would be able to use the id instead of the path.
So it seems possible to change the paths in general and sometimes
people propose changing paths for correct ones.
For example, AuthorizationTestJSON could be changed to
AuthorizationTest by removing JSON because now opposite(XML) tests
don't exist in Tempest.

If such change is fine from Defcore viewpoint also, I can agree
confidently with these changes.

Thanks


[1] http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json

2016-03-17 9:20 GMT-07:00 Mark Voelker mvoelker@vmware.com:
FYI for DefCore folks that might wish to contribute to the discussion as
there are ~118 negative tests included in the most recent Board-approved
DefCore Guideline. [1]

We discussed negative tests included in the DefCore Guidelines a bit in
the past and general consensus has been that it’s reasonable to include
negative tests for a Capability since it validates that the “unhappy path”
works in an interoperable way just as the “happy path” for an action does.
Note that the suggestion here is to move negative tests to the Tempest
plugin interface. As we’ve discussed, DefCore can accept in-project-tree
tests via the Tempest plugin interface and RefStack will able to run them.
Therefore I think if this plan is implemented, it should be mostly
non-impacting for us: we can continue including the negative tests we have
today, though we may need to do some housekeeping as tests move around (so
we should probably keep an eye on the review queues…it would be super
helpful to have a heads-up from reviewers on those patches if possible, but
we’ll probably find them either way =).

[1] http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json

At Your Service,

Mark T. Voelker

Begin forwarded message:

From: "Ken'ichi Ohmichi" ken1ohmichi@gmail.com
Subject: [openstack-dev] [QA][all] Propose to remove negative tests from
Tempest
Date: March 16, 2016 at 9:20:11 PM EDT
To: OpenStack Development Mailing List

Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Hi

I have one proposal[1] related to negative tests in Tempest, and
hoping opinions before doing that.

Now Tempest contains negative tests and sometimes patches are being
posted for adding more negative tests, but I'd like to propose
removing them from Tempest instead.

Negative tests verify surfaces of REST APIs for each component without
any integrations between components. That doesn't seem integration
tests which are scope of Tempest.
In addition, we need to spend the test operating time on different
component's gate if adding negative tests into Tempest. For example,
we are operating negative tests of Keystone and more
components on the gate of Nova. That is meaningless, so we need to
avoid more negative tests into Tempest now.

If wanting to add negative tests, it is a nice option to implement
these tests on each component repo with Tempest plugin interface. We
can avoid operating negative tests on different component gates and
each component team can decide what negative tests are valuable on the
gate.

In long term, all negative tests will be migrated into each component
repo with Tempest plugin interface. We will be able to operate
valuable negative tests only on each gate.

Any thoughts?

Thanks
Ken Ohmichi


[1]: https://review.openstack.org/#/c/293197/

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


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.16 Meeting Invite Wed. March 23, 11:00 AM CST/ 16:00 UTC

Hello Everyone,

Due to the daylight saving time, for most this meeting will now be an hour later.

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.16
Notes from last meeting: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-16-16.00.html

Note the meeting location: #openstack-meeting-3.

If you can't join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome!https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.16 Meeting Invite Wed. March 30, 11:00 AM CST/ 16:00 UTC

Hello Everyone,

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.17
Notes from last meeting: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-23-16.00.html

Note the meeting location: #openstack-meeting-3.

If you can't join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome!https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.18 Meeting Invite Wed. April 6, 11:00 AM CST/ 16:00 UTC

Hello Everyone,

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.18
Notes from last meeting: no notes, since the bot took a break in the middle of the meeting.

Note the meeting location: #openstack-meeting-3.

If you can't join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome!https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.19 Meeting Invite Wed. April 13, 11:00 AM CST/ 16:00 UTC

Hello Everyone,

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.19
Notes from last meeting: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-04-06-16.01.html

Note the meeting location: #openstack-meeting-3.

If you can't join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome!https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] 招待: DefCore Ring.19 Meeting Invite Wed. April 13, 11:00 AM CS... - 2016/04/13 (水) 09:00 〜 10:00 (Ken'ichi Ohmichi)

次の予定にご招待します。

タイトル: DefCore Ring.19 Meeting Invite Wed. April 13, 11:00 AM CST/ 16:00
UTC
日時: 2016/04/13 (水) 09:00 〜 10:00 太平洋時間 - バンクーバー
場所: IRC: #openstack-meeting-3
カレンダー: Ken'ichi Ohmichi
参加者:
* Ken'ichi Ohmichi- 主催者
* defcore-committee@lists.openstack.org

予定の詳細:
https://www.google.com/calendar/event?action=VIEW&eid=NzVobTZjcHBjNWlqNGI5bzZoaW0yYjlrY29vM2FiYjI2cGozNGI5bDZzcDY4bzlpNjhyMzBlMW9jayBkZWZjb3JlLWNvbW1pdHRlZUBsaXN0cy5vcGVuc3RhY2sub3Jn&tok=MjEja2VuMW9obWljaGlAZ21haWwuY29tMTA2MWJkZmJjMTMyNWUwMDUxNzEyN2Y0ODAzZjA1MTdlNzM5NDBiNw&ctz=America/Vancouver&hl=ja

Google カレンダーからの招待状: https://www.google.com/calendar/

予定の参加者になっているため、本メールを
defcore-committee@lists.openstack.org にお送りしています。

今後この予定の更新を受け取らないようにするには、この予定を拒否してください。
あるいは、https://www.google.com/calendar/ で Google カレンダーのアカウント
を登録すると、カレンダー全体の通知機能を設定できます。

この招待状を転送すると、他の受信者によってあなたの出欠状況が変更される可能性
があります。詳細については
https://support.google.com/calendar/answer/37135#forwarding をご覧ください


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Invitación: DefCore Ring.19 Meeting Invite Wed. April 13, 11:00 AM CS... mié 13 de abr de 2016 18:00 - 19:00 (dmellado@redhat.com)

Tienes una invitación para el siguiente evento.

Título: DefCore Ring.19 Meeting Invite Wed. April 13, 11:00 AM CST/ 16:00
UTC
Cuándo: mié 13 de abr de 2016 18:00 - 19:00 Madrid
Lugar: IRC: #openstack-meeting-3
Calendario: dmellado@redhat.com
Quién:
* dmellado@redhat.com- organizador
* defcore-committee@lists.openstack.org
* daniel.mellado.es@ieee.org

Detalles del evento:
https://www.google.com/calendar/event?action=VIEW&eid=YzlpamNvcHA2aGhqZ2I5bzZkZ2ppYjlrNjVoamViYjI2a3IzYWI5bzZzcjNjb3BpNjBxamdwOWk2NCBkZWZjb3JlLWNvbW1pdHRlZUBsaXN0cy5vcGVuc3RhY2sub3Jn&tok=MTkjZG1lbGxhZG9AcmVkaGF0LmNvbWE5YTdkN2ZmZGQzMDFkOTUwNjY3NDA1NTc2N2VjM2Q2OTg5NDIzYmU&ctz=Europe/Madrid&hl=es

Invitación de Google Calendar: https://www.google.com/calendar/

Recibes este mensaje de cortesía en la dirección
defcore-committee@lists.openstack.org de la cuenta porque eres uno de los
participantes de este evento.

Si ya no quieres recibir más avisos sobre este evento, recházalo. Si lo
prefieres, solicita una cuenta de Google en
https://www.google.com/calendar/ y controla la configuración de las
notificaciones de todo tu calendario.

Si reenvías esta invitación, los destinatarios podrían cambiar tu respuesta
de confirmación de asistencia. Más información en
https://support.google.com/calendar/answer/37135#forwarding


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Spec kick off

Hi,

I am in the process of distilling all our conversations around the
suitability of the current tests for interoperability and I am putting
all the facts together in this email as the starting point to writing a
draft of the DefCore spec.

The midcycle conversation
We all seem to remember that we decided to write a DefCore test spec
back in the midcycle[0]. Just wanted to remind everyone the straw poll
questions that we took to foster this discussion[1].

The only thing that seems to be clear from that discussion is that we
needed a spec for interop/portability that would help frame the
interoperability discussion/testing.

We didn't agree on a way of owning tests because the resolution of this
discussion was that we would write interop specs and the discussion
about who owns what and how would hopefully be easier to answer after we
have a spec.

Test analysis
On a different session on the second day we agreed that Darrel and his
team of testers would do an analysis of the current tests and come back
with results of this analysis as input for the spec/test ownership
discussion. We have two links to results of this analysis[2]:

-
https://github.com/dwalleck/defcore-tools/blob/master/manual_test_analysis.txt
-
https://github.com/dwalleck/defcore-tools/blob/master/generated_test_analysis.txt

I will be working with him on getting more up to date information on
this front. And also figure out if he has already gone through the data
and made a list of potential test refactorings.

The spec

After a bit of thinking I have decided to work on this document in the
open on an etherpad so that we can collaborate on it and come up with a
draft that we can then propose and discuss in gerrit:

https://etherpad.openstack.org/p/DefCoreSpec-draft

This is just a boiler plate spec to fill out. Anybody with ideas can
just dump them in "other thoughts" and we will be writing the doc in a
collaborative manner. If you have sections to add that you think are
necessary, by all means do so even if you don't have content for them yet.

Cheers,
Gema

[2] https://etherpad.openstack.org/p/DefCoreRing.16
[1] Summary of straw poll during the sprint:

Question #1: Who is in favor of dedicated defcore interoperability
tests, maintained by DefCore and separate from developer-maintained tests?

Yes: +10
- as a tag to upstream tests
- if DefCore does not have to maintain the test
- need stable tests that match the spec

No: +1
- prefer to augment Tempest or extend Rally

Question #2: Does defcore needs ownership of test suite (to match the
spec mentioned in Q3, below)?

Yes: +8
No: +5

Question #3: Should DefCore define an explicit spec (for
interop/portability)?

Yes: +12
No: 0

[0]https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle

--
Gema Gomez-Solano gema.gomez-solano@canonical.com
STS, QE https://launchpad.net/~gema
Canonical Ltd. http://www.canonical.com


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Ring.20 Meeting Invite Wed. April 20, 11:00 AM CST/ 16:00 UTC

Hello Everyone,

Etherpad for this week: https://etherpad.openstack.org/p/DefCoreRing.20
Notes from last meeting: Bot took a break, so here are un-official logs: https://etherpad.openstack.org/p/DefCoreRing.19.IRClogs. When bot joined back in: http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-04-13-16.26.html

Note the meeting location: #openstack-meeting-3.

If you can't join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the IRC channel later. Patches and patch reviews are always welcome!https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore guidelines to include newest releases- please review

Hello Everyone,

During the last meeting we discussed the need to include the newest OpenStack release in our current guidelines. Based on our discussions, Mark proposed a change to existing guideline. We would like as many reviews as possible before the next DefCore meeting this Wednesday, please review and comment.

https://review.openstack.org/#/c/306614/

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Interop Working Group (OpenStack Summit in Person)

Etherpad: https://etherpad.openstack.org/p/DefCoreRing.AustinSummit2016

https://www.openstack.org/summit/austin-2016/summit-schedule/events/7471

Please join us for a working session discussing the latest issues with OpenStack interoperability.

Topics:

  • Board activity updates: 2016A process review
  • Discussion of 2016.08 Guideline
  • Identify needs for schema changes (1.5?)
  • Naming of next cycle
  • Review decisions made during cycle
  • Plan major topics for next cycle Review proposed scoring changes
    Led by: Mark Voelker and Chris Hoge

What can I expect to learn?
Current status of DefCore and plans for the new guidelines.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] QA: DefCore and Interoperability Testing QA: DefCore and Interoperability Testing

https://www.openstack.org/summit/austin-2016/summit-schedule/events/9168

Help establish criteria for what makes an interoperability test, and plan for changes and additions to close gaps in the future DefCore guidelines.
There is a push from some working group members to fork the test suite, so another goal is to continue to strengthen the DefCore/QA working relationship that has made DefCore successful to date.

Session Leader: Chris Hoge
Related links: https://review.openstack.org/#/c/301879/,https://etherpad.openstack.org/p/DefCoreSpec-draft
Etherpad: https://etherpad.openstack.org/p/newton-qa-defcore-and-interoperability


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Interoperability: The Elephants in the Room & What We're Doing About Them

https://www.openstack.org/summit/austin-2016/summit-schedule/events/8645

As OpenStack has matured over the past 5+ years, we've grown a healthy ecosystem of ways to consume OpenStack: there are distributions, appliances, managed offerings, public clouds, and consulting services to help you build your cloud. OpenStack can be used for private clouds, public clouds, and hybrid cloud scenarios, not to mention use case specific purposes like NFV. As the software and demand for it have matured though, interoperability between OpenStack clouds has become increasingly imporant. The DefCore Committee has now released several Guidelines that serve as interoperability standards, and the Technical Committee and Board of Directors are considering changes to OpenStack's mission statement that highlight interoperability as a core value.

In this talk, we'll look at the top barriers to interoperability OpenStack faces today, and discuss what's being done to address them. We'll also review the latest work from the DefCore Committee and look ahead to it's next challenges.

What can I expect to learn?
First, we'll talk about what the concerns are: what does "interoperability" mean? Does it mean API's are consistently supported? That toolkits and SDK's work across many clouds today? That image formats are consistently supported? That roles and policies are universal? That workloads can be moved from one cloud to another unchanged? That OpenStack workloads can be moved to other kinds of clouds? We'll provide information from community members, Board and TC members, and the DefCore Committee on different facets of interoperability.

Next, we'll discuss what the major barriers to interoperability today are. These will include notes from some of the research the DefCore Committee is currently working on to assemble a report for the Board, Technical Committee, and User Committee.

Finally, we'll discuss how the community is addressing these concerns today, and how interested parties can help. We'll point to examples of work done by project teams, the TC, DefCore, and more.


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Meeting Invite Wed. 11:00 AM CST/ 16:00 UTC

Hello Everyone,

Note the meeting location: #openstack-meeting-3.

If you can't join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the #openstack-defcore IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Hello Everyone,

Etherpad for Wednesday's meeting: https://etherpad.openstack.org/p/DefCoreLunar.14

Please add items to the agenda.

Note the meeting location: #openstack-meeting-3.

If you can't join us at this time, you can still contribute by sending email to the mailing list (or just to me or Mark), or joining us in the #openstack-defcore IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Egle


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Naming the Next DefCore Cycle

Hi All,

We had a small group at this week’s DefCore meeting on account of post-Summit recovery, so we decided to defer naming the next DefCore cycle and do it via online poll instead. I’ve created a poll with all the naming suggestions gathered over the past couple of weeks on etherpads here:

https://www.surveymonkey.com/r/3286MRP

In the event that anyone has trouble accessing the link, just drop me and email with your vote and I’ll make sure your preference gets factored in. We will close the poll at next week’s DefCore meeting. Happy voting!

At Your Service,

Mark T. Voelker
OpenStack Architect


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Some Governance Patches To Be Aware Of

Hi Folks,

For those of you who didn’t catch it elsewhere, here are a couple of DefCore-related things that the TC is currently considering that you may want to be aware of:

"add resolution explaining which tests we think defcore should use"
https://review.openstack.org/#/c/312718/

"add resolution asking defcore committee to avoid using proxy APIs in tests"
https://review.openstack.org/#/c/312719/

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

Regarding #1, (and I guess even #2 also), it is good to listen to the TC's opinion on these matters, but aren't we governed by the board-approved weighing/inclusion process?

Hi Folks,

For those of you who didn’t catch it elsewhere, here are a couple of DefCore-related things that the TC is currently considering that you may want to be aware of:

"add resolution explaining which tests we think defcore should use"
https://review.openstack.org/#/c/312718/

"add resolution asking defcore committee to avoid using proxy APIs in tests"
https://review.openstack.org/#/c/312719/

At Your Service,

Mark T. Voelker


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] Request agenda items for the next meeting

Hello,

I guess the naming of the cycle changes so, the etherpad I
optimistically hopped on to (DefCoreRing.22) becomes incorrect. Anyway,
I had a couple of items/questions to discuss with the committee this
week if at all possible.

  • Interoperability beyond APIs, and usage issues/hacks by other services.

  • Interop branding with the APIs, assumptions around services,
    deployments, etc.

    ** Thanks Mark for your excellent blog. It is very educational and
    enriches perspective. I do have follow up questions, or more of
    confirmations about glance-api usage by Nova, Cinder, Ironic, Horizon,
    OSC, etc.

Should this (
https://wiki.openstack.org/wiki/Governance/DefCoreCommittee ) wiki still
be considered the point of contact?

Please let me know if there are further action items on my part.

--

Thanks,
Nikhil


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] DefCore Meeting Invite Wed. May 11, 11:00 AM CST/ 16:00 UTC

Hello Everyone,

Note the meeting location: #openstack-meeting-3.

Agenda: https://etherpad.openstack.org/p/DefCoreLunar.2

If you can’t join us at this time, you can still contribute by sending email to the mailing list (or just to Egle or Mark), or joining us in the #openstack-defcore IRC channel later. Patches and patch reviews are always welcome! https://review.openstack.org/#/q/status:open+project:openstack/defcore,n,z

Info on OpenStack IRC: https://wiki.openstack.org/wiki/IRC
Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3

Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference

Thank you,
Chris Hoge


Defcore-committee mailing list
Defcore-committee@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

[OpenStack-DefCore] FW: [openstack-dev] [Neutron][QA] Call to action - Neutron/Tempest API tests dedup

Hey folks,

This is important info for DefCore (and Refstack to some extent) to track, as tests will be moving, but we will also get a much clearer picture of what the Neutron project considers "core" functionality, and what is considered advanced functionality.

Worth following and worth commenting on.

--Rocky

-----Original Message-----
From: Assaf Muller [mailto:assaf@redhat.com]
Sent: Friday, May 13, 2016 3:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QA] Call to action - Neutron/Tempest API tests dedup

TL;DR: I'm looking for volunteers for tasks 1, 2 and 3 listed below.
Help would be hugely appreciated and %(local_drink)s will be bought in
Barcelona. I've posted example patches that demonstrate the idea.
Needless to say I'm here to provide reviews and to answer questions.
Additionally, most of the discussions have been within the Neutron
community and I'm looking for feedback from Tempest folks.

The context:
The Neutron community has been engaged in a long running effort to
move some of the networking API tests to the Neutron tree. We started
by copying the api/network directory tree, later keeping only the
tests, importing the test infrastructure itself from Tempest. We
continued by minimizing the imports we do from Tempest (Excluding
tempest.lib), and introduced a Neutron Tempest plugin.

One issue that remains is that some of the tests are still found in
both repositories. This confuses contributors and wastes compute
resources. Since the tests run against stable/{liberty|mitaka} and
master, it should be safe to dedup. I proposed a line in the sand so
that 'core resources' remain to be tested in Tempest and more
'advanced' APIs are tested in Neutron. The concept was agreed upon by
the Neutron and (Then) Tempest PTLs, and the specifics were discussed
and a consensus was found in patch [2]. Here is the resulting doc for
your viewing pleasure [5].

The work:
After I removed the API tests for core resources from the Neutron
tree, there remain three tasks to finish the de-dup:

1*) Remove tests for advanced APIs from Tempest. The full list of
tests that I propose be removed from Tempest is tracked here [1] (With
the rationale found at [2]), and an example patch may be found here
[4].
2) Push tests for Neutron core resources that were added after the
fork from Tempest, then delete these from Neutron. This is also
tracked in [1], with example patches found here [6]. This is not a
strict cut/paste as the way Tempest and Neutron interact with clients
is slightly different. Fun!
3) Sync tests for Neutron core resources that were updated after the
fork from Tempest. Test modifications include: Bug fixes for raceful
tests, py3 fixes, doc string typos and more. This is also tracked in
[1], with example patches found here [3].

  • I believe that as far as the Tempest test removal criteria found at
    [7], this case falls under the first exception: 'The class of testing
    has been decided to be outsid