[OpenStack-Infra] OpenDev infra as an OSF pilot project

[Jonathan Bryce]

Hi everyone,

I saw some of the discussions on different channels last week about the ongoing 
move of the OpenDev infra services out of OpenStack project and TC governance. 
One of the questions that was raised was around setting it up as an OSF pilot 
project. I wanted to send an email to this list to see if that was something 
the team was interested in moving forward on.

As a pilot project, it would create some official standing for the new effort 
that would make it clear it’s something that is still supported by the OSF 
community and staff. It would also provide additional opportunities for 
education and exposure as part of the foundation’s overall activities. While 
the OpenDev infra services are somewhat different than the other projects we 
have piloted (e.g. Zuul), I think the process would still work and could be 
helpful to complete the transition to a more standalone community both from a 
governance and perception standpoint.

Pilot projects are initiated through action of the foundation staff and over 
time may be confirmed by the Board as a top-level project with long-term 
support. I personally would be supportive of taking the pilot step, and would 
like to hear thoughts from those of you who are directly engaged in it.

Thanks,

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

Re: [OpenStack-Infra] Airship project replication/sync to GitHub

[Jonathan Bryce]

On May 16, 2019 08:07:25 "Clark Boylan"  wrote:


On Wed, May 15, 2019, at 4:17 PM, SKELS, KASPARS wrote:



Hi OpenStack infra team,




we would like to set up replication


From  https://opendev.org/airship ->  https://github.com/airshipit




The GitHub space airshipit should already be available to OpenStack Foundation.


Let us know how to proceed with this.




Kindly, Kaspars & Airship team


The first step is for us to migrate the Airship repos in github under 
https://github.com/openstack to https://github.com/airshipit. To do this 
you will need to add the "OpenStack Infrastructure" openstackadmin account 
as admin on the airshipit org (this is a necessary permission to do 
transfer between orgs).


I think I might have set up this org, so I need to find those credentials 
and share with the team to do step 1.


Jonathan


Then provide us with a list of the repos that should be moved and we'll run 
our script over them to perform the org transfer.



This org transfer ensures that github redirects are created so that people 
using the older urls will find the new urls. Once that is done you can 
remove the openstackadmin account from the airshipit org.



Then the next step is to set up the Zuul git replication jobs as described 
at 
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html 
for each of these repos (this is something you can do in your repos without 
infra involvement).



To get things going maybe respond to this email thread with the list of 
repos to transfer on github once the openstackadmin account is added to the 
airshipit org?



Clark


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





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

[OpenStack-Infra] Cross-community/generic mailing lists

[Jonathan Bryce]

Hi everyone,

I was having a conversation with some people who are working across multiple 
communities involved in virtualization and container security and they were 
interested in having a higher level mailing list for open discussions. It 
doesn’t necessarily make sense to tie it to any particular project mailing 
list, and I was wondering how others on the OpenDev team felt about creating 
discussion lists along these lines on lists.opendev.org. This isn’t the first 
time we’ve seen this use case, and seems like it could be a nice service to a 
number of communities.

Thoughts?

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

Re: [openstack-dev] Affected by OSIC, Layoffs? Or want to help?

[Jonathan Bryce]

I'll do it too. I can probably do two tickets.





On April 21, 2017 11:36:57 AM Lauren Sell  wrote:


Hi everyone,

The Foundation wants to help any Stackers affected by recent layoffs such 
as OSIC get to the Boston Summit. There are companies hiring and we want to 
retain our important community members!


If you are a contributor who was recently laid off and need help getting to 
Boston, please contact me ASAP. We have a little bit of room left in our 
travel support block, and want to extend rooms and free passes to those 
affected to help if we can.


Amy Marrich also had a great idea for any of you frequent flyers interested 
in pitching in! Community members could offer up some of our personal 
frequent flyer miles to sponsor flights for these Stackers. I’d love to be 
the first...if you were laid off and need sponsorship for a flight, I’m 
willing to sponsor a round trip domestic flight or one-way international 
flight with my miles. Contact me.


Anyone else want to pitch in?

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




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

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Jonathan Bryce]

Hi Ben,

> On Mar 9, 2017, at 10:23 AM, Ben Swartzlander  wrote:
> 
> I might be the only one who has negative feelings about the PTG/Forum split, 
> but I suspect the foundation is suppressing negative feedback from myself and 
> other developers so I'll express my feelings here. If there's anyone else who 
> feels like me please reply, otherwise I'll assume I'm just an outlier.

