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] [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] 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
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] 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] [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] [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][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)
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)
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)
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] [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][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] [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] 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] [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] [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] 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] [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] 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] [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] [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][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][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] 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] 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] [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
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] [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] [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
[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][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
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] [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] [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] [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] [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] 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] [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] [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
