| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-22 | |||
| 14:01:15 | mriedem | stephenfin: your gerrit emails go to your inbox? | |
| 14:01:21 | mriedem | that's your mistake | |
| 14:01:47 | mriedem | gotta setup a filter rule, especially for the CI emails | |
| 14:02:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix 500 if list servers called with empty regex pattern https://review.openstack.org/506585 | |
| 14:02:20 | openstackgerrit | Chris Dent proposed openstack/nova master: DNM: Don't monkey patch eventlet in functional tests https://review.openstack.org/506668 | |
| 14:05:07 | liuyulong | hi mriedem, https://review.openstack.org/#/c/375221/, I've updated the spec, could you please review it again? | |
| 14:05:39 | openstackgerrit | Merged openstack/os-traits master: Updated from global requirements https://review.openstack.org/503646 | |
| 14:07:08 | mriedem | liuyulong: Kevin_Zheng was going to update that spec since we thought it was abandoned, | |
| 14:07:13 | liuyulong | mriedem, there are some things that need to be clarified is that this spec can be under parallel development with Kenvin_zheng's os-keypair API. | |
| 14:07:19 | mriedem | liuyulong: we discussed this at the PTG last week, and want a different direction | |
| 14:07:27 | mriedem | right | |
| 14:07:49 | mriedem | we said we'd provide a way to update the keypair for a specific server, and then the user can reboot or rebuild the instance | |
| 14:08:00 | liuyulong | it's not the same. One adding API, one updating rebuild API. | |
| 14:08:01 | mriedem | because they might not need to rebuild the guest depending on how cloud-init is configured | |
| 14:08:10 | mriedem | the goal is the same | |
| 14:08:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Deprecate 'keymap' options https://review.openstack.org/483994 | |
| 14:10:24 | liuyulong | One API can done for updating keypair. But the new API may need two steps. It's waste. | |
| 14:10:55 | liuyulong | but the new API can be used for a running injection. | |
| 14:11:27 | liuyulong | So I'd like to say, both can be added to nova. | |
| 14:12:06 | mriedem | liuyulong: by that logic, why don't we also add keypair to the reboot API so you can specify a new keypair on reboot? | |
| 14:12:13 | mriedem | it starts to become a slippery slope | |
| 14:12:33 | liuyulong | New API can result an inconsistent situtation when the vm is not reboot. | |
| 14:12:48 | mriedem | does Kevin_Zheng have a spec up for review yet? | |
| 14:12:54 | liuyulong | yes | |
| 14:13:00 | mriedem | inconsistent how? | |
| 14:13:06 | liuyulong | https://review.openstack.org/#/c/506552 | |
| 14:13:17 | mriedem | yes the keypair is different, because the user changed it | |
| 14:13:28 | mriedem | and it's different from the guest until the guest is rebooted or rebuilt | |
| 14:14:11 | mriedem | mikal: cburgess: keypair update API spec https://review.openstack.org/#/c/506552 | |
| 14:14:13 | mriedem | since you wanted to review | |
| 14:14:49 | liuyulong | That makes could user confused. But rebuild API naturally with a restart. | |
| 14:17:11 | mriedem | well, we'd be documenting this API | |
| 14:17:23 | mriedem | if you update the keypair on the instance, you have to reboot or rebuild after that | |
| 14:17:26 | mriedem | for it to take effect | |
| 14:17:26 | liuyulong | IMHO, both specs are OK for now. One step for rebuild API make more reasonable. | |
| 14:17:46 | mriedem | sorry but we don't really need 3 ways to do this same thing | |
| 14:18:05 | leakypipes | mriedem: +3 | |
| 14:18:06 | mriedem | 3 = keypair update + user reboot/rebuild, keypair during rebuild, keypair during reboot | |
| 14:18:29 | mriedem | because then people will also say, "why can't i update the keypair when i unshelve my offloaded instance too?!" | |
| 14:18:38 | mriedem | or migrate it | |
| 14:20:56 | leakypipes | superdan: morning. | |
| 14:21:14 | superdan | leakypipes: I can confirm that it is indeed morning. | |
| 14:21:20 | liuyulong | reboot API can also update the keypair? | |
| 14:21:33 | leakypipes | superdan: has Jax attempted homocide yet? | |
| 14:22:01 | superdan | leakypipes: I think you mean homicide, and not yet this morning | |
| 14:22:33 | mriedem | ha | |
| 14:22:33 | superdan | but. it's early. | |
| 14:22:40 | leakypipes | superdan: ha, indeed. | |
| 14:22:46 | mriedem | liuyulong: no, but that's my point, | |
| 14:23:11 | mriedem | if we have one api to update the keypair just on the instance, and one api to rebuild with a new keypair, then people would also want the reboot api to take a keypair, and possibly other APIs, like migrate and unshelve | |
| 14:23:32 | mriedem | and we don't want an explosion of API changes to provide a new keypair for every operation | |
| 14:25:16 | finucannot | leakypipes: Finally settled on a Friday nick that doubles as a learning opportunity (how to pronounce my last name) | |
| 14:26:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: placement: add ProviderTree.is_inventory_empty https://review.openstack.org/480957 | |
| 14:26:07 | leakypipes | finucannot: well played, sir. | |
| 14:26:52 | Kevin_Zheng | https://blueprints.launchpad.net/nova/+spec/use-constrain-for-microversion-values does anyone find this useful? | |
| 14:27:08 | liuyulong | `rebuild` means recreate a instance, so for custom data, they should have ways to change it. Like name, adminPass, image etc. | |
| 14:27:33 | liuyulong | Its not a explosion. | |
| 14:27:44 | liuyulong | Just a expanding of rebuilding API | |
| 14:27:57 | mriedem | liuyulong: so do you think we should also allow passing in new volumes and ports when rebuilding an instance? | |
| 14:28:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Make 'get_domain' private https://review.openstack.org/417378 | |
| 14:29:29 | artom | finucannot, I guess apostrophes aren't allowed in IRC nicks, eh? | |
| 14:29:32 | finucannot | leakypipes, sahid: That patch has been open for a long time as is a pretty trivial TODO resolution. Could ye take a look at some point | |
| 14:29:43 | finucannot | artom: I didn't try, just in case :) | |
| 14:29:48 | artom | 'cuz finucan't keeps the same number of syllable | |
| 14:29:51 | artom | syllables | |
| 14:29:55 | leakypipes | finucannot: yuppers. just finishing up a review on ralonsoh__'s patch | |
| 14:30:03 | finucannot | leakypipes: (y) | |
| 14:30:31 | finucannot | artom: Hexchat rejects it anyway, so I assume not | |
| 14:30:38 | liuyulong | No. But it is a key data, if rebuilt instance or cloud-platform does not support password. Then the key pair is the only one way to login. | |
| 14:30:51 | artom | finucannot, yeah, I'm pretty sure it's not allowed | |
| 14:31:02 | ralonsoh__ | leakypipes: thanks for the review | |
| 14:31:03 | liuyulong | instance can be running without volume and port. | |
| 14:31:24 | mriedem | liuyulong: Kevin_Zheng's spec provides a way to update the keypair which would still be used when rebuilding | |
| 14:31:25 | liuyulong | but instance can be useless without a way to login. | |
| 14:31:33 | mriedem | and rebooting | |
| 14:31:35 | mriedem | and migrating | |
| 14:31:36 | mriedem | and unshelving | |
| 14:32:31 | Kevin_Zheng | Yeah, the new way will be more generic | |
| 14:32:34 | leakypipes | finucannot: k, on to your patch. swap with you... https://review.openstack.org/#/c/474892/ | |
| 14:32:37 | figleaf | superdan: working on your comments about the Selection object. | |
| 14:32:50 | bauzas | damn Friday gods | |
| 14:32:58 | leakypipes | ralonsoh__: no problemo :) | |
| 14:33:16 | figleaf | superdan: is there a general way of handling the "Cannot load 'node_name' in the base class" type of errors when not every value is passed at creation time? | |
| 14:33:24 | liuyulong | again, its totally two different ways. One API make sense while rebuild. That also make consistent with instance name, image, admin pass. | |
| 14:33:26 | finucannot | leakypipes: I feel this is an unworthy trade, but I like ralonsoh__ so deal ;) | |
| 14:33:52 | superdan | figleaf: everything should be passed at create time for this I would think | |
| 14:33:59 | leakypipes | finucannot: +2 from me on that | |
| 14:34:06 | ralonsoh__ | finucannot: me too hehehe | |
| 14:34:12 | leakypipes | now on to figleaf's patches... | |
| 14:34:28 | figleaf | leakypipes: be aware that I have updates to post soon | |
| 14:34:39 | figleaf | you might want to wait | |
| 14:35:16 | Kevin_Zheng | liuyulong: I think the Matts point is, we don't need two ways, if we open this door, people may ask to add it too to reboot API, etc | |
| 14:36:34 | liuyulong | If new API does not supporting running injection, the DB keypair and guest keypair are not consistent without a rebuiding, reboot, unshelving... This looks not good. | |
| 14:36:43 | leakypipes | figleaf: k. just reading superdan | |
| 14:36:49 | leakypipes | s review of the Selection patch now. | |
| 14:36:57 | leakypipes | figleaf: will hold off on commenting. | |
| 14:37:14 | liuyulong | Kevin_Zheng, no, I'll not agree that. If its not a `recreating` API. | |
| 14:37:43 | Kevin_Zheng | liuyulong: yeah, we will document it well | |
| 14:38:48 | liuyulong | Kevin_Zheng, document can not avoid that inconsistent. Cloud user may not remember what they have done, : ) | |
| 14:39:46 | liuyulong | So, again, IMHO, both specs are OK for now. One step for rebuild API make more reasonable. | |