“Suppressing negative feedback” is a pretty strong accusation (and I’m honestly 
not sure how you even imagine we are doing that). I searched through the last 2 
years of mailing list threads and couldn’t find negative feedback from you 
around the PTG. Same for googling around the internet in general. I might have 
missed a place where you had provided this feedback, so feel free to pass it 
along again. Also, if there’s some proof behind the accusation, I would love to 
see it so I can address it with whoever might be doing the suppressing. It’s 
certainly not something I would support anyone in the foundation doing. You can 
send it to me directly off-list if you feel more comfortable providing it that 
way.

Putting that aside, I appreciate your providing your input. The most consistent 
piece of feedback we received was around scheduling and visibility for 
sessions, so I think that is definitely an area for improvement at the next 
PTG. I heard mixed feedback on whether the ability to participate in multiple 
projects was better or worse than under the previous model, but understanding 
common conflicts ahead of time might give us a chance to schedule in a way that 
makes the multi-project work more possible. Did you participate in both Cinder 
and Manila mid-cycles in addition to the Design Summit sessions previously? 
Trying to understand which types of specific interactions you’re now less able 
to participate in.

I’m also interested in finding ways to support remote participation, but it’s a 
hard problem that has failed more often than it’s worked when we’ve tried it. 
I’m still open to continuing to attempt new methods—we actually brainstormed 
some ideas in Atlanta and if you have any suggestions, let’s experiment the 
next time around.

The PTG was actually an idea that was initiated by development teams, and 
something that we tried to organize to make it as productive as possible for 
the teams. The goal of the PTGs is to provide focused time to that help us make 
better software, and there’s really no other benefit that the Foundation gets 
from them. We did have some teams, like Kuryr, who did not participate in 
person at the PTG. I talked to Antoni before and offered to assist with 
whatever we could when they did their VTG, and we will continue to support 
teams whether they participate in future PTGs or not.

Thanks for keeping an open mind on the Forum. If you have opinions around what 
will make it more or less successful, please get involved in the planning for 
it. It’s being planned and scheduled in the open with input from the dev and 
user communities. I’ll be looking out for your feedback after Boston. Promise I 
won’t do anything to suppress it, positive or negative. = )

Jonathan


> The new structure is asking developers to travel 4 times a year (minimum) and 
> makes it impossible to participate in 2 or more vertical projects.
> 
> I know that most of the people working on Manila have pretty limited travel 
> budgets, and meeting 4 times a year basically guarantees that a good number 
> of people will be remote at any given meeting. From my perspective if I'm 
> going to be meeting with people on the phone I'd rather be on the phone 
> myself and have everyone on equal footing.
> 
> I also normally try to participate in Cinder as well as Manila and the new 
> PTG structures makes that impossible. I decided to try to be positive and to 
> wait until after the PTG to make up my mind but having attended in Atlanta it 
> was exactly as bad as I expected in terms of my ability to participate in 
> Cinder.
> 
> I will be in Boston to try to develop a firsthand opinion of the new Forum 
> format but as of now I'm pretty unhappy with the proposal. For Manila I'm 
> proposing that the community either meets at PTG and skips conferences or 
> meetings at conferences and skips PTGs going forward. I'm not going to ask 
> everyone to travel 4 times a year.
> 
> -Ben Swartzlander
> Manila PTL
> 
> 
> On 03/07/2017 07:35 AM, Thierry Carrez wrote:
>> Hi everyone,
>> 
>> I recently got more information about the space dedicated to the "Forum"
>> at the OpenStack Summit in Boston. We'll have three different types of
>> spaces available.
>> 
>> 1/ "Forum" proper
>> 
>> There will be 3 medium-sized fishbowl rooms for cross-community
>> discussions. Topics for the discussions in that space will be selected
>> and scheduled by a committee formed of TC and UC members, facilitated by
>> Foundation staff members. In case you missed it, the brainstorming for
>> topics started last week, announced 

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Jonathan Bryce]

> On Feb 28, 2017, at 4:25 AM, Thierry Carrez  wrote:
> 
> Clint Byrum wrote:
 So, I'll ask more generally: do you believe that the single openstack-dev
 mailing list is working fine and we should change nothing? If not, what
 problems has it created for you? 
