| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-29 | |||
| 13:21:57 | sean-k-mooney | loci does not use layers kolla does so when you pull down all the contaier to disk the kolla ones are much smaller then if you jsut add up the totoal isze of the images listed on docker hub | |
| 13:22:30 | jaypipes | ah, good point sean-k-mooney | |
| 13:23:13 | sean-k-mooney | haha i just looked up the loci bas image which is based on centos and its alos 73MB becase centos | |
| 13:24:58 | cdent | to me, the fundamental issue with the containers being created is that they are not single processes dummies pushing logs to stderr. they are doing all sorts of stuff | |
| 13:25:25 | sean-k-mooney | cdent: most of them are | |
| 13:26:02 | sean-k-mooney | cdent: infact the only kolla one i know of that is not is one i wrote whtat was ment to be tempory | |
| 13:26:28 | sean-k-mooney | kolla even runs ovs in 2 containers 1 for the ovs-db and a second for the ovs-vswithd | |
| 13:26:58 | cdent | last I checked the service containers run apache2 and then mod_wsgi and then the service | |
| 13:27:15 | cdent | far better to have an external ingress thing which proxies to a single process in the container | |
| 13:27:37 | sean-k-mooney | ah well yes | |
| 13:28:02 | sean-k-mooney | you litrally ment singel procress rather then i start a singel proces which may spawn others | |
| 13:28:09 | cdent | i did, yes | |
| 13:28:46 | sean-k-mooney | well they said they were open to uwsgi in stead of apachy and they already use haproxy so that would give you the same effect | |
| 13:34:59 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: WIP: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 13:34:59 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add DownCellFixture https://review.openstack.org/614810 | |
| 13:35:53 | cdent | sean-k-mooney: If I had clones, I'd help | |
| 13:36:19 | sean-k-mooney | loci has come a long way sicne i last looked at it | |
| 13:37:15 | sean-k-mooney | its funny we had a patch that would transfrom the kolla docker files and build them in a way very similar to how loci is building things but it did not get merged in the end | |
| 13:43:36 | efried | jaypipes: Would you please hit https://review.openstack.org/#/c/615646/ quick so I can rework the whole series at once? | |
| 13:44:44 | jaypipes | efried: yessir, on it. | |
| 13:44:48 | efried | thank you sir. | |
| 13:45:09 | jaypipes | efried: I'd reviewed it already but not left a vote since I wanted to see how all the upper patches worked. | |
| 13:45:37 | efried | jaypipes: Cool. It's really much more related to the one below it (linked in the commit message). | |
| 13:58:16 | gibi | nova meeting in two minutes on #openstack-meeting | |
| 13:58:55 | openstack | bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9) | |
| 13:58:55 | openstackgerrit | Matthew Booth proposed openstack/nova master: Add BFV, ephemeral, and swap test cases for bug 1550919 https://review.openstack.org/620917 | |
| 14:15:18 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: WIP: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 14:21:40 | openstackgerrit | Matthew Booth proposed openstack/nova master: libvirt: Don't delete disks on shared storage during evacuate https://review.openstack.org/578846 | |
| 14:34:06 | gmann | mriedem: https://review.openstack.org/#/q/topic:nova-next-queens+(status:open+OR+status:merged) | |
| 14:35:41 | mriedem | thanks | |
| 14:46:02 | KeithMnemonic | mriedem this should be good now https://review.openstack.org/#/c/614872/ since the queens merged it seems | |
| 14:46:34 | efried | kashyap: we're discussing https://review.openstack.org/#/c/575735/ in the nova meeting. Are you going to be able to take another look? | |
| 14:46:48 | kashyap | efried: Hi | |
| 14:47:18 | mriedem | KeithMnemonic: yup, you don't have to tell me :) | |
| 14:47:22 | mriedem | need another stable core | |
| 14:47:26 | mriedem | bauzas: dansmith: ^ | |
| 14:47:41 | KeithMnemonic | sorry we have an inpatient customer ;-) | |
| 14:48:09 | KeithMnemonic | didnt mean to pester | |
| 14:48:41 | mriedem | KeithMnemonic: it's fine | |
| 14:48:50 | mriedem | we need reminders | |
| 14:50:11 | bauzas | yup, and good news, I'm almost done with all my internal cruft, so moar time upstream \o/ | |
| 14:57:49 | artom | bauzas, mriedem, hey, so I https://review.openstack.org/#/c/599587/, would appreciate another round of reviews :) | |
| 14:58:00 | artom | Err, I accidentally the verb | |
| 14:59:18 | bauzas | artom: I'll, once I'm done with sean-k-mooney's one ;) | |
| 14:59:37 | phasespace | windows host aggregate. Is this because the AZ host aggregates also need the metadata properties? | |
| 14:59:37 | phasespace | Question. I'm trying to use the AggregateImagePropertiesIsolation scheduler filter. I've set up two availability zones (which themselves are host aggregates and contain all hosts in total), and created another host aggregate intended for windows VMs, with only a subset of the hosts. I've set the os_type metadata for the host aggregate to windows, and likewise with the image metadata. Still I'm able to launch instances on hosts not in the | |
| 14:59:44 | artom | bauzas, SRIOV live migration? I should proll'y circle back to that as well : | |
| 14:59:45 | artom | :/ | |
| 15:00:00 | bauzas | :) | |
| 15:01:25 | cfriesen | mriedem: thanks for the heads-up on the other hpet bug | |
| 15:02:29 | mriedem | yw | |
| 15:03:56 | mriedem | phasespace: that is likely the problem, | |
| 15:04:09 | mriedem | the windows aggregate can only host images with the matching images, | |
| 15:04:20 | mriedem | but that doesn't *exclude* the other hosts, not in the windows aggregate, from hosting those same images | |
| 15:04:46 | mriedem | phasespace: there is a nova spec describing this exact issue, sec | |
| 15:04:56 | mriedem | phasespace: https://review.openstack.org/#/c/609960/ | |
| 15:05:44 | rambo_li__ | hi,all. I find it is important that live-resize the instance in production environment. We have talked it many years and we agreed this in Rocky PTG, then the author remove the spec to Stein, but there is no information about this spec, is there anyone to push the spec and achieve it? The link:https://review.openstack.org/#/c/141219/ | |
| 15:06:01 | rambo_li__ | if anyone can tell me the actual progress? | |
| 15:06:24 | mriedem | rambo_li__: there were actually a series of PoC patches for that blueprint https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/instance-live-resize | |
| 15:06:44 | sean-k-mooney | cfriesen: mriedem by the way i have been asked to enable a feature that is very simlar to hpet in that it jsut a feture booling to set in the config. should i propsoe a spec an basically copy what we agreed for hpet or specless blueprint? | |
| 15:07:11 | mriedem | rambo_li__: the problem is while there is general agreement on supporting live resize, it is a somewhat complicated change and low priority, which therefore means it does not really get attention | |
| 15:07:45 | mriedem | sean-k-mooney: i would start with specless and bring it up in open discussion in the nova meeting | |
| 15:08:40 | sean-k-mooney | mriedem: ok the feture is jsut enable/disbaleing the PMU (performce monitoring unit) to reduce latency for realtime guests | |
| 15:08:45 | sean-k-mooney | ill write it up | |
| 15:10:45 | rambo_li__ | ok,thank you,last one ,:)Currently openstack does not support limiting the total number of block volumes that can be attached to an instance. It can be a useful quota which, on after implementation, will restrict the deterioration of VM performance disallowing a unlimited number of block volumes attachments to a VM. The link:https://blueprints.launchpad.net/nova/+spec/block-volume-limit-per-instance | |
| 15:11:03 | rambo_li__ | what do you think of it ? | |
| 15:11:21 | mriedem | sean-k-mooney: why does that need to be a config option rather than an image property? | |
| 15:11:45 | mriedem | rambo_li__: i thought there was already a duplicate spec for this, sec | |
| 15:11:58 | mriedem | rambo_li__: https://blueprints.launchpad.net/nova/+spec/conf-max-attach-volumes | |
| 15:12:27 | sean-k-mooney | mriedem: oh i ment the libvirt xml sorry config was bad phrasing on my part | |
| 15:13:04 | mriedem | rambo_li__: that one also had a spec https://review.openstack.org/#/c/597306/ | |
| 15:13:06 | rambo_li__ | oh,I'm sorry about it | |
| 15:13:08 | mriedem | and a lot more discussion | |
| 15:13:11 | sean-k-mooney | mriedem: you could use a flaver extra_spec or image metadata to turn it on of off | |
| 15:13:54 | rambo_li__ | ok,ok, | |
| 15:13:58 | mriedem | rambo_li__: no problem; if that fits your use case then great. | |
| 15:14:06 | mriedem | it's not quota, | |
| 15:14:16 | mriedem | it's per-driver configuration for the max number of block devices per guest. | |
| 15:15:03 | rambo_li__ | yeah,it is necessary in some case | |
| 15:15:09 | rambo_li__ | cases | |
| 15:15:28 | rambo_li__ | :) | |
| 15:16:07 | mriedem | ok i will mark the other blueprint as superseded | |
| 15:17:51 | rambo_li__ | mriedem:goodbye | |
| 15:18:01 | mriedem | rambo_li__: good night | |
| 15:18:26 | mriedem | melwitt: johnthetubaguy: am i missing something or does this spec intentionally not support the block device limit for boot from volume? https://review.openstack.org/#/c/597306/ | |
| 15:19:09 | mriedem | because it doesn't mention boot from volume with >26 bdms, and if we support that for attach volume, i expect people are going to want it for bfv later - so if there is good reason for not supporting it on bfv that should probably be amended to the spec | |
| 15:21:11 | openstack | Launchpad bug 1677217 in OpenStack Compute (nova) " AggregateImagePropertiesIsolation filter return unwanted compute nodes" [Undecided,In progress] - Assigned to Md Nadeem (mail2nadeem92) | |
| 15:21:11 | mriedem | phasespace: also see https://bugs.launchpad.net/nova/+bug/1677217 | |
| 15:37:54 | openstackgerrit | Matthew Booth proposed openstack/nova master: Address nits from change I5619728d https://review.openstack.org/620941 | |
| 15:37:54 | openstack | bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9) | |
| 15:37:54 | openstackgerrit | Matthew Booth proposed openstack/nova master: Add BFV, ephemeral, and swap test cases for bug 1550919 https://review.openstack.org/620917 | |
| 15:39:39 | openstackgerrit | Matthew Booth proposed openstack/nova master: libvirt: Don't delete disks on shared storage during evacuate https://review.openstack.org/578846 | |
| 15:45:54 | artom | What are those "Cannot load <field> in the base class" errors again? I remember getting a few of them when writing tests for new code | |
| 15:48:11 | artom | Do they happen because you forgot to load a field with expected_attrs? Or does that only exist for Instances? | |
| 15:48:16 | artom | dansmith, ^^ awake yet? | |
| 15:48:40 | dansmith | artom: it means you're trying to lazy-load a field for which there is no handler | |
| 15:49:09 | dansmith | lazy-loading isn't magic, the object has to implement it specifically, because it may or may not mean "go back to the database" | |
| 15:49:17 | artom | dansmith, ah, there we go, thanks! | |
| 15:59:42 | phasespace | mriedem: thanks! | |
| 16:13:53 | openstackgerrit | Monty Taylor proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/508345 | |