December 2018 - openstack-discuss

Review-Priority for Project Repos
by Surya Singh 11 Jan '19

11 Jan '19

Dear All, There are many occasion when we want to priorities some of the patches whether it is related to unblock the gates or blocking the non freeze patches during RC. So adding the Review-Priority will allow more precise dashboard. As Designate and Cinder projects already experiencing this[1][2] and after discussion with Jeremy brought this to ML to interact with these team before landing [3], as there is possibility that reapply the priority vote following any substantive updates to change could make it more cumbersome than it is worth. Teams please share your experience of using Review-Priority. [1] https://review.openstack.org/#/c/295253/ [2] https://review.openstack.org/#/c/620664/ [3] https://review.openstack.org/#/c/626824/ --- Best Regards Surya

12 17

[Openstack-discuss][Cinder] Fail to mount the volume on the target node
by Minjun Hong 11 Jan '19

11 Jan '19

Hi. After I installed Cinder, I have had a problem which I cannot make instances with volume storage. I created an instance on Horizon and it always has failed. Actually, I'm using Xen as the hypervisor and there was not any special log about Nova. But, in the Xen's log (/var/log/xen/bootloader.5.log), I saw the hypervisor cannot find the volume which is provided by Cinder: Traceback (most recent call last): > File "/usr/lib/xen/bin/pygrub", line 929, in <module> > raise RuntimeError, "Unable to find partition containing kernel" > RuntimeError: Unable to find partition containing kernel And, I also found something noticeable in the Cinder's log ('/var/log/cinder/cinder-volume.log' on the Block storage node): 2018-12-31 04:08:11.189 12380 INFO cinder.volume.manager > [req-93eb0ad3-6c6c-4842-851f-435e15d8639b bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] Attaching volume > 4c21b8f1-ff07-4916-9692-e74759635978 to instance > bea7dca6-fb04-4791-bac9-3ad560280cc3 at mountpoint /dev/xvda on host None. It seems that Cinder cannot receive information of the target node ('on host None' above) so, I think it can cause the problem that Cinder fails to provide the volume due to lack of the host information. Since I could not find any other logs except that log, I need more hints. Please give me some help Thanks! Regard,

2 1

openstack stack fails
by Alfredo De Luca 11 Jan '19

11 Jan '19

Hi all. I installed magnum on openstack and now, after a few issue with cinder type list error, it passed that issue but now I have another one.... AuthorizationFailure: resources.kube_masters.resources[0].resources.master_wait_handle: Authorization failed. Not sure what to do nor check Any clue? Cheers -- *Alfredo*

3 37

[oslo][migrator] RFE Configuration mapping tool for upgrade - coordinate teams
by Herve Beraud 10 Jan '19

10 Jan '19

Hey teams, ## Summary The main goal of this thread is to coordinate teams to adopt the oslo realease migrator tools and raise prior on this topics. ## History During the openstack submit in 2017 at Sydney a team from the Fujitsu company propose a talk about how to make fast forward upgrade from an openstack release to an another, and present the state of art of the configuration migrator inside openstack and the tools availables to do that. This team describe that for now, we have oslo.config generator tool to show deprecated options in newer release but they are still lacking some mapping configurations. After that the same team propose oslo.config specifications to improve migrators. Where specifications was designed by the following reviews: - https://review.openstack.org/#/c/520043/ - https://review.openstack.org/#/c/526314/ - https://review.openstack.org/#/c/526261/ The main goal of the proposed changes in these specs is to handle configuration changes over releases: - https://specs.openstack.org/openstack/oslo-specs/specs/rocky/handle-config-… These specifications describe that there should be some helper in oslo.config for automatically adopt new changes and help users manage their configuration files easily. Scenario: Below is the proposed workflow that users can perform on old system to generate new configuration for preparing upgrading to new release: +--------------+ Old configuration +--------> | (N-1 release) | Oslo | | Config +-------> New configuration Namespaces +--------> Migrator | (N release) | | +--------------+ Running on new environment Since these specifications was validated, some patches was submitted by the Fujitsu team to implement them: https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+… Details: - handle config mapping changes ( https://review.openstack.org/526314 ) - update valid value in choice list for the opt ( https://review.openstack.org/603060 ) - update 'sample_default' instead of 'default' when migrating ( https://review.openstack.org/606211 ) - use difflib to report mismatches in migrator tests ( https://review.openstack.org/606210 ) - replace loop with dictionary lookup ( https://review.openstack.org/606209 ) - replace 'upgrade_value' with 'convert_on_upgrade' ( https://review.openstack.org/606207 ) Since these changes was proposed some peoples from the Fujitsu seems to left the company and also seems to abandon this topic. During the last oslo meeting I had added this topic to the meeting agenda to bring up this topic and to help us to move forward on it. http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-12-17-15.00.log… http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000856… ## Current state Some reviews was validated but some others need to be recovered due to the lack of response about the original authors. I've submit some patches on reviews to help us to move on it. I've made some reviews based on the last comments and based on the asked changes but now we need someone with an deeply knowledge on oslo.config to validate the works. ## Others aspects Some tools like puppet/ansible/chef etc... already in use in openstack can already handle migrators/upgrades and manage config changes. - Do we need to introduce an another tool like this one to do this job? - How many people are manually writing OpenStack configs in the first place? - Does it make sense to implement these changes? ## List of similar features on others projects - Tripleo provide a major release upgrade mechanisme ( https://docs.openstack.org/tripleo-docs/latest/upgrade/developer/upgrades/m… ) - Openstack-Ansible also provide release upgrade mechanisme ( https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/major-up… ) - OpenStack fuel also propose specifications to upgrade configuration and release ( https://specs.openstack.org/openstack/fuel-specs/specs/7.0/upgrade-major-op… ) This wiki can be useful to obtain the big picture of the release upgrade management in openstack ( https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime ) I surely forgot some tools and alternatives, if you see something that can be added here do not hesitate to reply to add it. ## Conclusion I bring up this topic to open a debate so do not hesitate react on this topic by responding at this thread to help us to have a better big picture to make the best choice. Thanks folks. Best regards. -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