>>> 
>>> As a person who sends a lot of process-driven email to this list,
>>> it is not working for my needs to communicate with others.
>>> 
>>> Over the past few cycles when I was the release PTL, I always had
>>> a couple of PTLs say there was too much email on this list for them
>>> to read, and that they had not read my instructions for managing
>>> releases. That resulted in us having to train folks at the last
>>> minute, remind them of deadlines, deal with them missing deadlines,
>>> and otherwise increased the release team's workload.
>>> 
>>> It is possible the situation will improve now that the automation
>>> work is mostly complete and we expect to see fewer significant
>>> changes in the release workflow. That still leaves quite a few
>>> people regularly surprised by deadlines, though.
>> 
>> The problem above is really the krux of it. Whether or not you can keep
>> up with the mailing list can be an unknown, unknown. Even now, those
>> who can't actually handle the mailing list traffic are in fact likely
>> missing this thread about whether or not people can handle the mailing
>> list traffic (credit fungi for pointing out this irony to me on IRC).
> 
> Right, the main issue (for me) is that there is no unique way to reach
> out to people that you're 100% sure they will read. For some the miracle
> solution will be a personal email, for some it will be an IRC ping, for
> some it will be a Twitter private message. There is no 100% sure
> solution, and everyone prioritizes differently. The burden of reaching
> out and making sure the message was acknowledged is on the person who
> sends the message, and that just doesn't scale past 50 teams. That
> includes release team communications to PTLs, but also things like
> election nomination deadlines and plenty of other things.

Clint asked if there were specific issues in the workflow, and one item both 
Thierry and Doug have identified is reaching ALL project leaders consistently 
with important notifications or requests. I have also seen some working group 
leaders and Foundation staff experience similar difficulties. Perhaps creating 
a business-oriented list for PTLs similar to docs/infra that could help with 
that particular problem.

Jonathan



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

[openstack-dev] Supporting our global community

[Jonathan Bryce]

OpenStack is a global open source community. The OpenStack Foundation serves 
members in 180 countries focused on advancing the capabilities and 
accessibility of open infrastructure everywhere. We fundamentally believe 
diversity and collaboration are a powerful force for innovation, and it has 
been amazing to see the product of tens of thousands of people around the world 
over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump 
that targets individuals from 7 countries. The order restricts the travel and 
movement of people in a discriminatory way that  results in a restriction on 
access to talent and ideas. It is still unclear how the policies will play out 
and be enforced, but we will be watching, advocating for and supporting our 
community members to the best of our ability. 

This executive order will not impact the governance of the Foundation or the 
way the community operates globally. We will continue to support user groups 
and community members that are active in the seven countries named by the 
executive order, alongside our 120+ user groups around the world. However, we 
have two scheduled events in the United States within the next six months that 
will attract a global audience: the PTG (Project Teams Gathering) in Atlanta, 
Feb 20-24, a smaller event that will bring together hundreds of upstream 
contributors, and the OpenStack Summit in Boston, May 8-11, our larger event 
that happens every six months. 

This executive order could impact some community members' ability to travel to 
Atlanta and Boston, but unfortunately it is too late at this point to change 
the location of these events. The following three OpenStack Summits, however, 
are now scheduled to occur outside of the United States. The next Summit will 
be in November 2017 in Sydney, Australia and we are working to finalize the 
details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned 
that his plans to travel from Canada to Atlanta to attend the PTG may be 
restricted, simply because he a dual citizen of Canada and Iraq.  Mohammed has 
been contributing code to OpenStack since 2011 and is the CEO and Founder of 
Vexxhost. Blocking his travel would serve no purpose and rob the community of a 
valuable contributor during an important event. If you are concerned about the 
impact or have any questions, please don't hesitate to reach out to me at 
jonat...@openstack.org.

Political actions like this highlight the importance of our collective values. 
The Four Opens, the founding principles of our community, exist to ensure the 
free flow of talent and ideas, across geographic, national, organizational or 
other lines that might divide us. We believe in humanity. We believe in 
opportunity. We believe in the power of collaboration across borders, and we 
will continue to carry forward our mission.

We also posted this online: 
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell



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

Re: [Openstack-operators] What would you like in Pike?

[Jonathan Bryce]

> On Jan 16, 2017, at 11:03 AM, Matt Riedemann  
> wrote:
> 
> On 1/12/2017 7:30 PM, Melvin Hillsman wrote:
>> Hey everyone,
>> 
>> I am hoping to get a dialogue started to gain some insight around things
>> Operators, Application Developers, and End Users would like to see
>> happen in Pike. If you had a dedicated environment, dedicated team, and
>> freedom to choose how you deployed, new features, older features,
>> enhancements, etc, and were not required to deal with customer/client
>> tickets, calls, and maintenances, could keep a good feedback loop
>> between your team and the upstream community of any project, what would
>> like to make happen or work on hoping the next release of OpenStack
>> had/included/changed/enhanced/removed…?
>> 
> 
> I just wanted to say thanks for starting this thread. I often wonder what 
> people would like to see the Nova team prioritize because we don't get input 
> from the product work group or Foundation really on big ticket items so we're 
> generally left to prioritizing work on our own each release.

