| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 17:24:18 | openstackgerrit | Mario Villaplana proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487 | |
| 17:38:48 | cdent | sdague: hiccup on mod_proxy_uwsgi: we need this version https://uwsgi-docs.readthedocs.io/en/latest/Changelog-2.0.13.html to get unix socket support, xenial is 2.0.12 | |
| 17:39:12 | cdent | do we have a usual solution to such issues? | |
| 17:41:44 | clarkb | cdent: you can ask ubuntu to backport, but generally if its not a bug I don't think they do. The other option is to get it into cloud archive (and then use cloud archive). Or maybe just use tcp? | |
| 17:42:17 | cdent | clarkb: not using tcp is a design goal | |
| 17:42:28 | cdent | clarkb: https://etherpad.openstack.org/p/devstack-uwsgi | |
| 17:42:51 | openstackgerrit | Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710 | |
| 17:43:08 | clarkb | cdent: to avoid the port allcoation madness? | |
| 17:43:15 | cdent | in part yeah | |
| 17:43:34 | clarkb | another option may be to use not apache if another tls terminator has better uwsgi support? | |
| 17:44:26 | cdent | clarkb: yeah, nginx was the original plan, but we're doing discovery on apache options to see about limit the surface of the change | |
| 17:55:25 | sdague | cdent: we have a certain amount of flexibility in making it a reasonable dev environment, even if it means more change. I'm totally find with the nginx cut over at the same time | |
| 17:58:07 | clarkb | can I selfishly ask that https://bugs.launchpad.net/nova/+bug/1676363 and its associated changes get reviews/input/etc? This is the sort of issue in the pike release that will break us (us being infra) when the noav change that precipitated this hits clouds | |
| 17:58:07 | openstack | Launchpad bug 1676363 in OpenStack Compute (nova) "The network metadata should be more useful" [Medium,In progress] - Assigned to Dr. Jens Rosenboom (j-rosenboom-j) | |
| 18:05:56 | jaypipes | clarkb: looking now. | |
| 18:16:13 | cdent | sdague: added some notes on the hackarounds I did to get mox_proxy_uwsgi working, going to switch to some other things for a while: https://etherpad.openstack.org/p/devstack-uwsgi | |
| 18:18:28 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.volume_attach.error notification https://review.openstack.org/455801 | |
| 18:29:04 | prabhuraj | Hi all, Warm Greetings, someone could review my code https://review.openstack.org/#/c/397471/ | |
| 18:29:14 | prabhuraj | https://review.openstack.org/#/c/397459/ | |
| 18:29:34 | mriedem | prabhuraj: wrong channel? | |
| 18:29:36 | mriedem | those are fuel patches | |
| 18:29:37 | mriedem | this is nova | |
| 18:34:18 | clarkb | jaypipes: tldr on glean was cloud init couldn't configure rax interfaces and monty went off and made a thing that could. But also cloud init has historically made some very bad choices for us so I think mordred was just looking for an excuse at that point. (distro specific users, mounting volumes in places where we did not wnat them mounted are the two big ones that I recall) | |
| 18:34:56 | jaypipes | clarkb: hey, cool by me. I wasn't complaining about NIH or anything. was genuinely learning about a new thing :) | |
| 18:35:08 | clarkb | ya, just thought I'd explain after seeing your comment :) | |
| 18:35:54 | clarkb | jaypipes: there are days I am grumpy about it (especially when something breaks due to sillyness in glean) but then there are times when we don't break due to something cloud init would have done when I am happy | |
| 18:35:56 | clarkb | :) | |
| 18:36:17 | jaypipes | no worries clarkb :) | |
| 18:36:33 | clarkb | but its become quite common with ironic uses I guess because it groks vlans and stuff | |
| 18:36:57 | jaypipes | clarkb: doesn't cloud-init grok vlans as well? I think it does... | |
| 18:37:21 | clarkb | I think it didn't for a long time? | |
| 18:38:01 | jaypipes | clarkb: ok, done with reviews on that series. | |
| 18:38:15 | jaypipes | clarkb: only thing I'd like to see is prefixlen be an int not a string. | |
| 18:38:16 | clarkb | this is mostly second hand I don't actually do ironic things. VLANs and link aggregation were the two big features they like | |
| 18:38:22 | jaypipes | clarkb: otherwise, looks fine to me. | |
| 18:38:27 | clarkb | jaypipes: awesome thank you for taking a look | |
| 18:38:30 | jaypipes | any time. | |
| 18:39:39 | jaypipes | clarkb: link agg: https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py#n590 and vlans: https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py#n614 :) | |
| 18:44:40 | mordred | jaypipes: yah -so - when we started in on glean, cloud-init was on a very explicit freeze not accepting new things becaue they were working on a v2 | |
| 18:44:53 | mordred | jaypipes: which meant adding support for the network_info.json stuff was a no-go | |
| 18:45:03 | mordred | they have since unfrozen, which is great for everyone | |
| 18:45:09 | jaypipes | cool beans. | |
| 18:45:54 | mordred | so at this point the main difference is size - glean assumes the only thing you want it to do is get networking set up and inject ssh keys - and that you NEVER want to talk to non-config-drive metadata service | |
| 18:46:12 | mordred | cloud-init is much more flexible and lets you inject arbitrary scripts | |
| 18:46:20 | mordred | which some people think is cool | |
| 18:47:05 | mordred | and I support them in that - I, for myself, _never_ want to run scripts via cloud-init because I can run scripts over ssh much more easily and more debuggably :) | |
| 18:47:07 | dansmith | mordred: orly, glean is configdrive-only? | |
| 18:47:15 | mordred | dansmith: yup | |
| 18:47:18 | dansmith | interesting | |
| 18:47:34 | mordred | we have had nothing but terrible experiences with the ec2-style metadata service | |
| 18:47:42 | mordred | crashing clouds and instances not booting and instances timing out and whatnot | |
| 18:47:50 | mordred | so we avoid it like the plague | |
| 18:48:12 | mordred | config-drive is teh ossum | |
| 18:48:30 | dansmith | mordred: yeah, especially when you have puppet running every 15 minutes on every instance against central metadata services | |
| 18:48:44 | mordred | dansmith: yup | |
| 18:49:07 | dansmith | and when I say every fifteen minutes I mean "for 14 minutes total until smoke" | |
| 18:49:47 | mordred | dansmith: since cloud-init does support config-drive, i'd LOVE it if nova just defaulted config-drive to on, removed the option to turn it off, and then removed the ec2 metadata service | |
| 18:50:07 | dansmith | yeah, the only problem is the staticness of it | |
| 18:50:12 | mordred | dansmith: but I suppose that's at odds with my stance about not changing things, so maybe I'm a hypocrit :) | |
| 18:50:16 | dansmith | i.e. volume attach and nic attach | |
| 18:50:40 | mordred | right- so ... | |
| 18:50:55 | jaypipes | lmao | |
| 18:51:21 | mordred | network attach should just work, since clouds should just be offering dhcp, which means there is no need for config-drive to be updated (unless the cloud is broken) | |
| 18:51:36 | dansmith | mordred: unless you want/need metadata about that nic | |
| 18:52:06 | mordred | but if you're adding a NIC after boot, you're adding the nic, so you as the orchestrator likely already know you're doing it and should be able to direct the instance to do something different,no? | |
| 18:52:37 | dansmith | unless you have an agent that looks for nics with tags of "multipath-to-db" and enslaves them into a bond, | |
| 18:52:40 | mordred | I mean, the only reason we need config-drive for network info anyway is for clouds without dhcp - for the rest I recommend using your orchestration tool to talk to the nova api | |
| 18:52:50 | dansmith | not necessarily | |
| 18:52:53 | jaypipes | mordred: right, unless you're a VNFM or MANO system that is dynamically swapping metadata about your workload's vNICs at runtime and having the workload reconfigure service function chains. | |
| 18:53:07 | dansmith | that ^ | |
| 18:53:50 | mordred | I'm still not sure why that isn't just an API call on the service API - which would of course be hard because we haven't bothered with per-instance credentials :) | |
| 18:53:50 | dansmith | jaypipes: it does kinda sound like a chemical | |
| 18:54:24 | jaypipes | mordred: bingo. | |
| 18:54:29 | mordred | but ec2 metadata services is a poor workaround for having an agent in an instance just make API calls to the control plane in a sane fashion | |
| 18:54:46 | jaypipes | mordred: also correct. | |
| 18:55:30 | dansmith | so you want the instance to hit the api, find out the ports that are on the instance, and corellate them all by mac address to know what to do with which actual device in the OS? | |
| 18:55:56 | mordred | dansmith: well, the list ports call also lists the mac addresses of the ports | |
| 18:56:02 | mordred | but yah - I do that for every instance we spin up in nodepool | |
| 18:56:16 | mordred | because I have to to figure out if the instance needs a floating ip or not | |
| 18:56:42 | mordred | so sure! | |
| 18:57:13 | dansmith | that works if you've got creds in the instance | |
| 18:57:29 | mordred | we could also just have an API call that gives a rollup report similar to what's in the metadata service - I'm just saying it doesn't need to be a special network port that's only usable to talk to the special service that doesn't scale | |
| 18:57:37 | mordred | and instead we should focus on getting creds into the instance | |
| 18:57:47 | mordred | which would make many people happy | |
| 18:58:29 | dansmith | well, I dunno, given where we are, tags on the devices we add seems like a reasonable thing to me | |
| 18:58:42 | dansmith | especially given that there are some devices for which there is no service to talk to | |
| 18:58:46 | dansmith | like a raw pci device | |
| 18:59:15 | mordred | wouldn't that raw pci device be there at boot? or be a thing you added to the vm via nova? | |
| 18:59:16 | dansmith | if cinder gives us the serial number of the block device that we're going to add or something, then I guess we can do the same for cinder, | |
| 18:59:22 | dansmith | but otherwise that's a problem | |
| 18:59:43 | mordred | I mean - I hear you | |
| 18:59:45 | dansmith | mordred: what does it matter if it was there at boot? | |
| 19:00:04 | mordred | if it's there at boot, it can have data in config-drive without any issues | |
| 19:00:23 | mordred | the static nature of config-drive and dynamic devices was the issue | |
| 19:00:34 | dansmith | sure, I thought we were talking about not needing metadata at al | |
| 19:00:38 | mordred | oh golly no | |
| 19:00:41 | mordred | metadata is great | |
| 19:00:43 | dansmith | cinder doesn't show me a device serial number or aything, | |
| 19:00:51 | dansmith | so not sure that I can do the same correlation inside the guest for it | |
| 19:00:57 | mordred | well, mounting volumes is hard no matter what | |