August 2018 - Starlingx-discuss - lists.starlingx.io

[Starlingx-discuss] Update rpms_from_3rd_parties.lst versions
by Ornelas Aguayo, Jesus 09 Aug '18

09 Aug '18

Hi All, Does anyone know if there's a reason to use exactly the influxdb version 0.9.5.1? The package influxdb-0.9.5.1-1.x86_64.rpm was last modified on the 8th December of 2105, this package is currently in the http://git.openstack.org/cgit/openstack/stx-tools/tree/centos-mirror-tools/… list file that downloads the rpm packages using wget. In order to build this package from the tagged version it requires multiple patches to update the source code pointing to newer urls, clone , and checkout multiple repositories to the time the package was built; This effort can be done, but I was wondering if wouldn't be better to ask if we can use the latest version instead, because maybe in the end, we might be updating the package to the latest version. I'm also wondering if there's an specific reason to use the specific versions from all the packages from the list: libvirt-python-3.5.0-1 *Reason: must match libvirt version (input from the starlingX weekly meeting) novnc-0.6.2-1 python2-httpbin-0.5.0-6 python2-pytest-httpbin-0.2.3-6 python2-pytest-mock-1.6.0-2 python2-storops-0.4.7-2. python-gunicorn-19.7.1-1 kubernetes-1.10.0-1 influxdb-0.9.5.1-1 Regards, Jesus Ornelas Aguayo (chuy)

3 2

Re: [Starlingx-discuss] Questions about Provider MTU feature for StarlingX upstreaming
by Qin, Kailun 09 Aug '18

09 Aug '18

