| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-16 | |||
| 15:41:32 | shardy | dansmith: not sure, these are dlrn packages, I can try locally rebuilding with dlrn to check tho | |
| 15:41:46 | shardy | owalsh: rpm -qa seems to indicate that, which is a surprise | |
| 15:41:55 | sdague | dansmith: ok, I didn't realize the double master policy | |
| 15:42:04 | bauzas | mdbooth: eg. https://github.com/openstack/nova/blob/master/nova/scheduler/filters/affinity_filter.py#L89 | |
| 15:42:08 | dansmith | sdague: we never do this though, so not surprising we didn't do it right | |
| 15:42:10 | sdague | shardy: yeh, that looks like something unclean about the build | |
| 15:42:22 | sdague | dansmith: yeh, agreed | |
| 15:42:32 | shardy | sdague: yeah, I'll go and take a closer look at that, sorry for not spotting it sooner | |
| 15:42:32 | sdague | black swans are what they are | |
| 15:42:40 | mdbooth | bauzas: Ah... I was expecting it to use the instance info to update usage totals | |
| 15:42:41 | shardy | I'll leave the bug open for now until I figure it out | |
| 15:42:44 | mdbooth | Does it not do that? | |
| 15:43:40 | mdbooth | Also, instances is accessed there as a property, so I may have been grepping the wrong thing | |
| 15:44:23 | mriedem | BobBall: i'd like johnthetubaguy's opinion on that too | |
| 15:44:45 | mriedem | but it seems the default vif driver should be the ovs one if use_neutron=True by default in ocata | |
| 15:48:02 | mriedem | sdague: is there a reason we can't pip install rather than pip develop in a grenade run? | |
| 15:48:03 | mdbooth | bauzas: The code in question is here: https://review.openstack.org/#/c/430091/4/nova/scheduler/filters/disk_filter.py | |
| 15:48:13 | mdbooth | It's examining host_state.total_usable_disk_gb | |
| 15:48:37 | dansmith | mriedem: so I'm not sure the dev install is all that unusual, | |
| 15:48:53 | dansmith | mriedem: because the people I know that deploy from git do so in venvs, which is kinda how this behaves | |
| 15:49:10 | mriedem | yeah i thought about venvs | |
| 15:49:18 | mriedem | that's what bluebox does | |
| 15:49:23 | mdbooth | AFAICT that value is only ever set by a periodic task, and not if ComputeManager is sending updates? | |
| 15:49:27 | sdague | mriedem: the whole reason for the dev install is so that you can actually hack on and fix things | |
| 15:49:35 | mdbooth | bauzas: TBH I'm pretty confused | |
| 15:49:36 | sdague | it's kind of the purpose of devstack | |
| 15:49:40 | mriedem | sdague: yeah but we wouldn't do that in a CI run | |
| 15:49:47 | dansmith | mriedem: then it's different from local | |
| 15:49:53 | mriedem | seems d-g could tell us to actually install | |
| 15:49:56 | sdague | mriedem: sure, but then you end up with another difference between CI and local | |
| 15:50:07 | sdague | and people get all mad why reproduce is not a thing | |
| 15:50:11 | dansmith | yeah, which isn't great, especially if what we have is testing a legit mode | |
| 15:50:17 | dansmith | which I think it is because of venvs | |
| 15:50:23 | mriedem | fine fine | |
| 15:50:29 | mriedem | just spit balling | |
| 15:50:34 | sdague | mriedem: yeh, sure | |
| 15:50:44 | mriedem | i'll go back to trashing things in this roundtable | |
| 15:50:57 | bauzas | mdbooth: wait, which value ? | |
| 15:51:09 | bauzas | mdbooth: you're showing me something not related to the instance | |
| 15:51:14 | sdague | this is just one of those places where we have to remember that testing is a model of production, and as a model, we've made certain approximations | |
| 15:51:37 | mdbooth | bauzas: Right. I was trying to find an association between those 2 things, and I can't find one. | |
| 15:51:41 | mriedem | at the least i guess we need something doc'ed for this since it was missed | |
| 15:51:54 | mriedem | so in 2 years from now when we do another one of these we can consult the guide | |
| 15:51:57 | mdbooth | I was assuming it exists, because otherwise I don't see how that value is updated exception by a heavyweight periodic task. | |
| 15:52:09 | bauzas | mdbooth: so, the HostState is generated/updated at every request in the HostManager | |
| 15:52:12 | mdbooth | However, that's just assumption on my part. | |
| 15:52:25 | bauzas | and then we pass it to the filter for each compute | |
| 15:54:10 | mdbooth | bauzas: We're not calling back to the compute host for each request though, right? | |
| 15:54:42 | mdbooth | bauzas: The model is occasionally we get real values by inspecting the compute host, and in between we do a best effort ? | |
| 15:55:30 | jaypipes | I see that mordred has stepped in a pile of mascot poo this morning. | |
| 15:58:34 | bauzas | mdbooth: I need to go find my daughter | |
| 15:58:52 | bauzas | mdbooth: but let's discuss in 1 hour if I'm there | |
| 16:02:20 | mriedem | jaypipes: link me | |
| 16:06:03 | frickler | BobBall: could you take a look at https://review.openstack.org/434666 please? second (different) error after xenserver recheck, both look unrelated to my patch | |
| 16:08:36 | BobBall | frickler: We believe the ssh timeout issue is one we have a fix for (found the probable fix yesterday) - but we're currently doing more testing on it before merging to the CI. I've not seen that subnet failure before though. | |
| 16:09:13 | BobBall | There was a cirros change which made the CI very sad this morning, so I don't have enough statistics after that was fixed to say whether there is another wider issue or bad luck. | |
| 16:09:47 | BobBall | frickler: Hit recheck again - we are monitoring things and when we have a few hours more worth of data hopefully we can say whether there is a new issue or not | |
| 16:16:53 | mordred | jaypipes: could soemeone please revoke my email access? | |
| 16:16:57 | mriedem | bauzas: https://review.openstack.org/#/c/434552/ | |
| 16:16:59 | mriedem | for rc2 | |
| 16:17:42 | mdbooth | mordred jaypipes: Did I miss the juicy bits? Seemed civil to me. | |
| 16:18:53 | mriedem | nova got lumped in there i saw | |
| 16:19:13 | mriedem | nova didn't fight the mascot thing that much, we just said we didn't care (or i didn't care and thought it was silly) | |
| 16:19:20 | mriedem | but we don't have a homegrown mascot | |
| 16:26:43 | openstackgerrit | Dan Smith proposed openstack/nova master: Make CellDatabases fixture work over RPC https://review.openstack.org/434563 | |
| 16:26:44 | openstackgerrit | Dan Smith proposed openstack/nova master: Make start and stop admin actions cells-aware https://review.openstack.org/433362 | |
| 16:32:43 | mriedem | sdague: johnthetubaguy: can one of you put this through? https://review.openstack.org/#/c/434552/ | |
| 16:32:46 | mriedem | needed for rc2 | |
| 16:33:13 | mriedem | dansmith: did you want to get this into docs for rc2 or don't care? https://review.openstack.org/#/c/432482/ | |
| 16:33:44 | frickler | BobBall: will do, thanks for checking | |
| 16:34:13 | dansmith | mriedem: I was a little worried with that one that it might be implying that you could upgrade from cellsv1 to cellsv2, but I never articulated that | |
| 16:34:26 | dansmith | mriedem: but yeah, I'm fine with it going into ocata if you want | |
| 16:34:56 | sdague | mriedem: bam! | |
| 16:35:12 | mriedem | sweet | |
| 16:35:28 | sdague | mriedem: so I need to tweak that spec for keystone validation of projects, as the 403 case wasn't really specified well enough | |
| 16:35:37 | mriedem | so anyone else want to help sway me either way on whether or not we should quickly change the default on the xen vif_driver config option to be the ovs driver since neutron is the default now in ocata? | |
| 16:35:51 | mriedem | otherwise the xen vif driver is not correct by default out of the box in a fresh ocata install for xen | |
| 16:35:59 | mriedem | sdague: ok | |
| 16:36:35 | BobBall | I'm perfectly happy for the default to change - I wasn't sure if we could deprecate it (not sure if rax are using for quark) | |
| 16:37:04 | mriedem | BobBall: johnthetubaguy: i'm +2 on https://review.openstack.org/#/c/424428/ | |
| 16:37:12 | mriedem | any changes to the default vif_driver config can be a separate change | |
| 16:37:22 | mriedem | BobBall: do you know if rax is even using an in-tree vif driver for xen? | |
| 16:37:24 | dansmith | mriedem: I thought the logo was going to have some hands on it | |
| 16:37:40 | mriedem | i noticed the vif_driver option is a classloading option so you can load out of tree vif drivers for xen | |
| 16:37:43 | mriedem | dansmith: as in the gaping butthole? | |
| 16:37:47 | mriedem | that's only on twitter | |
| 16:37:55 | dansmith | mriedem: yeah, I must have missed where that was downvoted | |
| 16:37:57 | dansmith | ah, maybe so | |
| 16:38:29 | BobBall | mriedem: I know RAX use an out-of-tree VIF driver but I'm not certain if they use vif_driver or have custom patches | |
| 16:38:49 | mriedem | ok, because i'd like to close the out of tree vif driver support in here via the vif_driver option | |
| 16:38:56 | mriedem | and just make the vif driver decision based on use_neutron | |
| 16:39:11 | mriedem | we've been closing that window on lots of other configs | |
| 16:39:21 | mriedem | that would actually allow us to kill the vif_driver option and not use it | |
| 16:39:37 | mriedem | BobBall: you're sure that bridge driver won't work with neutron? | |
| 16:40:29 | mriedem | i won't hold rc2 up for it, anyone using xen i'm sure should already know about this | |
| 16:40:29 | BobBall | mriedem: No. But I'm sure we don't test it with Neutron and I would be quite shocked (or should I say pleasantly surprised?) if it does work. I always considered it to be nova-net only. | |
| 16:40:55 | mriedem | well we know it won't work with live migration and xenserver 7.0 i guess? | |
| 16:41:32 | BobBall | Right. | |
| 16:41:58 | mriedem | i'd kind of like to start the deprecation timer on that option in ocata if possible | |
| 16:42:01 | mriedem | so we don't lose 6 months | |