I agree; thanks Melvin! Great input so far.

Matt, on the input on big ticket items, I’d love to get your feedback on what 
is missing or you’d like to see more of in the Foundation reports or Product 
Working Group roadmaps to make them more useful for these kinds of items. Is 
this thread more consumable because specific functionality is identified over 
themes? Is it the way it’s scoped to a release? We could possibly even add in a 
similar question (“What would you like to see in the next release?”) to the 
user survey if this is info you’ve been looking for.

Thanks,

Jonathan






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

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

[Jonathan Bryce]

> On Jan 16, 2017, at 11:58 AM, Jay S. Bryant  
> wrote:
> 
> On 01/13/2017 10:29 PM, Mike Perez wrote:
>> The way validation works is completely up to the project team. In my research
>> as shown in the Summit etherpad [5] there's a clear trend in projects doing
>> continuous integration for validation. If we wanted to we could also have the
>> marketplace give the current CI results, which was also requested in the
>> feedback from driver maintainers.
> Having the CI results reported would be an interesting experiment. I wonder 
> if having the results even more publicly reported would result in more stable 
> CI's.  It is a dual edged sword however. Given the instability of many CI's 
> it could make OpenStack look bad to customers who don't understand what they 
> are looking at.  Just my thoughts on that idea.

That’s very useful feedback. Having that kind of background upfront is really 
helpful. As we make updates on the display side, we can take into account if 
certain attributes are potentially unreliable or at a higher risk of showing 
instability and have the interface better support that without it looking like 
everything is failing and a river of red X’s. Are there other things that might 
be similar?

Jonathan



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

[OpenStack-Infra] Thanks for enabling a great demo!

[Jonathan Bryce]

Hi Infra team,

I wanted to send a note to say thanks for helping us demo the power of a global 
footprint of clouds powered by OpenStack in Barcelona. If you weren’t there, 
you can watch the video as Lyz coaches me through adding some regions to 
nodepool and Clark and fungi push the change out (with a behind-the-scenes) +2 
from jeblair): 
http://www.openstack.org/videos/video/demoing-the-worlds-largest-multi-cloud-ci-application

We received a lot of really positive feedback, and I was very happy to be able 
to show off the awesome work you all have done over the last few years building 
out these tools. As I said in Barcelona, thanks again to everyone for letting 
us play with your systems live and in production!

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

[openstack-dev] Summit evolution online town halls

[Jonathan Bryce]

Hi everyone,

You might have seen the FAQ we posted last week about the continuing work 
on evolving the format and structure of the Summits: 
http://www.openstack.org/blog/2016/05/faq-evolving-the-openstack-design-summit/


I wanted to send a reminder note out to highlight that Thierry and I will 
be hosting 2 online town halls tomorrow at 1130 and 1900 UTC to talk 
through the current thinking and answer any new questions. Links to the 
webinars are at the top of the blog post. If you have specific questions 
not covered in the FAQ that you'd like us to talk about, feel free to email 
either of us directly beforehand and we will add them to the list.


Jonathan




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

Re: [openstack-dev] [Openstack] Rescinding the M name decision

[Jonathan Bryce]

 On Jul 9, 2015, at 9:35 AM, Russell Bryant rbry...@redhat.com wrote:
 
 On 07/09/2015 09:19 AM, Neil Jerram wrote:
 In the hope of forestalling an unnecessary sub-thread...
 
 Mita was #1 in the vote, so has presumably already been ruled out by
 OpenStack's legal review.
 
 That is correct.


Hi everyone,

I’ve really loved seeing everyone’s understanding and engagement on this thread 
as we worked through the release cycle naming for ‘M’. This was the first 
attempt to follow a new process, so not surprisingly, we found some 
improvements in the algorithm for the future. Still it’s awesome to see how 
constructive and positive the whole conversation has been.

I wanted to provide a quick update on the status of the Foundation’s reviews of 
the names. First, as Russell mentioned above, after the voting was completed, 
we asked our trademark counsel to do checks on the top 3 names. The first two 
both had significant trademark issues with existing trademark holders in the 
same space that would have prevented us from using the names in most 
jurisdictions where we have our largest communities (US, Europe and Asia). The 
3rd choice was relatively low risk and so we passed word back to Monty who 
announced it. Once we realized there were other issues with Meiji, we asked for 
an expedited check of the next 3 names: Mitaka, Musashi, and Meguro. The 
preliminary check shows that Mitaka and Meguro both present an acceptable level 
of risk, while Musashi is higher on the risk scale and would probably create 
problems for usage.

