| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-29 | |||
| 12:44:25 | sean-k-mooney | cdent is a few minuts ahead of us it seams | |
| 12:44:33 | cdent | http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000338.html | |
| 12:44:49 | cdent | I subscribed to openstack-discuss very early so probably my messages a few seconds before others :) | |
| 12:46:28 | kashyap | Also all the mailing lists are being merged, aren't they? | |
| 12:46:59 | cdent | yeah, openstack-discuss is the one true mailing list now | |
| 12:47:27 | cdent | until early next week the others are still around and include the new one in what they send to | |
| 12:47:37 | cdent | but next week the old ones will stop accepting submissions | |
| 12:47:45 | cdent | but the archives will remain | |
| 12:48:37 | kashyap | (Thx) | |
| 12:48:52 | kashyap | cdent: What's the rationale for merging all of them, and making it into a one Jupiter-sized firehose? | |
| 12:49:23 | cdent | yeah probably better to read the related discussion. there are many reasons | |
| 12:49:35 | cdent | some better than others | |
| 12:50:48 | kashyap | Thanks | |
| 12:51:33 | cdent | the overriding reason is to break down some of the artificial boundaries between devs, users, ops, I touch upon that in https://anticdent.org/mailing-list-review.html | |
| 12:52:41 | kashyap | Yeah, but it also requires people to massively "up their game" of managing emails. | |
| 12:53:16 | cdent | Yes, that was one of the arguments that people made, but the conclusions appeared to be: you need to do that anyway for any of the lists | |
| 12:53:25 | cdent | which seemed a bit weak to me, but meh | |
| 12:53:55 | kashyap | cdent: If only more people realized (not just in our community; but inside company lists, too) this: | |
| 12:53:58 | kashyap | [quote] | |
| 12:53:59 | kashyap | [/quote] | |
| 12:54:01 | kashyap | Your main goal as a member of a mailing list is to keep the archive as useful as possible for other members of the community. Do that, and the dynamic activity on the list itself also manages to be useful. | |
| 12:55:08 | cdent | we've found several time, kashyap, that you and I have very similar attitudes towards community collaboration... | |
| 12:55:12 | sean-k-mooney | kashyap: none does that to the openstack list right | |
| 12:55:44 | kashyap | sean-k-mooney: Yeah, true. But it is also due to not doing enough due diligence about how to work in an open source community. | |
| 12:56:22 | kashyap | cdent: Probably it's just that I got exposed to old-school mailing list approach, being at RHT for 10 years I guess :-) | |
| 12:56:50 | sean-k-mooney | i kind of whish they had just made the mailing list openstack instead of openstack-discuss. i always coralate discuss mailing list with purly enduser support | |
| 12:56:55 | kashyap | sean-k-mooney: Err, what I meant was -- no one does that on the list, but there's a _crap_ load of "meeting invites" and related junk | |
| 12:57:12 | kashyap | Post the minutes, but not frequent reminders about invites and what-not. | |
| 12:57:33 | kashyap | sean-k-mooney: That is true, on the naming; 'qemu-discuss' is a user-focused list. | |
| 12:57:33 | sean-k-mooney | kashyap: i had an auto delete filter for meting invites | |
| 12:57:34 | cdent | sean-k-mooney: that was discussed too, but that list already exists, and the hope was by creating a new one to remove a lot of dead addresses | |
| 12:57:42 | kashyap | sean-k-mooney: Heh, thanks for the idea | |
| 12:58:45 | sean-k-mooney | cdent: ya i assumed that was the reason still i would be intally much less incliend to join it as a dev | |
| 12:59:24 | cdent | which gets to one of the other reasons: stop people thinking that way | |
| 12:59:26 | sean-k-mooney | its not an issue because i know its going to be the only opstack mailing list but otherwise i would ignore it | |
| 13:00:55 | sean-k-mooney | cdent: i dont think discuss is something we should have been trying to reclaim for all discussions about a project but that ship has sailed so ill hold my piece on that topic | |
| 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? | |