openstack-discuss

openstack-discuss@lists.openstack.org

December 2019

  • 149 participants
  • 184 discussions
On Tue, Sep 18, 2018 at 1:30 PM Alex Schultz <aschultz(a)redhat.com> wrote:>> On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann <mriedemos(a)gmail.com> wrote:> > The release page says Ocata is planned to go into extended maintenance mode> > on Aug 27 [1]. There really isn't much to this except it means we don't do> > releases for Ocata anymore [2]. There is a caveat that project teams that do> > not wish to maintain stable/ocata after this point can immediately end of> > life the branch for their project [3]. We can still run CI using tags, e.g.> > if keystone goes ocata-eol, devstack on stable/ocata can still continue to> > install from stable/ocata for nova and the ocata-eol tag for keystone.> > Having said that, if there is no undue burden on the project team keeping> > the lights on for stable/ocata, I would recommend not tagging the> > stable/ocata branch end of life at this point.> >> > So, questions that need answering are:> >> > 1. Should we cut a final release for projects with stable/ocata branches> > before going into extended maintenance mode? I tend to think "yes" to flush> > the queue of backports. In fact, [3] doesn't mention it, but the resolution> > said we'd tag the branch [4] to indicate it has entered the EM phase.> >> > 2. Are there any projects that would want to skip EM and go directly to EOL> > (yes this feels like a Monopoly question)?> >>> I believe TripleO would like to EOL instead of EM for Ocata as> indicated by the thead>http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.ht…>Bringing this backup to see what we need to do to get the stable/ocatabranches ended for the TripleO projects. I'm bringing this upbecause we havehttps://review.openstack.org/#/c/647009/ which is forthe upcoming rename but CI is broken and we have no interest incontinue to keep the stable/ocata branches alive (or fix ci for them).Thanks,-Alex> Thanks,> -Alex>> > [1]https://releases.openstack.org/> > [2]> >https://docs.openstack.org/project-team-guide/stable-branches.html#maintena…> > [3]> >https://docs.openstack.org/project-team-guide/stable-branches.html#extended…> > [4]> >https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.…> >> > --> >> > Thanks,> >> > Matt> >> > __________________________________________________________________________> > OpenStack Development Mailing List (not for usage questions)> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
5 11
0 0

07 May '20
The Security SIG has recently been looking into updating severalsites/documentation and one part we discussed the last couple meetings wasthe security tools listings[0]. One of the projects listed there,Syntribos, doesn't appear to have much activity[1] outside ofzuul/python/docs maintenance and the idea of retiring the project wasmentioned.However, there does seem to be an occasional bug-fix submitted, so we aresending this email out to see if anyone is still utilizing Syntribos. Ifso, please either respond here, reach out to us in the #openstack-securityirc channel, or fill out the section in the Security SIG Agenda etherpad[2].Thanks![0]https://security.openstack.org/#security-tool-development[1]https://review.opendev.org/#/q/project:openstack/syntribos[2]https://etherpad.openstack.org/p/security-agenda
2 2
0 0
[openstack-ansible] dropping suse support
by Mohammed Naser 05 May '20