At this time, we’re going to do a deeper check on Mitaka, which was the #4 
candidate in voting and would be next in line after Meiji. I know Itoh-san 
mentioned the Mitaka locale has the potential to be associated with certain 
corporations in Japan, but my personal feeling is that may not be significant 
enough to override it’s position in the voting and it’s availability for use.

I’d encourage anyone with other concerns about Mitaka to post those within the 
next 24 hours so we can appropriately consider and discuss them. We should have 
results on the deeper trademark check by next week as well and can hopefully 
settle on a final name.

Thanks again for all the discussion and participation and especially to Monty 
who’s been on the front lines of helping us navigate this. Feel free to let me 
know if you have any other questions,

Jonathan
210-317-2438


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

Re: [openstack-dev] [tc] Take back the naming process

[Jonathan Bryce]

 On Jan 27, 2015, at 3:50 PM, Monty Taylor mord...@inaugust.com wrote:
 
 I do not like how we are selecting names for our releases right now.
 The current process is autocratic and opaque and not fun - which is the
 exact opposite of what a community selected name should be.

Autocratic? Could you elaborate?


 I propose:
 
 * As soon as development starts on release X, we open the voting for the
 name of release X+1 (we're working on Kilo now, we should have known the
 name of L at the K summit)
 
 * Anyone can nominate a name - although we do suggest that something at
 least related to the location of the associated summit would be nice
 
 * We condorcet vote on the entire list of nominated names
 
 * After we have the winning list, the foundation trademark checks the name
 
 * If there is a trademark issue (and only a trademark issue - not a
 marketing doesn't like the name issue) we'll move down to the next
 name on the list
 
 If we cannot have this process be completely open and democratic, then
 what the heck is the point of having our massive meritocracy in the
 first place? There's a lot of overhead we deal with by being a
 leaderless collective you know - we should occasionally get to have fun
 with it.


If your goal is to actually involve our massive meritocracy, I’d suggest 
expanding this thread to include at least the community marketing mailing list 
rather than just the -dev mailing list (possibly also the Foundation mailing 
list?). The release names are some of our most prominent brands, meaning 
choosing them is by definition a marketing activity. Not including the part of 
our meritocracy with experience in branding and marketing feels 
counterintuitive to me (again if the goal is actually to be meritocratic).

Jonathan



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

Re: [openstack-dev] [PTL] Designating required use upstream code

[Jonathan Bryce]

On Feb 6, 2014, at 8:08 AM, Dolph Mathews dolph.math...@gmail.com wrote:

 I'm curious about the level of granularity that's envisioned in each 
 definition. Designated sections could be as broad as keystone.* or as 
 narrow as keystone.token.controllers.Auth.validate_token_head(). It could be 
 defined in terms of executables, package paths, or line numbers.
 
 The definition is likely to change over time (i.e. per stable release). For 
 example, where support for password-based authentication might have been 
 mandated for an essex deployment, a havana deployment has the ability to 
 remove the password auth plugin and replace it with something else.
 
 The definition may also be conditional, and require either A or B. In 
 havana for example, where keystone shipped two stable APIs side by side, I 
 wouldn't expect all deployments to enable both (or even bother to update 
 their paste pipeline from a previous release).


Here’s an example of the real world application in the current implementation 
of the commercial usage agreements (Russell alluded to this earlier):

http://www.openstack.org/brand/powered-by-openstack/
--
PRODUCT REQUIREMENTS. You must meet the following requirements in order to 
qualify for an OpenStack Powered trademark license:

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

2) To ensure compatibility, your product must:

i. include the entirety of the OpenStack Compute (Nova) code from either of the 
latest two releases and associated milestones, but no older, and

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

3) 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.
--

The request from the DefCore committee around designated sections would replace 
Section 2(i) in the above example. The external API testing that is being 
developed would fulfill Section 3. You’ll notice that Section 2(i) is not 
granular at all, but does include a version requirement. I think Thierry’s 
proposal around breaking it into two separate steps makes a lot of sense. 
Ultimately, it all has to find its way into a form that can be included into 
the legal agreements these organizations sign.

Jonathan






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

Re: [openstack-dev] [Openstack-docs] Conventions on naming

[Jonathan Bryce]

