Re: [openstack-dev] [tc] assigning new liaisons to projects
On Mon, Oct 8, 2018 at 11:57 PM Ghanshyam Mann wrote: > > > > On Mon, 08 Oct 2018 23:27:06 +0900 Doug Hellmann < > d...@doughellmann.com> wrote > > TC members, > > > > Since we are starting a new term, and have several new members, we need > > to decide how we want to rotate the liaisons attached to each our > > project teams, SIGs, and working groups [1]. > > > > Last term we went through a period of volunteer sign-up and then I > > randomly assigned folks to slots to fill out the roster evenly. During > > the retrospective we talked a bit about how to ensure we had an > > objective perspective for each team by not having PTLs sign up for their > > own teams, but I don't think we settled on that as a hard rule. > > > > I think the easiest and fairest (to new members) way to manage the list > > will be to wipe it and follow the same process we did last time. If you > > agree, I will update the page this week and we can start collecting > > volunteers over the next week or so. > > +1, sounds good to me. > > -gmann > +1 from me as well. > > > > Doug > > > > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker > > > > > __ > > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)
+1 from me. On Thu, Sep 20, 2018 at 5:59 PM Melvin Hillsman wrote: > I agree all lists should be merged as discussed otherwise why not just > leave all things as they are :P > > On Thu, Sep 20, 2018 at 4:49 PM Emilien Macchi wrote: > >> >> >> On Thu, Sep 20, 2018 at 5:47 PM Doug Hellmann >> wrote: >> >>> Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +: >>> > tl;dr: The openstack, openstack-dev, openstack-sigs and >>> > openstack-operators mailing lists (to which this is being sent) will >>> > be replaced by a new openstack-disc...@lists.openstack.org mailing >>> > list. >>> >>> Since last week there was some discussion of including the openstack-tc >>> mailing list among these lists to eliminate confusion caused by the fact >>> that the list is not configured to accept messages from all subscribers >>> (it's meant to be used for us to make sure TC members see meeting >>> announcements). >>> >>> I'm inclined to include it and either use a direct mailing or the >>> [tc] tag on the new discuss list to reach TC members, but I would >>> like to hear feedback from TC members and other interested parties >>> before calling that decision made. Please let me know what you think. >>> >> >> +2 , easier to manage, easier to reach out. >> -- >> Emilien Macchi >> __ >> 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 >> > > > -- > Kind regards, > > Melvin Hillsman > mrhills...@gmail.com > mobile: (832) 264-2646 > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [election][tc]Question for candidates about global reachout
nnel would prevent our community from fragmenting. >> > > >> > > Truly the usage of IRC is certainly questionable, but if we have >> multiple ways to discuss, I just doubt we could prevent us to silo >> ourselves between our personal usages. >> > > Either we consider the new channels as being only for southbound >> communication, or we envisage the possibility, as a community, to migrate >> from IRC to elsewhere (I'm particulary not fan of the latter so I would >> challenge this but I can understand the reasons) >> > > >> > > -Sylvain >> > > >> > >> > Objectively, I don't see a way to endorse something other than IRC >> > without some form of collective presence on more than just Wechat to >> > keep the message intact. IRC is the official messaging platform, for >> > whatever that's worth these days. However, at present, it makes less >> > and less sense to explicitly eschew other outlets in favor. From a >> > Chef OpenStack perspective, the common medium is, perhaps not >> > unsurprising, code review. Everything else evolved over time to be >> > southbound paths to the code, including most of the conversation >> > taking place there as opposed to IRC. >> > >> > The continuation of this thread only confirms that there is already >> > fragmentation in the community, and that people on each side of the >> > void genuinely want to close that gap. At this point, the thing to do >> > is prevent further fragmentation of the intent. It is, however, far >> > easier to bikeshed over which platform of choice. >> > >> > At present, it seems a collective presence is forming ad hoc, >> > regardless of any such resolution. With some additional coordination >> > and planning, I think that there could be something that could scale >> > beyond one or two outlets. >> > >> > Best, >> > Samuel >> > >> > >> __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> -- >> Mohammed Naser — vexxhost >> - >> D. 514-316-8872 >> D. 800-910-1726 ext. 200 >> E. mna...@vexxhost.com >> W. http://vexxhost.com >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://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 > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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-sigs] Open letter/request to TC candidates (and existing elected officials)
Folks, Sorry for the top post - Those of you that are still at PTG, please feel free to drop in to the Clear Creek room today. Thanks, Dims On Thu, Sep 13, 2018 at 2:44 PM Jeremy Stanley wrote: > On 2018-09-12 17:50:30 -0600 (-0600), Matt Riedemann wrote: > [...] > > Again, I'm not saying TC members should be doing all of the work > > themselves. That's not realistic, especially when critical parts > > of any major effort are going to involve developers from projects > > on which none of the TC members are active contributors (e.g. > > nova). I want to see TC members herd cats, for lack of a better > > analogy, and help out technically (with code) where possible. > > I can respect that. I think that OpenStack made a mistake in naming > its community management governance body the "technical" committee. > I do agree that having TC members engage in activities with tangible > outcomes is preferable, and that the needs of the users of its > software should weigh heavily in prioritization decisions, but those > are not the only problems our community faces nor is it as if there > are no other responsibilities associated with being a TC member. > > > Given the repeated mention of how the "help wanted" list continues > > to not draw in contributors, I think the recruiting role of the TC > > should take a back seat to actually stepping in and helping work > > on those items directly. For example, Sean McGinnis is taking an > > active role in the operators guide and other related docs that > > continue to be discussed at every face to face event since those > > docs were dropped from openstack-manuals (in Pike). > > I completely agree that the help wanted list hasn't worked out well > in practice. It was based on requests from the board of directors to > provide some means of communicating to their business-focused > constituency where resources would be most useful to the project. > We've had a subsequent request to reorient it to be more like a set > of job descriptions along with clearer business use cases explaining > the benefit to them of contributing to these efforts. In my opinion > it's very much the responsibility of the TC to find ways to > accomplish these sorts of things as well. > > > I think it's fair to say that the people generally elected to the > > TC are those most visible in the community (it's a popularity > > contest) and those people are generally the most visible because > > they have the luxury of working upstream the majority of their > > time. As such, it's their duty to oversee and spend time working > > on the hard cross-project technical deliverables that operators > > and users are asking for, rather than think of an infinite number > > of ways to try and draw *others* to help work on those gaps. > > But not everyone who is funded for full-time involvement with the > community is necessarily "visible" in ways that make them electable. > Higher-profile involvement in such activities over time is what gets > them the visibility to be more easily elected to governance > positions via "popularity contest" mechanics. > > > As I think it's the role of a PTL within a given project to have a > > finger on the pulse of the technical priorities of that project > > and manage the developers involved (of which the PTL certainly may > > be one), it's the role of the TC to do the same across openstack > > as a whole. If a PTL doesn't have the time or willingness to do > > that within their project, they shouldn't be the PTL. The same > > goes for TC members IMO. > > Completely agree, I think we might just disagree on where to strike > the balance of purely technical priorities for the TC (as I > personally think the TC is somewhat incorrectly named). > -- > Jeremy Stanley > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] Open letter/request to TC candidates (and existing elected officials)
On Wed, Sep 12, 2018 at 3:30 PM Dan Smith wrote: > > I'm just a bit worried to limit that role to the elected TC members. If > > we say "it's the role of the TC to do cross-project PM in OpenStack" > > then we artificially limit the number of people who would sign up to do > > that kind of work. You mention Ildiko and Lance: they did that line of > > work without being elected. > > Why would saying that we _expect_ the TC members to do that work limit > such activities only to those that are on the TC? I would expect the TC > to take on the less-fun or often-neglected efforts that we all know are > needed but don't have an obvious champion or sponsor. > > I think we expect some amount of widely-focused technical or project > leadership from TC members, and certainly that expectation doesn't > prevent others from leading efforts (even in the areas of proposing TC > resolutions, etc) right? > +1 Dan! > --Dan > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [api] Open API 3.0 for OpenStack API
Edison, This is definitely a step in the right direction if we can pull it off. Given the previous experiences and the current situation of how and where we store the information currently and how we generate the website for the API(s), can you please outline - what would be the impact to projects? - what steps they would have to take? Also, the whole point of having these definitions is that the generated code works. Do we have a sample/mock API where we can show that the Action and Microversions can be declared to reflect reality and it can actually work with the generated code? Thanks, Dims On Wed, Aug 29, 2018 at 2:37 AM Edison Xiang wrote: > Hi team, > > As we know, Open API 3.0 was released on July, 2017, it is about one year > ago. > Open API 3.0 support some new features like anyof, oneof and allof than > Open API 2.0(Swagger 2.0). > Now OpenStack projects do not support Open API. > Also I found some old emails in the Mail List about supporting Open API > 2.0 in OpenStack. > > Some limitations are mentioned in the Mail List for OpenStack API: > 1. The POST */action APIs. > These APIs are exist in lots of projects like nova, cinder. > These APIs have the same URI but the responses will be different when > the request is different. > 2. Micro versions. > These are controller via headers, which are sometimes used to describe > behavioral changes in an API, not just request/response schema changes. > > About the first limitation, we can find the solution in the Open API 3.0. > The example [2] shows that we can define different request/response in the > same URI by anyof feature in Open API 3.0. > > About the micro versions problem, I think it is not a limitation related a > special API Standard. > We can list all micro versions API schema files in one directory like > nova/V2, > or we can list the schema changes between micro versions as tempest > project did [3]. > > Based on Open API 3.0, it can bring lots of benefits for OpenStack > Community and does not impact the current features the Community has. > For example, we can automatically generate API documents, different > language Clients(SDK) maybe for different micro versions, > and generate cloud tool adapters for OpenStack, like ansible module, > terraform providers and so on. > Also we can make an API UI to provide an online and visible API search, > API Calling for every OpenStack API. > 3rd party developers can also do some self-defined development. > > [1] https://github.com/OAI/OpenAPI-Specification > [2] > https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109 > [3] > https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute > > Best Regards, > Edison Xiang > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [stable][nova] Nominating melwitt for nova stable core
+1 from me On Tue, Aug 28, 2018 at 5:27 PM Sean McGinnis wrote: > On Tue, Aug 28, 2018 at 03:26:02PM -0500, Matt Riedemann wrote: > > I hereby nominate Melanie Witt for nova stable core. Mel has shown that > she > > knows the stable branch policy and is also an active reviewer of nova > stable > > changes. > > > > +1/-1 comes from the stable-maint-core team [1] and then after a week > with > > no negative votes I think it's a done deal. Of course +1/-1 from existing > > nova-stable-maint [2] is also good feedback. > > > > [1] https://review.openstack.org/#/admin/groups/530,members > > [2] https://review.openstack.org/#/admin/groups/540,members > > > > +1 from me. > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] UUID sentinel needs a home
On Fri, Aug 24, 2018 at 8:01 PM Jeremy Stanley wrote: > On 2018-08-24 18:51:08 -0500 (-0500), Matt Riedemann wrote: > [...] > > So just follow me here people, what if we had this common shared > > library where code could incubate and then we could write some > > tools to easily copy that common code into other projects... > > If we do this, can we at least put it in a consistent place in all > projects? Maybe name the directory something like "openstack/common" > just to make it obvious. > > > I'm pretty sure I could get said project approved as a top-level > > program under The Foundation and might even get a talk or two out > > of this idea. I can see the Intel money rolling in now... > > Seems like a sound idea. Can we call it "Nostalgia" for no > particular reason? Though maybe "Recurring Nightmare" would be a > more accurate choice. > /me wakes up screaming!! > -- > Jeremy Stanley > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] UUID sentinel needs a home
Where exactly Eric? I can't seem to find the import: http://codesearch.openstack.org/?q=(from%7Cimport).*oslotest=nope==oslo.utils -- dims On Wed, Aug 22, 2018 at 11:24 PM Jay Pipes wrote: > > On Wed, Aug 22, 2018, 10:13 AM Eric Fried wrote: > >> For some time, nova has been using uuidsentinel [1] which conveniently >> allows you to get a random UUID in a single LOC with a readable name >> that's the same every time you reference it within that process (but not >> across processes). Example usage: [2]. >> >> We would like other projects (notably the soon-to-be-split-out placement >> project) to be able to use uuidsentinel without duplicating the code. So >> we would like to stuff it in an oslo lib. >> >> The question is whether it should live in oslotest [3] or in >> oslo_utils.uuidutils [4]. The proposed patches are (almost) the same. >> The issues we've thought of so far: >> >> - If this thing is used only for test, oslotest makes sense. We haven't >> thought of a non-test use, but somebody surely will. >> - Conversely, if we put it in oslo_utils, we're kinda saying we support >> it for non-test too. (This is why the oslo_utils version does some extra >> work for thread safety and collision avoidance.) >> - In oslotest, awkwardness is necessary to avoid circular importing: >> uuidsentinel uses oslo_utils.uuidutils, which requires oslotest. In >> oslo_utils.uuidutils, everything is right there. >> > > My preference is to put it in oslotest. Why does oslo_utils.uuidutils > import oslotest? That makes zero sense to me... > > -jay > > - It's a... UUID util. If I didn't know anything and I was looking for a >> UUID util like uuidsentinel, I would look in a module called uuidutils >> first. >> >> We hereby solicit your opinions, either by further discussion here or as >> votes on the respective patches. >> >> Thanks, >> efried >> >> [1] >> >> https://github.com/openstack/nova/blob/17b69575bc240ca1dd8b7a681de846d90f3b642c/nova/tests/uuidsentinel.py >> [2] >> >> https://github.com/openstack/nova/blob/17b69575bc240ca1dd8b7a681de846d90f3b642c/nova/tests/functional/api/openstack/placement/db/test_resource_provider.py#L109-L115 >> [3] https://review.openstack.org/594068 >> [4] https://review.openstack.org/594179 >> >> __ >> 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] Proposing Zane Bitter as oslo.service core
Belated +1. Welcome Zane! On Thu, Aug 16, 2018 at 5:35 AM Ben Nemec wrote: > Since there were no objections, I've added Zane to the oslo.service core > team. Thanks and welcome, Zane! > > On 08/03/2018 11:58 AM, Ben Nemec wrote: > > Hi, > > > > Zane has been doing some good work in oslo.service recently and I would > > like to add him to the core team. I know he's got a lot on his plate > > already, but he has taken the time to propose and review patches in > > oslo.service and has demonstrated an understanding of the code. > > > > Please respond with +1 or any concerns you may have. Thanks. > > > > -Ben > > > > > __ > > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo][tooz][etcd] need help debugging tooz test failure
Jay, Doug, We need to blacklist 0.2.2 and 0.2.3 (looking at changelog in) https://github.com/dims/etcd3-gateway/releases Thanks! -- Dims On Tue, Aug 14, 2018 at 4:03 AM Jay Pipes wrote: > On 08/13/2018 03:52 PM, Doug Hellmann wrote: > > Excerpts from Jay Pipes's message of 2018-08-13 13:21:56 -0400: > >> On 08/12/2018 04:11 PM, Doug Hellmann wrote: > >>> The tooz tests on master and stable/rocky are failing with an error: > >>> > >>> UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in > position 0: > >>> invalid continuation byte > >>> > >>> This is unrelated to the change, which is simply importing test job > >>> settings or updating the .gitreview file. I need someone familiar with > >>> the library to help debug the issue. > >>> > >>> Can we get a volunteer? > >> > >> Looking into it. Seems to be related to this upstream patch to > >> python-etcd3gw: > >> > >> > https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95 > >> > >> Best, > >> -jay > >> > > > > Thanks, Jay! > > > > I see that Dims says he pushed a release. Is that something we need to > > update in the constraints list, then? > > Yeah, likely. We'll need to blacklist the 0.2.3 release of etcd3-gateway > library in the openstack/tooz requirements file. > > I think? :) > > -jay > > ______ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo][tooz][etcd] need help debugging tooz test failure
Thanks Jay. Pushed out a 0.2.4 with a revert to the offending PR On Tue, Aug 14, 2018 at 1:22 AM Jay Pipes wrote: > On 08/12/2018 04:11 PM, Doug Hellmann wrote: > > The tooz tests on master and stable/rocky are failing with an error: > > > > UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position > 0: > > invalid continuation byte > > > > This is unrelated to the change, which is simply importing test job > > settings or updating the .gitreview file. I need someone familiar with > > the library to help debug the issue. > > > > Can we get a volunteer? > > Looking into it. Seems to be related to this upstream patch to > python-etcd3gw: > > > https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95 > > Best, > -jay > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] Proposing Zane Bitter as oslo.service core
+1 from me! On Fri, Aug 3, 2018 at 12:58 PM Ben Nemec wrote: > > Hi, > > Zane has been doing some good work in oslo.service recently and I would > like to add him to the core team. I know he's got a lot on his plate > already, but he has taken the time to propose and review patches in > oslo.service and has demonstrated an understanding of the code. > > Please respond with +1 or any concerns you may have. Thanks. > > -Ben > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] proposing Moisés Guimarães for oslo.config core
+1 from me! On Wed, Aug 1, 2018 at 6:27 AM Doug Hellmann wrote: > > Moisés Guimarães (moguimar) did quite a bit of work on oslo.config > during the Rocky cycle to add driver support. Based on that work, > and a discussion we have had since then about general cleanup needed > in oslo.config, I think he would make a good addition to the > oslo.config review team. > > Please indicate your approval or concerns with +1/-1. > > Doug > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [all] TC Report 18-26
On Tue, Jul 3, 2018 at 1:06 PM Jay Pipes wrote: > > On 07/02/2018 03:31 PM, Zane Bitter wrote: > > On 28/06/18 15:09, Fox, Kevin M wrote: > >> * made the barrier to testing/development as low as 'curl > >> http://..minikube; minikube start' (this spurs adoption and > >> contribution) > > > > That's not so different from devstack though. > > > >> * not having large silo's in deployment projects allowed better > >> communication on common tooling. > >> * Operator focused architecture, not project based architecture. > >> This simplifies the deployment situation greatly. > >> * try whenever possible to focus on just the commons and push vendor > >> specific needs to plugins so vendors can deal with vendor issues > >> directly and not corrupt the core. > > > > I agree with all of those, but to be fair to OpenStack, you're leaving > > out arguably the most important one: > > > > * Installation instructions start with "assume a working datacenter" > > > > They have that luxury; we do not. (To be clear, they are 100% right to > > take full advantage of that luxury. Although if there are still folks > > who go around saying that it's a trivial problem and OpenStackers must > > all be idiots for making it look so difficult, they should really stop > > embarrassing themselves.) > > This. > > There is nothing trivial about the creation of a working datacenter -- > never mind a *well-running* datacenter. Comparing Kubernetes to > OpenStack -- particular OpenStack's lower levels -- is missing this > fundamental point and ends up comparing apples to oranges. 100% > Best, > -jay > > ______ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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][sdk] Integrating OpenStack and k8s with a service broker
"do you think this is an area that OpenLab could help out with?" << YES!! please ping mrhillsman and RuiChen over on #askopenlab -- Dims On Wed, Jun 6, 2018 at 11:44 AM, Zane Bitter wrote: > On 06/06/18 11:18, Chris Hoge wrote: >> >> Hi Zane, >> >> Do you think this effort would make sense as a subproject within the Cloud >> Provider OpenStack repository hosted within the Kubernetes org? We have >> a solid group of people working on the cloud provider, and while it’s not >> the same code, it’s a collection of the same expertise and test resources. > > > TBH, I think it makes more sense as part of the OpenStack community. If you > look at how the components interact, it goes: > > Kubernetes Service Catalog -> Automation Broker -> [this] -> OpenStack > > So the interfaces with k8s are already well-defined and owned by other > teams. It's the interface with OpenStack that requires the closest > co-ordination. (Particularly if we end up autogenerating the playbooks from > introspection on shade.) If you look at where the other clouds host their > service brokers or Ansible Playbook Bundles, they're not part of the > equivalent Kubernetes Cloud Providers either. > > We'll definitely want testing though. Given that this is effectively another > user interface to OpenStack, do you think this is an area that OpenLab could > help out with? > >> Even if it's hosted as an OpenStack project, we should still make sure >> we have documentation and pointers from the >> kubernetes/cloud-provider-openstack >> to guide users in the right direction. > > > Sure, that makes sense to cross-advertise it to people we know are using k8s > on top of OpenStack already. (Although note that k8s does not have to be > running on top of OpenStack for the service broker to be useful, unlike the > cloud provider.) > >> While I'm not in a position to directly contribute, I'm happy to offer >> any support I can through the SIG-OpenStack and SIG-Cloud-Provider >> roles I have in the K8s community. > > > Thanks! > > cheers, > Zane. > > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] Technical Committee Update, 4 June
On Mon, Jun 4, 2018 at 1:16 PM, Jeremy Stanley wrote: > On 2018-06-04 11:30:17 -0400 (-0400), Doug Hellmann wrote: > [...] >> Jeremy has revived the thread about adding a secret/key store to >> our base services via the mailing list. We discussed the topic >> extensively in the most recent TC office hour, as well. I think we >> are close to agreeing that although saying a "castellan supported" >> database is insufficient for all desirable use cases, it is sufficient >> for a useful number of use cases and would be a reasonable first >> step. Jeremy, please correct me if I have misremembered that outcome. >> >> * http://lists.openstack.org/pipermail/openstack-dev/2018-May/130567.html >> * http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-05-31-15.00.html > [...] > > Basically correct (I think we said "a Castellan-compatible key > store"). I intend to have a change up for review to append this to > the base services list in the next day or so as the mailing list > discussion didn't highlight any new concerns and indicated that the > previous blockers we identified have been resolved in the > intervening year. +100 Jeremy! > Jeremy Stanley > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [StarlingX] StarlingX code followup discussions
Josh,
The Kata team is talking to QEMU maintainers about how best to move
forward. Specially around stripping down things that's not needed for
their use case. They are not adding code from what i got to know (just
removing stuff).
-- Dims
On Fri, Jun 1, 2018 at 12:12 PM, Joshua Harlow wrote:
> Slightly off topic but,
>
> Have you by any chance looked at what kata has forked for qemu:
>
> https://github.com/kata-containers/qemu/tree/qemu-lite-2.11.0
>
> I'd be interested in an audit of that code for similar reasons to this
> libvirt fork (hard to know from my view point if there are new issues in
> that code like the ones you are finding in libvirt).
>
> Kashyap Chamarthy wrote:
>>
>> On Tue, May 22, 2018 at 01:54:59PM -0500, Dean Troyer wrote:
>>>
>>> StarlingX (aka STX) was announced this week at the summit, there is a
>>> PR to create project repos in Gerrit at [0]. STX is basically Wind
>>
>>
>> From a cursory look at the libvirt fork, there are some questionable
>> choices. E.g. the config code (libvirt/src/qemu/qemu.conf) is modified
>> such that QEMU is launched as 'root'. That means a bug in QEMU ==
>> instant host compromise.
>>
>> All Linux distributions (that matter) configure libvirt to launch QEMU
>> as a regular user ('qemu'). E.g. from Fedora's libvirt RPM spec file:
>>
>> libvirt.spec:%define qemu_user qemu
>> libvirt.spec: --with-qemu-user=%{qemu_user} \
>>
>> * * *
>>
>> There are multiple other such issues in the forked libvirt code.
>>
>> [...]
>>
>
> __
> 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
--
Davanum Srinivas :: https://twitter.com/dims
__
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][all] A culture change (nitpicking)
On Wed, May 30, 2018 at 6:09 PM, Matthew Treinish wrote: > On Thu, May 31, 2018 at 12:21:35AM +, Fox, Kevin M wrote: >> To play devils advocate and as someone that has had to git bisect an ugly >> regression once I still think its important not to break trunk. It can be >> much harder to deal with difficult issues like that if trunk frequently >> breaks. >> >> Thanks, >> Kevin >> >> From: Sean McGinnis [sean.mcgin...@gmx.com] >> Sent: Wednesday, May 30, 2018 5:01 PM >> To: openstack-dev@lists.openstack.org >> Subject: Re: [openstack-dev] [tc][all] A culture change (nitpicking) >> >> > "master should be always deployable and fully backward compatible and >> > so we cant let anything in anytime that could possibly regress anyone" >> > >> > Should we change that attitude too? Anyone agree? disagree? >> > >> > Thanks, >> > Dims >> > >> I'll definitely jump at this one. >> >> I've always thought (and shared on the ML several times now) that our >> implied >> but not explicit support for CD from any random commit was a bad thing. >> >> While I think it's good to support the idea that master is always >> deployable, I >> do not think it is a good mindset to think that every commit is a >> "release" and >> therefore should be supported until the end of time. We have a coordinated >> release for a reason, and I think design decisions and fixes should be >> based on >> the assumption that a release is a release and the point at which we >> need to be >> cognizant and caring about keeping backward compatibility. Doing that for >> every single commit is not ideal for the overall health of the product, IMO. >> > > It's more than just a CD guarantee, while from a quick glance it would seem > like > that's the only value it goes much deeper than that. Ensuring that every > commit > works, is deployable, and maintains backwards compatibility is what enables us > to have such a high quality end result at release time. Quite frankly it's > looking at every commit as always being a working unit that enables us to > manage > a project this size at this velocity. Even if people assume no one is actually > CDing the projects(which we shouldn't), it's a flawed assumption to think that > everyone is running strictly the same code as what's in the release tarballs. > I > can't think of any production cloud out there that doesn't carry patches to > fix > things encountered in the real world. Or look at stable maint we regularly > need > to backport fixes to fix bugs found after release. If we can't rely on these > to > always work this makes our life much more difficult, both as upstream > maintainers but also as downstream consumers of OpenStack. > > The other aspect to look at here is just the review mindset, supporting every > every commit is useable puts reviewers in the mindset to consider things like > backwards compatibility and deployability when looking at proposed changes. If > we stop looking for these potential issues, we t will also cause many more > bugs > to be in our released code. To simply discount this as only a release concern > and punt this kind of scrutiny until it's time to release is not only going to > make release time much more stressful. Also, our testing is built to try and > ensure every commit works **before** we merge it. If we decided to take this > stance as a community then we should really just rip out all the testing, > because that's what it's there to verify and help us make sure we don't land a > change that doesn't work. If we don't actually care about that making sure > every > commit is deployable we are wasting quite a lot of resources on it. "rip out all testing" is probably taking it too far Matt. Instead of perfection when merging, we should look for iteration and reverts. That's what i would like to see. I am not asking for a "Commit-Then-Review" like the ASF. I want us to be just be practical and have some leeway to iterate / update / experiment instead of absolute perfection from all angles. We should move the needle at least a bit away from it. > > -Matt Treinish > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][all] A culture change (nitpicking)
On Wed, May 30, 2018 at 5:23 PM, Jeremy Stanley wrote: > On 2018-05-30 14:50:11 -0700 (-0700), Davanum Srinivas wrote: > [...] >> Let me poke at this a bit. Some of the projects do say (not in so >> many words): >> >> "master should be always deployable and fully backward compatible and >> so we cant let anything in anytime that could possibly regress anyone" >> >> Should we change that attitude too? Anyone agree? disagree? > > I think this is orthogonal to the thread. The idea is that we should > avoid nettling contributors over minor imperfections in their > submissions (grammatical, spelling or typographical errors in code > comments and documentation, mild inefficiencies in implementations, > et cetera). Clearly we shouldn't merge broken features, changes > which fail tests/linters, and so on. For me the rule of thumb is, > "will the software be better or worse if this is merged?" It's not > about perfection or imperfection, it's about incremental > improvement. If a proposed change is an improvement, that's enough. > If it's not perfect... well, that's just opportunity for more > improvement later. Well said Jeremy! > -- > Jeremy Stanley > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][all] A culture change (nitpicking)
Please see below: On Wed, May 30, 2018 at 2:37 PM, Chris Dent wrote: > On Wed, 30 May 2018, Julia Kreger wrote: > >> I don't feel like anyone is proposing to end the use of -1's, but that >> we should generally be encouraging, accepting, and trusting. > > > Being encouraging, accepting, and trusting is the outcome I'd like > to see from this process. Being less nitpicking is a behavior or > process change. Adjusting attitudes (in some environments lightly, > in others more) so that we (where "we" is regulars in the projects, > experienced reviewers, and cores) perceive patches as something to > be grateful for and shepherded instead of an intrusion or obligation > would be a significant and beneficial culture change. > > A perhaps more straightforward way to put it is: When someone (even > one of "us") submits a patch they are doing us (the same "we" as > above) a favor and we owe them not just a cordial and supportive > response, but one with some continuity. > > Like many, I'm guilty of letting a false or inflated sense of urgency > get the better of me and being an ass in some reviews. Sorry about > that. > > A cultural shift in this area will improve things for all of us. > Nitpicking is symptomatic of an attitude, one we can change, not the > disease itself. > >> We also need to be mindful >> of context as well, and in the grand scheme not try for something >> perfect as many often do. This *does* mean we land something that >> needs to be fixed later or reverted later, but neither are things we >> should fear. We can't let that fear control us. Let me poke at this a bit. Some of the projects do say (not in so many words): "master should be always deployable and fully backward compatible and so we cant let anything in anytime that could possibly regress anyone" Should we change that attitude too? Anyone agree? disagree? Thanks, Dims > > Yes, very much yes. > > -- > Chris Dent ٩◔̯◔۶ https://anticdent.org/ > freenode: cdent tw: @anticdent > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][all] A culture change (nitpicking)
emely precise English, or >>>> compliance to a particular core reviewer's style preferences, which >>>> may not be the same as another core reviewer. >>>> >>>> These things are not just frustrating, but also very inhibiting for >>>> part time contributors such as students who may also be time limited. >>>> Or an operator who noticed something that was clearly a bug and that >>>> put forth a very minor fix and doesn't have the time to revise it over >>>> and over. >>>> >>>> While nitpicks do help guide and teach, the consensus seemed to be >>>> that we do need to shift the culture a little bit. As such, I've >>>> proposed a change to our principles[1] in governance that attempts to >>>> capture the essence and spirit of the nitpicking topic as a first >>>> step. >>>> >>>> -Julia >>>> - >>>> [1]: https://review.openstack.org/570940 >>>> >>>> >>>> __ >>>> 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 >> >> >> __ >> 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][all] A culture change (nitpicking)
Thanks for driving this Julia. +1. It's time to do this. -- Dims On Tue, May 29, 2018 at 6:55 AM, Julia Kreger wrote: > During the Forum, the topic of review culture came up in session after > session. During these discussions, the subject of our use of nitpicks > were often raised as a point of contention and frustration, especially > by community members that have left the community and that were > attempting to re-engage the community. Contributors raised the point > of review feedback requiring for extremely precise English, or > compliance to a particular core reviewer's style preferences, which > may not be the same as another core reviewer. > > These things are not just frustrating, but also very inhibiting for > part time contributors such as students who may also be time limited. > Or an operator who noticed something that was clearly a bug and that > put forth a very minor fix and doesn't have the time to revise it over > and over. > > While nitpicks do help guide and teach, the consensus seemed to be > that we do need to shift the culture a little bit. As such, I've > proposed a change to our principles[1] in governance that attempts to > capture the essence and spirit of the nitpicking topic as a first > step. > > -Julia > - > [1]: https://review.openstack.org/570940 > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [all] TC Report 18-20
fyi Jay tried to once - http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#111511 On Tue, May 15, 2018 at 12:40 PM, Graham Hayes <g...@ham.ie> wrote: > On 15/05/18 17:33, Tim Bell wrote: >> From my memory, the LCOO was started in 2015 or 2016. The UC was started at >> the end of 2012, start of 2013 (https://www.openstack.org/blog/?p=3777) with >> Ryan, JC and I. >> >> Tim > > Yeap - I miss read what mrhillsman said [0]. > > The point still stands - I think this does need to be discussed, and the > outcome published to the list. > > Any additional background on why we allowed LCOO to operate like this > would help a lot. > > - Graham > > 0 - > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T15:03:54 > >> -Original Message- >> From: Graham Hayes <g...@ham.ie> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: Tuesday, 15 May 2018 at 18:22 >> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> >> Subject: Re: [openstack-dev] [tc] [all] TC Report 18-20 >> >> .. >> >> > # LCOO >> > >> > There's been some concern expressed about the The Large Contributing >> > OpenStack Operators (LCOO) group and the way they operate. They use >> > an [Atlassian Wiki](https://openstack-lcoo.atlassian.net/) and >> > Slack, and have restricted membership. These things tend to not >> > align with the norms for tool usage and collaboration in OpenStack. >> > This topic came up in [late >> > >> April](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T14:39:36) >> > >> > but is worth revisiting in Vancouver. >> >> From what I understand, this group came into being before the UC was >> created - a joint UC/TC/LCOO sync up in Vancouver is probably a good >> idea. >> >> >> >> >> __ >> 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [all] TC Report 18-20
fyi Jay tried to once - http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#111511 On Tue, May 15, 2018 at 12:40 PM, Graham Hayes <g...@ham.ie> wrote: > On 15/05/18 17:33, Tim Bell wrote: >> From my memory, the LCOO was started in 2015 or 2016. The UC was started at >> the end of 2012, start of 2013 (https://www.openstack.org/blog/?p=3777) with >> Ryan, JC and I. >> >> Tim > > Yeap - I miss read what mrhillsman said [0]. > > The point still stands - I think this does need to be discussed, and the > outcome published to the list. > > Any additional background on why we allowed LCOO to operate like this > would help a lot. > > - Graham > > 0 - > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T15:03:54 > >> -Original Message- >> From: Graham Hayes <g...@ham.ie> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: Tuesday, 15 May 2018 at 18:22 >> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> >> Subject: Re: [openstack-dev] [tc] [all] TC Report 18-20 >> >> .. >> >> > # LCOO >> > >> > There's been some concern expressed about the The Large Contributing >> > OpenStack Operators (LCOO) group and the way they operate. They use >> > an [Atlassian Wiki](https://openstack-lcoo.atlassian.net/) and >> > Slack, and have restricted membership. These things tend to not >> > align with the norms for tool usage and collaboration in OpenStack. >> > This topic came up in [late >> > >> April](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T14:39:36) >> > >> > but is worth revisiting in Vancouver. >> >> From what I understand, this group came into being before the UC was >> created - a joint UC/TC/LCOO sync up in Vancouver is probably a good >> idea. >> >> >> >> >> __ >> 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][docs] documenting openstack "constellations"
On Tue, May 1, 2018 at 4:21 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200: >> On 05/01/2018 04:08 PM, Doug Hellmann wrote: >> > The TC has had an item on our backlog for a while (a year?) to >> > document "constellations" of OpenStack components to make it easier >> > for deployers and users to understand which parts they need to have >> > the features they want [1]. >> > >> > John Garbutt has started writing the first such document [2], but >> > as we talked about the content we agreed the TC governance repository >> > is not the best home for it, so I have proposed creating a new >> > repository [3]. >> > >> > In order to set up the publishing jobs for that repo so the content >> > goes to docs.openstack.org, we need to settle the ownership of the >> > repository. >> > >> > I think it makes sense for the documentation team to "own" it, but >> > I also think it makes sense for it to have its own review team >> > because it's a bit different from the rest of the docs and we may >> > be able to recruit folks to help who might not want to commit to >> > being core reviewers for all of the documentation repositories. The >> > TC members would also like to be reviewers, to get things going. >> > >> > So, is the documentation team willing to add the new "constellations" >> > repository under their umbrella? Or should we keep it as a TC-owned >> > repository for now? >> >> I'm fine having it as parts of the docs team. The docs PTL should be >> part of the review team for sure, >> >> Andreas > > Yeah, I wasn't really clear there: I intend to set up the documentation > and TC teams as members of the new team, so that all members of both > groups can be reviewers of the new repository. +1 Doug > Doug > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] campaign question: How can we make contributing to OpenStack easier?
Thierry, please see below: On Tue, Apr 24, 2018 at 6:24 AM, Thierry Carrez <thie...@openstack.org> wrote: > Fox, Kevin M wrote: >> OpenStack has created artificial walls between the various Projects. It >> shows up, for example, as holes in usability at a user level or extra >> difficulty for operators juggling around so many projects. Users and for the >> most part, Operators don't really care about project organization, or ptls, >> or cores or such. OpenStack has made some progress this direction with >> stuff like the unified cli. But OpenStack is not very unified. > > I've been giving this some thought (in the context of a presentation I > was giving on hard lessons learned from 8 years of OpenStack). I think > that organizing development around project teams and components was the > best way to cope with the growth of OpenStack in 2011-1015 and get to a > working set of components. However it's not the best organization to > improve on the overall "product experience", or for a maintenance phase. > > While it can be confusing, I like the two-dimensional approach that > Kubernetes followed (code ownership in one dimension, SIGs in the > other). The introduction of SIGs in OpenStack, beyond providing a way to > build closer feedback loops around specific topics, can help us tackle > this "unified experience" problem you raised. The formation of the > upgrades SIG, or the self-healing SIG is a sign that times change. Maybe > we need to push in that direction even more aggressively and start > thinking about de-emphasizing project teams themselves. Big +1. Another thing to check into is how can we split some of the work the PTL does into multiple roles ... that are short term and is rotated around. Hoping that will help with the problem where we need folks to be totally available full time to do meaningful work in a project. > -- > Thierry Carrez (ttx) > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [kolla][vote]Retire kolla-kubernetes project
+1 On Sat, Apr 21, 2018 at 5:56 PM, Pete Birley <pete@port.direct> wrote: > +1 > > On Thu, Apr 19, 2018, 1:24 AM Eduardo Gonzalez <dabar...@gmail.com> wrote: >> >> +1 >> >> 2018-04-19 8:21 GMT+02:00 Christian Berendt >> <bere...@betacloud-solutions.de>: >>> >>> +1 >>> >>> > On 18. Apr 2018, at 03:51, Jeffrey Zhang <zhang.lei@gmail.com> >>> > wrote: >>> > >>> > Since many of the contributors in the kolla-kubernetes project are >>> > moved to other things. And there is no active contributor for months. On >>> > the other hand, there is another comparable project, openstack-helm, in >>> > the >>> > community. For less confusion and disruptive community resource, I >>> > propose >>> > to retire the kolla-kubernetes project. >>> > >>> > More discussion about this you can check the mail[0] and patch[1] >>> > >>> > please vote +1 to retire the repo, or -1 not to retire the repo. The >>> > vote will be open until everyone has voted, or for 1 week until April >>> > 25th, >>> > 2018. >>> > >>> > [0] >>> > http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html >>> > [1] https://review.openstack.org/552531 >>> > >>> > -- >>> > Regards, >>> > Jeffrey Zhang >>> > Blog: http://xcodest.me >>> > >>> > __ >>> > 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 >>> >>> -- >>> Christian Berendt >>> Chief Executive Officer (CEO) >>> >>> Mail: bere...@betacloud-solutions.de >>> Web: https://www.betacloud-solutions.de >>> >>> Betacloud Solutions GmbH >>> Teckstrasse 62 / 70190 Stuttgart / Deutschland >>> >>> Geschäftsführer: Christian Berendt >>> Unternehmenssitz: Stuttgart >>> Amtsgericht: Stuttgart, HRB 756139 >>> >>> >>> >>> __ >>> 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 > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [Elections][TC] Announcing Davanum Srinivas (dims) candidacy for TC
Team, Please consider my candidacy for Rocky. Please see my previous two candidacy statements [1][2], participation in TC deliberations [3] and recent bootstrap of SIG-OpenStack/SIG-Kubernetes cross community collaboration [4] with the Kubernetes/CNCF communities. With the OpenLab initiative, we have been able to get our sister projects like GopherCloud, Terraform etc some solid testing and we are well on our way to co-test master of Kubernetes and OpenStack as well. While i have been long enough to be considering turning over leadership role to other folks, i do feel like i have some unfinished business that i would like to concentrate on for the next year. I spent quite a bit of time with things that use OpenStack and have a new appreciation for the challenges in the field and in practice. Just for example the need for a "validator" by our partners in CF [5] illustrates the kind of challenges our users face. I would like to spend some time working / tackling these kinds of issues. Other things that i have promised but not yet acted on to my satisfaction are drafting some initial constellation(s), making it easier on part time contributors, easing the pain of working in the community for folks in other geographies etc. I hope you consider my candidacy. I will be working on these things irrespective of whether i am elected or not :) Thanks, Dims [1] https://git.openstack.org/cgit/openstack/election/plain/candidates/newton/TC/Davanum_Srinivas.txt [2] https://git.openstack.org/cgit/openstack/election/plain/candidates/pike/TC/dims.txt [3] https://review.openstack.org/#/q/project:openstack/governance+reviewedby:%22Davanum+Srinivas+(dims)+%253Cdavanum%2540gmail.com%253E%22 [4] https://github.com/kubernetes/cloud-provider-openstack [5] https://github.com/cloudfoundry-incubator/cf-openstack-validator -- Davanum Srinivas :: https://twitter.com/dims __ 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] [Heat][Trove][Vitrage] (Re: [oslo][requirements][vitrage] oslo.service 1.28.1 breaks Vitrage gate)
Dear Trove, Vitrage, Heat teams, Can you please see if this review will affect your CI jobs? https://review.openstack.org/#/c/558206/ I've tested at least the Heat unit tests. But need you to test as well as a previous version of this change broke stuff Thanks, Dims On Fri, Dec 15, 2017 at 5:51 AM, ChangBo Guo <glongw...@gmail.com> wrote: > Thanks for raising this, Oslo team will revert the change in > https://review.openstack.org/#/c/528202/ > > 2017-12-14 23:58 GMT+08:00 Afek, Ifat (Nokia - IL/Kfar Sava) > <ifat.a...@nokia.com>: >> >> Hi, >> >> >> >> The latest release of oslo.service 1.28.1 breaks the Vitrage gate. We are >> creating several threads and timers [1], but only the first thread is >> executed. We noticed that Trove project already reported this problem [2]. >> >> >> >> Please help us fix it. >> >> >> >> Thanks, >> >> Ifat. >> >> >> >> [1] >> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/services.py >> >> [2] https://review.openstack.org/#/c/527755/ >> >> >> >> >> >> >> __ >> 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 >> > > > > -- > ChangBo Guo(gcb) > Community Director @EasyStack > > ______ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project
+1 to consolidate. Thanks, Dims On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang <zhang.lei@gmail.com> wrote: > There are two projects to solve the issue that run OpenStack on > Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both > leverage helm tool for orchestration. There is some different perspective > at the beginning, which results in the two teams could not work together. > > But recently, the difference becomes too small. and there is also no active > contributor in the kolla-kubernetes project. > > So I propose to retire kolla-kubernetes project. If you are still > interested in running OpenStack on kubernetes, please refer to > openstack-helm project. > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] proposing Ken Giusti for oslo-core
w00t! yes please +1 On Mon, Mar 26, 2018 at 11:53 AM, Jay Pipes <jaypi...@gmail.com> wrote: > Big +1. > > > On 03/26/2018 11:52 AM, Doug Hellmann wrote: >> >> Ken has been managing oslo.messaging for ages now but his participation >> in the team has gone far beyond that single library. He regularly >> attends meetings, including the PTG, and has provided input into several >> of our team decisions recently. >> >> I think it's time we make him a full member of the oslo-core group. >> >> Please respond here with a +1 or -1 to indicate your opinion. >> >> Thanks, >> Doug >> >> __ >> 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [k8s] Hosting location for OpenStack Kubernetes Provider
FYI, New repo is ready! https://github.com/kubernetes/cloud-provider-openstack We could use a lot of help. So please join us. -- Dims On Tue, Mar 13, 2018 at 1:54 PM, Chris Hoge <ch...@openstack.org> wrote: > At the PTG in Dublin, SIG-K8s started working towards migrating the > external Kubernetes OpenStack cloud provider[1] work to be an OpenStack > project. Coincident with that, an upstream patch[2] was proposed by > WG-Cloud-Provider to create upstream Kubernetes repositories for the > various cloud providers. > > I want to begin a conversation about where we want this provider code to > live and how we want to manage it. Three main options are to: > > 1) Host the provider code within the OpenStack ecosystem. The advantages > are that we can follow OpenStack community development practices, and > we have a good list of people signed up to help maintain it. We would > also have easier access to infra test resources. The downside is we pull > the code further away from the Kubernetes community, possibly making it > more difficult for end users to find and use in a way that is consistent > with other external providers. > > 2) Host the provider code within the Kubernetes ecosystem. The advantage > is that the code will be in a well-defined and well-known place, and > members of the Kubernetes community who want to participate will be able > to continue to use the community practices. We would still be able to > take advantage of infra resources, but it would require more setup to > trigger and report on jobs. > > 3) Host in OpenStack, and mirror in a Kubernetes repository. We would > need to work with the K8s team to make sure this is an acceptable option, > but would allow for a hybrid development model that could satisty the > needs of members of both communities. This would require a committment > from the K8s-SIG-OpenStack/OpenStack-SIG-K8s team to handling tickets > and pull requests that come in to the Kubernetes hosted repository. > > My personal opinion is that we should take advantage of the Kubernetes > hosting, and migrate the project to one of the repositories listed in > the WG-Cloud-Provider patch. This wouldn't preclude moving it into > OpenStack infra hosting at some point in the future and possibly > adopting the hybrid approach down the line after more communication with > K8s infrastructure leaders. > > There is a sense of urgency, as Dims has asked that we relieve him of > the responsibility of hosing the external provider work in his personal > GitHub repository. > > Please chime in with your opinions on this here so that we can work out > an where the appropriate hosting for this project should be. > > Thanks, > Chris Hoge > K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead > > [1] https://github.com/dims/openstack-cloud-controller-manager > [2] https://github.com/kubernetes/community/pull/1862 > [3] https://etherpad.openstack.org/p/sig-k8s-2018-dublin-ptg > > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [keystone] Keystone Team Update - Weeks of 29 January and 5 February 2018
Very cool Suramya! On Sat, Feb 10, 2018 at 11:07 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > > > On Fri, Feb 9, 2018 at 4:51 PM, Colleen Murphy <coll...@gazlene.net> wrote: >> >> # Keystone Team Update - Weeks of 29 January and 5 February 2018 >> >> It's been a busy couple of weeks and I missed the last update, here's >> an update for the last two weeks. >> >> ## News >> >> ### RC1 >> >> RC1 was cut today[1]. We expect to release an RC2 after branching >> since we have a translations patch and a couple of bugfixes that we >> hope to get in. >> >> ### PTG Planning >> >> We're finalizing topics to cover during the cross-project days of the >> PTG[2]. >> >> [1] https://review.openstack.org/#/c/542385/ >> [2] https://etherpad.openstack.org/p/baremetal-vm-rocky-ptg >> >> ## Open Specs >> >> Search query: https://goo.gl/pc8cCf >> >> We don't have any new specs proposed currently but Adrian has hinted >> that an interesting one is on its way[3]. >> >> [3] >> http://lists.openstack.org/pipermail/openstack-operators/2018-February/014852.html >> >> ## Recently Merged Changes >> >> Search query: https://goo.gl/hdD9Kw >> >> We merged 33 changes this last week, 76 since the last update >> newsletter. These included the last of our api-ref reorganization >> changes, cleanup of v2 cruft and documentation, and some major >> bugfixes. >> >> ## Changes that need Attention >> >> Search query: https://goo.gl/tW5PiH >> >> There are 25 changes that are passing CI, not in merge conflict, have >> no negative reviews and aren't proposed by bots. Please focus reviews >> on release-critical bugs. >> >> ## Milestone Outlook >> >> https://releases.openstack.org/queens/schedule.html >> >> We've released our RC1 and we are in hard string freeze. We have two >> more weeks to make another RC release. >> >> ## Shout-outs >> >> Thanks to our Outreachy intern Suramya for completing our api-ref >> reorganization! This was a big step in making our API reference more >> useable. Of course we have many more things for you to help us with ;) > > > ++ > > This was a big undertaking and it's awesome to see it completed. Thanks, > Suramya! > >> >> >> ## Help with this newsletter >> >> Help contribute to this newsletter by editing the etherpad: >> https://etherpad.openstack.org/p/keystone-team-newsletter >> >> __ >> 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] not run for PTL
Thanks for all your help @gcb! On Tue, Jan 16, 2018 at 5:55 AM, ChangBo Guo <glongw...@gmail.com> wrote: > Hi Oslo folks, > > I taken the role of PTL in last 2 cycles, and would like to focus on coding > this cycle. > it's time to let new leader to make oslo better. So I won't be running > for PTL reelection for Rocky cycle. Thanks all of your support and trust > in last 2 cycles. > > > -- > ChangBo Guo(gcb) > Community Director @EasyStack > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] proposing Stephen Finucan for oslo-core
+1 from me. Thanks, Dims On Mon, Jan 8, 2018 at 9:58 AM, Jay Pipes <jaypi...@gmail.com> wrote: > big +1 from me. > > > On 01/08/2018 09:55 AM, Doug Hellmann wrote: >> >> Stephen (sfinucan) has been working on pbr, oslo.config, and >> oslo.policy and reviewing several of the other Oslo libraries for >> a while now. His reviews are always helpful and I think he would >> make a good addition to the oslo-core team. >> >> As per our usual practice, please reply here with a +1 or -1 and >> any reservations. >> >> Doug >> >> __ >> 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] Oslo team updates
+1 from me as well. Thanks everyone! On Tue, Jan 2, 2018 at 9:31 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from ChangBo Guo's message of 2018-01-02 11:53:02 +0800: >> In last two cycles some people's situation changed, can't focus on Oslo >> code review, so I propose some changes in Oslo team. Remove following >> people, thanks their past hard wok to make Oslo well, and welcome them back >> if they want to join the team again. please +1/-1 for the change >> >> Generalist Code Reviewers: >> Brant Knudson >> >> Specialist API Maintainers: >> oslo-cache-core: Brant Kundson David Stanek >> oslo-db-core: Viktor Serhieiev >> oslo-messaging-core:Dmitriy Ukhlov Oleksii Zamiatin Viktor Serhieiev >> oslo-policy-core: Brant Kundson David Stanek guang-yee >> oslo-service-core: Marian Horban >> >> We welcome anyone join the team or contribution in Oslo. The Oslo program >> brings together generalist code reviewers and specialist API maintainers >> They share a common interest in tackling copy-and-paste technical debt >> across the OpenStack project. For more information please refer to wiki >> [1]. >> >> [1] https://wiki.openstack.org/wiki/Oslo > > +1 -- it's sad to see the team shrink a bit, but it's good to keep the > list accurate based on when people can contribute. > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] Dublin PTG format
On Tue, Nov 28, 2017 at 4:46 AM, Chris Dent <cdent...@anticdent.org> wrote: > On Tue, 28 Nov 2017, Flavio Percoco wrote: > >> Others have raised concerns about being able to properly keep the momentum >> of >> the day going if we adopt the new format. I have to admit that I'm also >> concerned about this. Switching context every half day may not be ideal. > > > This is the real crux of the biscuit. For team oriented work being > able to get into the nova-zone (or whatever) for an extended period > is important. Having to switch in and out of that per day would not > be pleasant and would also make the time less effective. > > At base, I think part of the challenge with how we manage this stuff > is that because the available time is such a scarce resource (10 > days out of 365) we want to make sure we touch upon everything that > matters. But bouncing from topic to topic means that each topic and > the people involved do not get the depth of engagement for it to > really matter. In the end what matters is not so much that we talk > about any particular topic, but that we talk about any topic, so > that we develop the shared language that allows us to talk about it > more later. > > Which is just a long-winded way of saying: Let's not parcel time > into small chunks. +1 to " Let's not parcel time into small chunks." > -- > Chris Dent (⊙＿⊙') https://anticdent.org/ > freenode: cdent tw: @anticdent > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [security] [api] Script injection issue
Adding [api] to make sure the API (SIG?) sees this too On Fri, Nov 17, 2017 at 3:22 AM, TommyLike Hu <tommylik...@gmail.com> wrote: > Hey all, > Recently when we integrating and testing OpenStack services. We found > there is a potential script injection issue that some of our services accept > the input with special character [1] [2], for instance we can create an > instance or a volume with the name of 'script inside'. One > of the possible solutions is add HTML encode/decode support in Horizon, but > it's not guaranteed every OpenStack user is using Horizon. So should we > apply more strict restriction on user's input? > Also, I found Google Cloud have a strict and explicit restrction in > their instance insert API document [3]. > > [1]: Nova: > https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L148 > [2]: Cinder: > https://github.com/openstack/cinder/blob/master/cinder/api/openstack/wsgi.py#L1253 > [3]: Google Cloud: > https://cloud.google.com/compute/docs/reference/latest/instances/insert > > Thanks > TommyLike.Hu > > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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-operators] Upstream LTS Releases
On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson <m...@not.mn> wrote: > > > On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > >> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M <kevin@pnnl.gov> wrote: >>> The pressure for #2 comes from the inability to skip upgrades and the fact >>> that upgrades are hugely time consuming still. >>> >>> If you want to reduce the push for number #2 and help developers get their >>> wish of getting features into users hands sooner, the path to upgrade >>> really needs to be much less painful. >>> >> >> +1000 >> >> We are upgrading from Kilo to Mitaka. It took 1 year to plan and >> execute the upgrade. (and we skipped a version) >> Scheduling all the relevant internal teams is a monumental task >> because we don't have dedicated teams for those projects and they have >> other priorities. >> Upgrading affects a LOT of our systems, some we don't fully have >> control over. And it can takes months to get new deployment on those >> systems. (and after, we have to test compatibility, of course) >> >> So I guess you can understand my frustration when I'm told to upgrade >> more often and that skipping versions is discouraged/unsupported. >> At the current pace, I'm just falling behind. I *need* to skip >> versions to keep up. >> >> So for our next upgrades, we plan on skipping even more versions if >> the database migration allows it. (except for Nova which is a huge >> PITA to be honest due to CellsV1) >> I just don't see any other ways to keep up otherwise. > > ?!?! > > What does it take for this to never happen again? No operator should need to > plan and execute an upgrade for a whole year to upgrade one year's worth of > code development. > > We don't need new policies, new teams, more releases, fewer releases, or > anything like that. The goal is NOT "let's have an LTS release". The goal > should be "How do we make sure Mattieu and everyone else in the world can > actually deploy and use the software we are writing?" > > Can we drop the entire LTS discussion for now and focus on "make upgrades > take less than a year" instead? After we solve that, let's come back around > to LTS versions, if needed. I know there's already some work around that. > Let's focus there and not be distracted about the best bureaucracy for not > deleting two-year-old branches. > > > --John John, So... Any concrete ideas on how to achieve that? Thanks, Dims > > > /me puts on asbestos pants > >> >> -- >> Mathieu >> >> ___ >> OpenStack-operators mailing list >> openstack-operat...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] Upstream LTS Releases
On Wed, Nov 15, 2017 at 7:01 AM, Chris Friesen <chris.frie...@windriver.com> wrote: > On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: > >>> The quality of backported fixes is expected to be a direct (and only?) >>> interest of those new teams of new cores, coming from users and operators >>> and >>> vendors. >> >> >> I'm not assuming bad intentions, not at all. But there is a lot of >> involved in a >> decision whether to make a backport or not. Will these people be able to >> evaluate a risk of each patch? Do they have enough context on how that >> release >> was implemented and what can break? Do they understand why feature >> backports are >> bad? Why they should not skip (supported) releases when backporting? >> >> I know a lot of very reasonable people who do not understand the things >> above >> really well. > > > I would hope that the core team for upstream LTS would be the (hopefully > experienced) people doing the downstream work that already happens within > the various distros. +1 Chris! > > Chris > > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] Upstream LTS Releases
Blair, Please add #2 as a line proposal in: https://etherpad.openstack.org/p/LTS-proposal So far it's focused on #1 Thanks, Dims On Wed, Nov 15, 2017 at 3:30 AM, Blair Bethwaite <blair.bethwa...@gmail.com> wrote: > Hi all - please note this conversation has been split variously across > -dev and -operators. > > One small observation from the discussion so far is that it seems as > though there are two issues being discussed under the one banner: > 1) maintain old releases for longer > 2) do stable releases less frequently > > It would be interesting to understand if the people who want longer > maintenance windows would be helped by #2. > > On 14 November 2017 at 09:25, Doug Hellmann <d...@doughellmann.com> wrote: >> Excerpts from Bogdan Dobrelya's message of 2017-11-14 17:08:31 +0100: >>> >> The concept, in general, is to create a new set of cores from these >>> >> groups, and use 3rd party CI to validate patches. There are lots of >>> >> details to be worked out yet, but our amazing UC (User Committee) will >>> >> be begin working out the details. >>> > >>> > What is the most worrying is the exact "take over" process. Does it mean >>> > that >>> > the teams will give away the +2 power to a different team? Or will our >>> > (small) >>> > stable teams still be responsible for landing changes? If so, will they >>> > have to >>> > learn how to debug 3rd party CI jobs? >>> > >>> > Generally, I'm scared of both overloading the teams and losing the >>> > control over >>> > quality at the same time :) Probably the final proposal will clarify it.. >>> >>> The quality of backported fixes is expected to be a direct (and only?) >>> interest of those new teams of new cores, coming from users and >>> operators and vendors. The more parties to establish their 3rd party >> >> We have an unhealthy focus on "3rd party" jobs in this discussion. We >> should not assume that they are needed or will be present. They may be, >> but we shouldn't build policy around the assumption that they will. Why >> would we have third-party jobs on an old branch that we don't have on >> master, for instance? >> >>> checking jobs, the better proposed changes communicated, which directly >>> affects the quality in the end. I also suppose, contributors from ops >>> world will likely be only struggling to see things getting fixed, and >>> not new features adopted by legacy deployments they're used to maintain. >>> So in theory, this works and as a mainstream developer and maintainer, >>> you need no to fear of losing control over LTS code :) >>> >>> Another question is how to not block all on each over, and not push >>> contributors away when things are getting awry, jobs failing and merging >>> is blocked for a long time, or there is no consensus reached in a code >>> review. I propose the LTS policy to enforce CI jobs be non-voting, as a >>> first step on that way, and giving every LTS team member a core rights >>> maybe? Not sure if that works though. >> >> I'm not sure what change you're proposing for CI jobs and their voting >> status. Do you mean we should make the jobs non-voting as soon as the >> branch passes out of the stable support period? >> >> Regarding the review team, anyone on the review team for a branch >> that goes out of stable support will need to have +2 rights in that >> branch. Otherwise there's no point in saying that they're maintaining >> the branch. >> >> Doug >> >> ______ >> 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 > > > > -- > Cheers, > ~Blairo > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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-operators] LTS pragmatic example
Let's focus our energy on the etherpad please https://etherpad.openstack.org/p/LTS-proposal On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas <dava...@gmail.com> wrote: > Saverio, > > Please see this : > https://docs.openstack.org/project-team-guide/stable-branches.html for > current policies. > > On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto <saverio.pr...@switch.ch> > wrote: >>> Which stable policy does that patch violate? It's clearly a bug >>> because the wrong information is being logged. I suppose it goes >>> against the string freeze rule? Except that we've stopped translating >>> log messages so maybe we don't need to worry about that in this case, >>> since it isn't an exception. >> >> Well, I also would like to understand more about stable policy violations. >> When I proposed such patches in the past for the release N-2 I have >> always got the answer: it is not a security issue so it will not be merged. >> >> This is a good example of how things have been working so far: >> >> https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa >> >> This cinder patch was merged in master. It was then merged in Mitaka. >> But it was not merged in Liberty just because "only security fixes" were >> allowed at that point. >> >> You can read that in the comments: >> https://review.openstack.org/#/c/306610/ >> >> Is this kind of things going to change after the discussion in Sydney ? >> The discussion is not enough ? what we need to get done then ? >> >> thank you >> >> Saverio >> >> >> ______ >> 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 > > > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ 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-operators] LTS pragmatic example
Saverio, Please see this : https://docs.openstack.org/project-team-guide/stable-branches.html for current policies. On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto <saverio.pr...@switch.ch> wrote: >> Which stable policy does that patch violate? It's clearly a bug >> because the wrong information is being logged. I suppose it goes >> against the string freeze rule? Except that we've stopped translating >> log messages so maybe we don't need to worry about that in this case, >> since it isn't an exception. > > Well, I also would like to understand more about stable policy violations. > When I proposed such patches in the past for the release N-2 I have > always got the answer: it is not a security issue so it will not be merged. > > This is a good example of how things have been working so far: > > https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa > > This cinder patch was merged in master. It was then merged in Mitaka. > But it was not merged in Liberty just because "only security fixes" were > allowed at that point. > > You can read that in the comments: > https://review.openstack.org/#/c/306610/ > > Is this kind of things going to change after the discussion in Sydney ? > The discussion is not enough ? what we need to get done then ? > > thank you > > Saverio > > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] Upstream LTS Releases
Bogdan, Team, So i got this etherpad started. Please add policy ideas at the top and volunteer for the team too., https://etherpad.openstack.org/p/LTS-proposal Thanks, Dims On Wed, Nov 15, 2017 at 3:08 AM, Bogdan Dobrelya <bdobr...@redhat.com> wrote: >>> The concept, in general, is to create a new set of cores from these >>> groups, and use 3rd party CI to validate patches. There are lots of >>> details to be worked out yet, but our amazing UC (User Committee) will >>> be begin working out the details. >> >> >> What is the most worrying is the exact "take over" process. Does it mean >> that the teams will give away the +2 power to a different team? Or will our >> (small) stable teams still be responsible for landing changes? If so, will >> they have to learn how to debug 3rd party CI jobs? >> >> Generally, I'm scared of both overloading the teams and losing the control >> over quality at the same time :) Probably the final proposal will clarify >> it.. > > > The quality of backported fixes is expected to be a direct (and only?) > interest of those new teams of new cores, coming from users and operators > and vendors. The more parties to establish their 3rd party checking jobs, > the better proposed changes communicated, which directly affects the quality > in the end. I also suppose, contributors from ops world will likely be only > struggling to see things getting fixed, and not new features adopted by > legacy deployments they're used to maintain. So in theory, this works and as > a mainstream developer and maintainer, you need no to fear of losing control > over LTS code :) > > Another question is how to not block all on each over, and not push > contributors away when things are getting awry, jobs failing and merging is > blocked for a long time, or there is no consensus reached in a code review. > I propose the LTS policy to enforce CI jobs be non-voting, as a first step > on that way, and giving every LTS team member a core rights maybe? Not sure > if that works though. > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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-operators] LTS pragmatic example
Flavio, Saverio, Agree, that review may be a good example of what could be done. More info below. Saverio said - "with the old Stable Release thinking this patch would not be accepted on old stable branches." My response - "Those branches are still under stable policy. That has not changed just because of an email thread or a discussion in Forum" Saverio said - "Let's see if this gets accepted back to stable/newton" My response - "The branch the review is against is still under stable policy. So things that will or will not be backported will not change" Saverio said - "Please note that a developers/operators that make the effort of fixing this in master, should do also all the cherry-pickes back. We dont have any automatic procudure for this." My response - "How the cherry-picks are done for stable branches will not change. This is a stable branch, so there is no automatic procedure for backporting" I really want folks to help with stable first, learn how things are done and then propose changes to stable branch policies and help execute them If folks want to chase LTS, then we are outlining a procedure/process that is a first step towards LTS eventually. Thanks, Dims On Wed, Nov 15, 2017 at 2:46 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 14/11/17 22:33 +1100, Davanum Srinivas wrote: >> >> Saverio, >> >> This is still under the stable team reviews... NOT LTS. >> >> Your contacts for the Nova Stable team is ... >> https://review.openstack.org/#/admin/groups/540,members >> >> Let's please be clear, we need new people to help with LTS plans. >> Current teams can't scale, they should not have to and it's totally >> unfair to expect them to do so. > > > I think you may have misunderstood Saverio's email. IIUC, what he was trying > to > do was provide an example in favor of the LTS branches as discussed in > Sydney, > rather than requesting for reviews or suggesting the stable team should do > LTS. > > Flavio > >> On Tue, Nov 14, 2017 at 8:02 PM, Saverio Proto <ziopr...@gmail.com> wrote: >>> >>> Hello, >>> >>> here an example of a trivial patch that is important for people that >>> do operations, and they have to troubleshoot stuff. >>> >>> with the old Stable Release thinking this patch would not be accepted >>> on old stable branches. >>> >>> Let's see if this gets accepted back to stable/newton >>> >>> >>> https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea >>> >>> Please note that a developers/operators that make the effort of fixing >>> this in master, should do also all the cherry-pickes back. We dont >>> have any automatic procudure for this. >>> >>> thank you >>> >>> Saverio > > > -- > @flaper87 > Flavio Percoco -- Davanum Srinivas :: https://twitter.com/dims __ 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] LTS pragmatic example
Saverio, This is still under the stable team reviews... NOT LTS. Your contacts for the Nova Stable team is ... https://review.openstack.org/#/admin/groups/540,members Let's please be clear, we need new people to help with LTS plans. Current teams can't scale, they should not have to and it's totally unfair to expect them to do so. Thanks, Dims On Tue, Nov 14, 2017 at 8:02 PM, Saverio Proto <ziopr...@gmail.com> wrote: > Hello, > > here an example of a trivial patch that is important for people that > do operations, and they have to troubleshoot stuff. > > with the old Stable Release thinking this patch would not be accepted > on old stable branches. > > Let's see if this gets accepted back to stable/newton > > https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea > > Please note that a developers/operators that make the effort of fixing > this in master, should do also all the cherry-pickes back. We dont > have any automatic procudure for this. > > thank you > > Saverio > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates
Please see below: On Tue, Oct 24, 2017 at 10:11 AM, Thierry Carrez <thie...@openstack.org> wrote: > Doug Hellmann wrote: >> [...] >> It feels like we have two related by not necessarily dependent >> policy questions we need to answer before we decide how to proceed: > > I don't have strong opinions on any of those two, I think anything would > work. If I had to pick between yes and no, here is my gut feeling: > >> (a) Do we want to move the release job definitions from project-config >> and openstack-zuul-jobs to the releases repo? > > Leaning towards yes as it will (imho) simplify maintenance. We'll still > have a couple of privileged jobs that will live on the infra side though? Agree with Thierry. >> (b) Do we want to have multiple release job templates due to custom >> dependencies (or any other reason)? > > Leaning towards no if we can avoid it, again to simplify operations. > That said, it will be difficult to enforce... Same. Let's start without it and revisit if we need them later. > -- > Thierry Carrez (ttx) > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [kolla] [PTL] who can start the official meeting?
Swapnil, Dunno if it was malicious or someone just trying to understand how things work. Worth reaching out to jinke [1] [1] http://git.openstack.org/cgit/openstack/stackalytics/commit/?id=e2593c113d64868b44f27a9fba15a564855236c6 Thanks, Dims On Wed, Oct 11, 2017 at 12:35 PM, Swapnil Kulkarni <cools...@gmail.com> wrote: > On Wed, Oct 11, 2017 at 9:52 PM, Michał Jastrzębski <inc...@gmail.com> wrote: >> I haven't seen "malicious" meeting starters yet, let's hope that won't >> happen:) On the other hand, ad-hoc chair change can, and did, happen, >> so I agree with fungi - I don't think we need to put restrictions on >> that. >> >> On 11 October 2017 at 09:11, Jeremy Stanley <fu...@yuggoth.org> wrote: >>> On 2017-10-11 21:35:26 +0530 (+0530), Swapnil Kulkarni wrote: >>> [...] >>>> The problem here is if we know who are most likely to chair the >>>> meeting e.g. [1] we can allow them to start the meeting. >>> [...] >>> >>> I'm pretty certain I wouldn't want to have to propose a patch to >>> update that every time I needed someone to chair a meeting in my >>> absence. This doesn't seem like a common enough issue to warrant the >>> added complexity and red tape of access controls on our meeting >>> automation. >>> -- >>> Jeremy Stanley >>> >>> __ >>> 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 > > Michal, > > I just gave one instance of malicious meeting attempt [1] happened > today and it happened to be kolla meeting so I noticed its not correct > timing for the same. I would put it as permission-ed access rather > than restriction, because as much as we want to keep it open we need > to maintain the genuineness of meeting. I would not want to stumble > into a junk log file while I am reading it later looking for > something. > > > [1] > http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-10-11-10.31.log.html > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [pbr] Migration to Storyboard
+1 On Wed, Oct 11, 2017 at 12:05 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Stephen Finucane's message of 2017-10-11 15:05:50 +0100: >> The Python packaging ecosystem is shifting under our feet and we have a >> couple >> of things in pbr we need to look at over the next few months (Pipfiles, >> pyenv, >> changes in setuptools setup.cfg, ...). We should probably track these >> somewhere >> and Storyboard [1] seems like a better candidate for doing this than >> Launchpad >> (plus, I get to play with Storyboard). >> >> I can initiate the transfer (it seems pretty easy to do [2]) but I'd like to >> make sure there are no objections before doing so. >> >> Speak now or forever hold your tongue. >> >> Stephen >> >> [1] https://docs.openstack.org/infra/storyboard/ >> [2] https://docs.openstack.org/infra/storyboard/migration.html >> > > We have a bunch of open bugs. It would be good to triage those to see > which, if any, need to be migrated. > > Otherwise I'm +1. > > Doug > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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][election] TC candidacy (dims)
Oops! Matt Treinish pointed out i have 6 more months to go :) Thanks, Dims On Fri, Oct 6, 2017 at 8:38 AM, Davanum Srinivas <dava...@gmail.com> wrote: > Team, > > Please consider my candidacy for Queens. I just realized how time flies, > reading > my previous two self nominations [1][2]. As a TC we have made significant > strides in the last cycle[3] and my contributions have been around how we can > do better working with adjacent communities and getting people from outside > US involved and productive. We have significant challenges in both areas. > Let's > start with the one about engaging new potentially part-time contributors, the > newly forming SIG around "First Contact" is something we need to pool > our efforts > into it. Encouraging activities around SIG-OpenStack in kubernetes (and the > mirror SIG-Kubernetes proposed in OpenStack) is turning the corner seeing the > level of interest at the PTG [5]. I fully intend to help in both areas so > our Foundation can stay at the cutting edge and relevant in the current and > emerging eco systems. > > Thanks, > Dims > > > [1] > https://git.openstack.org/cgit/openstack/election/plain/candidates/newton/TC/Davanum_Srinivas.txt > [2] > https://git.openstack.org/cgit/openstack/election/plain/candidates/pike/TC/dims.txt > [3] > http://lists.openstack.org/pipermail/openstack-dev/2017-October/122962.html > [4] > http://lists.openstack.org/pipermail/openstack-sigs/2017-September/thread.html#74 > [5] https://etherpad.openstack.org/p/queens-ptg-sig-k8s > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ 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][mogan] Need help for replacing the current master
Many thanks to Jeremy and Clark. We are back on our feet for Mogan. Thanks, Dims On Fri, Oct 6, 2017 at 1:03 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-09-29 00:19:25 -0400 (-0400), Davanum Srinivas wrote: >> I tried several things, not sure i have enough git-fu to pull this >> off. For example. > [...] >> remote: ERROR: In commit de26dc69aa28f57512326227a65dc3f9110a7be1 >> remote: ERROR: committer email address sleepsonthefl...@gmail.com >> remote: ERROR: does not match your user account. > [...] > > Yep, sorry about that (and sorry we've been too distracted to > respond before now, thanks for the reminder in IRC). We should have > predicted you'd need forgeCommitter in addition to pushMerge. We've > added that via https://review.openstack.org/510158 which has now > applied in Gerrit so please do try again and I'll try to be more > responsive in assisting with any further errors (but hopefully it'll > "just work" now). > -- > Jeremy Stanley > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [tc][election] TC candidacy (dims)
Team, Please consider my candidacy for Queens. I just realized how time flies, reading my previous two self nominations [1][2]. As a TC we have made significant strides in the last cycle[3] and my contributions have been around how we can do better working with adjacent communities and getting people from outside US involved and productive. We have significant challenges in both areas. Let's start with the one about engaging new potentially part-time contributors, the newly forming SIG around "First Contact" is something we need to pool our efforts into it. Encouraging activities around SIG-OpenStack in kubernetes (and the mirror SIG-Kubernetes proposed in OpenStack) is turning the corner seeing the level of interest at the PTG [5]. I fully intend to help in both areas so our Foundation can stay at the cutting edge and relevant in the current and emerging eco systems. Thanks, Dims [1] https://git.openstack.org/cgit/openstack/election/plain/candidates/newton/TC/Davanum_Srinivas.txt [2] https://git.openstack.org/cgit/openstack/election/plain/candidates/pike/TC/dims.txt [3] http://lists.openstack.org/pipermail/openstack-dev/2017-October/122962.html [4] http://lists.openstack.org/pipermail/openstack-sigs/2017-September/thread.html#74 [5] https://etherpad.openstack.org/p/queens-ptg-sig-k8s -- Davanum Srinivas :: https://twitter.com/dims __ 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][oslo] Retiring openstack/pylockfile
+1 from me On Fri, Sep 29, 2017 at 11:07 PM, ChangBo Guo <glongw...@gmail.com> wrote: > pylockfile was deprecated about two years ago in [1] and it is not used in > any OpenStack Projects now [2] , we would like to retire it according to > steps of retiring a project[3]. > > > [1]c8798cedfbc4d738c99977a07cde2de54687ac6c#diff-88b99bb28683bd5b7e3a204826ead112 > [2] http://codesearch.openstack.org/?q=pylockfile=nope== > [3]https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project > -- > ChangBo Guo(gcb) > Community Director @EasyStack > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][mogan] Need help for replacing the current master
Jeremy, Clark, I tried several things, not sure i have enough git-fu to pull this off. For example. [dims@dims-mac 00:03] ~/openstack/openstack/mogan ⟩ git push gerrit HEAD:refs/for/master Counting objects: 8104, done. Delta compression using up to 4 threads. Compressing objects: 100% (2350/2350), done. Writing objects: 100% (8104/8104), 1.19 MiB | 0 bytes/s, done. Total 8104 (delta 2634), reused 8103 (delta 2634) remote: Resolving deltas: 100% (2634/2634) remote: Processing changes: refs: 1, done remote: remote: ERROR: In commit de26dc69aa28f57512326227a65dc3f9110a7be1 remote: ERROR: committer email address sleepsonthefl...@gmail.com remote: ERROR: does not match your user account. remote: ERROR: remote: ERROR: The following addresses are currently registered: remote: ERROR:dava...@gmail.com remote: ERROR:d...@huawei.com remote: ERROR: remote: ERROR: To register an email address, please visit: remote: ERROR: https://review.openstack.org/#/settings/contact remote: remote: To ssh://review.openstack.org:29418/openstack/mogan.git ! [remote rejected] HEAD -> refs/for/master (invalid committer) error: failed to push some refs to 'ssh://dim...@review.openstack.org:29418/openstack/mogan.git' Would it be simpler for you to do this for mogan team? Thanks, Dims PS: i did get added to mogan-core to try this experiment On Thu, Sep 28, 2017 at 9:09 AM, Davanum Srinivas <dava...@gmail.com> wrote: > Jeremy, Clark, > > Filed a change :) > https://review.openstack.org/508151 > > Thanks, > Dims > > On Thu, Sep 28, 2017 at 8:55 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: >> On 2017-09-27 20:02:25 -0400 (-0400), Davanum Srinivas wrote: >>> I'd like to avoid the ACL update which will make it different from >>> other projects. Since we don't expect to do this again, can you please >>> help do this? >> [...] >> >> He (probably accidentally) left out the word "temporary." The ACL >> only needs to allow merge commits to be pushed long enough for that >> merge commit to get pushed for review, and then the ACL can be >> reverted to its earlier state. >> -- >> Jeremy Stanley >> >> __ >> 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 >> > > > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ 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][mogan] Need help for replacing the current master
Jeremy, Clark, Filed a change :) https://review.openstack.org/508151 Thanks, Dims On Thu, Sep 28, 2017 at 8:55 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-09-27 20:02:25 -0400 (-0400), Davanum Srinivas wrote: >> I'd like to avoid the ACL update which will make it different from >> other projects. Since we don't expect to do this again, can you please >> help do this? > [...] > > He (probably accidentally) left out the word "temporary." The ACL > only needs to allow merge commits to be pushed long enough for that > merge commit to get pushed for review, and then the ACL can be > reverted to its earlier state. > -- > Jeremy Stanley > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][mogan] Need help for replacing the current master
Clark, I'd like to avoid the ACL update which will make it different from other projects. Since we don't expect to do this again, can you please help do this? Thanks, Dims On Wed, Sep 27, 2017 at 7:55 PM, Clark Boylan <cboy...@sapwetik.org> wrote: > On Tue, Sep 26, 2017, at 05:57 PM, Zhenguo Niu wrote: >> Thanks Clark Boylan, >> >> We have frozen the Mogan repo since this mail sent out, and there's no >> need >> to update the replacement master. So please help out when you got time. > > I mentioned this to dims on IRC today, but should write it here as well > for broader reach. It looks like https://github.com/dims/mogan is a fast > forwardable change on top of 7744129c83839ab36801856f283fb165d71af32e. > Also its less than ten commits ahead of current mogan master (7744129). > For this reason I think you can just push those commits up to Gerrit and > review them normally. > > The only gotcha with this is you may need to update the Gerrit ACLs to > allow merge commit pushes. > > Clark > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] Garbage patches for simple typo fixes
Doug, Howard (cc'ed) already did a bunch of reaching out especially on wechat. We should request his help. Howard, Can you please help with communications and follow up? Thanks, Dims On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500: >> On 9/22/2017 7:10 AM, Tom Barron wrote: >> > FWIW I think it is better not to attribute motivation in these cases. >> > Perhaps the code submitter is trying to pad stats, but perhaps they are >> > just a new contributor trying to learn the process with a "harmless" >> > patch, or just a compulsive clean-upper who hasn't thought through the >> > costs in reviewer time and CI resources. >> >> I agree. However, the one that set me off last night was a person from >> one company who I've repeatedly -1ed the same types of patches in nova >> for weeks, including on stable branches, and within 10 minutes of each >> other across several repos, so it's clearly part of some daily routine. >> That's what prompted me to send something to the mailing list. >> > > As fungi points out, education and communication are likely to be > our best solution. Maybe one approach is to identify the companies > and individuals involved and find one of our community members to > contact them directly via email. We would want the person doing > that to be willing to explain all of the reasons the community does > not want the sort of activity we are rejecting and to provide > guidance about more useful contributions (Matt's comment is a great > start on both). I imagine that conversation would take a good deal > of patience, especially after the second or third time, but a personal > touch frequently makes all the difference in these sorts of cases. > > If we have someone willing to step into that sort of role, I would > be happy to help craft the initial contact messages and advise as > needed. > > Does anyone want to volunteer to work with me and actually send the > emails? > > Doug > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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][nova][mogan] How to show respect to the original authors?
@Zhenguo, Can you make a formal request via email? add "[infra]" and "[mogan]" tags so everyone in mogan is aware of this and the infra folks give their ok. Then we can ping infra using "infra-root" on the #openstack-infra channel and ask them to replace. Sounds good? Thanks, Dims On Fri, Sep 22, 2017 at 8:41 AM, Zhenguo Niu <niu.zgli...@gmail.com> wrote: > @Dims, > > Yes, I think the history is OK, do I need to ping some infra guys or if you > can help to replace the repo? > > On Fri, Sep 22, 2017 at 7:22 PM, Davanum Srinivas <dava...@gmail.com> wrote: >> >> @Zhenguo, >> >> Can you please confirm that the history looks good? >> >> Thanks, >> Dims >> >> On Fri, Sep 22, 2017 at 1:35 AM, Zhenguo Niu <niu.zgli...@gmail.com> >> wrote: >> > Thanks dims, that's cool :D >> > >> > I'll make sure there's no new patches landed to master before replacing >> > the >> > repo. >> > >> > On Fri, Sep 22, 2017 at 9:53 AM, Davanum Srinivas <dava...@gmail.com> >> > wrote: >> >> >> >> Zhenguo, >> >> >> >> I did some fancy surgery with both cinder and nova repos to add the >> >> history, please check my repo here: >> >> https://github.com/dims/mogan/commits/master >> >> >> >> (Needed quota.py from cinder and rest of the files from Nova) >> >> >> >> If that repo looks good, then we can request infra folks to replace >> >> the current master with that one. >> >> >> >> Thanks, >> >> Dims >> >> >> >> On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu <niu.zgli...@gmail.com> >> >> wrote: >> >> > >> >> > >> >> > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann <mriede...@gmail.com> >> >> > wrote: >> >> >> >> >> >> On 9/21/2017 11:55 AM, Mike Perez wrote: >> >> >>> >> >> >>> On 15:56 Sep 20, Flavio Percoco wrote: >> >> >>>> >> >> >>>> On 20/09/17 12:21 +, Jeremy Stanley wrote: >> >> >>>>> >> >> >>>>> On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote: >> >> >>>>> [...] >> >> >>>>>> >> >> >>>>>> please indicate which file from Nova, so if anyone wanted to >> >> >>>>>> cross >> >> >>>>>> check for fixes etc can go look in Nova >> >> >>>>> >> >> >>>>> [...] >> >> >>>>> >> >> >>>>> While the opportunity has probably passed in this case, the ideal >> >> >>>>> method is to start with a Git fork of the original as your seed >> >> >>>>> project (perhaps with history pruned to just the files you're >> >> >>>>> reusing via git filter-branch or similar). This way the complete >> >> >>>>> change history of the files in question is preserved for future >> >> >>>>> inspection. >> >> >>>> >> >> >>>> >> >> >>>> If it's not too late, I would definitely recommend going with a >> >> >>>> fork, >> >> >>>> fwiw. >> >> >>>> >> >> >>>> Flavio >> >> >>>> >> >> >>>> -- >> >> >>>> @flaper87 >> >> >>>> Flavio Percoco >> >> >>> >> >> >>> >> >> >>> +1 please fork instead. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> __ >> >> >>> 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 >> >> >>> >> >> >> >> >> >> I'm pretty sure this ship has sailed. Mogan has been around since >> >> >> before >> >> >> the PTG in Atl
Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?
@Zhenguo, Can you please confirm that the history looks good? Thanks, Dims On Fri, Sep 22, 2017 at 1:35 AM, Zhenguo Niu <niu.zgli...@gmail.com> wrote: > Thanks dims, that's cool :D > > I'll make sure there's no new patches landed to master before replacing the > repo. > > On Fri, Sep 22, 2017 at 9:53 AM, Davanum Srinivas <dava...@gmail.com> wrote: >> >> Zhenguo, >> >> I did some fancy surgery with both cinder and nova repos to add the >> history, please check my repo here: >> https://github.com/dims/mogan/commits/master >> >> (Needed quota.py from cinder and rest of the files from Nova) >> >> If that repo looks good, then we can request infra folks to replace >> the current master with that one. >> >> Thanks, >> Dims >> >> On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu <niu.zgli...@gmail.com> >> wrote: >> > >> > >> > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann <mriede...@gmail.com> >> > wrote: >> >> >> >> On 9/21/2017 11:55 AM, Mike Perez wrote: >> >>> >> >>> On 15:56 Sep 20, Flavio Percoco wrote: >> >>>> >> >>>> On 20/09/17 12:21 +, Jeremy Stanley wrote: >> >>>>> >> >>>>> On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote: >> >>>>> [...] >> >>>>>> >> >>>>>> please indicate which file from Nova, so if anyone wanted to cross >> >>>>>> check for fixes etc can go look in Nova >> >>>>> >> >>>>> [...] >> >>>>> >> >>>>> While the opportunity has probably passed in this case, the ideal >> >>>>> method is to start with a Git fork of the original as your seed >> >>>>> project (perhaps with history pruned to just the files you're >> >>>>> reusing via git filter-branch or similar). This way the complete >> >>>>> change history of the files in question is preserved for future >> >>>>> inspection. >> >>>> >> >>>> >> >>>> If it's not too late, I would definitely recommend going with a fork, >> >>>> fwiw. >> >>>> >> >>>> Flavio >> >>>> >> >>>> -- >> >>>> @flaper87 >> >>>> Flavio Percoco >> >>> >> >>> >> >>> +1 please fork instead. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> __ >> >>> 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 >> >>> >> >> >> >> I'm pretty sure this ship has sailed. Mogan has been around since >> >> before >> >> the PTG in Atlanta. >> >> >> >> -- >> >> >> >> Thanks, >> >> >> >> Matt >> >> >> >> >> >> >> >> __ >> >> 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 >> > >> > >> > Yes, we are way past that, and there are already 1000+ commits since >> > Mogan >> > created, >> > >> > -- >> > Best Regards, >> > Zhenguo Niu >> > >> > >> > __ >> > 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 >> > >> >> >> >> -- >> Davanum Srinivas :: https://twitter.com/dims >> >> __ >> 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 > > > > > -- > Best Regards, > Zhenguo Niu > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][nova][mogan] How to show respect to the original authors?
Zhenguo, I did some fancy surgery with both cinder and nova repos to add the history, please check my repo here: https://github.com/dims/mogan/commits/master (Needed quota.py from cinder and rest of the files from Nova) If that repo looks good, then we can request infra folks to replace the current master with that one. Thanks, Dims On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu <niu.zgli...@gmail.com> wrote: > > > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann <mriede...@gmail.com> wrote: >> >> On 9/21/2017 11:55 AM, Mike Perez wrote: >>> >>> On 15:56 Sep 20, Flavio Percoco wrote: >>>> >>>> On 20/09/17 12:21 +0000, Jeremy Stanley wrote: >>>>> >>>>> On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote: >>>>> [...] >>>>>> >>>>>> please indicate which file from Nova, so if anyone wanted to cross >>>>>> check for fixes etc can go look in Nova >>>>> >>>>> [...] >>>>> >>>>> While the opportunity has probably passed in this case, the ideal >>>>> method is to start with a Git fork of the original as your seed >>>>> project (perhaps with history pruned to just the files you're >>>>> reusing via git filter-branch or similar). This way the complete >>>>> change history of the files in question is preserved for future >>>>> inspection. >>>> >>>> >>>> If it's not too late, I would definitely recommend going with a fork, >>>> fwiw. >>>> >>>> Flavio >>>> >>>> -- >>>> @flaper87 >>>> Flavio Percoco >>> >>> >>> +1 please fork instead. >>> >>> >>> >>> >>> __ >>> 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 >>> >> >> I'm pretty sure this ship has sailed. Mogan has been around since before >> the PTG in Atlanta. >> >> -- >> >> Thanks, >> >> Matt >> >> >> __ >> 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 > > > Yes, we are way past that, and there are already 1000+ commits since Mogan > created, > > -- > Best Regards, > Zhenguo Niu > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][nova][mogan] How to show respect to the original authors?
Zhenguo, Thanks for bringing this up. For #1, yes please indicate which file from Nova, so if anyone wanted to cross check for fixes etc can go look in Nova For #2, When you pick up a commit from Nova, please make sure the commit message in Mogan has the following * The gerrit change id(s) of the original commit, so folks can easily go find the original commit in gerritt * Add "Co-Authored-By:" tags for each author in the original commit so they get credit Also, Please make sure you do not alter any copyright or license related information in the header when you first copy a file from another project. Thanks, Dims On Wed, Sep 20, 2017 at 4:20 AM, Zhenguo Niu <niu.zgli...@gmail.com> wrote: > Hi all, > > I'm from Mogan team, we copied some codes/frameworks from Nova since we want > to be a Nova with a bare metal specific API. > About why reinventing the wheel, you can find more informations here [1]. > > I would like to know what's the decent way to show our respect to the > original authors we copied from. > > After discussing with the team, we plan to do some improvements as below: > > 1. Adds some comments to the beginning of such files to indicate that they > leveraged the implementation of Nova. > > https://github.com/openstack/mogan/blob/master/mogan/baremetal/ironic/driver.py#L19 > https://github.com/openstack/mogan/blob/master/mogan/console/websocketproxy.py#L17-L18 > https://github.com/openstack/mogan/blob/master/mogan/consoleauth/manager.py#L17 > https://github.com/openstack/mogan/blob/master/mogan/engine/configdrive.py#L17 > https://github.com/openstack/mogan/blob/master/mogan/engine/metadata.py#L18 > https://github.com/openstack/mogan/blob/master/mogan/network/api.py#L18 > https://github.com/openstack/mogan/blob/master/mogan/objects/aggregate.py#L17 > https://github.com/openstack/mogan/blob/master/mogan/objects/keypair.py#L17 > https://github.com/openstack/mogan/blob/master/mogan/objects/server_fault.py#L17 > https://github.com/openstack/mogan/blob/master/mogan/objects/server_group.py#L17 > https://github.com/openstack/mogan/blob/master/mogan/scheduler/client/report.py#L17 > https://github.com/openstack/mogan/blob/master/mogan/scheduler/filter_scheduler.py#L17 > > 2. For the changes we follows what nova changed, should reference to the > original authors in the commit messages. > > > Please let me know if there are something else we need to do or there are > already some existing principles we can follow, thanks! > > > > [1] https://wiki.openstack.org/wiki/Mogan > > > -- > Best Regards, > Zhenguo Niu > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] removing screen from devstack - RSN
w00t! On Thu, Sep 7, 2017 at 8:45 AM, Sean Dague <s...@dague.net> wrote: > On 08/31/2017 06:27 AM, Sean Dague wrote: >> The work that started last cycle to make devstack only have a single >> execution mode, that was the same between automated QA and local, is >> nearing it's completion. >> >> https://review.openstack.org/#/c/499186/ is the patch that will remove >> screen from devstack (which was only left as a fall back for things like >> grenade during Pike). Tests are currently passing on all the gating jobs >> for it. And experimental looks mostly useful. >> >> The intent is to merge this in about a week (right before PTG). So, if >> you have a complicated devstack plugin you think might be affected by >> this (and were previously making jobs pretend to be grenade to keep >> screen running), now is the time to run tests against this patch and see >> where things stand. > > This patch is in the gate and now merging, and with it devstack now has > a single run mode, using systemd units, which is the same between test > and development. > > Thanks to everyone helping with the transition! > > -Sean > > -- > Sean Dague > http://dague.net > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo][oslo.db][keystone] A POC of Keystone over CockroachDB
== >> >> CockroachDB lets you write transactions that respect ACID properties. >> Regarding the "I" (Isolation), CockroachDB offers snapshot and >> serializable isolation but doesn't rely on locks to do that. So every >> time there is concurrent editing transactions that end in a conflict, >> then you have to retry the transactions. Fortunately, `oslo.db' >> already offers a decorator[6] to do that automatically. But, based on >> tests we run with Tempest/Rally, we figured out that some Keystone's >> SQL requests needed the decorator. >> >> You can look at the differences between OpenStack/keystone/stable/pike >> and our fork on GitHub[7]. >> >> >> What's next? >> >> >> You can drop yourself on the VM as a stack user and run Rally tests >> (see README). Tempest is disabled because we have an issue with its >> installation[8]. Note that modifications we made to make it works are >> minimal. This is promising for the adoption of CockroachDB by other >> core services. Nonetheless: >> >> - Fixing the problem with sqlalchemy-migrate will be helpful to ease >> the deployment process. If you are willing to help, we will be >> really grateful. >> >> - We have to look through the performance prism: Keystone over >> CockroachDB vs. Keystone over Galera. This part may involve more >> modifications of `oslo.db'. One thing we have in mind is the >> management of retrying transactions since CockroachDB's >> documentation suggests an approach[9] that doesn't match with actual >> `oslo.db' implementation. >> >> Best, >> >> [1] https://beyondtheclouds.github.io/ >> [2] https://github.com/BeyondTheClouds/openstack-cockroachdb-dev/ >> [3] https://github.com/openstack/sqlalchemy-migrate/tree/master/ >> [4] >> https://github.com/openstack/oslo.db/blob/stable/pike/oslo_db/sqlalchemy/exc_filters.py >> [5] >> https://github.com/openstack/oslo.db/compare/openstack:stable/pike...BeyondTheClouds:cockroachdb/pike >> [6] https://github.com/openstack/oslo.db/blob/stable/pike/oslo_db/api.py#L84 >> [7] >> https://github.com/openstack/keystone/compare/stable/pike...BeyondTheClouds:cockroachdb/pike >> [8] https://bugs.launchpad.net/devstack/+bug/1714981 >> [9] >> https://www.cockroachlabs.com/docs/stable/transactions.html#transaction-retries >> >> -- >> Ronan-A. Cherrueau >> https://rcherrueau.github.io >> >> __ >> 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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][masakari] new project teams application for Masakari
Sam, Please add Masakari to https://etherpad.openstack.org/p/queens-PTG-TC-SWG and find us in the "Technical Committee / Stewardship WG room" at the PTG. Thanks, Dims On Fri, Sep 1, 2017 at 1:25 PM, Sam P <sam47pr...@gmail.com> wrote: > Hi All, > > I have just proposed inclusion of Masakari[1] (Instances High Availability > Service) into list of official OpenStack projects in [2]. Regarding this > proposal, I would like to ask OpenStack community for what else can be > improved > in the project to meet all the necessary requirements. > > And I would like use this thread to extend the discussion about project > masakari. It would be great if you can post your comments/questions in [2] or > in > this thread. I would be happy to discuss and answer to your questions. > > I will be at PTG in Denver from 9/12 (Tuesday) to 9/14(Thursday). Other > Masakari > team members also will be there at PTG. We are happy to discuss anything > regarding to Masakari in PTG. > Please contact us via freenode IRC @ #openstack-masakari, or openstack-dev ML > with prefix [masakari]. > > Thank you. > > [1] https://wiki.openstack.org/wiki/Masakari > [2] https://review.openstack.org/#/c/500118/ > > --- Regards, > Sampath > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [release] Release countdown for week R+1 and R+2, September 4-15
Thanks for your leadership Thierry! -- Dims On Fri, Sep 1, 2017 at 4:04 AM, Thierry Carrez <thie...@openstack.org> wrote: > What? A release countdown at R+1 week? Did someone have too many > celebratory drinks after Pike release? Well, we are not all done yet. We > have release-trailing deliverables to take care of. > > General Information > --- > > As you probably know, Pike was successfully released[1] on the target > date this Wednesday. Projects and libraries following the > cycle-with-intermediary model can now propose early Queens releases. > > However, some deployment-oriented deliverables (from Puppet-OpenStack, > Kolla, TripleO...) have opted for a *cycle-trailing* release model, in > order to finalize their Pike deliverables *after* the main components > are released. Those deliverables should already have published their > first release candidates. They can push additional RCs (or last-minute > intermediary releases) during the R+1 and R+2 weeks, but need to post > their Pike final release before the cycle-trailing release deadline > (September 14). > > [1] > http://lists.openstack.org/pipermail/openstack-announce/2017-August/002009.html > > Upcoming Deadlines & Dates > -- > > Release deadline for cycle-trailing deliverables: September 14 > Queens PTG in Denver: Sept 11-15 > > As usual come find us on #openstack-release IRC channel if you have any > questions or concerns. > > This is the last of the release countdown emails you'll receive from me > for Pike. You should soon receive Queens-related communications from our > new fearless leader, Sean McGinnis. Thanks again everyone for a great > development cycle and a smooth release. Take a step back, look at what > you achieved, and be proud. > > -- > Thierry Carrez (ttx) > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [release] Pike release day - 1
Folks, Everyone please feel free to vote on that review as a way of celebrating the release https://review.openstack.org/#/c/498263/ Thanks, Dims On Tue, Aug 29, 2017 at 4:30 AM, Thierry Carrez <thie...@openstack.org> wrote: > Hi everyone, > > Pike will be formally released tomorrow before 1500utc, with the last > release candidates being promoted to final (for cycle-with-milestones > deliverables) and the release page being finalized. > > A change proposing those promotions is up for review at: > https://review.openstack.org/#/c/498263/ > > PTLs for cycle-with-milestones projects are encouraged to add their +1 > to that review, in order to formally record their acceptance in the > change metadata. > > Unless some major new show-stopper appears today, the current Pike > intermediary releases and release candidates will be included in the > "Pike release" tomorrow. > > Cheers! > > -- > Thierry Carrez (ttx) > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [keystone] Adding Kristi Nikolla to keystone-core
Go Kristi! On Tue, Aug 15, 2017 at 3:00 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > I made the announcement in today's keystone meeting [0] that the current > reviewers have decided to add Kristi Nikolla (knikolla) to the team. > > Kristi has been an extremely valuable asset to the team over the last > couple of releases. He especially stepped up to the plate during Pike. > He provides consistent and valuable feedback on reviews, actively > participates in discussions about the project's future, and takes > initiative when something needs to get done. In addition to that, he's > been great about helping folks out in the channel and getting our Pike > release candidate out the door. > > I'm excited to add Kristi to the keystone core group and I look forward > to seeing him make positive changes. Thanks for all the dedication and > hard work, Kristi! > > [0] > http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-08-15-18.00.log.html#l-130 > > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo][oslo.messaging] Proposing Andy Smith as an oslo.messaging core reviewers
+1 On Tue, Aug 15, 2017 at 12:21 PM, Ben Nemec <openst...@nemebean.com> wrote: > +1 > > > On 08/14/2017 05:59 AM, ChangBo Guo wrote: >> >> I propose that we add Andy Smith to the oslo.messaging team. >> >> Andy Smith has been actively contributing to oslo.messaging for a while >> now, both >> in helping make oslo.messaging better via code contribution(s) and by >> helping with >> the review load when he can. He's been involved on the AMQP 1.0 side for >> awhile. He's really interested in taking ownership of the experimental Kafka >> driver, which would be great to have someone able to drive that. >> >> Please respond with +1/-1 >> >> Voting will last 2 weeks and will end at 28th of August. >> >> Cheers, >> -- >> ChangBo Guo(gcb) >> >> >> __ >> 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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][oslo.policy] A new Keystone-Oslo hook for external PDP
Ruan, The hook is the easy part, having the data you need for making the decision is harder. -- Dims On Thu, Aug 10, 2017 at 10:51 AM, <ruan...@orange.com> wrote: > Dims, > There is a similar prototype https://review.openstack.org/#/c/237521/. > Our idea is to provide a more generic one instead of Fortress. > Ruan > > > -Original Message- > From: Davanum Srinivas [mailto:dava...@gmail.com] > Sent: jeudi 10 août 2017 16:32 > To: OpenStack Development Mailing List (not for usage questions) > Cc: DUVAL Thomas OBS/OAB > Subject: Re: [openstack-dev] [openstack][oslo.policy] A new Keystone-Oslo > hook for external PDP > > Ruan, > > Have you prototyped to see if you have all the information you need is > available in the context (or can be gathered from Nova)? > ( quickly check what the existing HttpCheck mechanism sends over the wire ) > > Thanks, > Dims > > On Thu, Aug 10, 2017 at 10:17 AM, <ruan...@orange.com> wrote: >> Hello, >> >> We would like to have an external and centralized security policy >> engine >> (PDP) that can pilot both OpenStack and SDN controllers. For this >> reason, we have developed and upstreamed a hook for the new >> OpenDaylight release Carbon >> (https://git.opendaylight.org/gerrit/#/c/46146/), and we’d like to develop a >> similar hook for the OpenStack/Oslo-policy. >> >> >> >> A blueprint was submitted to >> https://blueprints.launchpad.net/pbr/+spec/external-pdp-for-oslo-polic >> y, and the spec is submitted to https://review.openstack.org/#/c/492543/. >> >> We hope that this topic can be discussed in the next oslo meeting. >> >> Thank you, >> >> Ruan HE >> >> >> >> __ >> ___ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> >> __ >> 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 >> > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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 > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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][oslo.policy] A new Keystone-Oslo hook for external PDP
Ruan, Have you prototyped to see if you have all the information you need is available in the context (or can be gathered from Nova)? ( quickly check what the existing HttpCheck mechanism sends over the wire ) Thanks, Dims On Thu, Aug 10, 2017 at 10:17 AM, <ruan...@orange.com> wrote: > Hello, > > We would like to have an external and centralized security policy engine > (PDP) that can pilot both OpenStack and SDN controllers. For this reason, we > have developed and upstreamed a hook for the new OpenDaylight release Carbon > (https://git.opendaylight.org/gerrit/#/c/46146/), and we’d like to develop a > similar hook for the OpenStack/Oslo-policy. > > > > A blueprint was submitted to > https://blueprints.launchpad.net/pbr/+spec/external-pdp-for-oslo-policy, and > the spec is submitted to https://review.openstack.org/#/c/492543/. > > We hope that this topic can be discussed in the next oslo meeting. > > Thank you, > > Ruan HE > > > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes
Morgan, Awesome! when there's some momentum, we can move it to a public repo -- Dims On Wed, Aug 9, 2017 at 12:26 AM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > I shall take a look at the webhooks and see if I can help on this front. > > --Morgan > > On Tue, Aug 8, 2017 at 6:34 PM, joehuang <joehu...@huawei.com> wrote: >> Dims, >> >> Integration of keystone and kubernetes is very cool and in high demand. >> Thank you very much. >> >> Best Regards >> Chaoyi Huang (joehuang) >> >> >> From: Davanum Srinivas [dava...@gmail.com] >> Sent: 01 August 2017 18:03 >> To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing >> List (not for usage questions) >> Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone >> based Authentication and Authorization for Kubernetes >> >> Team, >> >> Having waded through the last 4 attempts as seen in kubernetes PR(s) >> and Issues and talked to a few people on SIG-OpenStack slack channel, >> the consensus was that we should use the Webhook mechanism to >> integrate Keystone and Kubernetes. >> >> Here's the experiment : https://github.com/dims/k8s-keystone-auth >> >> Anyone interested in working on / helping with this? Do we want to >> create a repo somewhere official? >> >> Thanks, >> Dims >> >> -- >> Davanum Srinivas :: https://twitter.com/dims >> >> __ >> 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 > > -- > You received this message because you are subscribed to the Google Groups > "kubernetes-sig-openstack" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-sig-openstack+unsubscr...@googlegroups.com. > To post to this group, send email to > kubernetes-sig-openst...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/kubernetes-sig-openstack/CAGnj6au7sxEssRVEf8d6Ha8ZKHk5sD5-Xayn%2BoV%2B5%3DcuHW4sDQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Davanum Srinivas :: https://twitter.com/dims __ 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] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes
Joe, If you see the code in the git repo, you will see that we do use "Authorizer interface", so it is possible use the same code as a custom module. Guess you are thinking about a downstream kubernetes distro. Thanks, Dims On Wed, Aug 9, 2017 at 1:21 AM, joehuang <joehu...@huawei.com> wrote: > Except webhook, how about custom module(call keystone API directly from > custom module) for authorization? ( > https://kubernetes.io/docs/admin/authorization/#custom-modules ) > > Webhook: > Pros.: http calling, loose coupling, more flexible configuration. > Cons.: Degraded performance, one more hop > custom module: > Pros.: direct function call, better performance, less process to > maintain. > Cons.: coupling, built-in module. > > Best Regards > Chaoyi Huang (joehuang) > > > From: Morgan Fainberg [morgan.fainb...@gmail.com] > Sent: 09 August 2017 12:26 > To: OpenStack Development Mailing List (not for usage questions) > Cc: kubernetes-sig-openst...@googlegroups.com > Subject: Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone > based Authentication and Authorization for Kubernetes > > I shall take a look at the webhooks and see if I can help on this front. > > --Morgan > > On Tue, Aug 8, 2017 at 6:34 PM, joehuang <joehu...@huawei.com> wrote: >> Dims, >> >> Integration of keystone and kubernetes is very cool and in high demand. >> Thank you very much. >> >> Best Regards >> Chaoyi Huang (joehuang) >> >> >> From: Davanum Srinivas [dava...@gmail.com] >> Sent: 01 August 2017 18:03 >> To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing >> List (not for usage questions) >> Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone >> based Authentication and Authorization for Kubernetes >> >> Team, >> >> Having waded through the last 4 attempts as seen in kubernetes PR(s) >> and Issues and talked to a few people on SIG-OpenStack slack channel, >> the consensus was that we should use the Webhook mechanism to >> integrate Keystone and Kubernetes. >> >> Here's the experiment : https://github.com/dims/k8s-keystone-auth >> >> Anyone interested in working on / helping with this? Do we want to >> create a repo somewhere official? >> >> Thanks, >> Dims >> >> -- >> Davanum Srinivas :: https://twitter.com/dims >> >> __ >> 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 > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [api] [tc] Nominatimg Eric Fried for service-types-authority core
+1 from me On Tue, Aug 8, 2017 at 11:35 AM, Chris Dent <cdent...@anticdent.org> wrote: > > I don't believe we have an established procedure for core > nominations in the service-types-authority group, so I'll just go > ahead and take the initiative. I think we should make Eric Fried > (efried on IRC) a core in that group. He's been doing a great deal > of work related to service types and service catalog, is around all the > time, and would be a worthy addition. > > If you don't like this idea but would like to say so privately, > please contact me. Otherwise I'll give a few days and make it so. > > The [tc] tag is on here because the repo is considered "owned by the > technical committee". > > We may also wish to consider removing Anne Gentle and Brant Knudson > who are less available these days. > > -- > Chris Dent (⊙＿⊙') https://anticdent.org/ > freenode: cdent tw: @anticdent > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] New code contributors no longer forced to join the foundation
Thanks Jeremy! i know it took a lot of background work/effort by the team to get here. -- Dims On Mon, Aug 7, 2017 at 7:28 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > Due to improvements in the OpenStack Foundation member directory and > our technical election tooling, it is no longer necessary to join > the foundation as an individual member just to be able to submit > changes through Gerrit for official repositories. You do, however, > still eventually need to join if you want to be able to participate > in technical elections (as a candidate or a voter). > > The Account Setup section[1] of the Developer's Guide has been > updated to reflect the new simpler process, and a separate > (optional) Eligibility to Vote in Elections section[2] has been > added. This process change significantly simplifies the onboarding > process for new code contributors by removing a very error-prone > and, for many, eyebrow-raising hurdle. > > A little background: the Bylaws of the OpenStack Foundation Appendix > 4 Technical Committee Member Policy[3] (section 3b) limits voter > rolls for technical elections to Foundation Individual Members. It > was never strictly required by policy to join the foundation if you > only wanted to contribute code and had no interest in voting, which > is not an entirely uncommon case for new contributors. Due to > previous technical limitations in our systems we still forced new > contributors to join, because that was the easiest way at the time > to be relatively certain who was qualified to participate in > technical elections. Now that we have a mechanism for verifying > membership on demand when validating nominations and generating > voter rolls, we have made the step of joining the foundation > optional (though still very much recommended once you reach the > point as a contributor where you want to participate in community > governance processes). > > [1] https://docs.openstack.org/infra/manual/developers.html#account-setup > [2] > https://docs.openstack.org/infra/manual/developers.html#eligibility-to-vote-in-elections > [3] https://www.openstack.org/legal/technical-committee-member-policy/ > -- > Jeremy Stanley > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets
Raildo, I am interested in this topic. PTG session sounds great! Thanks, Dims On Fri, Aug 4, 2017 at 3:34 PM, Raildo Mascena de Sousa Filho < rmasc...@redhat.com> wrote: > Hi all, > > We had a couple of discussions with the Oslo team related to implement > Pluggable drivers for oslo.config[0] and use those feature to implement > support to protect plaintext secret on configuration files[1]. > > In another hand, due the containerized support on OpenStack services, we > have a community effort to implement a k8s ConfigMap support[2][3], which > might make us step back and consider how secret management will work, since > the config data will need to go into the configmap *before* the container > is launched. > > So, I would like to see what the community think. Should we continue > working on that pluggable drivers and protect plain text secrets support > for oslo.config? Makes sense having a PTG session[4] on Oslo to discuss > that feature? > > Thanks for the feedback in advance. > > Cheers, > > [0] https://review.openstack.org/#/c/454897/ > [1] https://review.openstack.org/#/c/474304/ > [2] https://github.com/flaper87/keystone-k8s-ansible/blob/ > 6524b768d75a28adf44c74aca77ccf13dd66b1a9/provision-keystone- > apb/tasks/main.yaml#L71-L108 > [3] https://kubernetes.io/docs/ > <https://kubernetes.io/docs/tasks/configure-pod-container/configmap/>tas > ks/configure-pod-container/configmap/ > <https://kubernetes.io/docs/tasks/configure-pod-container/configmap/> > [4] https://etherpad.openstack.org/p/oslo-ptg-queens > -- > > Raildo mascena > > Software Engineer, Identity Managment > > Red Hat > > <https://www.redhat.com> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > > __ > 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 > > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [release][requirements][shade][infra] FFE for zuul-sphinx
I'd support this FFE for reasons stated above (specifically "only be used in test-requirements.txt") +1 Thanks, Dims On Wed, Aug 2, 2017 at 5:32 PM, Monty Taylor <mord...@inaugust.com> wrote: > Heya, > > We'd like to request a requirements feature freeze exception to add the > zuul-sphinx library. > > zuul-sphinx is an Infra-managed Sphinx extension used to process job > documentation for zuul jobs for Zuul v3. Since jobs can be defined in > individual project repos in Zuul v3, generating documentation for in-repo > jobs is a task that needs to be done in the project itself. > > zuul-sphinx itself will only be used in test-requirements.txt and itself > only has dependencies on sphinx and pyyaml. > > We'd like an FFE for it because we're using shade as an early test-case of > an OpenStack project that does all of the normal OpenStack things (release > management, requirements syncing, devstack jobs) and as shade is release > managed we can't otherwise add the extension to document the jobs we're > adding. > > Also - in Zuul v3 jobs can be defined in branches as well, so having > zuul-sphinx available for stable/pike as we roll it out broadly will be > nice. It may worth considering ocata backport - but we can consider that > once it's actually needed. > > Anywho - it would be dandy to get an exception on this one. > > Thanks! > Monty > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] Only 40 days to PTG !
May be good to point out to new folks, the etherpads for discussions are here: https://wiki.openstack.org/wiki/PTG/Queens/Etherpads Thanks, Dims On Wed, Aug 2, 2017 at 10:33 AM, Thierry Carrez <thie...@openstack.org> wrote: > Hi everyone, > > Time flies, and we are just 40 days from the Project Teams Gathering in > Denver. Time for a few reminders! > > > 1/ Registration > > If you haven't registered yet, you should do so[1] ASAP. Beyond securing > your slot to the event, it helps us planning for rooms and lunches based > on your days of attendance. > > [1] https://queensptg.eventbrite.com/ > > > 2/ Travel support program > > If you'd like to come join your project team in Denver but need > financial help, our Travel Support Program[2] is still open. However the > deadline for applications is *this Sunday, August 6*, so don't forget to > apply in time ! > > [2] https://openstackfoundation.formstack.com/forms/travelsupportptg_denver > > > 3/ Visa > > If you need a visa, it's getting pretty late to go through the whole > process in time for the event. Let us know ASAP if you need an > invitation letter[3] ! > > [3] https://openstackfoundation.formstack.com/forms/visa_form_denver_ptg > > > 4/ Event layout > > We are still finalizing the list of teams and rooms that will meet at > the event[4]. As previously announced, this time the week is split in > the following way: > > - Monday/Tuesday: inter-team discussions on specific themes: workgroup > discussions, help desks from various support teams, discussions for > teams relying on liaisons like Oslo / Horizon / Docs, release goals > hacking rooms... > > - Wednesday-Thursday-Friday: discussions within each project team to > coordinate the Queens work, solve pressing issues and start getting > things done > > [4] > https://docs.google.com/spreadsheets/u/1/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312=true > > > Let me know if you have any question. You can also ask questions on > #openstack-ptg, or contact the events team at p...@openstack.org. > > -- > Thierry Carrez (ttx) > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [release][requirements][barbican][octavia][LBaaS][heat] FFE Request for python-barbicanclient library
4.5.0 is already blocked. My +1 to block 4.5.1 as well. https://github.com/openstack/requirements/blob/master/global-requirements.txt The release team was waiting for a good barbicanclient release before branching as mentioned by Doug: http://lists.openstack.org/pipermail/openstack-dev/2017-July/120314.html So +1 from me to release 4.5.2 and land g-r/u-c updates. Thanks, Dims On Tue, Aug 1, 2017 at 4:48 PM, Dave McCowan (dmccowan) <dmcco...@cisco.com> wrote: > This note is to request a Feature Freeze Exemption (FFE) for the > python-barbicanclient library in Pike. > > Python-barbicanclient 4.5.0 was intended to be the Pike release. However, > after it was released, testing with the Heat and Octavia projects found that > it contained an incompatible change resulting in Tracebacks for those > projects. > > The issue was reported in this bug. > https://bugs.launchpad.net/python-barbicanclient/+bug/1706841 > > A first, and partial, attempt to fix this was merged in this patch. > https://review.openstack.org/487721 > This patch is included in release 4.5.1. > > A second, and successful, fix was merged in this patch. > https://review.openstack.org/489518 > This patch is included in release 4.5.2. > > The Barbican team requests a feature freeze exemption for > python-barbicanclient release 4.5.2 to be the release for Pike. Releases > 4.5.0 and 4.5.1 should be blocked in global requirements. > > Thanks, > Dave > IRC:dave-mccowan > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [requirements][release][oslo] FFE for oslo.policy
+1, i'd support this as the 2 commits in there are not in the normal/runtime flow for oslo.policy and just touch the doc bits. Thanks, Dims On Tue, Aug 1, 2017 at 4:36 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > I was cleaning up a few documentation things for keystone and noticed an > issue with how the configuration reference was rendering. It turns out > the oslo.policy library needed a few tweaks to the show-policy directive > along with some changes to keystone that allowed us to properly render > all default policies. I documented these in a bug report tagging both > projects [0]. > > Two fixes were made to the oslo.policy library (thanks, Doug!) that will > allow projects to render their entire policy document using the > show-policy directive. Both fixes have merged in oslo.policy master and > have been backported to stable/pike. I also have a release proposed to > cut a new version of oslo.policy for us to use for pike [1]. > > Opening this up for discussion to see if we can grant an FFE so that we > can use the proper version of oslo.policy. More context in IRC as well [2]. > > Let me know if you have any questions. Thanks! > > Lance > > [0] https://bugs.launchpad.net/keystone/+bug/1707246 > [1] https://review.openstack.org/#/c/489599/ > [2] > http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-01.log.html#t2017-08-01T18:14:57 > > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes
Team, Having waded through the last 4 attempts as seen in kubernetes PR(s) and Issues and talked to a few people on SIG-OpenStack slack channel, the consensus was that we should use the Webhook mechanism to integrate Keystone and Kubernetes. Here's the experiment : https://github.com/dims/k8s-keystone-auth Anyone interested in working on / helping with this? Do we want to create a repo somewhere official? Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ 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] [Cinder][Nova][Requirements] Lib freeze exception for os-brick
I'd support this Sean. +1
Thanks,
Dims
On Mon, Jul 31, 2017 at 10:37 AM, Sean McGinnis <sean.mcgin...@gmx.com> wrote:
> I am requesting a library release of os-brick during the feature freeze
> in order to fix an issue with the recently landed online volume extend
> feature across Nova and Cinder.
>
> Patches have landed in both projects to add this feature. It wasn't until
> later that Matt was able to get tempest tests in that found an issue with
> some of the logic in the os-brick library. That has now been fixed in the
> stable/pike branch in os-brick with this patch:
>
> https://review.openstack.org/#/c/489227/
>
> We can get a new library release out as soon as the freeze is over, but
> due to the fact that we do not raise global requirements for stable
> branches after release, there could be some deployments that would still
> use the old ("broken") lib. We would need to get this release out before
> the final pike branching of Cinder and Nova to be able to raise G-R to
> make sure the new release is used with this fix.
>
> I see this change as a low risk for other regression, and it would allow
> us to not ship a broken feature.
>
> Thanks,
> Sean
>
> __
> 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
--
Davanum Srinivas :: https://twitter.com/dims
__
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] [release]need help for python-tricircleclient
Hi Joe, You can ping folks on -infra channel on monday to remove the old branch and then we can merge the referenced review to create a fresh one. Thanks, Dims On Sat, Jul 29, 2017 at 2:22 AM, joehuang <joehu...@huawei.com> wrote: > Hello, > > The patch [1] is to add a tag for python-tricircleclient after new features > were added to it since last release. But unfortunately, a branch called > "stable/pike" was there in Apr., and lead to the patch can not pass the gate > test. > > "deliverables/pike/python-tricircleclient.yaml: > openstack/python-tricircleclient 563f700b62de6b57671ec077293da6fa348c250a > not present in pike branch" > > Shall I cherry pick all latest introduced patches from master to the > stable/pike branch, or the old branch which was created in Apr. should be > renamed? > > [1] https://review.openstack.org/#/c/488903/ > > Best Regards > Chaoyi Huang (joehuang) > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][docs] 404s on docs website after the great reorg
On Thu, Jul 27, 2017 at 2:24 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Jeremy Stanley's message of 2017-07-27 16:40:08 +: >> On 2017-07-27 12:23:39 -0400 (-0400), Sean Dague wrote: >> > In the #openstack-nova channel this morning we were debugging some cells >> > v2 things, and ran into the fact that the online docs for this - >> > https://docs.openstack.org/nova/latest/cells.html go to a 404. That's a >> > previously well known link, people have it in their browser history, >> > bookmarks, wiki pages, other websites. >> > >> > My understanding of big moves like this is that redirects are important. >> > Things going blackhole like that not only is an inconvenience to users, >> > but impacts our search engine rankings, and takes a while for them to >> > all sift out. I know in sites I run I'm still regularly getting in >> > bounds to paths on the site that haven't been there for 8 years. >> > >> > It would be really good if we had a way (manual or automated) to have >> > 301 redirects, that are fixable by the teams that now own the >> > documentation (the project teams). >> >> We can look at including .htaccess files in the tree I guess? Or >> some metadata the publish job uses to build them maybe? > > That's exactly what I was thinking. > > 1. Enable .htaccess files by turning on allowoverride for >docs.openstack.org. > > 2. Add .htaccess files in each tree, as needed (see >https://review.openstack.org/487932 for an example of how this >is done with sphinx). > > 3. Update the main .htaccess file in openstack-manuals to redirect >from the old location of docs in a way that passes the full path. >Right now we redirect to /project/latest/: > > redirectmatch 301 "^/developer/([^/]+)/.*$" /$1/latest/ > >I think that would change to look something like: > > redirectmatch 301 "^/developer/([^/]+)/(.*)$" /$1/latest/$2 > >We would only want to do that for projects that actually have >.htaccess files, so we can put a flag in the project-data files in >openstack-manuals and generate project-specific redirect rules (we're >already doing that for some other pages). > > Then when someone visits docs.o.o/developer/nova/cells.html it would > redirect to docs.o.o/nova/latest/cells.html. The nova team then > need to have a redirect from docs.o.o/nova/latest/cells.html to > docs.o.o/nova/latest/user/cells.html. > > If folks think that's a good approach, I will start on the patches > needed in infra and openstack-manuals (1 and 3). Sounds like good plan Doug. Thanks! > Doug > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [release] nominating Sean McGinnis for releases-core
+1 from me. Welcome to the team Sean! On Thu, Jul 27, 2017 at 11:14 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Sean has been increasingly active with the release team this cycle, and > wants to contribute. I think we should go ahead and add him to the > releases-core group. > > Please respond +1/-1. > > Doug > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [relmgt] Non-candidacy for the Queens cycle Release management PTL
Totally agree Doug. Thanks for your all your efforts and guidance Thierry On Thu, Jul 27, 2017 at 9:58 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Sean McGinnis's message of 2017-07-27 08:45:16 -0500: >> > >> > I have multiple reasons for not running this cycle. First, as part of my >> > expanded role at the Foundation my travel commitments increased a bit. >> > The Release management PTL role requires regular work: I ended up doing >> > a relatively bad job at PTLing this cycle, by being away during a number >> > of critical weeks. Fortunately, I could count on the presence of the >> > other team members (especially dhellmann and dims) to keep things under >> > control! >> >> Thank you Thierry and team for the great work. Depite what you say, I >> don't think anyone has felt the impact, so - great job! >> >> Sean >> > > +1 to that -- With your guidance we have solidified the processes > the team uses so well that we can all share the load. That's exactly > the sort of situation we need for all of our cross-project teams. > > Doug > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo][oslo.db] nominating Jay Pipes for oslo-db-core
+1 from me! On Thu, Jul 27, 2017 at 10:10 AM, Michael Bayer <mba...@redhat.com> wrote: > Yeah if Jay has the time that's a big +1 from me! > > On Thu, Jul 27, 2017 at 10:04 AM, Doug Hellmann <d...@doughellmann.com> wrote: >> I have noticed that Jay has been very deeply involved in several >> recent design discussions about oslo.db, and he obviously has a >> great deal of experience in the area, so even though he hasn't been >> actively reviewing patches recently I think he would be a good >> addition to the team. I have asked him, and he is interested and will >> try to become more active as well. >> >> Please indicate your opinion with +1/-1. >> >> Doug >> >> __ >> 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware
Thanks Eric. Shipping it. On Sat, Jul 22, 2017 at 2:28 PM, Eric Fried <openst...@fried.cc> wrote: > dims- > > SHA was good; just hadn't merged yet. It has now. All greens. > Assuming lbragstad/morgan/mordred are on board, let's do it. > > Thanks, > efried > > On 07/22/2017 10:06 AM, Davanum Srinivas wrote: >> Lance, >> >> Ack. SHA needs to be fixed (https://review.openstack.org/#/c/486279/) >> >> Thanks, >> Dims >> >> On Sat, Jul 22, 2017 at 10:24 AM, Lance Bragstad <lbrags...@gmail.com> wrote: >>> Thanks Dims, >>> >>> Looks like Morgan and Monty have it working through the gate now. >>> >>> On Sat, Jul 22, 2017 at 7:26 AM, Davanum Srinivas <dava...@gmail.com> wrote: >>>> >>>> Lance, other keystone cores, >>>> >>>> there's a request for 3.0.1, but one of the reviews that it needs is >>>> not merged yet >>>> >>>> https://review.openstack.org/#/c/486231/ >>>> >>>> >>>> Thansk, >>>> Dims >>>> >>>> On Fri, Jul 21, 2017 at 11:40 PM, Lance Bragstad <lbrags...@gmail.com> >>>> wrote: >>>>> >>>>> >>>>> On Fri, Jul 21, 2017 at 9:39 PM, Monty Taylor <mord...@inaugust.com> >>>>> wrote: >>>>>> >>>>>> On 07/22/2017 07:14 AM, Lance Bragstad wrote: >>>>>>> >>>>>>> After a little head scratching and a Pantera playlist later, we ended >>>>>>> up >>>>>>> figuring out the main causes. The failures can be found in the gate >>>>>>> [0]. >>>>>>> The two failures are detailed below: >>>>>>> >>>>>>> 1.) Keystoneauth version 3.0.0 added a lot of functionality and might >>>>>>> return a different url depending on discovery. Keystonemiddleware use >>>>>>> to >>>>>>> be able to mock urls to keystone in this case because keystoneauth >>>>>>> didn't modify the url in between. Keystonemiddleware didn't know how >>>>>>> to >>>>>>> deal with the new url and the result was a Mock failure. This is >>>>>>> something that we can fix in keystonemiddleware once we have a version >>>>>>> of keystoneauth that covers all discovery cases and does the right >>>>>>> thing. NOTE: If you're mocking requests to keystone and using >>>>>>> keystoneauth somewhere in your project's tests, you'll have to deal >>>>>>> with >>>>>>> this. More on that below. >>>>>> >>>>>> >>>>>> Upon further digging - this one is actually quite a bit easier. There >>>>>> are >>>>>> cases where keystoneauth finds an unversioned discovery endpoint from a >>>>>> versioned endpoint in the catalog. It's done for quite a while, so the >>>>>> behavior isn't new. HOWEVER - a bug snuck in that caused the url it >>>>>> infers >>>>>> to come back without a trailing '/'. So the requests_mock entry in >>>>>> keystonemiddleware was for http://keystone.url/admin/ and keystoneauth >>>>>> was >>>>>> doing a get on http://keystone.url/admin. >>>>>> >>>>>> It's a behavior change and a bug, so we're working up a fix for it. The >>>>>> short story is though that once we fix it it should not cause anyone to >>>>>> need >>>>>> to update requests_mock entries. >>>>> >>>>> >>>>> Ah - thanks for keeping me honest here. Good to know both issues will be >>>>> fixed with the same patch. For context, this was the thought process as >>>>> we >>>>> worked through things earlier [0]. >>>>> >>>>> I appreciate the follow-up! >>>>> >>>>> >>>>> [0] >>>>> >>>>> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-07-21.log.html#t2017-07-21T19:57:30 >>>>> >>>>>> >>>>>> >>>>>>> 2.) The other set of failures were because keystoneauth wasn't >>>>>>> expecting >>>>>>> a URL without a path [1], causin
Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware
Lance, Ack. SHA needs to be fixed (https://review.openstack.org/#/c/486279/) Thanks, Dims On Sat, Jul 22, 2017 at 10:24 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > Thanks Dims, > > Looks like Morgan and Monty have it working through the gate now. > > On Sat, Jul 22, 2017 at 7:26 AM, Davanum Srinivas <dava...@gmail.com> wrote: >> >> Lance, other keystone cores, >> >> there's a request for 3.0.1, but one of the reviews that it needs is >> not merged yet >> >> https://review.openstack.org/#/c/486231/ >> >> >> Thansk, >> Dims >> >> On Fri, Jul 21, 2017 at 11:40 PM, Lance Bragstad <lbrags...@gmail.com> >> wrote: >> > >> > >> > On Fri, Jul 21, 2017 at 9:39 PM, Monty Taylor <mord...@inaugust.com> >> > wrote: >> >> >> >> On 07/22/2017 07:14 AM, Lance Bragstad wrote: >> >>> >> >>> After a little head scratching and a Pantera playlist later, we ended >> >>> up >> >>> figuring out the main causes. The failures can be found in the gate >> >>> [0]. >> >>> The two failures are detailed below: >> >>> >> >>> 1.) Keystoneauth version 3.0.0 added a lot of functionality and might >> >>> return a different url depending on discovery. Keystonemiddleware use >> >>> to >> >>> be able to mock urls to keystone in this case because keystoneauth >> >>> didn't modify the url in between. Keystonemiddleware didn't know how >> >>> to >> >>> deal with the new url and the result was a Mock failure. This is >> >>> something that we can fix in keystonemiddleware once we have a version >> >>> of keystoneauth that covers all discovery cases and does the right >> >>> thing. NOTE: If you're mocking requests to keystone and using >> >>> keystoneauth somewhere in your project's tests, you'll have to deal >> >>> with >> >>> this. More on that below. >> >> >> >> >> >> Upon further digging - this one is actually quite a bit easier. There >> >> are >> >> cases where keystoneauth finds an unversioned discovery endpoint from a >> >> versioned endpoint in the catalog. It's done for quite a while, so the >> >> behavior isn't new. HOWEVER - a bug snuck in that caused the url it >> >> infers >> >> to come back without a trailing '/'. So the requests_mock entry in >> >> keystonemiddleware was for http://keystone.url/admin/ and keystoneauth >> >> was >> >> doing a get on http://keystone.url/admin. >> >> >> >> It's a behavior change and a bug, so we're working up a fix for it. The >> >> short story is though that once we fix it it should not cause anyone to >> >> need >> >> to update requests_mock entries. >> > >> > >> > Ah - thanks for keeping me honest here. Good to know both issues will be >> > fixed with the same patch. For context, this was the thought process as >> > we >> > worked through things earlier [0]. >> > >> > I appreciate the follow-up! >> > >> > >> > [0] >> > >> > http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-07-21.log.html#t2017-07-21T19:57:30 >> > >> >> >> >> >> >>> 2.) The other set of failures were because keystoneauth wasn't >> >>> expecting >> >>> a URL without a path [1], causing an index error. I tested the fix [2] >> >>> against keystonemiddleware and it seems to take care of the issue. >> >>> Eric >> >>> is working on a fix. Once that patch is fully tested and vetted we'll >> >>> roll another keystoneauth release (3.0.1) and use that to test >> >>> keystonemiddleware to handle the mocking issues described in #1. From >> >>> there we should be able to safely bump the minimum version to 3.0.1, >> >>> and >> >>> avoid 3.0.0 all together. >> >> >> >> >> >> Patch is up for this one, and we've confirmed it fixes this issue. >> >> >> >>> Let me know if you see anything else suspicious with respect to >> >>> keystoneauth. Thanks! >> >>> >> >>> >> >>> [0] >> >>> >> >>> >> >>> http://logs.openstack.org/84/486184/1/check/gate-keystonemid
Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware
>>>>>> I started noticing some trivial changes failing in the >>>>>> keystonemiddleware gate [0]. The failures are in tests that use the >>>>>> keystoneauth1 library (8 tests are failing by my count), which we >>>>>> released a new version of yesterday [1]. I've proposed a patch to >>>>>> blacklist keystoneauth1 3.0.0 from keystonemiddleware until we can >>>>>> figure out what happened [2]. Status is being tracked in a bug against >>>>>> keystonemiddleware [3], but might need to be broadened if these >>>>>> changes >>>>>> are affecting other projects. >>>>>> >>>>>> I'll be in -keystone working through some of the issues if you need >>>>>> me. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Lance >>>>>> >>>>>> [0] https://review.openstack.org/#/c/486184/ >>>>>> [1] >>>>>> http://lists.openstack.org/pipermail/openstack-dev/2017-July/119969.html >>>>>> [2] https://review.openstack.org/#/c/486213/ >>>>>> [3] https://bugs.launchpad.net/keystonemiddleware/+bug/1705770 >>>>>> >>>>>> >>>> >>> >>> >>> >>> >>> >>> __ >>> 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 > > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] Stepping down from oslo-core
Thanks for all your help @jd !! yes of course (on tooz) -- Dims On Thu, Jul 20, 2017 at 3:59 AM, Julien Danjou <jul...@danjou.info> wrote: > Hi folks, > > I've not been reviewing or contributing to oslo.* stuff for a while and > I don't intend to change that in the near future. It seems only fair to > step down. > > As I'm currently the only maintainer of tooz, I'd still suggest to leave > me on tooz-core though. :) > > Cheers, > -- > Julien Danjou > # Free Software hacker > # https://julien.danjou.info > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [Glare][TC] Application for inclusion of Glare in the list of official projects
On Tue, Jul 11, 2017 at 7:33 AM, Chris Dent <cdent...@anticdent.org> wrote:
> On Tue, 11 Jul 2017, Mikhail Fedosin wrote:
>
>> For example, deactivating an image in Glance looks like *POST*
>> /v2/images/{image_id}/actions/deactivate with empty body.
>> At one time, Chris Dent advised us to avoid such decisions, and simply
>> change the status of the artifact to 'deactivated' using *PATCH*, which we
>> did.
>
>
> Indeed I did. The point of that was to avoid "actions" style URLs on
> resources that already have that information in their
> representations so that the interface is more RESTful and doesn't
> have a profusion of verby URLs. The other option is to PUT a full
> representation with the status changed.
>
> But that's not the point here. The issue is that in order for Glare
> to provide a seamless compatibility layer with Glance it needs to be
> able to present a facade which is _identical_ to Glance. Not mostly
> the same but with improvement, but identical with all the same
> warts.
Big +1 to "Not mostly the same but with improvement, but identical
with all the same warts.". Anything else is a deal breaker IMHO.
Thanks,
Dims
>
> This provides a critical part in a smooth migration plan. As people
> become aware of glare being there, they can start taking advantage
> of the new features in their new code or code that they are ready to
> update, without having to update old stuff.
>
> If Glare has fairly good separation between the code that handles
> URLs and processes bodies (in and out) and the code that does stuff
> with those bodies[1], it ought to be somewhat straightforward to
> create such a facade.
>
> [1] Not gonna use model, view, controller here; those terms have
> never been accurate for web-based APIs.
>
>
>
> --
> Chris Dent ┬──┬◡ﾉ(° -°ﾉ) https://anticdent.org/
> freenode: cdent tw: @anticdent
>
> __
> 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
>
--
Davanum Srinivas :: https://twitter.com/dims
__
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] [fuxi] [kuryr] [stackube] [openstack-helm] [kolla-kubernetes] [magnum] [zun] Projects in the intersection of Kubernetes and OpenStack
Folks, Between the projects listed, we seem to be covering a whole lot of use cases. Are there others that we are missing? Anyone have other ideas for things we could be doing that needs a home? Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] scheduling oslosphinx for retirement at the start of queens
+1 from me On Mon, Jul 10, 2017 at 9:10 AM, Doug Hellmann <d...@doughellmann.com> wrote: > Oslo team, > > With all documentation now moving to use the openstackdocs theme, > I propose that we retire the oslosphinx repository during Queens. > We should go ahead and create the stable/pike branch at the end of > this cycle, so that we have a way to deal with bugs in existing > pike releases, but I think we can retire the repository at any point > after that. > > Thoughts? > > Doug > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] Status update, July 7th
Let's do this! On Fri, Jul 7, 2017 at 8:46 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-07-07 10:19:48 +0200 (+0200), Thierry Carrez wrote: > [...] >> == Need for a TC meeting next Tuesday == >> >> I propose we have a meeting next week to discuss the next steps in >> establishing the vision. I feel like we should approve it soon, >> otherwise we'll get too close to the vision date (Spring 2019)... We >> also need to wrap up the goals (selecting the two and deferring the >> others). Who is up for discussing those items at our usual meeting slot >> time on Tuesday ? > > Count me in; seems like it would be helpful. > -- > Jeremy Stanley > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [stable]requirements] Bootstrapiing requirements-stable-core
+1 from me. On Wed, Jun 21, 2017 at 6:48 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: > Hi All, > Recently it's been clear that we need a requirements-stable team. > Until npw that's been handled by the release managers and the > stable-maint-core team. > > With the merge of [1] The have the groundwork for that team. I'd like > to nominate: > > * dmllr -- Dirk Mueller > * prometheanfire -- Matthew Thode > * SeanM -- Sean McGinnis > > As that initial team. Each of them has been doing regular reviews on > stable branches and have shown an understanding of how the stable policy > applies to the requirements repo. > > Yours Tony. > > [1] https://review.openstack.org/#/c/470419/ > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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][fuel] Making Fuel a hosted project
Vova, I really hope and wish for a reboot!. Please do note that the change proposed is only just a governance repo change. There is no one here who has proposed any retiring of the fuel repositories (process for retirement is here - [1]). Thanks, Dims [1] https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project On Wed, Jun 21, 2017 at 4:34 PM, Vladimir Kuklin <aglaren...@gmail.com> wrote: > Folks, I sent a reply a couple of days ago, but somehow it got lost. The > original message goes below > > Folks > > It is essentially true that Fuel is no longer being developed as almost 99% > of people have left the project and are working on something else. May be, > in the future, when the dust settles, we can resume working on it, but the > probability is not so high as of now. > > I would like to thank everyone who worked on the project - contributors, > reviewers, core-reviewers, ex-PTLs Alex Shtokolov, Vladimir Kozhukalov and > Dmitry Borodaenko - it was a pleasure to work with you guys. > > Also, I would like to thank puppet-openstack project team as we worked > together on many things really effectively and wish them good luck as well. > > Special Kudos to Jay and Dims as they helped as a lot on governance and > community side. > > I hope, we will work some day together again. > > At the same time, I would like to mention that Fuel is still being actively > used and some bugs are still being fixed, so I would suggest, if that is > possible, that we keep the github repository available for a while, so that > those guys can still access the repositories. > > Having that said, I do not have any other objections on making Fuel Hosted > project. > > > Yours Faithfully > > Vladimir Kuklin > > email: ag...@aglar.ru > email(alt.): aglaren...@gmail.com > mob.: +79267023968 > mob.: (when in EU) +393497028541 > mob.: (when in US) +19293122331 > skype: kuklinvv > telegram -- Davanum Srinivas :: https://twitter.com/dims __ 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] [trove][all][tc] A proposal to rearchitect Trove
On Wed, Jun 21, 2017 at 1:52 AM, Thierry Carrez <thie...@openstack.org> wrote: > Zane Bitter wrote: >> [...] >> Until then it seems to me that the tradeoff is between decoupling it >> from the particular cloud it's running on so that users can optionally >> deploy it standalone (essentially Vish's proposed solution for the *aaS >> services from many moons ago) vs. decoupling it from OpenStack in >> general so that the operator has more flexibility in how to deploy. >> >> I'd love to be able to cover both - from a user using it standalone to >> spin up and manage a DB in containers on a shared PaaS, through to a >> user accessing it as a service to provide a DB running on a dedicated VM >> or bare metal server, and everything in between. I don't know is such a >> thing is feasible. I suspect we're going to have to talk a lot about VMs >> and network plumbing and volume storage :) > > As another data point, we are seeing this very same tradeoff with Magnum > vs. Tessmaster (with "I want to get a Kubernetes cluster" rather than "I > want to get a database"). > > Tessmaster is the user-side tool from EBay deploying Kubernetes on > different underlying cloud infrastructures: takes a bunch of cloud > credentials, then deploys, grows and shrinks Kubernetes cluster for you. > > Magnum is the infrastructure-side tool from OpenStack giving you > COE-as-a-service, through a provisioning API. > > Jay is advocating for Trove to be more like Tessmaster, and less like > Magnum. I think I agree with Zane that those are two different approaches: > > From a public cloud provider perspective serving lots of small users, I > think a provisioning API makes sense. The user in that case is in a > "black box" approach, so I think the resulting resources should not > really be accessible as VMs by the tenant, even if they end up being > Nova VMs. The provisioning API could propose several options (K8s or > Mesos, MySQL or PostgreSQL). I like this! ^^ If we can pull off "different underlying cloud infrastructures" like TessMaster, that would be of more value to folks who may not be using OpenStack (or VMs!) > > From a private cloud / hybrid cloud / large cloud user perspective, the > user-side deployment tool, letting you deploy the software on various > types of infrastructure, probably makes more sense. It's probably more > work to run it, but you gain in flexibility. That user-side tool would > probably not support multiple options, but be application-specific. > > So yes, ideally we would cover both. Because they target different > users, and both are right... > > -- > Thierry Carrez (ttx) > > ______ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [devstack] etcd v3.2.0?
Tony, On Sun, Jun 18, 2017 at 11:34 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Sun, Jun 18, 2017 at 08:19:16PM -0400, Davanum Srinivas wrote: > >> Awesome! thanks Tony, some kolla jobs do that for example, but i think >> this job is a better one to key off of: >> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/infra.yaml#n381 >> >> Outline of the work is - check if there are any new releases in github >> downloads, if so download them using wget and then delegate to the scp >> publisher (with keep-hierarchy) to create the new directories and >> upload the file(s). > > So perhaps I'm dense but I can't see an easy way to get a list of > release artefacts from github in a form that wget can consume. The best > I can see is via the API. I've knocked up a quick'n'dirty mirror > script[1] but I really feel like I've gone off into the weeds. > > You basically need to do: > > git clone && cd > virtualenv .venv > .venv/bin/pip install -U pip setuptools wheel > .venv/bin/pip install -r ./requirements.txt # [2] > .venv/bin/python ./mirror-github-releases.py \ > 'coreos/etcd::.*linux.*gz:etcd' \ > 'coreos/etcd:6225411:.*linux.*gz:etcd' Works for me! > This will in theory from the 3.2.0 (latest) release and look at the > 3.1.7 release, see that it's already publically mirrored and move on. > > It wouldn't be too hard to incorporate into a job. Thoughts? > > Yours Tony. > > [1] https://github.com/tbreeds/mirror-github-releases > [2] Yes of course I could publish it on pypi if we want to go down this > path > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] [requirements] How about using boto3 instead of boto in requirements
Hi Pengju Jiao, The main consume i believe is EC2-API : http://codesearch.openstack.org/?q=%5Eboto=nope=.*req.*%5C.txt= http://codesearch.openstack.org/?q=%5E(from%7Cimport).*boto=nope== Can you please reach out to them? Thanks, Dims On Mon, Jun 19, 2017 at 3:11 AM, jiaopengju <jiaopen...@cmss.chinamobile.com> wrote: > Hi, everyone: > > I have a blueprint of freezer to support s3 storage driver [1], so I need to > add boto3 to the requirements [2]. > > Why use boto3 but not boto? > > Boto3 [3] is the next version of Boto, is now stable and recommended for > general use. It can be used side-by-side with Boto in the same project, so > it is easy to start using Boto3 in your existing projects as well as new > projects. Going forward, API updates and all new feature work will be > focused on Boto3. > > > Problem > > Boto3 requires botocore, jmespath and s3transfer. botocore and jmespath are > already used by boto, this is because boto is used by ec2-api (and > heat-cfntools, rally and swift3). After adding Boto3 to requirements, we > will have old and new libraries ATM. > > > My suggenstion > > How about using boto3 instead of boto? This will require us to do some > migration about boto to boto3. > > > Anyone has ideas or suggesstions? Thank you very much! > > > [1] https://review.openstack.org/#/c/471295 > > [2]https://review.openstack.org/#/c/473067 > > [3]https://github.com/boto/boto3 > > > Pengju Jiao > mail: jiaopen...@cmss.chinamobile.com > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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
