Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-02
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
17:10:58 sean-k-mooney but ya if your using bfv then it sound like it should be good
17:21:33 openstackgerrit Stephen Finucane proposed openstack/nova master: Fail to live migration if instance has a NUMA topology https://review.openstack.org/611088
17:31:36 openstackgerrit Merged openstack/nova master: Fix libvirt volume tests passing invalid disk_info https://review.openstack.org/529328
17:43:02 openstackgerrit Jim Rollenhagen proposed openstack/nova-specs master: Use conductor groups to partition nova-compute services for Ironic https://review.openstack.org/609709
17:45:20 leakypipes fried_rolls, SteelyDan, melwitt: if you have a moment: https://review.openstack.org/#/c/614351/
18:04:47 openstackgerrit John Garbutt proposed openstack/nova master: WIP: Integrating with unified limits https://review.openstack.org/615180
18:15:56 openstackgerrit Merged openstack/nova master: Pass disk_info dict to libvirt_info https://review.openstack.org/529329
18:41:15 mriedem SteelyDan: besides the RequestSpec.is_bfv resource tracking/filtering fix in rocky, can you think of any other major volume-related features/bug fixes we had?
18:41:22 mriedem in rocky specifically
18:42:07 SteelyDan I'd have to look.. I suck at remembering time intervals like that
18:42:18 SteelyDan but nothing jumps out at me as recent, no
19:19:00 fried_rice leakypipes: https://review.openstack.org/#/c/614351/ back atcha. I'm not a full -1 here, but would like the alternative considered. Also weirdness noted inline - I'm sure I'm just blind.

Earlier   Later