On Feb 5, 2014, at 10:18 AM, Steve Gordon sgor...@redhat.com wrote:

 - Original Message -
 From: Andreas Jaeger a...@suse.com
 To: Mark McLoughlin mar...@redhat.com, OpenStack Development Mailing 
 List (not for usage questions)
 openstack-dev@lists.openstack.org
 Cc: Jonathan Bryce jonat...@openstack.org
 Sent: Wednesday, February 5, 2014 9:17:39 AM
 Subject: Re: [openstack-dev] [Openstack-docs] Conventions on naming
 
 On 02/05/2014 01:09 PM, Mark McLoughlin wrote:
 On Wed, 2014-02-05 at 11:52 +0100, Thierry Carrez wrote:
 Steve Gordon wrote:
 From: Anne Gentle anne.gen...@rackspace.com
 Based on today's Technical Committee meeting and conversations with the
 OpenStack board members, I need to change our Conventions for service
 names
 at
 https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names
 .
 
 Previously we have indicated that Ceilometer could be named OpenStack
 Telemetry and Heat could be named OpenStack Orchestration. That's not
 the
 case, and we need to change those names.
 
 To quote the TC meeting, ceilometer and heat are other modules (second
 sentence from 4.1 in
 http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/)
 distributed with the Core OpenStack Project.
 
 Here's what I intend to change the wiki page to:
 Here's the list of project and module names and their official names
 and
 capitalization:
 
 Ceilometer module
 Cinder: OpenStack Block Storage
 Glance: OpenStack Image Service
 Heat module
 Horizon: OpenStack dashboard
 Keystone: OpenStack Identity Service
 Neutron: OpenStack Networking
 Nova: OpenStack Compute
 Swift: OpenStack Object Storage
 
 Small correction. The TC had not indicated that Ceilometer could be
 named OpenStack Telemetry and Heat could be named OpenStack
 Orchestration. We formally asked[1] the board to allow (or disallow)
 that naming (or more precisely, that use of the trademark).
 
 [1]
 https://github.com/openstack/governance/blob/master/resolutions/20131106-ceilometer-and-heat-official-names
 
 We haven't got a formal and clear answer from the board on that request
 yet. I suspect they are waiting for progress on DefCore before deciding.
 
 If you need an answer *now* (and I suspect you do), it might make sense
 to ask foundation staff/lawyers about using those OpenStack names with
 the current state of the bylaws and trademark usage rules, rather than
 the hypothetical future state under discussion.
 
 Basically, yes - I think having the Foundation confirm that it's
 appropriate to use OpenStack Telemetry in the docs is the right thing.
 
 There's an awful lot of confusion about the subject and, ultimately,
 it's the Foundation staff who are responsible for enforcing (and giving
 advise to people on) the trademark usage rules. I've cc-ed Jonathan so
 he knows about this issue.
 
 But FWIW, the TC's request is asking for Ceilometer and Heat to be
 allowed use their Telemetry and Orchestration names in *all* of the
 circumstances where e.g. Nova is allowed use its Compute name.
 
 Reading again this clause in the bylaws:
 
  The other modules which are part of the OpenStack Project, but
   not the Core OpenStack Project may not be identified using the
   OpenStack trademark except when distributed with the Core OpenStack
   Project.
 
 it could well be said that this case of naming conventions in the docs
 for the entire OpenStack Project falls under the distributed with case
 and it is perfectly fine to refer to OpenStack Telemetry in the docs.
 I'd really like to see the Foundation staff give their opinion on this,
 though.