05 May '20
Hi everyone,I've been trying to avoid writing this email for the longest timeever. It's really painful to have to reach this state, but I thinkwe've hit a point where we can no longer maintain support for SUSEwithin OpenStack Ansible.Unfortunately, with the recent layoffs, the OSA team has taken a hugehit in terms of contributors which means that there is far lesscontributors within the project. This means that we have lessresources to go around and it forces us to focus on a more functional,reliable and well tested set of scenarios.Over the past few cycles, there has been effort to add SUSE support toOpenStack Ansible, during the time that we had maintainers, it wasgreat and SUSE issues were being fixed promptly. In addition, due tothe larger team at the time, we found ourselves having some extra timewhere we can help unbreak other gates. Jesse used to call this a"labour of love", which I admired at the time and hoped we continue todo as much as we can of.However, the lack of a committed maintainer for OpenSUSE has resultedin constantly failing jobs[1][2] (which were moved to non-voting,wasting CI resources as no one fixed them). In addition, it's causingseveral gate blocks for a few times with no one really finding thetime to clean them up.We are resource constrained at this point and we need the resource togo towards making the small subset of supported features functional(i.e. CentOS/Ubuntu). We struggle with that enough, and there seemsto be no deployers that are running SUSE in real life at the momentbased on bugs submitted.With that, I propose that we drop SUSE support this cycle. If anyonewould like to volunteer to maintain it, we can review that option, butthat would require a serious commitment as we've had maintainers stepoff and it hurts the velocity of the project as no one can merge codeanymore...Really wish I didn't have to write this emailMohammed[1]:http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct…[2]:http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct…
6 9
0 0
On Tue, Dec 10, 2019 at 11:15 PM Gorka Eguileor <geguileo(a)redhat.com> wrote:>> On 06/12, Brett Milford wrote:> > On Fri, Nov 22, 2019 at 3:54 AM Matt Riedemann <mriedemos(a)gmail.com> wrote:> > >> > > On 10/17/2019 5:24 AM, Gorka Eguileor wrote:> > > > I stand by my initial recommendation, being able to update the existing> > > > attachment to add the connection information from Nova.> > >> > > OK, thanks for the input and thoughtfulness on this. I've abandoned my> > > change since I'm not going to be pushing this boulder anymore but left> > > notes in the change in case someone else wants to pick it up some day.> > >> > > Note to nova cores: this means we'll have legacy volume attachment> > > compat code around forever.> > >> > > --> > >> > > Thanks,> > >> > > Matt> > >> >> > Hi Groka, Cinder & Nova devs,> >> > Following up this thread from the context of> >https://review.opendev.org/#/c/579004/> >> > To summarise the discussion:> > - initialize_connection shouldn't be called more than once, as it> > may mess up some drivers.> > - To (safely) refresh connection_info a new api for cinder is required.>> Hi,>> It may be a new API or a modification of one of the existing ones.>>> > - a patch to nova, such as #579004 could make a call to this new api> > to refresh connection info on events such as reboot.> >> > Is there any other context to this issue I've missed or an alternate> > path to solving this?> >> > Does the creation of a new api for cinder have any implications for> > being able to backport this patch for nova?> >>> I don't think backporting it in Nova would do us much good, since the> Cinder code would not be backportable (it's a new feature, not a bug> fix).>>> > What would be the process for me to kick off this work?> >>> You should propose a Cinder spec [1] for your work and you may provide a> WIP patch to Cinder at the same time, though depending on the review you> may have to completely change that code later.>> Cheers,> Gorka.>> [1]:https://opendev.org/openstack/cinder-specs>> > Thanks for your help,> > Brett (bcm)> > --> > ❯ brett> >>Cheers Matt, Groka, I thought this might be the case.-- ❯ brett
2 2
0 0
This is a courtesy notice that having received no responses to my email of 28 October [0] proposing to EOL some currently open Cinder branches, and following the policy articulated in [1], at today's Virtual PTG meeting the Cinder project team has decided to put the following stable branches into the End of Life state: driverfixes/mitaka driverfixes/newton stable/ocata stable/pikeI will submit the paperwork to get this process moving one week from today (2 December 2019).cheers,brian[0]http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010385.…[1]https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…
4 8
0 0

07 Apr '20
We are looking at using OVN and are having some issues with it in our ML2 environment.We currently have 2 mechanism drivers in use: linuxbridge and midonet and these work well (midonet is the default tenant network driver for when users create a network)Adding OVN as a third mechanism driver causes the linuxbridge and midonet networks to stop working in terms of CRUD operations etc.It looks as if the OVN driver thinks it’s the only player and is trying to do things on ports that are in linuxbridge or midonet networks.Am I missing something here? (We’re using Stein version)Thanks,Sam
5 6
0 0
[ops] nova wsgi config
by Arnaud Morin 27 Feb '20

27 Feb '20
Hey all,I am trying to configure apache as a WSGI.Is there any other documentation than this:https://docs.openstack.org/nova/stein/user/wsgi.htmlIs there any recommendations?Thanks in advance!-- Arnaud Morin
4 7
0 0