Hi Matt, Thanks for the explanation. One thing that brings a little confusion is the terminology “provider network”: · In StarlingX, the so-called “provider network” is more related w/ physical network, like a superset of “upstream provider networks”, which addresses the values that are currently stored in configuration file parameters only; · while in upstream neutron, what distinguishes provider networks from tenant networks is who (admin/user) actually creates them and how. Just correct me if I’m wrong. If my understanding is correct, yes, I agree with Ian’s response. We’ll work on removing the Neutron configuration file based approach to MTU management and exposing it via a RESTful API as the benefits are clear to us. Thanks again! BR, Kailun From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Wednesday, August 8, 2018 9:05 PM To: Qin, Kailun <kailun.qin(a)intel.com>; Jolliffe, Ian <Ian.Jolliffe(a)windriver.com> Cc: Troyer, Dean <dean.troyer(a)intel.com>; Jones, Bruce E <bruce.e.jones(a)intel.com>; Chilcote Bacco, Derek A <derek.a.chilcote.bacco(a)intel.com>; Le, Huifeng <huifeng.le(a)intel.com>; Xu, Chenjie <chenjie.xu(a)intel.com>; Zhao, Forrest <forrest.zhao(a)intel.com>; Guo, Ruijing <ruijing.guo(a)intel.com>; Rowsell, Brent <Brent.Rowsell(a)windriver.com> Subject: RE: Questions about Provider MTU feature for StarlingX upstreaming HI Kailun, I’m not sure from your reply if you are agreeing or disagreeing with Ian’s response. The intent was to show that the business case for the provider network MTU configuration is to remove the Neutron configuration file based approach to MTU management and expose it via a RESTful API. This is a similar business case for the managed provider networks as a whole. It is understood that upstream neutron already supports MTU configuration at the tenant network level, but was trying to show that the provider network MTU configuration addresses the values that are current stored in configuration file parameters only. Regards, Matt From: Qin, Kailun [mailto:kailun.qin@intel.com] Sent: Wednesday, August 08, 2018 1:34 AM To: Jolliffe, Ian Cc: Troyer, Dean; Jones, Bruce E; Chilcote Bacco, Derek A; Le, Huifeng; Xu, Chenjie; Zhao, Forrest; Guo, Ruijing; Rowsell, Brent; Peters, Matt Subject: RE: Questions about Provider MTU feature for StarlingX upstreaming Hi Ian, Thanks for the feedback. The upstream neutron supports: • Set/modify a specific MTU on a (provider/tenant) network via REST API. This was introduced via “net-mtu-writable” API extension [1][2]. The requested MTU will work together w/ the MTU configuration options (global_physnet_mtu, physical_network_mtus and path_mtu) to configure the network MTU [3]. However, it does *NOT* support: • Dynamic MTU configuration options (global_physnet_mtu, physical_network_mtus and path_mtu) set/modify via REST API. [1] https://bugs.launchpad.net/neutron/+bug/1671634 [2] https://review.openstack.org/#/c/483518/ [3] https://docs.openstack.org/neutron/latest/admin/config-mtu.html So with the current upstream neutron implementation, the MTU configurations options still play a part at the deployment level. They serve as global maximum permissible and default values for network MTUs (of different network types). Meanwhile, neutron does support a dynamic alternative for users to set/modify specific MTUs across their networks. What do you think? Any use case that the current neutron is not able to cover? Let me know if anything unclear. Great thanks! BR, Kailun From: Jolliffe, Ian [mailto:Ian.Jolliffe@windriver.com] Sent: Wednesday, August 8, 2018 9:52 AM To: Qin, Kailun <kailun.qin(a)intel.com<mailto:kailun.qin@intel.com>> Cc: Troyer, Dean <dean.troyer(a)intel.com<mailto:dean.troyer@intel.com>>; Jones, Bruce E <bruce.e.jones(a)intel.com<mailto:bruce.e.jones@intel.com>>; Chilcote Bacco, Derek A <derek.a.chilcote.bacco(a)intel.com<mailto:derek.a.chilcote.bacco@intel.com>>; Le, Huifeng <huifeng.le(a)intel.com<mailto:huifeng.le@intel.com>>; Xu, Chenjie <chenjie.xu(a)intel.com<mailto:chenjie.xu@intel.com>>; Zhao, Forrest <forrest.zhao(a)intel.com<mailto:forrest.zhao@intel.com>>; Guo, Ruijing <ruijing.guo(a)intel.com<mailto:ruijing.guo@intel.com>>; Rowsell, Brent <Brent.Rowsell(a)windriver.com<mailto:Brent.Rowsell@windriver.com>>; Peters, Matt <Matt.Peters(a)windriver.com<mailto:Matt.Peters@windriver.com>> Subject: Re: Questions about Provider MTU feature for StarlingX upstreaming Hi Kailun; The provider network MTU goes along with the business case for managed provider networks. The feature comparison should not be between provider network MTUs and tenant network MTUs, but more about whether we support MTU values via provider network configuration (REST API). The comparable feature in OpenStack is the support for the ML2 global_physnet_mtu, physical_network_mtus and path_mtu configuration options. https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisem… Regards; Ian From: "Qin, Kailun" <kailun.qin(a)intel.com<mailto:kailun.qin@intel.com>> Date: Monday, August 6, 2018 at 3:01 AM To: Ian Jolliffe <Ian.Jolliffe(a)windriver.com<mailto:Ian.Jolliffe@windriver.com>> Cc: "Troyer, Dean" <dean.troyer(a)intel.com<mailto:dean.troyer@intel.com>>, "Jones, Bruce E" <bruce.e.jones(a)intel.com<mailto:bruce.e.jones@intel.com>>, "Chilcote Bacco, Derek A" <derek.a.chilcote.bacco(a)intel.com<mailto:derek.a.chilcote.bacco@intel.com>>, "Le, Huifeng" <huifeng.le(a)intel.com<mailto:huifeng.le@intel.com>>, "Qin, Kailun" <kailun.qin(a)intel.com<mailto:kailun.qin@intel.com>>, "Xu, Chenjie" <chenjie.xu(a)intel.com<mailto:chenjie.xu@intel.com>>, "Zhao, Forrest" <forrest.zhao(a)intel.com<mailto:forrest.zhao@intel.com>>, "Guo, Ruijing" <ruijing.guo(a)intel.com<mailto:ruijing.guo@intel.com>> Subject: Questions about Provider MTU feature for StarlingX upstreaming Hi Ian, We are analyzing the provider MTU feature for StarlingX upstreaming, in which case the patch 021ae1a introduced providernet MTU and c647127 introduced the port granularity bindings for MTU. Since the upstream neutron already has the network granularity MTU implemented [1] and made it available to be created or updated [2], would you please kindly help check whether we need to upstream this feature? If so, would you please share some business use cases or user stories related with us? [1] https://review.openstack.org/#/c/480738/ [2] https://review.openstack.org/#/c/483091/ Let me know if any question. Thanks a lot! BR, Kailun