In this case, we are talking about documentation that is produced and 
distributed with the integrated release to cover the Core OpenStack Project and 
the “modules that are distributed together with the Core OpenStack Project in 
the integrated release. This is the intended use case for the exception Mark 
quoted above from the Bylaws, and I think it is perfectly fine to refer to the 
integrated components in the OpenStack release documentation as OpenStack 
components.


 What Steve is asking IMO is whether we have to change OpenStack
 Telemetry to Ceilometer module or whether we can just say Telemetry
 without the OpenStack in front of it,
 
 Andreas
 
 Constraining myself to the topic of what we should be using in the 
 documentation, yes this is what I'm asking. This makes more sense to me than 
 switching to calling them the Heat module and Ceilometer module because:
 
 1) It resolves the issue of using the OpenStack mark where it (apparently) 
 shouldn't be used.
 2) It means we're still using the formal name for the program as defined by 
 the TC [1] (it is my understanding this remains the purview of the TC, it's 
 control of the mark that the board are exercising here).
 3) It is a more minor change/jump and therefore provides more continuity and 
 less confusion to readers (and similarly if one of them ever becomes endorsed 
 as core and we need to switch again

Re: [openstack-dev] [PTL] Designating required use upstream code

[Jonathan Bryce]

On Feb 5, 2014, at 11:12 AM, Mark McLoughlin mar...@redhat.com wrote:

 I don't have a big issue with the way the Foundation currently enforces
 you must use the code - anyone who signs a trademark agreement with
 the Foundation agrees to include the entirety of Nova's code. That's
 very vague, but I assume the Foundation can terminate the agreement if
 it thinks the other party is acting in bad faith.
 
 Basically, I'm concerned about us swinging from a rather lax you must
 include our code rule to an overly strict you must make no downstream
 modifications to our code”.

I tend to agree with you for the most part. As they exist today, the trademark 
licenses include a couple of components: legally agreeing to use the code in 
the projects specified (requires self certification from the licensee) and 
passing the approved test suite once it exists (which adds a component 
requiring external validation of behavior). By creating the test suite and 
selecting required capabilities that can be externally validated through the 
test suite, we would take a step in tightening up the usage and consistency 
enforceable by our existing legal framework.

I think that designated sections” could provide a useful construct for better 
general guidance on where the extension points to the codebase are. From a 
practical standpoint, it would probably be pretty difficult to efficiently 
audit an overly strict definition of the designated sections and this would 
still be a self certifying requirement on the licensee.

Jonathan


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

Re: [Openstack] [Foundation Board] Resolutions from the Technical Committee

[Jonathan Bryce]

To Mark’s earlier point, this is the relevant language in 4.1(b) 
(http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/):
 
The other modules which are part of the OpenStack Project, but not the Core 
OpenStack Project may not be identified using the OpenStack trademark except 
when distributed with the Core OpenStack Project.
 
In this sentence distributed with the Core OpenStack Project is another way 
of saying distributed with the integrated release.” Since Heat and Ceilometer 
are part of the integrated release starting with Havana, as voted on by the TC, 
the projects (a.k.a. modules) can be referred to with an OpenStack generic 
name, such as  OpenStack Orchestration, without being added to the Core 
list. Other modules such as Devstack which are not distributed as part of the 
integrated release could not as they don’t meet the exception in the sentence 
above.

To provide some context from the drafting process when this was written, the 
intent was to arrive at a set of modules explicitly approved by the Board as 
part of the Core OpenStack Project which would be useful for determining 
interop and commercial product and service trademark usage. This is along the 
lines of the “spider” work that has been going on. The exception in the 
sentence quoted above from 4.1(b) was to allow for an integrated release that 
included additional modules that the TC felt had the technical merit to be 
developed, released and distributed as part of the total set of OpenStack 
software, but that may not have the universal applicability of a module of the 
Core OpenStack Project that became a required component for commercial 
trademark use.

Jonathan


On Nov 14, 2013, at 11:01 AM, Boris Renski bren...@mirantis.com wrote:

 In this case, statement by Mark below is inaccurate. Until BoD passes the 
 resolution for Heat to call itself, OpenStack Orchestration (which I don't 
 believe it has), Heat remains an integrated project called Heat and NOT 
 OpenStack Orchestration 
 
 Am I getting it right? 
 
 
  *Can* the projects themselves use the word OpenStack such as
  OpenStack Orchestration? Answer: yes absolutely. This is already a
  done deal and we are already doing it in practice. And its covered
  under the bylaws once they are included in the integrated release by
  TC vote. There is no need for further action.
 
 
 On Thu, Nov 14, 2013 at 8:56 AM, Thierry Carrez thie...@openstack.org wrote:
 Boris Renski wrote:
  None of this answers the question of what is currently the difference
  between core and integrated. I agree with everything you said, but it
  sounds to me like *integrated* = *core* at this point.
 
 Well, no.
 
 Integrated is the list of projects we produce and release together
 every 6 months. That's fully determined by the TC.
 
 The Core OpenStack Project as defined in the bylaws is the list of
 projects that can call themselves OpenStack X. The TC recommends that
 it's the same as the list of integrated projects, but the BoD may decide
 to exclude some of those (since the bylaws grant them that power).
 
 And then there are all the other fun use cases for the word core.
 
 So while there is definitely a relation between Integrated and one of
 the many use cases of the term Core, I definitely wouldn't go as far
 as saying *integrated* = *core* at this point.
 
 --
 Thierry Carrez (ttx)
 
 ___
 Foundation-board mailing list
 foundation-bo...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Foundation Board] Resolutions from the Technical Committee

[Jonathan Bryce]

The current difference in implementation is that to be part of the Core 
OpenStack Project, a module must receive Board approval to be in that set. 
Another intended difference is that the Core OpenStack Project definition would 
be used as a means of collecting the projects for various trademark licensing 
and interop requirements. That part of the implementation is still in progress 
with the ongoing work of the Board.

The Bylaws were drafted to take into account the expected direction that these 
initiatives were going to move based off the drafting meetings we had last 
year, and they included some “forward looking” provisions like this. Same thing 
with the FITS testing piece of the trademark licenses that gives the TC the 
right to approve a test suite for usage.

