| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-02 | |||
| 14:29:27 | fried_rice | sean-k-mooney: As for changing the default, I doubt that's going to fly. For a change of this magnitude, we'll probably want to let it sit in experimental-optional state (where e.g. CERN and mnaser can try it out) for a while, and then consider changing the default in a separate patch, maybe in a future release. | |
| 14:30:24 | sean-k-mooney | fried_rice: ya i was debating that too. definetly a different patch | |
| 14:30:42 | sean-k-mooney | making it a train+ thing i could also see | |
| 14:31:12 | sean-k-mooney | did we actully agree on Train as the T release name by the way | |
| 14:32:52 | fried_rice | sean-k-mooney: The poll is still open afaik | |
| 14:32:56 | fried_rice | til next week | |
| 14:42:46 | sri_ | mriedem, yes :), I was also looking for proceees to update mon ip's in older versions of openstack, we have one of the stack running in Liberty | |
| 14:45:45 | sri_ | mriedem, thank you for your help :) | |
| 14:47:02 | mriedem | yw | |
| 14:50:00 | mriedem | SteelyDan: great, so removing that service version check is easy peasy. what's not is that a buttload of tests for the api rely on that code since they stub out an instance in the db w/o a related mapping, and we require the mapping now to lookup the instance. gonna be fun hunting those tests down. | |
| 14:50:12 | SteelyDan | hah nice | |
| 14:50:53 | jangutter | sean-k-mooney: the wiki has a very special icon next to the proposal. | |
| 14:51:04 | mriedem | ugh, rest api controller tests stubbing out the db api | |
| 14:51:05 | mriedem | fml | |
| 14:53:15 | openstackgerrit | John Garbutt proposed openstack/nova master: WIP: Unified limits ideas https://review.openstack.org/615180 | |
| 14:54:40 | jroll | SteelyDan: I'm having trouble coming up with a solution for my comment here, other than managing it in the database or something like etcd. mind taking a look to see if you can come up with anything? https://review.openstack.org/#/c/609709/3/specs/stein/approved/ironic-conductor-groups.rst@163 | |
| 14:55:53 | SteelyDan | jroll: why do you need to differentiate those two? | |
| 14:56:16 | SteelyDan | does default group imply it will take over everything? or will it look for a default group that ironic has nothing in since it's expected to be partitioned? | |
| 14:56:52 | jroll | SteelyDan: the latter | |
| 14:57:11 | SteelyDan | so what's the problem then? | |
| 14:57:42 | SteelyDan | if ironic is partitioned and you start up a compute with no config, it will look for the default group, find it empty and report no nodes (if I'm reading you correctly) | |
| 14:58:23 | jroll | SteelyDan: oh, I'm thinking of some nodes are partitioned and some are in the default group | |
| 14:58:40 | jroll | so we need to differentiate between "manage all nodes" and "manage only the default group" | |
| 14:58:52 | SteelyDan | why aren't those the same? meaning, | |
| 14:59:06 | SteelyDan | why isn't the default group inclusive of all nodes in ironic by default, and empty if you want strict partitioning? | |
| 14:59:40 | SteelyDan | and if you just want one group or something, then any node not configured would manage the default group (i.e. the rest) | |
| 14:59:49 | SteelyDan | I mean, I'm saying words without knowing how this works on the ironic side of course | |
| 15:00:22 | SteelyDan | even still, two config options could solve this right? manage_a_group=True|False, group_i_manage=[] | |
| 15:00:51 | jroll | right now you could have some "ungrouped" (default group) and some grouped | |
| 15:01:02 | jroll | I guess we could document that you shouldn't do this | |
| 15:01:15 | jroll | another option is a valid way to do it, I guess | |
| 15:02:38 | jroll | SteelyDan: thanks, I'll think it over and do two configs in the worst case | |
| 15:02:44 | SteelyDan | ack | |
| 15:03:03 | openstackgerrit | Chris Friesen proposed openstack/nova-specs master: Add support for emulated virtual TPM https://review.openstack.org/571111 | |
| 15:03:57 | melwitt | johnthetubaguy, leakypipes: queued_for_delete was added to instance_mappings by tssurya as part of the "handling of a down cell" set. and then I had talked about potentially using it for quota stuff at the dublin ptg I think | |
| 15:05:02 | leakypipes | melwitt: ack, ok. I half-remembered it correctly then ;) | |
| 15:05:13 | melwitt | :) | |
| 15:07:53 | johnthetubaguy | melwitt: cool, I have uploaded my quota ideas, finally: https://review.openstack.org/#/c/615180 | |
| 15:09:18 | melwitt | johnthetubaguy: cool, will check it out | |
| 15:25:10 | mnaser | small question | |
| 15:25:31 | mnaser | is there some rule or architectural decision in terms of nova not clobbering up or modifying other services | |
| 15:25:58 | mnaser | i'm trying to evaluate the local ceph cache thing, and i'm wonder if it would be acceptable to update the "locations" in glance if nova cached it in another cluster | |
| 15:26:24 | mnaser | it's interesting if it did, but also i totally get why it shouldn't, so i dunno | |
| 16:02:53 | mdbooth | Could somebody please restore workflow on https://review.openstack.org/#/c/529328/ and https://review.openstack.org/529329 for me? | |
| 16:03:33 | mdbooth | Previously approved, but shuffled the order to get them out of the way | |
| 16:14:07 | bauwser | mdbooth: ask leakypipes or finucannot | |
| 16:14:16 | bauwser | they'd be glad to help | |
| 16:14:35 | mdbooth | bauwser: I was trying to work out finucannot 's friday nick :) | |
| 16:14:42 | finucannot | mdbooth: done-zo | |
| 16:14:49 | mdbooth | finucannot: Cheers | |
| 16:52:45 | sean-k-mooney | mnaser: with the multi backend support in glance it might be ok for nova to add another location but i would never want nova to delete it form a speficic cluster | |
| 16:53:11 | mnaser | sean-k-mooney: yeah but thinking out loud i don't think its appropriate in case nova wants to do cache eviction | |
| 16:53:15 | sean-k-mooney | mnaser: that said that opens up a lot of corener cases in edge deployment or when you have restiction on where data can be stored | |
| 16:53:37 | mnaser | i've been hacking on it and it doesn't seem as crazy of an idea | |
| 16:54:14 | sean-k-mooney | mnaser: do you have ases were image x is not allowed to leave datacenter y | |
| 16:54:26 | sean-k-mooney | that is where this gets messy | |
| 16:54:38 | mnaser | sean-k-mooney: nope, not in this scenario at least | |
| 16:54:50 | mnaser | it's a deployment that spans 2 physical datacenters | |
| 16:54:59 | sean-k-mooney | nova does not know that so we cant assume nova can relocate teh image to anotehr cluster in general | |
| 16:55:34 | sean-k-mooney | mnaser: sure in your case it praobly fine, im just highlightin one fo the resonce nova would not do this by default | |
| 16:55:52 | mnaser | yep i agree | |
| 16:55:53 | sean-k-mooney | mnaser: haveing a config option on the other hand maybe | |
| 16:58:08 | sean-k-mooney | mnaser: if you get this working and it usefull to you then im sure people would at least consider it but likely the responce would be have a higher level service prechase the image for you out of band of nova | |
| 16:58:45 | mnaser | sean-k-mooney: right but in a public cloud environment.. i cant really do that | |
| 16:58:55 | mnaser | unless i setup replication which replicates *all* images across regions | |
| 16:59:04 | mnaser | sorry, not across region, but across ceph clusters | |
| 16:59:18 | mnaser | i.e. this is the case of a single glance, single nova deployment, multiple ceph clusters | |
| 16:59:40 | sean-k-mooney | am that depends on if you confie you teantes to specific clusers | |
| 17:00:03 | sean-k-mooney | in which case you only need to replicate the images that each of the teannts the use tha cluster need | |
| 17:00:47 | mnaser | right, but this is a public cloud so the answer is "everyone" .. as it presents itself as 2 independent availability zones | |
| 17:01:17 | mnaser | i mean i can see value in this type of feature for those who want to avoid downloading stuff non stop | |
| 17:01:30 | sean-k-mooney | this is specifcly for the ceph image backend by the way? | |
| 17:01:48 | mnaser | yes.. well.. normal backends cache images locally (even ceph) | |
| 17:01:54 | mnaser | but the problem is well.. it will be a local cache | |
| 17:01:58 | sean-k-mooney | mnaser: you basicaly want to tack advantage of cephs ablity to quickly clone volumes internally right | |
| 17:02:08 | mnaser | yes, and avoid the download by every compute node | |
| 17:02:21 | sean-k-mooney | ya thats what i assumed | |
| 17:02:33 | mnaser | otherwise the local storage would have been ok but yeah | |
| 17:03:03 | sean-k-mooney | mnaser: i might be worth seeing if you could do it in os-brick and have it stage the image in the ceph cluster on the first use of that image in that cluster | |
| 17:03:16 | mnaser | you know now what i think about it | |
| 17:03:19 | mnaser | i realize that like | |
| 17:03:30 | mnaser | this is more of a cinder problem because we no longer offer vms without bfv | |
| 17:03:50 | sean-k-mooney | mnaser: ya kindof | |
| 17:03:54 | mnaser | before we'd include ephemeral on storage so it was a nova issue | |
| 17:04:20 | mnaser | and i think this is kinda solved in https://docs.openstack.org/cinder/latest/admin/blockstorage-image-volume-cache.html | |
| 17:05:31 | sean-k-mooney | mnaser ya in the boot from volume case that should help alot | |
| 17:06:09 | sean-k-mooney | mnaser: that said in the ceph case i hope they are using ceph to do the clone internllay wich i assume they are | |
| 17:06:27 | mnaser | i think new cinder volumes from image do use ceph clone | |
| 17:06:42 | mnaser | so it would download from glance over http (in the cases of regions without local glance) | |
| 17:06:58 | mnaser | where the ceph cluster isnt directly accessible | |
| 17:07:10 | sean-k-mooney | provided glance was not backed also by ceph right | |
| 17:07:25 | mnaser | glance is backed by ceph, but it can do cow images in the same datacenter its hosted | |
| 17:07:30 | sean-k-mooney | if you glance is on ceph i think it can just to a direct clone pasing the ceph uri | |
| 17:07:51 | mnaser | yeah but that ceph cluster won't be accessible as it'd be in another datacenter | |
| 17:07:57 | mnaser | so it will fallback to just downloading over http | |
| 17:08:30 | sean-k-mooney | mnaser: right and you want to update glance with the second loaction once its cache by cinder | |
| 17:08:45 | mnaser | i mean, i dont have to, cinder will just know that it has it cached locally anyways | |
| 17:09:07 | mnaser | so bfv, create volume, cinder checks its cache (on local ceph), sees it exists, cow and boot vm | |
| 17:10:03 | sean-k-mooney | right but if you are not doing bfv and instead used the ceph backend for nova then you woudl want the other behavior | |
| 17:10:38 | sean-k-mooney | and in that config the caching and glance update would be nova problem | |