20 Feb '20
Hi,Over the past couple of cycles we have noticed that new contributions andmaintenance efforts for neutron-fwaas project were almost non existent.This impacts patches for bug fixes, new features and reviews. The Neutroncore team is trying to at least keep the CI of this project healthy, but wedon’t have enough knowledge about the details of the neutron-fwaascode base to review more complex patches.During the PTG in Shanghai we discussed that with operators and TC membersduring the forum session [1] and later within the Neutron team during thePTG session [2].During these discussions, with the help of operators and TC members, we reachedthe conclusion that we need to have someone responsible for maintaining project.This doesn’t mean that the maintainer needs to spend full time working on thisproject. Rather, we need someone to be the contact person for the project, whotakes care of the project’s CI and review patches. Of course that’s only aminimal requirement. If the new maintainer works on new features for theproject, it’s even better :)If we don’t have any new maintainer(s) before milestone Ussuri-2, which isFeb 10 - Feb 14 according to [3], we will need to mark neutron-fwaasas deprecated and in “V” cycle we will propose to move the projectfrom the Neutron stadium, hosted in the “openstack/“ namespace, to theunofficial projects hosted in the “x/“ namespace.So if You are using this project now, or if You have customers who areusing it, please consider the possibility of maintaining it. Otherwise,please be aware that it is highly possible that the project will bedeprecated and moved out from the official OpenStack projects.[1]https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forw…[2]https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored -Lines 379-421[3]https://releases.openstack.org/ussuri/schedule.html-- Slawek KaplonskiSenior software engineerRed Hat
8 14
0 0
[ops] Federated Identity Management survey
by Colleen Murphy 30 Jan '20

30 Jan '20
Hello operators,A researcher from the University of Kent who was influential in the design of keystone's federation implementation has asked the keystone team to gauge adoption of federated identity management in OpenStack deployments. This is something we've neglected to track well in the last few OpenStack user surveys, so I'd like to ask OpenStack operators to please take a few minutes to complete the following survey about your usage of identity federation in your OpenStack deployment (even if you don't use federation):https://uok.typeform.com/to/KuRY0qThe results of this survey will benefit not only university research but also the keystone team as it will help us understand where to focus our efforts. Your participation is greatly appreciated.Thanks for your time,Colleen (cmurphy)
1 3
0 0
[Telemetry][TC]Telemetry status
by Rong Zhu 24 Jan '20

24 Jan '20
Hi,As discussed with Rico I send a mail to report the telemetry project status.We had already finished some work in Ussuri:1.Support dynamic pollster feature Thanks Rafael Weingärtner hard workinghttps://review.opendev.org/#/c/677031/https://review.opendev.org/#/c/691659/https://review.opendev.org/#/c/691944/https://review.opendev.org/#/c/694345/https://review.opendev.org/#/c/693088/https://review.opendev.org/#/c/694519/2.Support aodh-evaluator built-in active/active deployment mode3.Support threshold type alarm again Thanks, Lingxianhttps://review.opendev.org/#/c/697566/https://review.opendev.org/#/c/695997/Also, We plan to do some work in Ussuri:1.Add Ceilometer API back Since Gnocchi is out of OpenStack and is unmaintained, we need to addCeilometer API back again.2.Mongodb database backend support As this thread [0] discuss, there are still some users still usemongodb as the database backend, we decide to add this support again.License issue should consider and fix by user. The OVH and Catalyst Cloudhad fix the mongodb performance issue with some mongodb changes. Gnoochiwill still support as the backed. Other database (like influxdb, ES....),we would happy everyone to submit patches to support as the database backedin ceilometer.3.cpu_utils support This is mentioned many many times, this is a useful metric, so wedecide support this again.4.Support container meters with Zun5. Acknowledgment of OpenStack-wide GoalsI created a storyboard to track Ceilometer Ussuri release to do things in[1]. Free free to add things you want to do in Ussuri release.[0]:http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010922…[1]:https://storyboard.openstack.org/#!/board/205-- Thanks,Rong Zhu
17 34
0 0