| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-06 | |||
| 21:13:36 | sean-k-mooney | but i cant find it | |
| 21:14:00 | mriedem | ioni: nova isn't really big on containers, it's basically vms and a front end for ironic baremetal, | |
| 21:14:24 | mriedem | nova-lxd is a thing out of tree as you know, openvz is in who knows what kind of maintenance state, and then there is libvirt+lxc which is also - who really knows if it works very well right now | |
| 21:15:22 | mriedem | of course with cirros you can just login with a password | |
| 21:15:25 | efried | sean-k-mooney: presumably I could have done all that dhcp and security group nonsense before creating the vm | |
| 21:15:41 | sean-k-mooney | efried: yes and you only have to do it once | |
| 21:15:54 | sean-k-mooney | efried: also i normally do it all via horizon as its faster | |
| 21:15:54 | efried | k, writing myself a cheat sheet | |
| 21:16:10 | efried | ew, gui | |
| 21:16:21 | sean-k-mooney | the cli is faster for most things but security groups are a pain on the cli | |
| 21:16:46 | efried | cheat sheet line for that: | |
| 21:16:47 | efried | openstack security group list -f value -c ID | xargs -n1 openstack security group rule create --ingress --protocol tcp --remote-ip 0.0.0.0/0 | |
| 21:17:02 | sean-k-mooney | efried: anyway as i said once you have the command you need to run. just put them in a file called local.sh and it will be run at the right time | |
| 21:17:44 | sean-k-mooney | oh is in the default local.sh in samples/local.sh | |
| 21:17:53 | sean-k-mooney | just copy that up one directory | |
| 21:18:48 | efried | hm, I thought I did all the right things on my other setup, but I'm still getting no route to host. | |
| 21:18:55 | efried | aaand gotta run get a kid | |
| 21:21:26 | melwitt | ioni: I see mention of openvz in the original proposal for the magnum project https://specs.openstack.org/openstack/magnum-specs/specs/pre-ocata/implemented/containers-service.html but I don't know if it supports it today | |
| 21:23:28 | sean-k-mooney | melwitt: ioni magnum is a different usage model | |
| 21:23:45 | sean-k-mooney | nova libvirt/lxc woudl be the closest | |
| 21:24:02 | melwitt | oh ok | |
| 21:24:10 | ioni | i just want to stop using openvz and migrate the current containers to something orchestrated by openstack with good support | |
| 21:24:28 | ioni | nova-lxd was something i could use but that was dropped recently by canonical | |
| 21:24:46 | sean-k-mooney | ioni: well there isnt really a good path forward if you also want the nova api | |
| 21:25:04 | sean-k-mooney | zun will work with docker style container but not system contianers | |
| 21:25:09 | sean-k-mooney | as far as i know | |
| 21:25:21 | ioni | right, that is want i found as well | |
| 21:25:32 | sean-k-mooney | nova libvirt wiht lxc could work but it does not have good support a the momemnt | |
| 21:25:51 | sean-k-mooney | if there was a lot of interest in it it would not take that much to get it working well again | |
| 21:26:26 | ioni | everybody told me that lxc support is not that great and was too scared to try it | |
| 21:26:48 | sean-k-mooney | its not but its not that far form being ok | |
| 21:27:31 | sean-k-mooney | the openvz driver is proably the best supproted fo all the nova conatiner drivers at the moment | |
| 21:27:43 | sean-k-mooney | it has not reaaly been a focus of nova of late | |
| 21:29:17 | openstackgerrit | Merged openstack/python-novaclient master: doc: Fix supported version descriptions https://review.opendev.org/693097 | |
| 21:29:29 | mriedem | i'm guessing the openvz 3rd party ci is still busted | |
| 21:30:33 | sean-k-mooney | was that the ci that had a hardcoded patch that is now in conclict because we fixed the bug | |
| 21:30:43 | mriedem | yes | |
| 21:31:17 | mriedem | looks like it doesn't even report anymore | |
| 21:31:26 | sean-k-mooney | ya i was just going to say that | |
| 21:31:32 | sean-k-mooney | i have not seen it in a while | |
| 21:31:43 | ioni | sean-k-mooney, alright thanks. i'll take a look at openvz 7 and nova | |
| 21:32:18 | sean-k-mooney | ioni: if you need contianer i would not bet on that long term | |
| 21:33:42 | ioni | sean-k-mooney, indeed, i mostly think that i'll do a container to full kvm migration, but that really sucks | |
| 21:34:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use ListOfUUIDField from oslo.versionedobjects https://review.opendev.org/693258 | |
| 21:34:49 | sean-k-mooney | if you are interested in system contaienr there are afew other like donnyd who also share that interest | |
| 21:35:47 | sean-k-mooney | so we could try and fix/test libvit lxc upstream but its currntly on lifesupprot/hobbyist support | |
| 21:36:20 | sean-k-mooney | kvm will have less desitiny but its deffently the best tested solution | |
| 21:37:41 | sean-k-mooney | night all o/ | |
| 21:37:50 | ioni | thanks for your feedback sean-k-mooney | |
| 22:01:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove unused 'nova-dsvm-base' job https://review.opendev.org/688389 | |
| 22:03:34 | kisahm | HI together, i have the problem, that 'openstack availability zone list' receives no output. the error message is ConnectFailure: Unable to establish connection to https://nova-url:8774/v2.1/os-availability-zone/detail: ('Connection aborted.', BadStatusLine('No status line received - the server has closed the connection',)) | |
| 22:03:55 | kisahm | nova api/placement shows no errors. | |
| 22:04:13 | kisahm | the request timed out after 90 sec | |
| 22:05:19 | kisahm | openstack queens release, deployed with Juju | |
| 22:07:41 | mriedem | melwitt: dansmith: this isn't bad, but i'm not sure i want to pull the trigger on it - see if you have opinions https://review.opendev.org/#/c/688122/ | |
| 22:07:51 | mriedem | i like the idea of not hitting the synchronized stuff if we have the entry in the cache | |
| 22:10:22 | melwitt | I'm pretty sure Kevin_Zheng proposed the same thing in the past in a simpler way and got nacked. lemme see if I can find | |
| 22:12:11 | kisahm | the nova-api-os-compute.log shows this error: Timed out waiting for response from cell 79275f0e-86b1-4859-aeac-642382585ef4: CellTimeout: Timeout waiting for response from cell | |
| 22:12:57 | mriedem | kisahm: known http://status.openstack.org/elastic-recheck/#1844929 | |
| 22:13:13 | melwitt | mriedem: ^ https://review.opendev.org/#/c/595530/2/nova/context.py | |
| 22:16:00 | mriedem | uh oh, do i see dansmith talking about eventlet + locks in there?! | |
| 22:16:11 | mriedem | dropping that on booth might start a war | |
| 22:16:56 | melwitt | hah | |
| 22:27:28 | kisahm | mriedem does the bug also exists in openstack releases >queens? | |
| 22:28:26 | mriedem | kisahm: logstash says it started in the upstream gate in train, but mostly master jobs | |
| 22:30:20 | mriedem | do people see any issue with this? https://review.opendev.org/#/c/540962/ - if not i'll rev it to add the short release note | |
| 22:30:42 | mriedem | tl;dr allow CONF.enable_new_services to be configured per-host rather than globally | |
| 22:30:52 | mriedem | so you can start some computes as disabled to start but not others | |
| 22:33:16 | efried | mriedem: so previously you would put that in your conductor conf and it would disable all computes? | |
| 22:33:26 | mriedem | yup | |
| 22:33:32 | mriedem | well, newly created computes | |
| 22:34:57 | efried | right | |
| 22:34:59 | efried | hm | |
| 22:35:19 | efried | it's a pretty serious semantic change, really. | |
| 22:36:09 | mriedem | as in, if you used different configs for your controllers and computes, and you had this set in your controllers but not computes, you might now have new enabled comptues where you'd expect them to be disabled b/c you didn't move the config? | |
| 22:36:49 | efried | let me make sure I'm understanding: you would have the option set to False in your compute-side conf, and when you bootstrap your compute, it'll start out disabled; but once you re-enable it, it will stay enabled from that point on -- like, the conf opt will not have an effect on subsequent starts of the service | |
| 22:37:05 | mriedem | it would be ignored if set in compute conf | |
| 22:37:07 | mriedem | as the bug notes | |
| 22:37:16 | efried | I mean in the new world | |
| 22:37:28 | melwitt | yeah, I was thinking similar. I thought usually that sort of thing would have hit the ML. I can't think of any issue with it other than possible confusion, which the release note would address | |
| 22:37:29 | mriedem | correct | |
| 22:37:35 | mriedem | it's only when starting a new service and the record is created | |
| 22:38:04 | efried | different levels of conductor and compute are supported though, right? | |
| 22:38:10 | melwitt | I'd want to ask dansmith if there's any upgrade concerns I'm missing | |
| 22:38:12 | efried | which one upgrades first? | |
| 22:38:15 | mriedem | the whole point is, i want to deploy some new computes but not make them scheduable until i can kick their tires | |
| 22:38:17 | mriedem | then add them to the pool | |
| 22:38:48 | mriedem | efried: doesn't really have anything to do with rpc upgrade levels if that's what you mean | |
| 22:39:09 | efried | no, I mean train conductor, ussuri compute. If the option is set differently, what happens? | |
| 22:39:11 | mriedem | for an upgrade, if you care about this, you'd probably leave it to False in conductor until you upgrade all computes to the new code, then you can remove it from conductor config | |
| 22:39:22 | mriedem | train conductor ussuri compute isn't really a thing | |
| 22:39:42 | efried | okay, vice versa. | |
| 22:39:50 | mriedem | if you had that for some reason, obviously the train conductor code would override | |
| 22:39:58 | efried | "if you care about this" and you remembered that you set it years ago in your conductor conf | |
| 22:40:29 | efried | Have we considered instead creating a *new* opt that's compute-only? Because then I could have the conductor "default" and the per-compute "override". | |
| 22:40:31 | mriedem | once everything is upgraded, having it set in your conductor conf would be a noop | |
| 22:40:37 | efried | yeah, I get that. | |
| 22:40:55 | mriedem | i mentioned moving the option to the [compute] group in a follow up | |
| 22:41:22 | mriedem | i didn't think about 2 options | |
| 22:42:32 | mriedem | i also don't know how much this is even used, so i don't know that we should boil the ocean over it | |