| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-22 | |||
| 19:19:44 | mriedem | claiming in two places has the same long-term functionality if we have to retry within a cell | |
| 19:20:26 | cdent | I think I'm leaning that way because of the "claim as early as possible" stuff I mentioned in one of my comments | |
| 19:20:26 | mriedem | i think the idea of doing claims in the scheduler AND conductor is if we do it in the scheduler, we have (a) tighter retry loop and (b) if we eventually drop reschedules in the cell, then we've already got the work done in the scheduler - as dan pointed out on the call | |
| 19:20:30 | mriedem | the short-term downside is you have duplication | |
| 19:21:01 | mriedem | i do'nt really see how that's not hidden in the scheduler report client though | |
| 19:21:07 | cdent | DRY is what breeds and deeply nested object hierarchies and that makes me cry | |
| 19:21:10 | mriedem | or some utility method shared between conductor and scheduler | |
| 19:21:13 | cdent | yes | |
| 19:22:38 | cdent | woot! I managed a whole 4 things off my to do list today. That's less than 4%. ossum. | |
| 19:22:54 | cdent | goodnight | |
| 19:23:08 | mriedem | melwitt: did you give up halfway? | |
| 19:23:34 | melwitt | mriedem: did I miss some comments? I didn't mean to | |
| 19:23:47 | melwitt | argh, sorry | |
| 19:27:40 | larsks | Howdy. I have an instance that is attached both ipv4 and ipv6 networks. The ipv4 networks show up in network_data.json on the config drive, but there is no trace of the ipv6 network. I see the same thing with a single network that has both ipv4 and ipv6 subnets...only the ipv4 information shows up. What could be causing this? | |
| 19:33:39 | dansmith | mriedem: I may be remembering wrong, but wasn't there a thing in the last six months or something about us not including ipv6 stuff in network.json in certain circumstances? re ^ | |
| 19:33:54 | fungi | larsks: that's a known issue. i gather there's an open bug, mailing list thread and proposed change(s) addressing it, though i don't have references handy at the moment | |
| 19:34:40 | mriedem | dansmith: i vaguely remember sdague and jaypipes reviewing something in there recently, but don't know if it was for this | |
| 19:35:12 | larsks | fungi: thanks. do you happen to know in which release it should work right now? E.g. was this a regression in ocata or master or something? | |
| 19:35:23 | larsks | And would I expect it to work in release N-1? | |
| 19:35:43 | mriedem | https://github.com/openstack/nova/commit/ccebded0cbb654be18db5b4e0e7f8b8a3a7cacdb ? | |
| 19:35:58 | mriedem | ^ is what i was thinking of | |
| 19:36:02 | mriedem | but does'nt look like the right thing | |
| 19:36:39 | openstack | Launchpad bug 1514082 in OpenStack Compute (nova) "network_data.json does not provide information about ipv6 addresses." [Undecided,Invalid] | |
| 19:36:39 | larsks | Hmmm, I found https://bugs.launchpad.net/nova/+bug/1514082 which suggests this is just a configuration issue. | |
| 19:38:46 | openstack | bug 1676363 in OpenStack Compute (nova) "The network metadata should be more useful" [Medium,In progress] https://launchpad.net/bugs/1676363 - Assigned to Dan Peschman (dpeschman) | |
| 19:38:46 | fungi | larsks: on another channel, clarkb pointed me to bug 1676363 | |
| 19:39:04 | mriedem | dansmith: why do we need with instance.obj_alternate_context on https://review.openstack.org/#/c/458634/12/nova/compute/api.py@1802 ? | |
| 19:39:05 | fungi | larsks: related ml thread starts at http://lists.openstack.org/pipermail/openstack-dev/2017-March/114563.html | |
| 19:39:15 | larsks | fungi: thanks for both pointers. I like the bug title. I'm going to see if it was just a config issue. | |
| 19:40:05 | dansmith | mriedem: because the instance has the ctxt inside not the cctxt | |
| 19:40:42 | dansmith | mriedem: well, actually, maybe not there I guess | |
| 19:40:58 | dansmith | mriedem: might be able to remove that one I guess | |
| 19:41:05 | mriedem | hold up | |
| 19:41:08 | mriedem | still going through this | |
| 19:41:53 | dansmith | I need food anyway | |
| 19:43:09 | mriedem | this is probably tied to get_instance stashing the targeted context on the instance object | |
| 19:43:17 | mriedem | that's probably something that deserves a comment in the code then | |
| 19:49:12 | jaypipes | mriedem: and it's that "get me alternate hosts" thing that I am really against. | |
| 19:49:24 | jaypipes | mriedem: in the conductor that is.. | |
| 19:52:09 | bauzas | sorry folks, was afk for dinner purposes | |
| 19:52:51 | jaypipes | dansmith: the diaper exception. nice. | |
| 19:53:36 | dansmith | jaypipes: that | |
| 19:53:48 | melwitt | mriedem: replied to the rest of the comments | |
| 19:53:49 | dansmith | is definitely not my term, but someone used it around me recently and I made note to use it again | |
| 19:54:22 | bauzas | jaypipes: dansmith: unfortunatly, I think it's related to the thread mriedem created about the pendulum switching | |
| 19:54:41 | bauzas | ie. should nova be tolerant to misconfig? | |
| 19:55:11 | bauzas | if we assume the answer be no, then I agree, case c) is probably not worth it for rescheduling | |
| 19:55:56 | mriedem | bauzas: that's not really why i started that thread | |
| 19:56:04 | bauzas | mriedem: that I know | |
| 19:56:10 | bauzas | mriedem: but I think the outcome is related | |
| 19:57:16 | mriedem | i think eventually disabling reschedules by default will make things that cause (c) to get exposed more clearly so that we can determine if they are things we should reschedule on, or handle as just bug fixes, i.e. some race we can handle | |
| 19:57:40 | mriedem | but it's a wild west of who knows | |
| 19:57:46 | bauzas | yup | |
| 19:57:51 | mriedem | b/c it's python and anything raised up from below goes in there | |
| 19:58:27 | mriedem | dansmith: left some comments/questions in https://review.openstack.org/#/c/458634/ | |
| 19:58:34 | dansmith | mriedem: thanks | |
| 19:58:36 | mriedem | dansmith: am i correct in stating that's all prep work for the next change in the series? | |
| 20:00:19 | mriedem | melwitt: ok looking | |
| 20:01:04 | bauzas | mriedem: dansmith: mmm, that https://review.openstack.org/#/c/458634/ is something I wondered when I was looking at my branch | |
| 20:02:00 | bauzas | mriedem: dansmith: correct me if I'm misunderstanding, but the problem is that we mutate the context so that when we exit the contextmanager, it's still having the new MQ ? | |
| 20:02:48 | bauzas | because if so, that explains what I discovered, ie. the fact that I was able to ComputeNodeList.get_all() without needing to scope my target | |
| 20:05:50 | mriedem | melwitt: replied to your replies, i don't get the point about old compute code calling count() | |
| 20:05:55 | mriedem | because it's not a separate service, | |
| 20:06:00 | mriedem | the old compute code will call the old count() code | |
| 20:06:17 | melwitt | mriedem: the count() function is accessible through the Quotas.count() remotable method | |
| 20:06:21 | mriedem | because it's all bundled together i think, unless maybe you have like a nova-common package and that gets updated before this or something? | |
| 20:06:47 | melwitt | I don't think compute actually calls count. but if something old did, then the new code would have to work | |
| 20:07:33 | mriedem | i don't see anything calling it | |
| 20:08:06 | mriedem | besides the api, | |
| 20:08:08 | mriedem | which you've changed here | |
| 20:08:26 | melwitt | I don't think anything is, dansmith was saying because the remotable method is there, we can't just change the format of what it returns | |
| 20:08:45 | mriedem | i think that's fine, and you're not | |
| 20:09:05 | mriedem | you added count_as_dict and the api calls that now | |
| 20:09:19 | melwitt | yeah, but underneath there has to be something in nova/quota.py that returns the old format | |
| 20:09:21 | melwitt | right? | |
| 20:09:29 | mriedem | but i'm asking about https://review.openstack.org/#/c/446239/7/nova/quota.py@1914 | |
| 20:09:34 | melwitt | if count() is to still be supported | |
| 20:09:45 | melwitt | Quotas.count() passes through to nova/quota.py | |
| 20:10:13 | mriedem | also this https://review.openstack.org/#/c/446239/7/nova/quota.py@1450 | |
| 20:10:17 | melwitt | and what I have there is "if count() use old counting function, else use the new one that returns a dict" | |
| 20:10:59 | mriedem | where does ^ happen? | |
| 20:11:35 | melwitt | at L1450 I'm defining the old count function if one is provided | |
| 20:11:59 | melwitt | because a Quotas.count() would call self.count() | |
| 20:13:15 | mriedem | which otherwise would fail if you didn't have https://review.openstack.org/#/c/446239/7/nova/quota.py@1608 ? | |
| 20:13:23 | mriedem | Quotas.count() calls count on the resource objec | |
| 20:13:28 | mriedem | the engine doesn't have a count() method | |
| 20:13:31 | dansmith | mriedem: yeah, prep for the next | |
| 20:14:03 | mriedem | whether or not you're talking to the engine, the driver or the resource object is always a gamble when yo'ure talking quotas | |
| 20:14:05 | dansmith | bauzas: I'm not sure what you're asking.. currently we mutate global context for the temporary target context handler, which isn't what we want | |
| 20:14:35 | mriedem | melwitt: oh no you're right | |
| 20:14:44 | mriedem | engine does have a count() method which calls count() on the resource object | |
| 20:14:49 | mriedem | CountableResource in this case | |
| 20:14:57 | bauzas | dansmith: I'm trying to explain that I saw a weird behaviour where I stupidly forgot to target a cell for calling the compute list, and it worked | |
| 20:15:17 | bauzas | while it should have be given me no computes, right? | |
| 20:15:20 | mriedem | still, couldn't nova.objects.Quotas.count() call count_as_dict and return the int? | |
| 20:15:20 | dansmith | bauzas: well, that's probably because you weren't in a multicell environment | |
| 20:15:23 | melwitt | mriedem: yeah, those methods I added on the NoopQuotaDriver were a mistake, they would do nothing | |
| 20:15:37 | dansmith | bauzas: without my (yet to be merged) patch to devstack, you're always single-cell | |
| 20:15:37 | bauzas | dansmith: that's what I thought, since it was for functional tests | |
| 20:15:50 | dansmith | and in functional tests unless you specifically arrange for multicell | |