2 2

[Starlingx-discuss] [Docs] Weekly Docs and Infrastructure call
by Jones, Bruce E 09 Aug '18

09 Aug '18

The Docs & Infra team will be holding a weekly call at 12:30 PST / 1930 UTC on Wednesdays each week. All are welcome. Details are on the wiki [0], with notes and agenda on an Etherpad[1]. Docs team, please add this call to your calendars! brucej [0] https://wiki.openstack.org/wiki/StarlingX/Docs_and_Infra [1] https://etherpad.openstack.org/p/stx-documentation

1 0

Re: [Starlingx-discuss] [Docs] StarlingX API Documentation
by Khalil, Ghada 08 Aug '18

08 Aug '18

Bruce/Abraham, Can you target the completion of this work ( tracked via https://storyboard.openstack.org/#!/story/2002712 ) in the August/early September time-frame? I’ve tagged the Story for the stx.2018.10 release as I believe we want to have the API docs ready for the October release. Please let me know if you disagree. Thanks, Ghada From: Waines, Greg Sent: Wednesday, August 08, 2018 7:33 AM To: Khalil, Ghada; Jolliffe, Ian; Arce Moreno, Abraham; starlingx-discuss(a)lists.starlingx.io Subject: Re: [Starlingx-discuss] StarlingX API Documentation ... yeah forgot to mention the point that Ghada makes below, we currently use a very very out-dated approach to API Documentation ... i.e. Grizzly timeframe ... which uses maven and wadl files ... very ugly. This approach also had the API documentation centralized in one spot ... whereas now the API documentation seems to live (correctly) in the same git as the code. So we additionally need to convert our API Documentation to the current format being used for OpenStack API Doc and should distribute the API documentation appropriately to the appropriate StarlingX sub-projects. Greg. From: "Khalil, Ghada" <Ghada.Khalil(a)windriver.com<mailto:Ghada.Khalil@windriver.com>> Date: Friday, August 3, 2018 at 6:41 PM To: "Jolliffe, Ian" <Ian.Jolliffe(a)windriver.com<mailto:Ian.Jolliffe@windriver.com>>, "Arce Moreno, Abraham" <abraham.arce.moreno(a)intel.com<mailto:abraham.arce.moreno@intel.com>>, "starlingx-discuss(a)lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss(a)lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>> Cc: Greg Waines <Greg.Waines(a)windriver.com<mailto:Greg.Waines@windriver.com>> Subject: RE: [Starlingx-discuss] StarlingX API Documentation Hi Abraham, (You may know this already) The StarlingX APIs (especially for sysinv) are currently documented at: https://git.openstack.org/cgit/openstack/stx-integ/tree/restapi-doc/restapi… You can use the content as a starting point. However, the mechanism used is outdated using maven and wadl files. So you need to use the more current approach. Greg Waines did some research on this. I strongly recommend you review with him when he's back from vacation (Tues Aug 7). Is this the story you are working on: https://storyboard.openstack.org/#!/story/2002712 ? If so, I'll add some of the details Greg has captured to the story. Regards, Ghada -----Original Message----- From: Jolliffe, Ian [mailto:Ian.Jolliffe@windriver.com] Sent: Friday, August 03, 2018 3:38 PM To: Arce Moreno, Abraham; starlingx-discuss(a)lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] StarlingX API Documentation Hi Abraham; Thanks for kicking this off. On 2018-08-03, 12:40 PM, "Arce Moreno, Abraham" <abraham.arce.moreno(a)intel.com<mailto:abraham.arce.moreno@intel.com>> wrote: A new goal in collaboration with our Tech Writing team is to document StarlingX APIs, so we did an initial research on what it means for StarlingX so your feedback is highly appreciated. [ OpenStack :: API ] For this activity we are initially be considering from API Documentation 2 separate efforts for each project: - API Guide .. the concepts in the API - API Ref .. a reference for the API Can we prioritize one over the other? We should do the concepts and the ref at the same time. The new OpenStack approach allows for tags to go in the code. Let's start with this work. [ StarlingX :: API ] It seems we can categorize the StarlingX APIs in 2: - Brand New APIs from StarlingX projects - Existing APIs from OpenStack projects StarlingX should not document other OpenStack API's, would their documentation not the source of truth? [ StarlingX :: API :: Brand New ] The projects falling into this category are the following: - [0] NFVI Orchestration - [1] High Availability/Process Monitoring/Service Management - [2] StarlingX System Configuration Management - [3] Horizon plugins for new StarlingX services - [4] Installation/Update/Patching/Backup/Restore Can we considered all the above to be included in this API documentation effort? Are we missing any other? All projects in the Flock should be included. I think there is a dependency on some of the code restructuring activities that are underway, we need to make sure these activities don't collide. Ian [ StarlingX :: API :: Existing ] All projects living under our starlingx-staging github organization [5] with upstream contributions [6] e.g. horizon, ceilometer, etc. We have not gone through a deeper review if we are modifying/adding new calls into the OpenStack projects however if we are and we need to document them: - There is official OpenStack <Project> API documentation, we can make references to them for the existing calls - What about the modifications/additions? Should we document them? What is the best place for this? We were talking in our weekly call about stx-docs is a good place for things without a repo, is this a good example? - Any easy way besides "find + grep" to get where those API modifications are happening? [ StarlingX :: API :: Unit Tests] OpenStack projects includes Unit Tests. Is this something we also need to consider for our StarlingX Bran New APIs? [0] http://git.openstack.org/cgit/openstack/stx-nfv/ [1] http://git.openstack.org/cgit/openstack/stx-ha/ [2] http://git.openstack.org/cgit/openstack/stx-config/ [3] http://git.openstack.org/cgit/openstack/stx-gui/ [4] http://git.openstack.org/cgit/openstack/stx-update/ [5] https://github.com/starlingx-staging [6] http://git.openstack.org/cgit/openstack/stx-upstream/tree/openstack _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss(a)lists.starlingx.io<mailto:Starlingx-discuss@lists.starlingx.io> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss(a)lists.starlingx.io<mailto:Starlingx-discuss@lists.starlingx.io> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

2 1

[Starlingx-discuss] Notes from the project call today
by Jones, Bruce E 08 Aug '18

08 Aug '18

Agenda and notes for the 8/8 meeting Recording: https://zoom.us/recording/share/8ko3BAnVqYpI-DvUlf5VsMXNucFFGDLpsDeUaEMVuQ-… * Key results from last week's F2F o Release schedule changed - now Oct'18, Mar'19, Jul'19. 3 per year o Build infra - we agreed that package versions can float except for packages that are patched o Sub-projects were finalized with Team Leads and Primes assigned. o Initial governance and TSC proposal discussed for input to the Foundation. Bruce to post the proposal to the list. DONE. o The beer in Ottawa is quite tasty. * Bug tracking options o External bugzilla instance (hosted by whom?) Github.com issue tracking? o Launchpad? This is the option recommended by the Foundation, who supports a migration tool from LP to SB if we want such in the future. Need a small group (Bruce, Ghada, anyone else) to evaluate LP. * Networking / Neutron upstream questions (in emails on the list) o tenant based custom setting and mac filter (d875491, c647127, b189392e, 28d6f56) o VXLAN provider network feature o provider MTU feature o provider network management feature (021ae1a) o router & DHCP rescheduling feature (00dd7cb, 05aed14) o system host management feature (566b640, 4aa521e, baa8264, c6849f, e6669ec) * Influx DB version - the one we're using is 2 years old. Can it float? If not, can we update it to something newer? Abe to take to the mailing list. * Matt's analysis of the Nova patches - please review for his view on the Nova changes https://docs.google.com/spreadsheets/d/1ugp1FVWMsu4x3KgrmPf7HGX8Mh1n80v-KVz… * Default install login and password - change? Yes but this is not easy. Work should be part of the config team. Bruce to create a story for them. * Build team status o Mirror script changes for per-company mirrors o Koji POC o Bruce/Saul/Chuy/Abe to discuss hosting the 9 packages in Clear Linux. o Internally running jobs to check the mirror scripts for updates. Reporting to internal Slack. Report to IRC? email? o Also running an internal job to do full builds, seeing 3 daily builds succeeding. * Release team status o Update from Release/Test teams on last milestone branch (2018.07) (Requested by Ghada) * Dashboard to be posted this week * Daily testing requested - can we run/report Sanity each day? AR Ada to discuss on the list o Feedback on Release Plan wiki update o AR Dean to pull stx.m2018.08 for the August milestone branch o Sample sub-project wiki page / tags * Other teams status o stx-gui - unknown

2 1

[Starlingx-discuss] ECG Keystone Edge Architectures meeting on Thursday (Aug 9)
by Ildiko Vancsa 08 Aug '18

08 Aug '18

Hi, The first meeting on Keystone Edge Architectures within the Edge Computing Group is scheduled for this Thursday (August 9) at 6am PDT / 1300 UTC. If you are interested in joining the discussions you can find the call details here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Keystone Our previous discussions about this topic are captured on this wiki: https://wiki.openstack.org/wiki/Keystone_edge_architectures Further information on Keystone federation testing and joint activities with the OPNFV Edge Cloud Project can be found here: https://etherpad.openstack.org/p/ECG_Keystone_Testing Please let me know if you have any questions. Thanks and Best Regards, Ildikó

1 0

[Starlingx-discuss] Updated initial governance proposal
by Jones, Bruce E 08 Aug '18

08 Aug '18

I have updated our draft Governance proposal [0] based on feedback from Ildiko. I've borrowed some language and concepts from the Kata Containers project [1] but adapted it to the structure that was agreed to our F2F last week. One of the changes is in terminology. Instead of Team Leads and Primes, I'm using the titles Project Leads and Technical Leads respectively, to help highlight that we are initially splitting the role typically performed by a Project Technical Lead. Please review the draft and share any feedback you have to this thread or in the document directly. [0] https://etherpad.openstack.org/p/stx-governance [1] https://github.com/kata-containers/community Thanks! brucej

1 0

[Starlingx-discuss] Virtual Multinode 2 controllers + 2 computes. Nova services are not up in Controller-1.
by Hernandez Gonzalez, Fernando 08 Aug '18

08 Aug '18

Does anybody have configured Virtual Multinode 2 controllers + 2 computes? I have a question regarding nova services on controller-1. I think this is more a question for windriver guy who have previous experience with TiC. Please if you have any idea let me know... Context: In horizon I can see both controllers Available one active other standby but I cannot see nova services up on controller-1. Ctl-0 and Ctl-1 in Horizon [cid:image002.jpg@01D42F0D.EF89E8E0] Ctl-0 and Ctl-1 same Port Interfaces in Horizon [cid:image004.jpg@01D42F0D.EF89E8E0] [cid:image011.jpg@01D42F0D.EF89E8E0] nova service-list executed in Ctl-0 with no Ctl-1 output. [cid:image012.jpg@01D42F0D.EF89E8E0] **Question: nova services will be up on controller-1 once I 1) locked Controller-0, and 2) Swact to controller-1? I did a research on "wr_titanium_cloud_installation_for_systems_with_controller_storage_1803.pdf", page 74, step 7; documentation just says controller-0 but nothing is shown for Controller-1. : ~(keystone_admin)$ nova service-list +------------------+--------------+--------+---------+-------+ ... | Binary | Host | Zone | Status | State | ... +------------------+--------------+--------+---------+-------+ ... | nova-conductor | controller-0 | int... | enabled | up | ... | nova-consoleauth | controller-0 | int... | enabled | up | ... | nova-scheduler | controller-0 | int... | enabled | up | ... Thanks. Fernando Hernandez Gonzalez Software Engineer Avenida del Bosque #1001 Col, El Bajío Zapopan, Jalisco MX, 45019 ____________________________________ Office: +52.33.16.45.01.34 inet 86450134

