settingsLogin | Registersettings

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

0 votes

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

asked Aug 14, 2014 in defcore-committee by Rob_Hirschfeld_at_de (1,900 points)   1 4
retagged Apr 14, 2015 by admin

26 Responses

0 votes

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

responded Aug 15, 2014 by Tom_Fifield (13,880 points)   2 4 8
0 votes

Tom,

I agree!

Josh and I did a presentation with examples in ATL (http://www.confreaks.com/videos/3695-openstacksummitatl2014-core-via-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-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
responded Aug 15, 2014 by Rob_Hirschfeld_at_de (1,900 points)   1 4
0 votes

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-via-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-committee
responded Aug 15, 2014 by Tom_Fifield (13,880 points)   2 4 8
0 votes

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


Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
responded Aug 15, 2014 by Tom_Fifield (13,880 points)   2 4 8
0 votes

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-via-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-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
responded Aug 15, 2014 by Joshua_McKenty (540 points)   1
0 votes

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-via-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-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
responded Aug 15, 2014 by Tom_Fifield (13,880 points)   2 4 8
0 votes

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
responded Aug 15, 2014 by Rob_Hirschfeld_at_de (1,900 points)   1 4
0 votes

Tom,

I thought we had some pretty specific examples for public and private clouds with references to specific projects. Remember, the mark is all or nothing at this point. Vendors must pass the required tests and use the required code to use the mark. There is no subset or partial mark at this point.

Rob

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

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-commit
te
e


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


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:
responded Aug 15, 2014 by Rob_Hirschfeld_at_de (1,900 points)   1 4
0 votes

The other trademark license requirements (to publish the versions of the components being used, etc) still apply as well.

Sent from my iPhone

On Aug 14, 2014, at 11:09 PM, wrote:

Tom,

I thought we had some pretty specific examples for public and private clouds with references to specific projects. Remember, the mark is all or nothing at this point. Vendors must pass the required tests and use the required code to use the mark. There is no subset or partial mark at this point.

Rob

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

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-commit
te
e


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


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:
responded Aug 15, 2014 by Joshua_McKenty (540 points)   1
0 votes

Cool - that's more like what I'm getting at - practical aspects of the
trademark license requirements as related to the below 'designated
sections', as they apply to what end users actually see.

So far I haven't seen anything remotely close to this written down, and
I believe it can really help with general understanding and comment.

Regards,

Tom

On 16/08/14 02:33, Joshua McKenty wrote:
The other trademark license requirements (to publish the versions of the
components being used, etc) still apply as well.

Sent from my iPhone

On Aug 14, 2014, at 11:09 PM, > wrote:

Tom,

I thought we had some pretty specific examples for public and private
clouds with references to specific projects. Remember, the mark is
all or nothing at this point. Vendors must pass the required tests
and use the required code to use the mark. There is no subset or
partial mark at this point.

Rob

-----Original Message-----
From: Tom Fifield [mailto:tom at openstack.org]
Sent: Thursday, August 14, 2014 7:44 PM
To: defcore-committee at lists.openstack.org

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

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-commit
te
e


Defcore-committee mailing list
Defcore-committee at lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committe
e


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
responded Aug 18, 2014 by Tom_Fifield (13,880 points)   2 4 8
...