| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-23 | |||
| 09:54:14 | openstackgerrit | Felipe Alfaro Solana proposed openstack/nova-specs master: Implements: blueprint nova-lxd-profiles https://review.openstack.org/467104 | |
| 09:57:14 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for os-migrations endpoint instead of stevedore https://review.openstack.org/461628 | |
| 09:59:50 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for os-migrations endpoint instead of stevedore https://review.openstack.org/461628 | |
| 10:02:09 | openstackgerrit | jichenjc proposed openstack/nova master: Use plain routes list for os-services endpoint instead of stevedore https://review.openstack.org/460818 | |
| 10:09:48 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081 | |
| 10:18:30 | openstackgerrit | Vu Cong Tuan proposed openstack/nova master: Repair links in Nova documentation https://review.openstack.org/467114 | |
| 11:15:36 | artom | o_O | |
| 11:16:05 | artom | https://review.openstack.org/#/c/400763/3 merged without unit tests | |
| 11:16:30 | artom | Is that legit? We're allowed to do that? I'd have though making sure the exception is caught would be a good test | |
| 11:32:54 | sfinucan | artom: Hmm, yeah. It should have tests, yes | |
| 11:47:48 | sfinucan | sdague: If I want to check out a particular commit of nova and run it with Devstack, I simply check it out and reboot all nova services with 'systemctl restart devstack@n-*', right? | |
| 11:48:10 | sfinucan | (First time tinkering with it since the systemd changes went in) | |
| 11:48:21 | sdague | yep | |
| 11:50:08 | sfinucan | cool | |
| 12:16:46 | openstackgerrit | Feodor Tersin proposed openstack/nova master: Implement ScaleIO image backend https://review.openstack.org/407440 | |
| 12:17:06 | ftersin | mdbooth: hi. did you have a chance to look at ^^^^ ? | |
| 12:18:25 | mdbooth | ftersin: Only very briefly, I'm afraid. I'm stuck on downstream work right now. It's top of my review list, though. | |
| 12:22:46 | ftersin | mdbooth: ok, i understand. Probably you might review it by part. E.g. driver.py at the first, or whatever you assume is the most 'suspicious' and requires attention | |
| 12:23:14 | mdbooth | ftersin: That is indeed where I started :) | |
| 12:23:54 | ftersin | mdbooth: to let us an opportunity to discuss and to rework complex things not being in rush | |
| 12:24:06 | ftersin | cool | |
| 12:24:07 | mdbooth | Incidentally, if the driver could be confined to imagebackend.py I'd be in favour pretty much on your word that it works. | |
| 12:24:21 | mdbooth | IIRC it's a bit differenty in a couple of places, though. | |
| 12:25:22 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/467170 | |
| 12:29:18 | ftersin | mdbooth: i think there are 3 kings of changes in driver.py. the 1st is trivial, i.e. the adding 'sio' into some places where 'rbd', 'lvm', etc already exist | |
| 12:30:07 | ftersin | the 2nd is intended to map/unmap feature. it cannot be removed but might be reworked | |
| 12:30:58 | ftersin | the 3rd one are some side changes, which might be separated into different patches or patch series | |
| 12:31:21 | openstackgerrit | Felipe Alfaro Solana proposed openstack/nova-specs master: Implements: blueprint nova-lxd-profiles https://review.openstack.org/467104 | |
| 12:31:26 | mdbooth | ftersin: Are the side changes generally applicable, or specific to this driver? | |
| 12:33:43 | ftersin | both. e.g. the fix of swap device is generally applicable, but the filtering of disk_info items (to prevent use them as files) is required for SIO driver | |
| 12:34:07 | ftersin | however it is required for Cinder driver as well | |
| 12:34:20 | ftersin | it or some other solution of the problem | |
| 12:35:18 | mdbooth | ftersin: If you have time, I'd appreciate splitting them out, I think. I'll review without, though. | |
| 12:35:43 | openstackgerrit | Eric Berglund proposed openstack/nova master: Add strict option to discover_hosts https://review.openstack.org/467218 | |
| 12:38:21 | ftersin | mdbooth: i proposed a series, which resolve that problem separately: https://review.openstack.org/#/q/topic:disk_info_processing | |
| 12:50:47 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Exclude deleted service records when calling hyervisor statistics https://review.openstack.org/467220 | |
| 12:56:39 | openstackgerrit | Eric Berglund proposed openstack/nova master: Add strict option to discover_hosts https://review.openstack.org/467218 | |
| 13:00:26 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 13:11:44 | mriedem | ahoy matey | |
| 13:11:49 | mriedem | (s) | |
| 13:11:57 | cdent | is it talk like a pirate day again? | |
| 13:12:12 | asettle | Yar | |
| 13:12:15 | asettle | it is | |
| 13:12:45 | cdent | since I'm in cornwall, I claim authenticity | |
| 13:13:08 | asettle | Please, please tell me you're in Penzance | |
| 13:15:57 | mriedem | dansmith: when you're decent i have some questions about your bottom cells change for target_cell | |
| 13:19:01 | cdent | asettle: sadly right this moment I am in Truro | |
| 13:19:54 | asettle | Truro is nice! | |
| 13:20:02 | asettle | But not Penzance | |
| 13:30:41 | dansmith | mriedem: in the review or you want to ask them here? | |
| 13:31:12 | pabelanger | morning! | |
| 13:31:24 | mriedem | dansmith: either | |
| 13:31:24 | dansmith | mriedem: I still need to follow up with a few more of your earlier comments I think, but removing the object targeting seems to not break anything | |
| 13:31:35 | mriedem | i just went through PS13 | |
| 13:31:39 | dansmith | mriedem: okay well I'm yet to be caffeinated so give me a few | |
| 13:31:45 | mriedem | ok | |
| 13:32:33 | pabelanger | Q: Why is there no PUT /os-keypairs functionality? We have a use case in openstack-infra where we want to update an existing key (to rotate public_keys) but we have to delete / create to achieve this | |
| 13:33:50 | pabelanger | Specifically, this would be for nodepool | |
| 13:34:03 | dansmith | pabelanger: I imagine it comes from not confusing the user about why they PUT a new keypair and can't suddenly use it to log into all the instances they've booted with that keypair | |
| 13:34:12 | dansmith | several other cloud-like platforms I know of have the same rule | |
| 13:38:10 | pabelanger | dansmith: I can understand that, but POST / PUT seem to be well documented on there behaviours. And other resources in nove do support PUT actions /servers and /quotas come to mind | |
| 13:38:27 | dansmith | but not flavors for the same reason | |
| 13:38:49 | dansmith | servers and quotas update doesn't affect something else, right? | |
| 13:39:02 | dansmith | like if I'm allowed to make a change to a server, I'm not affecting another server elsewhere | |
| 13:39:38 | pabelanger | sure, but the same could be said about an SSH key, if only used for a single server | |
| 13:39:38 | dansmith | one server does not reference another, nor does quota have such a link | |
| 13:40:12 | dansmith | but if you have it for one server and you change that key, it no longer matches what is in the server | |
| 13:40:27 | mriedem | ^ is definitely like flavors, | |
| 13:40:36 | mriedem | and we store the keypair in the instance in the db like flavors | |
| 13:41:05 | dansmith | yup | |
| 13:41:39 | pabelanger | The issue we are having is, if we need to rotate keys for nodepool (infra-root-keys in nova), we need to do a 2 step approach. This means, when we delete the key, nodepool starts failing to create new servers until we create infra-root-keys again. And since we do this via automation, it is difficult to do this process without causing an outage for nodepool | |
| 13:42:18 | mriedem | why not create the new key first and then delete the old key? | |
| 13:42:21 | mriedem | duplicates i guess | |
| 13:42:22 | mriedem | on the name | |
| 13:42:31 | dansmith | how can you use this for key rotation if it doesn't cause the existing servers to change the key they use? | |
| 13:42:45 | dansmith | mriedem: or just date your keys | |
| 13:42:55 | mriedem | i'm married | |
| 13:42:56 | dansmith | date *stamp* before you go there :) | |
| 13:42:58 | dansmith | dammit | |
| 13:44:49 | pabelanger | the SSH key, infra-root-keys is only used when (humans) need to log into a test node and debug it. We are okay with old nodes still using the first key, because up to 2 hours later the server is deleted. | |
| 13:46:18 | dansmith | okay so why not just create a new datestamped key? | |
| 13:47:03 | dansmith | pabelanger: anyway, you asked _why_ and I think that's why. I think it would be confusing to enable changing them at this point, but if you want to propose it we can discuss I suppose | |
| 13:47:19 | mriedem | i'm asking in ops too to see if users are asking for this | |
| 13:47:28 | mriedem | non-infra users let me say | |
| 13:47:31 | mriedem | infra are users too! | |
| 13:47:52 | pabelanger | So, to rotate this out today, we'd need to do the following: | |
| 13:48:06 | pabelanger | 1) update clouds_layout.yaml with new key: http://git.openstack.org/cgit/openstack-infra/system-config/tree/playbooks/clouds_layouts.yml#n35 | |
| 13:48:15 | pabelanger | land and merge (30mins) | |
| 13:48:21 | dansmith | mriedem: even if they are, we should decide whether we think it breaks our model or not | |
| 13:48:59 | mriedem | dansmith: sure, i'd just like to know if this is one of those things everyone has been secretly wanting forever and just no one asked | |
| 13:49:07 | pabelanger | 2) Replace infra-root-keys with new keyname in nodepool.yaml: http://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/nodepool.yaml (~78 entries) | |
| 13:49:07 | mriedem | like proxying volume type | |
| 13:49:09 | dansmith | mriedem: aye | |
| 13:49:21 | pabelanger | review and merge | |
| 13:49:23 | mriedem | dansmith: see my ML thread on volume type from late last night? | |
| 13:49:54 | dansmith | pabelanger: or build your system to list your keys and choose the one with the highest serial number at the point of each build right? | |
| 13:49:55 | dansmith | mriedem: no | |
| 13:50:40 | mriedem | it's a hoot and a half | |
| 13:50:42 | pabelanger | dansmith: sure, but as an operator I really only want 1 key at 1 time | |
| 13:51:21 | pabelanger | managing more then one is possible, but something not in our current workflows with other cloud settings. | |