| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-31 | |||
| 14:30:06 | mriedem | ) | |
| 14:30:29 | mriedem | that's how we get the instance.services column right? | |
| 14:30:47 | mriedem | calling it a column isn't really appropriate i suppose | |
| 14:30:50 | mriedem | model attribute | |
| 14:33:36 | dansmith | that's a join so we get the right thing, | |
| 14:33:53 | dansmith | that just gets us a list of matching records, not a boolean calculated, | |
| 14:34:04 | dansmith | but we could turn it into a boolean on the nova object if there's a bdm in that list I guess | |
| 14:34:44 | dansmith | do we keep the bdms after instance deletion? I think we use the flavor data for that usage info, so we'd need the bdms to still be there on deleted instances for that to work properly | |
| 14:35:02 | mriedem | the bdms are soft deleted just like the instance | |
| 14:35:07 | dansmith | okay | |
| 14:38:31 | openstackgerrit | Merged openstack/nova master: api-ref: add a warning about calling swap volume directly https://review.openstack.org/596492 | |
| 14:48:09 | mriedem | bauzas: see my todo/question in https://review.openstack.org/#/c/598365/1/nova/compute/resource_tracker.py - i'm assuming this is something operators may do in case they need to 'reset' allocation ratios on computes in the db back to the default | |
| 14:48:38 | mriedem | i.e. i set a config value for the allocation ratio, then want to get back to defaults, so remove my custom config and restart nova-compute and expect the compute to report the default allocation ratio | |
| 14:50:46 | bauzas | mriedem: ack, I need to go out, but I'll look at it | |
| 14:51:31 | bauzas | mriedem: mmm, about your question | |
| 14:52:12 | bauzas | mriedem: I think we can say something in a reno note that in case they want to use the default values, they should pass 16.0 for example | |
| 14:52:21 | bauzas | some upgrade section | |
| 14:52:38 | bauzas | setting it back to 0.0 looks insane to me | |
| 14:53:04 | bauzas | or another way to fix the problem would be to use the object method there | |
| 14:53:10 | mriedem | if we leave it and doc it anywhere, it should be in the option help, | |
| 14:53:22 | mriedem | release notes aren't read and are lost in the sands of time once you FFU | |
| 14:53:43 | bauzas | right, I meant in both a relnote and the help | |
| 14:53:56 | mriedem | need to wrap my head around this a bit myeslf | |
| 14:53:58 | mriedem | *myself | |
| 14:54:07 | bauzas | or I need to think about just modifying the conf default value | |
| 14:54:22 | bauzas | with your change too | |
| 14:54:35 | mriedem | my change needs to be backported so we wouldn't do that | |
| 14:54:37 | mriedem | in the same change | |
| 14:54:42 | bauzas | I mean, both fixing the RT *and* changing the default values | |
| 14:55:06 | bauzas | I need to go out but I'll think about it | |
| 14:57:42 | dansmith | man zuul is backed up real bad | |
| 14:58:52 | openstack | Launchpad bug 1790152 in OpenStack-Gate "jobs failing with ansible "ImportError: No module named manager" since 8/30" [Undecided,Fix released] | |
| 14:58:52 | mriedem | dansmith: yeah https://bugs.launchpad.net/openstack-gate/+bug/1790152 | |
| 14:58:57 | mriedem | already fixed but broke everything last night | |
| 15:00:04 | dansmith | yeah, but are we still on that backlog? | |
| 15:00:19 | dansmith | at 2am this morning they said "go ahead and recheck" -- maybe it's just the influx of everyone doing that/ | |
| 15:02:25 | mriedem | i assume so yes - everyone woke up and started rechecking the world | |
| 15:02:51 | openstackgerrit | Merged openstack/nova master: Remove old check_attach version check in API https://review.openstack.org/588348 | |
| 15:04:36 | mriedem | ^ feels good to have that gone | |
| 15:14:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Don't persist zero allocation ratios in ResourceTracker https://review.openstack.org/598365 | |
| 15:22:49 | cdent | sean-k-mooney: in case you're following along at home my car failed its mot rather spectacularly | |
| 15:25:56 | sean-k-mooney | cdent: i was actully wondering about that | |
| 15:26:32 | cdent | i'll find out the details in a few minutes when I go to pick it up. the parts it needs may be impossible to get. | |
| 15:26:50 | sean-k-mooney | cdent: fixable or not viable | |
| 15:27:26 | cdent | well, fixable with a) much money, b) access to parts. Both require some effort to resolve. | |
| 15:27:49 | sean-k-mooney | ya what is it by the way. you mentioned it was 21 years old but not the make or modle | |
| 16:34:03 | sean-k-mooney | melwitt: finucannot since sahid was fine https://review.openstack.org/#/q/topic:bug/1759420+(status:open+OR+status:merged) and melwitt mentioned to not squash unless i respin are they good to go? | |
| 16:35:15 | melwitt | sean-k-mooney: probably. I'd ask mriedem_away if he thinks squashing is important but he's away for atm | |
| 16:35:58 | finucannot | sean-k-mooney: Sure. I've +2d the bottom one but, in hindsight, I might leave both to melwitt seeing as she got there first (assuming that's alright with her) | |
| 16:37:18 | melwitt | finucannot: I'm fine with you taking them, I can +1 them anyway. I want to ask mriedem_away about squashing since it's related to the backport | |
| 16:37:50 | finucannot | melwitt: Yeah, it can wait until next week, in that case | |
| 16:38:03 | melwitt | we routinely backport 2-change deals for functional regression tests, but this is a unit regression test, just want to make sure with him since I'm not sure it matters | |
| 16:38:12 | sean-k-mooney | sure just comment or ping me if you want it squashed. its like 30 seconds to do but the gate is busy at the moment so did not want to push a change for no reason | |
| 16:38:42 | melwitt | ok, I'll let you know | |
| 17:43:00 | hamzy | hey y'all, my ethernet connections in instances installed via TripleO doesn't work. I seem to see all the bridges and connections setup, but some final qemu hardware connection is broken or missing http://paste.openstack.org/show/729241/ | |
| 17:44:02 | sean-k-mooney | hamzy: that all seams fine at first glance | |
| 17:44:14 | sean-k-mooney | hamzy: how did you determihn that the connectivity did not work | |
| 17:45:58 | hamzy | sean-k-mooney, on lines 78+ I can't get the IP via DHCP, or when I set it manually, ping the router | |
| 17:48:11 | sean-k-mooney | hamzy: is dhcp enable on the neutron subnet | |
| 17:48:15 | cfriesen | who's a good person to talk to about performance issues? | |
| 17:48:25 | cfriesen | I mean process startup times | |
| 17:49:35 | sean-k-mooney | cfriesen: as in makeing them better or debuging a problem | |
| 17:50:47 | sean-k-mooney | cfriesen: if your debugging a proablem i proably cant help but if you have a proposal on how to make it faster then im happy to be a sound board to bounce ideas off | |
| 17:50:49 | cfriesen | sean-k-mooney: in nova/compute/flavors.py we call "from nova.api.validation import parameter_types". This appears to be really expensive (~6 seconds in a recent test) due to the regex stuff, which makes a controller node startup fairly expensive | |
| 17:50:55 | hamzy | sean-k-mooney, yes I believe that it is... all ports on 'openstack port list' are active | |
| 17:51:48 | sean-k-mooney | cfriesen: ocuch 6 seconds for a singel function call for paramater validation is nuts | |
| 17:52:23 | sean-k-mooney | hamzy: yes they will be active regardless of if dhcp is enable on the subnet | |
| 17:52:28 | cfriesen | sean-k-mooney: that was in vbox, but it's still multiple seconds on bare metal. internally we moved the import down into the actual code so it's only done if we actually do the flavor creation | |
| 17:52:31 | sean-k-mooney | they also will have ips assigned | |
| 17:53:15 | sean-k-mooney | cfriesen: wait the import is executing code? is it building the regex on import or something if so that is terible | |
| 17:53:38 | hamzy | sean-k-mooney, http://paste.openstack.org/show/729253/ | |
| 17:54:02 | hamzy | is the DHCP agent only run on the controller? | |
| 17:54:56 | sean-k-mooney | cfriesen: sigh... https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L144-L492 its all at file scope we do this on every import | |
| 17:55:08 | cfriesen | sean-k-mooney: precisely | |
| 17:56:24 | sean-k-mooney | cfriesen: can you open a bug for that. i would have to check what this actully used for but personally i think we should lazy initallies the values or replace them with caching factoryFunctions | |
| 17:56:44 | cfriesen | sean-k-mooney: sure | |
| 17:57:06 | sean-k-mooney | the simplest thing to do is proably make them all properties but not sure that is leagal at file/module scope | |
| 17:57:38 | sean-k-mooney | hamzy: yes it should only be running on the contoller/networking nodes | |
| 17:58:33 | hamzy | sean-k-mooney, I would think that "sudo ip addr add ..." and ping .254 (router) should work as a test for network connectivity, right? | |
| 17:58:51 | sean-k-mooney | hamzy: can you do an "openstack subnet list" and then "openstack subnet show" for the subnet the vm is connected too | |
| 17:58:56 | leakypipes | cfriesen, sean-k-mooney: I'm actually only seeing a single re.compile() in that module... | |
| 17:59:22 | leakypipes | cfriesen, sean-k-mooney: It would seem like it would be more efficient to be re.compile()'ing all the regexes that are in module scope in that module. | |
| 18:00:28 | sean-k-mooney | leakypipes: actully i had assumed the ValidationRegex object was compiling them but i see now its not | |
| 18:01:10 | leakypipes | sean-k-mooney: no it is not... | |
| 18:01:33 | leakypipes | sean-k-mooney: or at least, it isn't AFAICT | |
| 18:02:02 | sean-k-mooney | ya looking over the file level stuff its not really doing anything expecive | |
| 18:02:16 | cfriesen | try running python and then doing "from nova.api.validation import parameter_types" | |
| 18:02:45 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/api/validation/__init__.py however might be | |
| 18:03:28 | sean-k-mooney | also not really be i hate when people hide stuff in __init__.py files | |
| 18:04:54 | cfriesen | just retested and it's 3 secs on pretty beefy hardware | |
| 18:05:25 | sean-k-mooney | cfriesen: and if you move the import to the fuction where its used what happens? | |
| 18:05:45 | cfriesen | sean-k-mooney: then you don't hit the delay at process startup, only when you actually run the function | |
| 18:06:11 | sean-k-mooney | cfriesen: yes but what is the delta in start up | |
| 18:06:22 | sean-k-mooney | if its 3 second to 2.9 then do we care | |
| 18:06:43 | cfriesen | no, it's 3 secs just for "from nova.api.validation import parameter_types" | |
| 18:06:56 | sean-k-mooney | oh that is different | |
| 18:07:25 | leakypipes | sean-k-mooney: well, there's no state in the dunderinit file at least... just functions. | |
| 18:07:44 | sean-k-mooney | cfriesen: can you temporally comment out the file level suff just to see if it changes | |
| 18:09:07 | leakypipes | holy fucksticks, Batman. | |
| 18:09:08 | leakypipes | [jaypipes@uberbox nova]$ source .tox/py27/bin/activate | |