Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-16
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
16:42:32 mriedem BobBall: who from rax might know what they use?
16:42:37 BobBall Totally agreed - what should we do? Log message if anyone uses the function? Update help on the vif_driver option?
16:42:49 BobBall johnthetubaguy: will know I'm sure - he's just been AWOL for a few hours ;)
16:42:52 mriedem let me post my idea
16:43:16 johnthetubaguy he is here
16:43:38 johnthetubaguy rackspace is neutron, with the quark plugin
16:43:48 BobBall Does you set vif_driver to the quark plugin?
16:43:50 johnthetubaguy uses ovs
16:43:54 BobBall or can we deprecate the vif_driver option in nova?
16:44:13 openstackgerrit Sujitha proposed openstack/nova master: Adding tags field to InstancePayload https://review.openstack.org/407228
16:44:58 johnthetubaguy BobBall: seems fine to me
16:45:07 mriedem heh the config option says this:
16:45:14 mriedem "NOTE: The XenAPIBridgeDriver should be used for running OVS or Bridge in XenServer."
16:45:22 mriedem i guess that's totally wrong?
16:45:47 BobBall heh... Indeed.
16:47:01 BobBall frickler: There was a new tempest test added which made use of floating IPs. I've excluded it now. Please re-check.
16:50:09 BobBall mriedem: sorry for the sadness in the XenServer CI - as mentioned to frickler above, we have identified the probable cause for the ssh timeouts (we had two neutron agents with the same hostname - which meant sometimes the wrong agent was picked for something or other...). A fix was made today, but further investigation is being done to prove it doesn't break secure groups (there was some suggestion yesterday it might, but today we believe it won't).
16:50:35 mriedem BobBall: that's fine, i know it's not failing on this patch
16:51:56 BobBall Indeed. There are many false negatives today - but rechecks should fix them now. Hopefully we'll have the proper fix in the CI early next week and we will re-enable these tests.

Earlier   Later