| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-13 | |||
| 08:27:48 | Qiming | alex_xu, there? | |
| 08:28:47 | robcresswell | Quick question; someone's added a patch to Horizon that hides the Soft Reboot button if the Instance state is anything other than Active; is this correct? Had a look at the API docs but they only seem to show how to form the request, not any of the conditions around its usage. | |
| 08:31:01 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: Added nova objects for intance diagnostics https://review.openstack.org/434745 | |
| 08:31:01 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: Replace diagnostics objects with Nova diagnostics objects https://review.openstack.org/394480 | |
| 08:31:02 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: Standardization of VM diagnostics info API. https://review.openstack.org/355540 | |
| 08:31:03 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: Completed implementation of instance diagnostics for Xen https://review.openstack.org/399613 | |
| 09:00:08 | bauzas | good morning Nova | |
| 09:02:31 | alex_xu | Qiming: hi, i'm here | |
| 09:08:19 | Qiming | alex_xu, I was checking admin password | |
| 09:11:51 | Qiming | alex_xu, it turns out that I will need to use "/servers/{server_id}/os-server-password" for password GET, and DELETE, use POST /servers/{server_id}/action for password update, and the password can be created only via POST /servers | |
| 09:24:57 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Typo fix in releasenotes: deprecate network options https://review.openstack.org/444778 | |
| 09:25:41 | gmann | sfinucan: alex_xu oomichi simple one - https://review.openstack.org/#/c/444778/ | |
| 09:26:44 | sfinucan | gmann: Done | |
| 09:27:03 | gmann | sfinucan: :) thanks | |
| 09:27:55 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Move detach logic from manager into driver BDM https://review.openstack.org/439520 | |
| 09:27:55 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Use detach_volume during default rebuild https://review.openstack.org/443932 | |
| 09:27:56 | openstackgerrit | Lee Yarwood proposed openstack/nova master: objects: Add attachment_id to BlockDeviceMapping https://review.openstack.org/437665 | |
| 09:27:56 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Only destroy BDMs after successful detach call https://review.openstack.org/440693 | |
| 09:27:57 | openstackgerrit | Lee Yarwood proposed openstack/nova master: db: Add attachment_id to block_device_mapping https://review.openstack.org/437597 | |
| 09:28:13 | alex_xu | gmann: done | |
| 09:28:26 | alex_xu | Qiming: i'm thinking whether all of those password are same thing | |
| 09:28:59 | Qiming | alex_xu, they are, IMO | |
| 09:29:02 | gmann | alex_xu: thanks | |
| 09:30:38 | gmann | alex_xu: Qiming admin one is different(updated using changePassword) and os-server-password is metadata one | |
| 09:31:51 | gmann | because delete call just remvoe from metadata which is encrypted one, it does not change in server | |
| 09:32:31 | Qiming | gmann, I'm no nova expert, should I care if the password is stored in metadata or somewhere else? | |
| 09:33:09 | Qiming | gmann, the doc tells me I can specify password for admin, I can change it, I can get it, and I can wipe it out | |
| 09:33:28 | alex_xu | I remember the admin one is for xen driver | |
| 09:34:48 | Qiming | gmann, the strange thing is that they are located in different locations, probably fine for command line tools, but not so good for SDK modeling | |
| 09:37:12 | lyarwood | mdbooth: morning, https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/cinder-new-attach-apis should be ready for reviews once you have time today, the focus is really on the db and object changes first if you wouldn't mind focusing on them. | |
| 09:38:16 | openstackgerrit | Thomas Bechtold proposed openstack/nova master: Log exception when hypervisor version check fails https://review.openstack.org/434927 | |
| 09:45:47 | dakhmetov | Greetings, guys! | |
| 09:45:57 | dakhmetov | Could you please review this patch: https://review.openstack.org/#/c/399679/ | |
| 09:50:47 | dakhmetov | I know a couple of people who are really affected by the inconsistency in instance's libvirt.xml. It will be great if you help me reviewing it. | |
| 09:54:06 | johnthetubaguy | dakhmetov: so I love half of your change, and worry about the other half | |
| 09:54:34 | johnthetubaguy | dakhmetov: using instance.user_id and instance.project_id totally makes sense, we should have done that for the beginning | |
| 09:55:06 | johnthetubaguy | username and projectname... thats feels wrong, what about we don't add that any more? | |
| 09:55:07 | dakhmetov | 2 johnthetubaguy please share your concern | |
| 09:55:16 | johnthetubaguy | I will add a note on the patch | |
| 09:55:23 | gmann | Qiming: admin pass can be injected while creating server and change password using action API is for xen and libvirt as alex_xu mentioned | |
| 09:55:48 | johnthetubaguy | dakhmetov: a related comment came up on friday at a HPC meetup I went to, so agreed it needs fixing | |
| 09:55:55 | openstackgerrit | Michael Henkel proposed openstack/nova master: Implements: blueprint opencontrail-dpdk-support https://review.openstack.org/441183 | |
| 09:56:39 | gmann | @Qiming not sure about exact SDK requirement on that and if any issue on nova side? | |
| 09:58:48 | johnthetubaguy | dakhmetov: I am worried about how usernames and project names change over time in keystone, but we keep those names just matching what they were went the instance booted | |
| 09:58:58 | johnthetubaguy | dakhmetov: maybe thats OK for your use case I guess? | |
| 10:00:22 | dakhmetov | 2 johnthetubaguy: yes, I also thought about it. The only option to avoid this issue is open Keystone session there each time | |
| 10:01:48 | johnthetubaguy | dakhmetov: my idea was to only have the ids in there, from the instance object, and leave the others blank for now? | |
| 10:02:31 | johnthetubaguy | that would ensure they are "correct" in some sense, but I feel bad breaking the folks that want the names there | |
| 10:04:59 | dakhmetov | johnthetubaguy: sure, there are a lot of folks who needs names there, as it described in nova xmlns 1.0 | |
| 10:07:53 | dakhmetov | so, what we have in current patch seems to be best solution, despite the fact that the stored user and project names can change | |
| 10:08:01 | mdbooth | dakhmetov: I've reviewed a change related to this recently. Do you have a link? | |
| 10:08:49 | dakhmetov | mdbooth: exactly! https://review.openstack.org/#/c/399679 | |
| 10:09:09 | mdbooth | Ah, ok. You fishing for a second +2? | |
| 10:09:33 | dakhmetov | mdbooth: yes, a kind of :) | |
| 10:11:12 | mdbooth | johnthetubaguy: My take on this is that we break things by rebuilding the libvirt xml. We shouldn't be doing that, and this is a necessary workaround. | |
| 10:11:45 | mdbooth | i.e. the conversation isn't so much about what these values mean, whether they're correct, or what they really should be | |
| 10:11:52 | mdbooth | But more: are they the same as before | |
| 10:12:22 | mdbooth | The other conversation is also interesting, though. | |
| 10:12:29 | johnthetubaguy | mdbooth: my worry is the bug that says I updated the project or user name in keystone, and now my lib virt xml is out of sync, for me its either we don't include the names or we do what dakhmetov has proposed | |
| 10:13:16 | johnthetubaguy | totally agreed grabbing it from the context was exactly the wrong thing to do | |
| 10:14:17 | johnthetubaguy | I was meaning the bug that is raised next time, after we fix this bit | |
| 10:14:29 | mdbooth | Ah, ok. | |
| 10:14:38 | mdbooth | So, that bug was always present | |
| 10:15:02 | johnthetubaguy | yep | |
| 10:15:04 | mdbooth | This information is static, so storing dynamic information there is suspect at best. | |
| 10:15:18 | johnthetubaguy | yeah, thats my take | |
| 10:15:33 | mdbooth | And I agree, and probably that we should remove username and projectname | |
| 10:15:47 | mdbooth | However, that's tangential to this bug, which is that we break our existing contract | |
| 10:15:57 | johnthetubaguy | cool, I was wondering if I was going down a crazy thought path | |
| 10:17:11 | mdbooth | dakhmetov: Incidentally, if you're close to users who are actually relying on this, I'd be interested to know what your take is on how to fix the changing username issue. | |
| 10:17:38 | johnthetubaguy | +1 thats what I was fishing for really | |
| 10:18:40 | mdbooth | dakhmetov: Is the issue that people have scripted this, and scripts will require updating? | |
| 10:19:10 | johnthetubaguy | FWIW, this change breaks those folks too | |
| 10:19:28 | mdbooth | johnthetubaguy: Really? I missed that. | |
| 10:19:43 | johnthetubaguy | all existing instance, once modified will now have no username or projectname, we are missing a unit test for that | |
| 10:20:42 | mdbooth | johnthetubaguy: Ah, yes. It's a fix only for future instances, I'd glossed over that. | |
| 10:21:07 | mdbooth | We could save the info before deleting it... | |
| 10:21:28 | mdbooth | Meh, lets get this done before gold plating it. | |
| 10:25:14 | johnthetubaguy | dakhmetov: I updated my comments to try summarise what I am thinking now, basically I would split this into two patches, and the second patch needs an extra unit test. | |
| 10:25:16 | mdbooth | dakhmetov: Can you quickly write the test case johnthetubaguy has asked for? Should be simple enough and probably just works, but we should definitely be testing that. | |
| 10:32:39 | alex_xu | Qiming: gmann, yea, i mean it even worse, they have similar name, but doing different thing | |
| 10:40:19 | dakhmetov | mdbooth: johnthetubaguy: reading your comments | |
| 10:41:35 | dakhmetov | as workaround for outdated names in instance's system_metadata: names can be updated in mysql | |
| 10:42:28 | dakhmetov | it's dirty hack, but anyway solves the possible issue | |
| 10:44:03 | mdbooth | dakhmetov: I think the safer option is to test that having nothing there at least doesn't break existing instances. That means that we're not regressing. Saving the info before rewriting the xml is better, but also a game of whack-a-mole, so best be safe first I think. | |
| 10:49:48 | kashyap | lyarwood: Isn't melwitt right here -- https://review.openstack.org/#/c/441204/5/nova/tests/unit/virt/libvirt/test_guest.py | |
| 10:50:01 | dakhmetov | mdbooth: So, what I need is to handle the situation with missing owner_user_name and owner_project_name in instance's metadata, as well as add test for this. Right? | |
| 10:50:05 | kashyap | Specifically her question about 'live=False' | |
| 10:50:36 | johnthetubaguy | dakhmetov: as long as we test for that, thats my main worry out the way | |
| 10:50:47 | mdbooth | dakhmetov: I suspect it already handles that, but we should definitely test as johnthetubaguy says. | |
| 10:50:56 | mdbooth | If it doesn't work, that would be a regression. | |
| 10:52:12 | johnthetubaguy | dakhmetov: yeah, I think the get() is OK, but deep down, I would rather we didn't populate the names at all myself, hence me being tempted to do this as two patches, one that just gets user_id and project_id from the instance, sets the others to None, then a second patch that adds in your cache of the names. | |
| 10:54:05 | mdbooth | johnthetubaguy: How about resolving username and projectname from keystone at the time we rewrite the metadata? | |
| 10:54:15 | mdbooth | Rather than storing it in system meta | |
| 10:54:18 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read NIC features in libvirt https://review.openstack.org/444415 | |
| 10:54:24 | mdbooth | Would that be so bad? | |
| 10:56:02 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Reserve NUMA nodes with PCI devices attached https://review.openstack.org/364468 | |
| 10:57:16 | dakhmetov | mdbooth: if we open Keystone session to resolve ids to names in libvirtxmdriver with token from request context, it may not have permissions to resolve names in keystone | |
| 10:57:46 | dakhmetov | we may not have permissions to resolve IDs to names in keystone even if we always open admin session | |
| 10:57:52 | dakhmetov | it's how I see it | |