3 3

[Starlingx-discuss] rebuild or upgrade the 9 RPM/sRPM in the 3rd party list
by Xie, Cindy 08 Aug '18

08 Aug '18

All, We talked about the 9 RPM/sRPM in: https://git.openstack.org/cgit/openstack/stx-tools/tree/centos-mirror-tools… I submitted 5 stories and please comments on the way to handle them: - https://storyboard.openstack.org/#!/story/2003339 - https://storyboard.openstack.org/#!/story/2003340 - https://storyboard.openstack.org/#!/story/2003341 - https://storyboard.openstack.org/#!/story/2003342 - https://storyboard.openstack.org/#!/story/2003357 @chuy is building the RPMs from Intel Koji, please add the status into the stories as well. So we can make decision if we want to upgrade or to re-build them. Thx. - cindy

3 4

Re: [Starlingx-discuss] Brent Rowsell commented on "upgrade libvirt-python to newer version support...
by Xie, Cindy 08 Aug '18

08 Aug '18

+ mailing list @chuy, I think this is the libvirt-python build issue you were reported out in the community meeting just now. Thx. - cindy -----Original Message----- From: Xie, Cindy Sent: Wednesday, August 8, 2018 9:54 PM To: 'Rowsell, Brent' <Brent.Rowsell(a)windriver.com> Cc: Jones, Bruce E <bruce.e.jones(a)intel.com>; Wold, Saul <saul.wold(a)intel.com>; Troyer, Dean <dean.troyer(a)intel.com> Subject: RE: Brent Rowsell commented on "upgrade libvirt-python to newer version support... Brent, Just had side conversation w/ Dean, he also agrees w/ you that libvirt and libvirt-python version doesn't need to be exact version in CentOS 7.5 dist. So it's nice that we can have a choice of upgrading to something newer. There is a 4.1 version in Fedora 28 dist, please see if you want to check and decide which version is the one we'd like to upgrade to. Thanks. - cindy -----Original Message----- From: Xie, Cindy Sent: Wednesday, August 8, 2018 9:27 PM To: 'Rowsell, Brent' <Brent.Rowsell(a)windriver.com> Cc: Jones, Bruce E <bruce.e.jones(a)intel.com>; Wold, Saul <saul.wold(a)intel.com> Subject: RE: Brent Rowsell commented on "upgrade libvirt-python to newer version support... Brent, Agree that we shall go w/ end-to-end solution, and actually this is already started by Shuicheng Lin, who is doing all .src.rpm package review and found out its dependencies and do upgrade to what CentOS 7.5 required. As for libvirt and libvirt-python, we shall follow the same approach, but this is more complicated as we have a forked libvirt repo, and we did analysis for the patches on top of it. They needs to be reviewed and rebased to a new libvirt version. If there are patches we cherry-picked from a newer libvirt, then we can drop them. I can create related stories to make sure the procedures are more transparent. Thx. - cindy -----Original Message----- From: Rowsell, Brent [mailto:Brent.Rowsell@windriver.com] Sent: Wednesday, August 8, 2018 9:16 PM To: Xie, Cindy <cindy.xie(a)intel.com> Cc: Jones, Bruce E <bruce.e.jones(a)intel.com>; Wold, Saul <saul.wold(a)intel.com> Subject: RE: Brent Rowsell commented on "upgrade libvirt-python to newer version support... We need an end to end plan to upgrade to 7.5 not a piece meal approach which is what we seem to be on. This is a recipe for breaking the load. We are likely to go to a newer version of libvirt compared to what is in centos 7.5 as 3.9 is quite old. The upversion of python-libvirt needs to be tied to libvirt upversion Brent -----Original Message----- From: Xie, Cindy [mailto:cindy.xie@intel.com] Sent: Wednesday, August 8, 2018 8:44 AM To: Rowsell, Brent <Brent.Rowsell(a)windriver.com> Cc: Jones, Bruce E <bruce.e.jones(a)intel.com>; Wold, Saul <saul.wold(a)intel.com> Subject: RE: Brent Rowsell commented on "upgrade libvirt-python to newer version support... Hi, Brent, Understand the complexity. What if we upgrade libvirt-python and all its dependencies, this is part of CentOS 7.5 upgrade. I know we have many patches on libvirt because we forked a repo, I am thinking to rebase those patches to 3.9 as well. Let me know if there is any work going on already, but in my opinion this is something we shall include in Q4 release. Thx. - cindy -----Original Message----- From: storyboard(a)storyboard.openstack.org [mailto:storyboard@storyboard.openstack.org] Sent: Wednesday, August 8, 2018 8:04 PM To: Xie, Cindy <cindy.xie(a)intel.com> Subject: Brent Rowsell commented on "upgrade libvirt-python to newer version support... Brent Rowsell added a comment to the story "upgrade libvirt-python to newer version supported by CentOS 7": "You cannot do this, This is tied to the version of libvirt that is used which is 3.5. Please do not make any changes here" URL: https://storyboard.openstack.org/#!/story/2003339 at 2018-08-08 12:04:02+00:00

1 0