Jonathan



On Nov 14, 2013, at 12:26 PM, Boris Renski bren...@mirantis.com wrote:

 Just to clear, I have nothing against Heat or Ceilometer calling themselves 
 OpenStack Orchestration and OpenStack Metering respectively. 
 
 What I am trying to understand is the current difference between core and 
 integrated projects and it doesn't sound like anybody knows. 
 
 
 On Thu, Nov 14, 2013 at 10:05 AM, Monty Taylor mord...@inaugust.com wrote:
 I believe the part of the thing Jonathan was referencing that the TC is
 talking about is the final line of 4.1(b):
 
 The Secretary shall maintain a list of the modules in the Core
 OpenStack Project which shall be posted on the Foundation’s website.
 
 Which led us to believe that we needed to suggest that the secretary
 update the list of modules so that heat and ceilometer could use the naming.
 
 However, I believe that Jonathan has clarified that this is not
 necessary and the both of them are already allowed to use that naming
 because they are part of the integrated release. This does not make them
 Core - but they do not need to be core in order to accomplish the
 thing the TC was asking about.
 
 SO - I think everyone's intent is in line, and we needed clarity on the
 actions actually needed.
 
 On 11/14/2013 12:56 PM, Boris Renski wrote:
  OK, I am totally confused then.
 
  If per bylaws any integrated project can called itself OpenStack Blah
  then we return to the question of current difference between integrated
  and core. It seems like there is no alignment. Jonathan's opinion
  contradicts Thierry's.
 
  Perhaps, we should all just agree that there is no difference until
  after the interop work is done and core becomes defined via a series of
  tests?
 
 
 
 
  On Thu, Nov 14, 2013 at 9:41 AM, Jonathan Bryce jbr...@jbryce.com
  mailto:jbr...@jbryce.com wrote:
 
  To Mark’s earlier point, this is the relevant language in 4.1(b)
  (http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/):
 
  The other modules which are part of the OpenStack Project, but not
  the Core OpenStack Project may not be identified using the OpenStack
  trademark except when distributed with the Core OpenStack Project.
 
  In this sentence distributed with the Core OpenStack Project is
  another way of saying distributed with the integrated release.”
  Since Heat and Ceilometer are part of the integrated release
  starting with Havana, as voted on by the TC, the projects (a.k.a.
  modules) can be referred to with an OpenStack generic name, such
  as  OpenStack Orchestration, without being added to the Core
  list. Other modules such as Devstack which are not distributed as
  part of the integrated release could not as they don’t meet the
  exception in the sentence above.
 
  To provide some context from the drafting process when this was
  written, the intent was to arrive at a set of modules explicitly
  approved by the Board as part of the Core OpenStack Project which
  would be useful for determining interop and commercial product and
  service trademark usage. This is along the lines of the “spider”
  work that has been going on. The exception in the sentence quoted
  above from 4.1(b) was to allow for an integrated release that
  included additional modules that the TC felt had the technical merit
  to be developed, released and distributed as part of the total set
  of OpenStack software, but that may not have the universal
  applicability of a module of the Core OpenStack Project that became
  a required component for commercial trademark use.
 
  Jonathan
 
 
  On Nov 14, 2013, at 11:01 AM, Boris Renski bren...@mirantis.com
  mailto:bren...@mirantis.com wrote:
 
   In this case, statement by Mark below is inaccurate. Until BoD
  passes the resolution for Heat to call itself, OpenStack
  Orchestration (which I don't believe it has), Heat remains an
  integrated project called Heat and NOT OpenStack Orchestration
  
   Am I getting it right?
  
  
*Can* the projects themselves use the word OpenStack such as
OpenStack

Re: [openstack-dev] Program description for Oslo

[Jonathan Bryce]

Any reason for not just calling it OpenStack Commons?

Mark McLoughlin mar...@redhat.com wrote:

Hey

The mission statement is what we've been using for a while. The
official title is new.

  Official Title: OpenStack Common Libraries
  PTL: Mark McLoughlin mar...@redhat.com
  Mission Statement:
To produce a set of python libraries containing infrastructure code 
shared by OpenStack projects. The APIs provided by these libraries
should be high quality, stable, consistent and generally applicable.

I did consider explicitly mentioning technical debt with something like:

  Mission Statement:
To tackle copy-and-paste technical debt in OpenStack by producing a
set of python libraries containing infrastructure code shared by
OpenStack projects. The APIs provided by these libraries should be
high quality, stable, consistent and generally applicable.

But for wholly new code, that sounds like you need to introduce
copy-and-paste technical debt before it can be considered in scope for
Oslo :)

Cheers,
Mark.


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