| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-24 | |||
| 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 | |
| 20:21:46 | dansmith | melwitt: why the queued_for_delete=True in the test? | |
| 20:21:56 | dansmith | won't hurt anything but doesn't seem relevant? | |
| 20:23:04 | spatel | sean-k-mooney: does openstack has any config option to tell build 5 machine in single shot? | |
| 20:23:31 | spatel | I am using terraform and its not letting me build 10 machine but if i say do 5 machine it works | |
| 20:23:31 | melwitt | dansmith: oh, I was thinking (at the time) I needed something to "save" with it but the uuid would have done it huh? other than that it just mimics the actual bug (update of qfd failed) but not really relevant | |
| 20:23:55 | dansmith | melwitt: but the copy you're save()ing shouldn't have that set in the real race condition | |
| 20:24:14 | dansmith | the *other* one might, but not the stale one right? | |
| 20:24:23 | dansmith | er, the one that really got deleted | |
| 20:25:51 | melwitt | dansmith: no it shouldn't. what I was thinking was I wanted to make an instance mapping that is not yet qfd = True and then in the test I would set qfd = True and save it but I cheated by not having the mapping be returned by a "get" method 😬 | |
| 20:25:51 | melwitt | dansmith: no it shouldn't. what I was thinking was I wanted to make an instance mapping that is not yet qfd = True and then in the test I would set qfd = True and save it but I cheated by not having the mapping be returned by a "get" method 😬 | |
| 20:26:37 | dansmith | so gonna snip that out for posterity? | |
| 20:26:45 | melwitt | sure | |
| 20:27:09 | dansmith | it sent me on a goose chase trying to figure out why it mattered, so probably good | |
| 20:27:16 | melwitt | oh sorry :( | |
| 20:27:32 | dansmith | my other -1 was going to be "we can't merge patches with only one revision because fairness" so this will fix that too :D | |
| 20:28:09 | dansmith | otherwise seems like an obvious fix | |
| 20:29:06 | melwitt | heh :) | |
| 20:29:56 | openstackgerrit | melanie witt proposed openstack/nova master: Raise InstanceMappingNotFound if StaleDataError is encountered https://review.opendev.org/734400 | |
| 20:30:21 | melwitt | dansmith: done ^ | |
| 20:30:32 | dansmith | beatcha | |
| 20:30:38 | melwitt | danke | |
| 21:04:44 | sean-k-mooney | spatel: yes not supports multi create and no you should not use it | |
| 21:05:21 | sean-k-mooney | unless you meen the per compute node build limit which is 10 | |
| 21:05:59 | spatel | sean-k-mooney: i am talking about in general limit (not per compute) | |
| 21:06:19 | sean-k-mooney | spatel: im pretty sure we dont have an api limit at least not one that would block 5 | |
| 21:06:25 | spatel | one of user trying to create bunch of vm for testing and its failing even i have capacity | |
| 21:06:37 | sean-k-mooney | the api is limited by your quota | |