| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-31 | |||
| 14:10:06 | dansmith | sysmeta would not be that thing though | |
| 14:10:08 | poojajadhav | mriedem: I was thought like currently placement usage api giving correct usages so we can get them and use it for the simple tenant usage api | |
| 14:10:27 | dansmith | poojajadhav: that's not what simple tenant usage wants or needs | |
| 14:10:31 | dansmith | it needs historical data | |
| 14:10:47 | poojajadhav | dansmith: hmm | |
| 14:11:18 | mriedem | simple tenant usage is asking for an aggregate usage of resources for a given tenant over a specific time period | |
| 14:12:15 | mriedem | placement doesn't expose consumer type (instance or volume or container) nor created_at time | |
| 14:12:28 | dansmith | nor keep anything after deletion | |
| 14:12:34 | dansmith | i.e. no historical archive | |
| 14:12:41 | mriedem | right | |
| 14:12:49 | mriedem | when a record is deleted in placement, it's gone | |
| 14:12:57 | mriedem | it's not put in a box in the basement like in nova | |
| 14:14:19 | leakypipes | mriedem: gonna have to wait until the glacier unfreezes I'm afraid. /me goes back to reviewing nova-specs | |
| 14:16:35 | poojajadhav | mriedem: I was trying to fix it.. but which can be then efficient way now :( | |
| 14:19:44 | mriedem | well, system_metadata isn't great | |
| 14:20:47 | mriedem | dansmith: thinking out loud, how crazy would it be to have a joinedload field in the db api when we get an instance that adds a boolean attribute to the sqla instance object that queries the bdms table for that instance to see if it's volume-backed, i.e. (1) bdm exists for the instance (2) boot_index=0, (3) destination_type='volume' ? | |
| 14:21:29 | mriedem | essentially nova.compute.utils.is_volume_backed_instance but in the db api | |
| 14:22:47 | dansmith | are those all columns? | |
| 14:23:18 | dansmith | even if they are, I dunno if you can easily synthesize a field on an ORM object or not | |
| 14:24:59 | mriedem | we do that in other places, like what we had for instance_group.policies | |
| 14:25:23 | mriedem | definitely not something i'm going to spend a lot of time thinking about today | |
| 14:25:28 | mriedem | i'll throw it in the bug as an idea | |
| 14:27:08 | dansmith | we synthesize something with a subquery? | |
| 14:29:28 | mriedem | well i was thinking stuff like htis | |
| 14:29:29 | mriedem | *this | |
| 14:29:30 | mriedem | primaryjoin='InstanceGroup.id == InstanceGroupPolicy.group_id') | |
| 14:29:30 | mriedem | _policies = orm.relationship(InstanceGroupPolicy, | |
| 14:30:03 | mriedem | or this from the services table: | |
| 14:30:04 | mriedem | 'Service.binary == "nova-compute",' | |
| 14:30:04 | mriedem | primaryjoin='and_(Service.host == Instance.host,' | |
| 14:30:04 | mriedem | backref='services', | |
| 14:30:04 | mriedem | "Instance", | |
| 14:30:04 | mriedem | instance = orm.relationship( | |
| 14:30:05 | mriedem | foreign_keys=host, | |
| 14:30:05 | mriedem | 'Instance.deleted == 0)', | |
| 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 | |