| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-24 | |||
| 10:32:24 | nightmare_unreal | okay :) . I will note that | |
| 10:32:25 | sean-k-mooney | i dont think that is a signifcant enough risk to warrent disabling it but that is something you should decied | |
| 10:33:15 | nightmare_unreal | okay. mnaybe after seeral trials and error i will find out | |
| 10:33:23 | sean-k-mooney | nightmare_unreal: cool as i said i personally recommend turning both on to ensure live migration actully eventually finish and it should be faster. | |
| 10:33:29 | nightmare_unreal | what suits best for my env | |
| 10:33:40 | nightmare_unreal | thanks | |
| 10:36:16 | sean-k-mooney | oh i guess you need to change https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_timeout_action to force_complete too | |
| 10:36:43 | sean-k-mooney | to get post copy to work. its noted in the config docs but i tought that was the default value not abort | |
| 12:41:45 | sean-k-mooney | stephenfin: can i pick your brain for a sec. its a dumb question but im interseted in what you expect. | |
| 12:41:53 | stephenfin | sure | |
| 12:42:40 | sean-k-mooney | stephenfin: if you have a tree and you do "for x in tree: do_stuff(x)" do you expect that to iterate over every node in the tree or over the roots? | |
| 12:43:17 | stephenfin | I'd expect it to iterate over the immediate children | |
| 12:43:28 | stephenfin | for grandchildren, you'd have to nest the for loop | |
| 12:43:31 | stephenfin | IMOP | |
| 12:43:33 | stephenfin | *IMO | |
| 12:44:28 | sean-k-mooney | so that is one way to do it yes. and in that case if i printed the child node woudl you expect it to print just its data or the data of its childeren | |
| 12:44:39 | sean-k-mooney | *also the data of its childern | |
| 12:44:59 | stephenfin | depends on how you have __repr__ implemented for the Node class | |
| 12:45:17 | stephenfin | You could do either, so long as it's consistent | |
| 12:45:39 | sean-k-mooney | so that the thing im currently implmeneting an __iter__ and __repr__ for ProviderTree and _Provider | |
| 12:45:39 | stephenfin | might be worth looking at what xml.etree.ElementTree does (and the lxml.etree equivalent) | |
| 12:46:21 | sean-k-mooney | stephenfin: so i know the lark parser lib chose to make the tree iterator, iterate over every node in the tree in a fixed order | |
| 12:46:30 | sean-k-mooney | not just the child nodes | |
| 12:46:48 | sean-k-mooney | and so if you pirnt the node they just print them selves not there childern | |
| 12:46:49 | stephenfin | that seems weird to me | |
| 12:46:56 | stephenfin | but it really depends on how you plan to use it | |
| 12:47:26 | sean-k-mooney | let me see what lxml does | |
| 12:47:59 | sean-k-mooney | i have implemetned both way and swap back and forward between what i think is correct. | |
| 13:04:18 | sean-k-mooney | stephenfin: they support both but in a slightly weird way https://lxml.de/tutorial.html#tree-iteration | |
| 13:05:19 | stephenfin | sean-k-mooney: what should I be looking at? | |
| 13:05:27 | stephenfin | I can only see a single root node with leaves | |
| 13:05:31 | sean-k-mooney | __iter__ on the element class iterates the childern __iter__ on the ElementTree class iterates all elements in the tree and the elemnet objects also have a .iter() function to do tree iteration on the elements | |
| 13:07:36 | stephenfin | Hmm, I'm not seeing that | |
| 13:07:42 | stephenfin | in the link you provided | |
| 13:08:15 | sean-k-mooney | "where you want to recursively traverse the tree and do something with its elements, tree iteration is a very convenient solution. Elements provide a tree iterator for this purpose. It yields elements in document order, i.e. in the order their tags would appear if you serialised the tree to XML:" | |
| 13:08:47 | sean-k-mooney | so the elements.itor() function is recursive over the child nodes and __iter__ is not recursive | |
| 13:09:24 | sean-k-mooney | so i think the behvior i want is __iter__ for ProviderTree should yeild all the provider in the tree in depth first order | |
| 13:09:50 | sean-k-mooney | but __iter__ on the provider will just yeild its imideate childeren | |
| 13:09:57 | sean-k-mooney | if i was to follow there patteren | |
| 13:12:45 | stephenfin | ah, so it's just a depth-first search | |
| 13:13:01 | sean-k-mooney | depth first traversal but yes | |
| 13:13:16 | stephenfin | *traversal, yeah | |
| 13:13:38 | sean-k-mooney | you could do it breathfirst but we already do depth first for get_provider_uuids | |
| 13:14:14 | stephenfin | what you're suggestions works for me, anyway | |
| 13:14:29 | stephenfin | different behavior on ProviderTree vs provider | |
| 13:15:23 | sean-k-mooney | ya i expect tree to have tree iteration and i guess node to have iteration of just there direct childern also make sense | |
| 13:15:42 | sean-k-mooney | stephenfin: etree makes there element behave like python lists | |
| 13:16:14 | sean-k-mooney | and i think that behvior makes sense for proviers but the ProviderTree shoudl act like a tree | |
| 13:37:22 | openstackgerrit | Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184 | |
| 14:37:55 | openstackgerrit | Dan Smith proposed openstack/nova master: Plumb image import functionality through our glance module https://review.opendev.org/731550 | |
| 14:37:55 | openstackgerrit | Dan Smith proposed openstack/nova master: Make libvirt able to trigger a backend image copy when needed https://review.opendev.org/656998 | |
| 14:37:56 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Add libvirt RBD configuration doc https://review.opendev.org/731577 | |
| 14:37:56 | openstackgerrit | Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184 | |
| 14:38:33 | dansmith | melwitt: had to rebase, can you re-+W those two? ^ | |
| 14:56:23 | aarents | Hi, what the meaning of "DNM:" in commit title ? | |
| 14:58:12 | bauzas | aarents: Do Not Merge | |
| 14:58:38 | aarents | bauzas: k thks | |
| 14:59:01 | bauzas | np | |
| 15:02:42 | melwitt | dansmith: will do | |
| 15:27:56 | stephenfin | bauzas: friendly reminder on https://review.opendev.org/#/c/714700/, if you've time :) | |
| 15:28:38 | bauzas | stephenfin: yup, haven't forgotten but I looked at the whole series to refresh my mind | |
| 15:30:03 | dansmith | melwitt: thanks | |
| 15:42:51 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/stein: Make greande jobs n-v for EM and oldest stable https://review.opendev.org/737332 | |
| 15:59:48 | bauzas | stephenfin: question before I leave https://review.opendev.org/#/c/714697/10/nova/objects/instance_numa.py@213 | |
| 16:00:39 | bauzas | I do understand this could be silly to have more than one policy, but should we have a kind of nova status upgrade check preventing it ? | |
| 16:37:07 | stephenfin | bauzas: It's not just silly, it's impossible | |
| 16:37:39 | stephenfin | The only way we'd get into that situation is via manual DB modifications, and when that's done all cards are off the table | |
| 16:38:25 | stephenfin | An upgrade check wouldn't resolve anything either, since if someone had done manual DB modifications beforehand, they could do them again after the upgrade check ran | |
| 16:41:32 | sean-k-mooney | bauzas: it was just stored in the wrong place | |
| 16:41:47 | sean-k-mooney | bauzas: the cpu policy has alsways been vm wide | |
| 16:41:52 | sean-k-mooney | not per cell | |
| 16:41:57 | stephenfin | yup. That was my bad | |
| 16:42:04 | stephenfin | I was young and innocent | |
| 16:42:13 | sean-k-mooney | i actully think this predates you | |
| 16:42:22 | stephenfin | nope, I added that | |
| 16:42:45 | sean-k-mooney | :'O how could you :P | |
| 16:42:53 | stephenfin | previously we determined whether policy was in effect by whether cpu_pinning_raw was set or not | |
| 16:43:01 | stephenfin | _that_ was ndipanov | |
| 16:43:11 | sean-k-mooney | ah ok | |
| 16:46:22 | sean-k-mooney | stephenfin: also handnt review that till now but it looks correct | |
| 16:47:05 | stephenfin | thanks | |
| 18:44:48 | sean-k-mooney | melwitt: dansmith shoudl this have a +w https://review.opendev.org/#/c/656998/ | |
| 18:45:33 | sean-k-mooney | dansmith: have you resolved the fact that it needs admin to work unless you own the image | |
| 18:45:57 | sean-k-mooney | https://review.opendev.org/#/c/734184 has the depends on but that earlier patch does not | |
| 18:45:59 | dansmith | sean-k-mooney: no, buried under many other dependent issues right now | |
| 18:46:33 | sean-k-mooney | dansmith: ok so the first two patches in the change have 3 +2s and +w | |
| 18:46:54 | dansmith | that should do it :) | |
| 18:47:03 | dansmith | it works as expected if you own the image, | |
| 18:47:11 | dansmith | and it's off by default, so I think it's okay at the moment from our side anyway | |
| 18:47:28 | dansmith | it just doesn't work with the image we create in devstack | |
| 18:47:32 | sean-k-mooney | right i was wondering if you wanted to hold them untill you fixed the other case but if you ok with them mergeing then cool | |
| 18:47:44 | dansmith | I think they're fine as is, | |
| 18:48:05 | dansmith | it's early in the cycle and if we don't get something resolved (I'm sure we will) then we can add to the docs patch about caveats | |
| 18:48:39 | sean-k-mooney | dansmith: ya if we dont figure something out we can always add a worksaround config option if needed to use admin | |
| 18:48:52 | sean-k-mooney | or document it as you said | |
| 18:48:56 | dansmith | yeah, although that has caveats for quota | |
| 18:49:00 | dansmith | so docs either way | |
| 18:49:47 | sean-k-mooney | ok in that case im going to call it a day o/ | |
| 18:50:14 | dansmith | thanks for looking out :) | |
| 20:17:36 | melwitt | dansmith, gmann: I've got a small fix proposed for a gate bug [that doesn't happen very often] around a InstanceMapping.save() race if you might be interested in reviewing https://review.opendev.org/734400 | |