Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal
On Fri, Oct 20, 2017 at 7:16 PM, Morgan Fainberg wrote: > Let me clarify a few things regarding the V2.0 removal: > > * This has been planned for years at this point. At one time (I am > looking for the documentation, once I find it I'll include it on this > thread) we worked with Nova and the TC to set forth a timeline on the > removal. Part of that agreement was that this was a one-time deal. We > would remove the V2.0 API in favor of the v3 API but would never > remove another API going forward. > Glad to hear this. Does this apply to all projects? Deprecation and removal of API versions or versions of features (especially before new version of feature has parity and proven scale to older version of feature) has been a pain point for large production public clouds in terms of keeping in sync with upstream which then adversely affects the ability of that organization to contribute back to upstream due to having to stay on older versions. It can quickly become too painful, risky, and costly to ever reconcile eventually leading to the organization no longer meaningful contributing to projects where they've drifted too far all together. I consider this scenario to be very unfortunate for the customer's of that public cloud as well as the OpenStack project itself. __ 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] StackViz is now enabled for all devstack-gate jobs
Congratulations! Happy to see this important milestone. Awesome job! On 6 Jun 2016 18:32, "Buckley, Tim Jason" wrote: > Hello all, > > I'd like to announce that StackViz will now be running at the end all > tempest-dsvm jobs and saving visualization output to the log server. > > StackViz is a visualization utility for generating interactive > visualizations of > jobs in the OpenStack QA pipeline and aims to ease debugging and > performance > analysis tasks. Currently it renders an interactive timeline for subunit > results and dstat data, but we are actively working to visualize more log > types > in the future. > > StackViz instances are saved as a 'stackviz' directory under 'logs' for > each job > run on http://logs.openstack.org/. For an example, see: > > http://logs.openstack.org/07/212207/8/check/gate-tempest-dsvm-full/2d30217/logs/stackviz/ > > For more information StackViz, see the project page at: > https://github.com/openstack/stackviz > > Bugs can also be reported at: > https://bugs.launchpad.net/stackviz > > Feedback is greatly appreciated! > > Thanks, > Tim Buckley > > > __ > 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] OpenStack Contributor Awards
On Tue, Feb 16, 2016 at 5:43 AM, Tom Fifield wrote: > Hi all, > > I'd like to introduce a new round of community awards handed out by the > Foundation, to be presented at the feedback session of the summit. > > > > in the meantime, let's use this thread to discuss the fun part: goodies. > What do you think we should lavish award winners with? Soft toys? Perpetual > trophies? baseball caps ? > For some, an appreciation plaque or nicely framed, signed letter of appreciation from the board or TC would provide the right amount of personal touch and effort to appropriately show our appreciation. -- Cody A.W. Somerville __ 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] [tc] "No Open Core" in 2016
On Sat, Feb 6, 2016 at 2:14 AM, Cody A.W. Somerville < cody.somervi...@gmail.com> wrote: > > I'd like to suggest we tightly scope this discussion and subsequent > decision to Poppy exclusively. The reason for this is two fold. The first > is so that a timely resolution and answer can be provided to the Poppy > team. The second is that I think once we've answered the specific > questions and concerns about Poppy (some of which I believe are novel in > nature) we'll be in a better position to then inductively reason about the > problem and derive the more generalized rule or principle that I think > Thierry was hoping to establish. > > In that vein, I'll try to summarize the questions or concerns I've seen > raised here and in the TC meeting[3] - apologies if I've missed any: > > Poppy is an OpenStack project designed to make CDN services easier to > consume with a generic vendor-neutral API[4]. The concern is that it only > has support for commercial CDN service providers. It does not have support > for a CDN service that is Open Source. > > 1. Is Poppy "open core"[5] or violate OpenStack's 'Four Opens'[6]? > I do not believe that Poppy meets the definition of "Open Core". By most accounts, "Open Core" is a business or licensing model where there are proprietary editions of a product built on top of a core open source technology or project and/or project uses copyright assignment in order to be able to dual license under non-open source licenses. Neither seem applicable here. > 2. Do we have a requirement that the primary component/backend (or at > least one of the components/backends) driven/abstracted/orchestrated by a > project (directly or via driver/plugin/et al) be considered Open Source? If > yes, is there room for an exception when one simply doesn't exist? Is > there special consideration for "services" (ie. think GPL vs. AGPL)? > There is clearly the preference, if not the requirement when such an opportunity exists, but no one has expressed that this is a hard requirement otherwise. > 3. Does a project that only enables the use of commercial > services/projects belong in OpenStack? > I think providing a standard abstraction for provisioning and managing content distribution furthers our goal of being the ubiquitous open cloud platform. I predict that content distribution will become an important and very standard capability desired in large cloud deployments, particularly in enterprise environments that span the globe, and so we'll likely see such a service developed and probably be powered by swift. Due to the nature of CDN, augmenting your content distribution capabilities with a third-party CDN provider will be common and natural. > 4. Does Poppy violate existing requirements around testing/CI[7][8]? > I do not believe that it does. Using mocks and/or unit tests would be sufficient to meet "test-driven gate" requirement. > 5. Does dependency on Casandra make Poppy non-free? > TBD. > 6. Does a project that only enables the use of non-OpenStack > services/projects belong in OpenStack? > The big tent model seems to explicitly encourage the idea that projects in the OpenStack ecosystem are welcome to consider themselves OpenStack projects. Poppy itself isn't just a consumer but is intended to be a first-class cloud service. Some additional facts that have been pointed out include: > > - It currently only supports Akamai - which makes sense to be the first > provider, Akamai is the CDN provider for Rackspace[9] and the project is > mostly developed by Rackspace[10] - but implementation is underway for > Fastly, Amazon CloudFront, and MaxCDN[11]. > - It currently only supports Rackspace DNS but support for Designate is > planned[11] (only a stub exists in tree currently). > I'm surprised these two points - particularly the latter, the fact that Poppy currently only supports Rackspace DNS where Designate does exist and could be integrated with - has not been raised by anyone else. Cody __ 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] [tc] "No Open Core" in 2016
On Wed, Feb 17, 2016 at 1:20 PM, Jay Pipes wrote: > On 02/17/2016 09:30 AM, Doug Hellmann wrote: > >> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: >> >>> On 02/16/2016 11:30 AM, Doug Hellmann wrote: >>> So I think the project team is doing everything we've asked. We changed our policies around new projects to emphasize the social aspects of projects, and community interactions. Telling a bunch of folks that they "are not OpenStack" even though they follow those policies is rather distressing. I think we should be looking for ways to say "yes" to new projects, rather than "no." >>> >>> My disagreements with accepting Poppy has been around testing, so let me >>> reiterate what I've already said in this thread. >>> >>> The governance currently states that under Open Development "The project >>> has core reviewers and adopts a test-driven gate in the OpenStack >>> infrastructure for changes" [1]. >>> >>> If we don't have a solution like OpenCDN, Poppy has to adopt a reference >>> implementation that is a commercial entity, and infra has to also be >>> dependent on it. I get Infra is already dependent on public cloud >>> donations, but if we start opening the door to allow projects to bring >>> in those commercial dependencies, that's not good. >>> >> >> Only Poppy's test suite would rely on that, though, right? And other >> projects can choose whether to co-gate with Poppy or not. So I don't see >> how this limitation has an effect on anyone other than the Poppy team. >> > > But what would really be tested in Poppy without any commercial CDN > vendor? Nothing functional, right? I believe the fact that Poppy cannot be > functionally tested in the OpenStack CI gate basically disqualifies it from > being "in OpenStack". > There is no implicit (or explicit) requirement for the tests to be a full integration/end-to-end test. Mocks and/or unit tests would be sufficient to satisfy "test-driven gate". __ 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] [tc] "No Open Core" in 2016
There are a lot of good questions and points being raised in this thread but I think it might be appropriate to say we've opened a can of worms. As mentioned by Doug there is a rather specific case[1] being considered that I think provides some important context and framing. It is clear that there are some that feel Poppy[2] should not be an official OpenStack project. Deciding what is and what isn't an OpenStack project is important for a number of reasons including protection of the brand/identity of the project and the community; being faithful to our principles; and logistical/resource constraints. It is a complicated and nuanced topic with many considerations as evidenced by the many conversations and opinions raised as part of the transition to the "big tent model". I'll agree with Anita that it is a remarkable point of strength that we've been able to communicate and find the consensus that we have on these subjects when it is clear from even this short thread that there is such a rich diversity of concerns, motivations, and agendas. I'd like to suggest we tightly scope this discussion and subsequent decision to Poppy exclusively. The reason for this is two fold. The first is so that a timely resolution and answer can be provided to the Poppy team. The second is that I think once we've answered the specific questions and concerns about Poppy (some of which I believe are novel in nature) we'll be in a better position to then inductively reason about the problem and derive the more generalized rule or principle that I think Thierry was hoping to establish. In that vein, I'll try to summarize the questions or concerns I've seen raised here and in the TC meeting[3] - apologies if I've missed any: Poppy is an OpenStack project designed to make CDN services easier to consume with a generic vendor-neutral API[4]. The concern is that it only has support for commercial CDN service providers. It does not have support for a CDN service that is Open Source. 1. Is Poppy "open core"[5] or violate OpenStack's 'Four Opens'[6]? 2. Do we have a requirement that the primary component/backend (or at least one of the components/backends) driven/abstracted/orchestrated by a project (directly or via driver/plugin/et al) be considered Open Source? If yes, is there room for an exception when one simply doesn't exist? Is there special consideration for "services" (ie. think GPL vs. AGPL)? 3. Does a project that only enables the use of commercial services/projects belong in OpenStack? 4. Does Poppy violate existing requirements around testing/CI[7][8]? 5. Does dependency on Casandra make Poppy non-free? 6. Does a project that only enables the use of non-OpenStack services/projects belong in OpenStack? Some additional facts that have been pointed out include: - It currently only supports Akamai - which makes sense to be the first provider, Akamai is the CDN provider for Rackspace[9] and the project is mostly developed by Rackspace[10] - but implementation is underway for Fastly, Amazon CloudFront, and MaxCDN[11]. - It currently only supports Rackspace DNS but support for Designate is planned[11] (only a stub exists in tree currently). I'm going to ponder the above and I'll respond with my thoughts. As for the following, they are all important and deserve deliberation but I'd respectfully suggest we table them for another day - or at least separately - so they get the attention and consideration they deserve: a) definitions for production-grade or scalable; b) new sets of requirements or standards for official projects, such as the former; c) new requirements or conventions around feature parity or priority between plugins/drivers/et al for Open Source vs. proprietary components; d) changing conventions around hosting of non-official projects; e) changing requirements around testing/CI; f) deciding anything already part of OpenStack isn't open enough or unsuitable to be an OpenStack project; or g) material change or extension to the shared or common understanding of "Open Core" in relation to deciding if Poppy is or is not open core. [1] https://review.openstack.org/#/c/273756/ [2] http://www.poppycdn.org/ [3] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-02-02-20.01.html [4] https://wiki.openstack.org/wiki/Poppy [5] https://en.wikipedia.org/wiki/Open_core [6] https://wiki.openstack.org/wiki/Open OR https://governance.openstack.org/reference/opens.html [7] https://governance.openstack.org/reference/project-testing-interface.html [8] Additional requirements exist such as must not install non-free software in our hosted CI. [9] https://www.rackspace.com/cloud/cdn-content-delivery-network [10] http://stackalytics.com/?project_type=all&release=all&module=poppy&metric=commits [11] https://github.com/openstack/poppy#features Best regards, Cody -- Cod
[openstack-dev] [all][infra] Impact of HPE Helion Public Cloud Sunset on OpenStack Infrastructure
The HPE Helion Public Cloud is one of several OpenStack public clouds that generously donate compute, network, and storage resources to power the OpenStack Developer Infrastructure. As you may know, HPE is sunsetting the HPE Helion Public Cloud on January 31st 2016[1]. Use of HPE Helion Public Cloud resources by the OpenStack Infrastructure system will be discontinued this Friday, January 29th. This will have an impact on the number of compute nodes available to run gate tests and as such developers may experience longer wait times. Efforts are underway to launch an OpenStack cloud managed by the OpenStack infrastructure team with hardware generously donated by Hewlett-Packard Enterprise. Among other outcomes, the intention is for this private cloud to provide a similar level of capacity for use by the infrastructure system in lieu of the HPE Helion Public Cloud. The infrastructure team is holding an in-person sprint to focus on this initiative next month in Fort Collins CO February 22nd - 25th[2][3]. For more information about the "infra-cloud" project, please see http://docs.openstack.org/infra/system-config/infra-cloud.html If your organization is interested in donating public cloud resources, please see http://docs.openstack.org/infra/system-config/contribute-cloud.html Last, but not least, a huge thank you to HPE for their support and continued commitment to the OpenStack developer infrastructure project. [1] http://community.hpe.com/t5/Grounded-in-the-Cloud/A-new-model-to-deliver-public-cloud/ba-p/6804409#.VqgUMF5VKlM [2] http://lists.openstack.org/pipermail/openstack-infra/2015-December/003554.html [3] https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint -- Cody A.W. Somerville __ 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] [Elections] TC Election analysis
On Thu, Apr 30, 2015 at 4:00 PM, Joe Gordon wrote: > On Thu, Apr 30, 2015 at 1:28 PM, Maish Saidel-Keesing > wrote: > >> On 04/30/15 21:48, Joe Gordon wrote: >> >>> As others have done for past elections, here is a brief breakdown of the >>> TC election ballot data. >>> >>> analysis: http://paste.openstack.org/show/213831 >>> source code: http://paste.openstack.org/show/213830 >>> >>> > Thanks Joe for the analysis. It is quite interesting. Another thing that >> I find interesting is the low participation rate. >> >> Out of 2169 eligible voters, 548 participated - that is 25.26%. >> > > According to [0] there were 369 ”Regular” contributors in 2014, and in > Kilo there were only 748 contributors with 5 or more patches out of > the 1886 contributors [1]. So measuring participation from eligible votes > is a misleading. Well over half of the eligible voters have only > contributed a few patches, and we had more voters participate then we have > 'regular' contributors. So I think our turnout is actually really good. > > [0] https://www.openstack.org/assets/reports/osf-annual-report-2014.pdf > [1] http://stackalytics.com/?release=kilo&metric=commits > > >> >> Comparing to previous elections >> Oct. 2014 - 1893 eligible voters, 506 participated - 26.73% >> Apr. 2014 - 1510 eligible voters, 408 participated - 29.66% >> >> I am wondering why the participation level is so low. This is really one >> of the few opportunities a contributor has to define the direction of >> OpenStack as a whole. And yet it goes down each election. >> > I would also hypothesize that contributors who are eligible but less regular in their contribution may not pay as much attention (or even be subscribed? -- would be an interesting metric to see I imagine) to the mailing list where a majority of the promotion and election activity occur. Where do all code contributors visit? Gerrit. If we were able to put up Clippy on Gerrit for April Fools, maybe we could put something up to raise awareness during the next election cycle? This could include linking people to the election wiki page and reminding eligible folks to ensure they have their correct e-mail address in Gerrit in order to receive a ballot. -- Cody A.W. Somerville __ 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] [infra] Nominating Elizabeth K. Joseph for infra-core and root
Huge +1 from me! Congratulations Elizabeth! On Fri, Jan 30, 2015 at 12:20 PM, James E. Blair wrote: > Hi, > > The Infrastructure program has a unique three-tier team structure: > contributors (that's all of us!), core members (people with +2 ability > on infra projects in Gerrit) and root members (people with > administrative access). Read all about it here: > > http://ci.openstack.org/project.html#team > > Elizabeth K. Joseph has been reviewing a significant number of infra > patches for some time now. She has taken on a number of very large > projects, including setting up our Git server farm, adding support for > infra servers running on CentOS, and setting up the Zanata translation > system (and all of this without shell access to production machines). > > She understands all of our servers, regardless of function, size, or > operating system. She has frequently spoken publicly about the unique > way in which we perform systems administration, articulating what we are > doing and why in a way that inspires us as much as others. > > Due to her strong systems administration background, I am nominating her > for both infra-core and infra-root simultaneously. I expect many of us > are looking forward to seeing her insight and direction applied with +2s > but also equally excited for her to be able to troubleshoot things when > our best-laid plans meet reality. > > Please respond with any comments or concerns. > > Thanks, Elizabeth, for all your work! > > -Jim > > __ > 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 > -- Cody A.W. Somerville __ 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] Launchpad bug tracker defects (was: Proposal oslo.db lib)
On Sat, Aug 17, 2013 at 12:57 AM, Clint Byrum wrote: > Excerpts from Thierry Carrez's message of 2013-08-16 13:55:46 -0700: > ... > > The reason is that it's actually difficult to get a view of all "oslo" > > bugs due to Launchpad shortcomings (a project can only be in one project > > group). So keeping them in a single "project" simplifies the work of > > people that look after all of "Oslo". > > > > This should be fixed in the future with a task tracker that handles > > project groups sanely, and then there is no reason at all to use the > > same project for different repositories. > > > > I know this sounds like a crazy idea, but have we looked at investing any > time in adding this feature to Launchpad? > > TripleO has the same problem. We look at bugs for: > > tripleo > diskimage-builder > os-apply-config > os-collect-config > os-refresh-config > > Now, having all of those in one project is simply not an option, as they > are emphatically different things. Part of TripleO is allowing users to > swap pieces out for others, so having clear lines between components is > critical. > > I remember similar problems working on juju, juju-jitsu, charm-tools, > and juju-core. > > Seems like it would be worth a small investment in Launchpad vs. having > to switch to another tracker. > Their issue is slightly more nuanced. They're already using project groups to provide a unified view (for all of OpenStack - which might be of dubious value) but the trouble is that a project can only belong to one project group. For tripleo, you might want to look at having a launchpad admin create you a project group if they aren't required to be part of the openstack project group. -- Cody A.W. Somerville ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
