| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-29 | |||
| 13:01:55 | cdent | I've always wanted lots of small lists (and irc channels, and projects and everything else) but I lost that battle nearly 4 years ago, so I gave up on that front | |
| 13:02:40 | kashyap | Lots of small lists work for people with effective email workflows. And are disciplined enough to manage them properly. Which is quite a high bar. | |
| 13:03:09 | cdent | yes. | |
| 13:03:25 | sean-k-mooney | cdent: i dont mind the merger of the list as i will just use email filter to break it up but i would prefer if all email had [*] subjust tags in them | |
| 13:05:19 | sean-k-mooney | e.g. if its ment for all add [all] | |
| 13:06:48 | jaypipes | sean-k-mooney: how does one even know that triple-o uses kolla under the hood? :( | |
| 13:07:09 | jaypipes | sean-k-mooney: I get so lost looking through triple-o's documentation and endless repos and abstractions | |
| 13:07:25 | jaypipes | sean-k-mooney: puppet, ansible, kolla, heat, mistral, just goes on and on. | |
| 13:07:36 | sean-k-mooney | jaypipes: i worked on kolla for a while so i know but ya triplos docs suck | |
| 13:09:05 | sean-k-mooney | the mariadb contianer is based on the kolla base contaienr which as the name implies creates a common baslien for all kolla contiers by enableing repos like the ubunto cloud archive or rdo | |
| 13:10:06 | sean-k-mooney | you can make the mariadb continer smaller by makeing the base container smaller but with the layers in docker container the actual contentce of the mariadb container should be small | |
| 13:15:13 | sean-k-mooney | jaypipes: personnally i always wanted to move kolla to alpine for the container images. to make the smaller | |
| 13:17:07 | sean-k-mooney | the centos mariadb rocky image is 189MB vs the ubuntu one which is 139 | |
| 13:19:04 | sean-k-mooney | 30MB of that comes from the fact the centos bas image is 75 megs vs ubutus xenial's 43 and with bionic droping to 32MB the centos containers are much bigger | |
| 13:19:07 | jaypipes | sean-k-mooney: or LOCI? | |
| 13:19:40 | jaypipes | sean-k-mooney: for the openstack service containers at least.. | |
| 13:20:16 | sean-k-mooney | loci did not have much of a size advantage the last time i looked but it has been 2 releases | |
| 13:20:59 | jaypipes | sean-k-mooney: for the openstack service projects, there was hundreds of MB difference. | |
| 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: Add DownCellFixture https://review.openstack.org/614810 | |
| 13:34:59 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: WIP: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 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 | openstackgerrit | Matthew Booth proposed openstack/nova master: Add BFV, ephemeral, and swap test cases for bug 1550919 https://review.openstack.org/620917 | |
| 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) | |
| 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 | 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:37 | phasespace | windows host aggregate. Is this because the AZ host aggregates also need the metadata properties? | |
| 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 | |