4 9

[dev][goal][python3][qa][devstack][ptl] changing devstack's python 3 behavior
by Doug Hellmann 09 Jan '19

09 Jan '19

Today devstack requires each project to explicitly indicate that it can be installed under python 3, even when devstack itself is running with python 3 enabled. As part of the python3-first goal, I have proposed a change to devstack to modify that behavior [1]. With the change in place, when devstack runs with python3 enabled all services are installed under python 3, unless explicitly listed as not supporting python 3. If your project has a devstack plugin or runs integration or functional test jobs that use devstack, please test your project with the patch (you can submit a trivial change to your project and use Depends-On to pull in the devstack change). [1] https://review.openstack.org/#/c/622415/ -- Doug

4 9

[kayobe] IRC meetings
by Mark Goddard 09 Jan '19

09 Jan '19

Hi, The community has requested that we start holding regular IRC meetings for kayobe, and I agree. I suggest we start with meeting every other week, in the #openstack-kayobe channel. I've created a Doodle poll [1] with each hour between 2pm and 6pm UTC available every weekday. Please respond on the poll with your availability. Thanks, Mark [1] https://doodle.com/poll/6di3pddsahg6h66k

1 1

[loci] Release management for LOCI
by Thierry Carrez 08 Jan '19

08 Jan '19

Hi, loci folks, The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise. As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external". In that context, the situation of the loci deliverable (openstack/loci repository) is unclear. Is it: 1. meant to be released through the openstack/releases repository, but just not ready yet (any hint of when it will be ?) 2. not meant to be "released" or tagged but more like continuously published (in which case we should add "release-management:none" to it) 3. meant to be released, but on a 3rd-party platform like the Docker Hub and not using openstack/releases to drive it (in which case we should add "release-management:external" to it) From previous discussions it appears (2) would best describe the loci situation, but I wanted to doublecheck it was still the case. Thanks, -- Thierry Carrez (ttx)

4 7

[nova] Persistent memory resource tracking model
by Rui Zang 07 Jan '19

07 Jan '19

5 10

[Ops] ops meetups team meeting 2018-12-18
by Chris Morgan 07 Jan '19

07 Jan '19

Meeting minutes from our meeting today on IRC are linked below. Key points: - next meeting Jan 8th 2019 - ops meetup #1 looks likely to be at Deutsche Telekom, Berlin, March 7,8 2019 - the team hopes to confirm this soon and commence technical agenda planning early January - team meetings will continue to be 10AM EST Tuesdays on #openstack-operators Meeting ended Tue Dec 18 15:44:05 2018 UTC. 10:44 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… 10:44 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… 10:44 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… About the OpenStack Operators Meetups team: https://wiki.openstack.org/wiki/Ops_Meetups_Team Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 1

[nova] implementation options for nova spec: show-server-numa-topology
by yonglihe 07 Jan '19

07 Jan '19

Hi, guys This spec needs input and discuss for move on. Currently the spec is under reviewing: https://review.openstack.org/#/c/612256/8 Plus with POC code: https://review.openstack.org/#/c/621476/3 and related stein PTG discuss: https://etherpad.openstack.org/p/nova-ptg-stein start from line 897 NUMA topology had lots of information to expose, for saving you time to jumping into to the spec, the information need to return include NUMA related like: numa_node,cpu_pinning,cpu_thread_policy,cpuset,siblings, mem,pagesize,sockets,cores, threads, and PCI device's information. Base on IRC's discuss, we may have 3 options about how to deal with those blobs: 1) include those directly in the server response details, like the released POC does: https://review.openstack.org/#/c/621476/3 2) add a new sub-resource endpoint to servers, most likely use key word 'topology' then: "GET /servers/{server_id}/topology" returns the NUMA information for one server. 3) put the NUMA info under existing 'diagnostics' API. "GET /servers/{server_id}/diagnostics" this is admin only API, normal user loss the possible to check their topology. when the information put into diagnostics, they will be look like: { .... "numa_topology": { cells [ { "numa_node" : 3 "cpu_pinning": {0:5, 1:6}, "cpu_thread_policy": "prefer", "cpuset": [0,1,2,3], "siblings": [[0,1],[2,3]], "mem": 1024, "pagesize": 4096, "sockets": 0, "cores": 2, "threads": 2, }, ... ] # cells } "emulator_threads_policy": "share" "pci_devices": [ { "address":"00:1a.0", "type": "VF", "vendor": "8086", "product": "1526" }, ] } Regards Yongli He

3 8