Earlier  
Posted Nick Remark
#openstack-nova - 2017-06-05
18:00:02 jaypipes zzzeek: which PG then barfed on
18:00:16 zzzeek jaypipes: yeah no, consumers.indexes is not changing itself when you drop those columns
18:00:19 mordred cdent, mriedem: the shade test patch is all green!
18:00:30 jaypipes zzzeek: hmm. ok.
18:00:42 zzzeek jaypipes: so, if you want *that*, do this: "from sqlalchemy import inspect; insp = inspect(migrate_engine); indexes = insp.get_indexes("consumers")"
18:00:44 cdent yayness. I think sdague said he's fast approve the devstack change
18:00:50 mordred although linuxbridge had a sad
18:01:27 jaypipes zzzeek: I think the simplest solution is to go back to revision 1 and do the execute(ALTER TABLE ... USING) thing for Postgresql?
18:01:38 zzzeek jaypipes: that will just give you names of indexes. if it were me I'd then just say "engine.execute("DROP INDEX <name>")", howver you can also say Index("myname").drop()
18:02:03 zzzeek jaypipes: I think it is yes. but all of these different scenarios can work, you're just having very bad luck stepping on every rake in the yard :)
18:02:23 jaypipes indeed :)
18:02:47 zzzeek jaypipes: try the USING with the conditional, i can make that or the other version work for you afte that
18:02:56 zzzeek jaypipes: you don't run mysql/pg functional tests locally ?
18:03:20 sdague that linuxbridge sad was a fail in test_device_tagging
18:03:34 jaypipes zzzeek: only mysql and sqlite, not postgreSQL, no...
18:03:34 sdague mriedem: that one being tracked yet, the error looks like it's going to be a race
18:03:43 jaypipes zzzeek: suppose I should :)
18:03:58 zzzeek jaypipes: it's just a yum install away... :)
18:04:15 jaypipes yeah yeah :)
18:04:35 zzzeek jaypipes: anyway I obv. have everythign running here so i can run through it later if you still cant get it working
18:04:58 jaypipes zzzeek: I'll just install PG :)
18:05:04 zzzeek jaypipes: OK.
18:10:19 mriedem sdague: huh? link?
18:12:33 openstackgerrit Merged openstack/nova master: Be more tolerant of keystone catalog configuration https://review.openstack.org/438049
18:12:49 mriedem sdague: oh you mean this http://logs.openstack.org/42/471042/2/check/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/4cc66aa/console.html#_2017-06-05_17_23_22_278409
18:12:58 mriedem i'm not aware of a bug for that
18:13:13 mriedem dansmith: just leave it
18:17:54 openstackgerrit Doug Hellmann proposed openstack/python-novaclient master: strip the remote prefixes from the release note branch specifiers https://review.openstack.org/471082
18:18:16 sdague mriedem: yeh - http://logs.openstack.org/42/471042/2/check/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/4cc66aa/console.html#_2017-06-05_17_23_22_337560
18:18:24 sdague I'll make a bug here in a minute for it
18:18:36 sdague there are a few hits on it
18:53:02 sdague \o/ for the diagnostics API standardization - https://review.openstack.org/#/c/355540/
19:03:12 openstackgerrit Chris Dent proposed openstack/nova master: Fix ChanceScheduler returning a wrong node https://review.openstack.org/466725
19:03:18 mriedem cool. a few wording things in there that could be cleaned up in a follow up change
19:04:09 mriedem now onto the novaclient change
19:06:10 mriedem cfriesen_: this is what you're waiting on btw https://review.openstack.org/#/c/471081/
19:06:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Replace messaging.get_transport with get_rpc_transport https://review.openstack.org/469659
19:06:32 cfriesen_ mriedem: mriedem: cool, thanks
19:08:26 cfriesen_ mriedem: the empty lines are needed for the nested lists to get formatted properly? is that yaml or rst?
19:09:00 mriedem rst
19:09:19 cfriesen_ is the hyphen a formatting element in rst?
19:09:26 mriedem yeah
19:10:03 mriedem http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#bullet-lists
19:10:14 cfriesen_ got it
19:10:47 efried mikal Should https://review.openstack.org/#/c/4379/ have removed the ", by name (not ID!)" part of https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L152 ?
19:12:16 efried or is there some reason we still need to enforce this lookup as being by name?
19:12:53 mriedem i will enjoy whatever answer mikal gives you for a thing done 5 years ago
19:13:50 mriedem oh,
19:13:59 efried Yeah, anyone should feel free to answer this.
19:14:00 mriedem and if/when he replies, make sure it's related to powervm :)
19:15:09 efried mriedem Since you asked, I was working on filling in a gap we missed in the in-tree impl: the only thing we populate in the InstanceInfo is the state.
19:15:36 efried While looking, I found that docstring and recognized that we've never looked that guy up by name (even in the out-of-tree driver).
19:15:58 efried So I went to figure out whether there was any basis for that edict.
19:16:29 mriedem remove ", by name (not ID!)" from the docstring
19:16:38 efried Doing it. Thanks.
19:16:38 mriedem it's always passed an Instance object
19:19:47 openstackgerrit Jay Pipes proposed openstack/nova master: placement project_id, user_id in PUT /allocations https://review.openstack.org/469634
19:19:48 openstackgerrit Jay Pipes proposed openstack/nova master: placement: use separate tables for projects/users https://review.openstack.org/470645
19:19:48 openstackgerrit Jay Pipes proposed openstack/nova master: placement: Add GET /usages to placement API https://review.openstack.org/469635
19:20:04 jaypipes zzzeek: \o/ ^
19:22:05 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Use util.extract_json in allocations handler https://review.openstack.org/471067
19:24:20 openstackgerrit Eric Fried proposed openstack/nova master: ComputeDriver.get_info not limited to inst name https://review.openstack.org/471106
19:24:31 efried mriedem ^^ This is why I earn the big bucks.
19:26:51 mriedem return conn.lookupByName(instance.name)
19:26:51 mriedem efried: it probably all ties back to the libvirt driver using this to get the guest info
19:27:03 mriedem most things in the virt driver layer are libvirt-biased
19:28:24 efried mriedem Don't I know it.
19:31:13 efried mriedem The other thing I noticed is that the only two consumes of get_info (in manager.py) only ever use the state. Makes me less panicky about hurrying to populate those other fields.
19:31:29 efried consumers*
19:47:27 efried jaypipes I presume the resource tracking stuff never plans to use get_info to figure out how much e.g. cpu/mem a VM is consuming - you're just going to record that at claim time and go with it?
19:50:05 dansmith efried: we don't know how much memory a guest is consuming without introspection
19:50:37 dansmith efried: and the amount of cpu it's using at some instantaneous point is not really an allocation thing
19:51:03 efried dansmith Okay, fair; but are there any plans for nova to actually use those InstanceInfo fields?
19:51:20 dansmith those...instanceinfo...fields...
19:51:23 efried Perhaps I'm missing some duck-typed dynamic usage of get_info
19:51:58 dansmith there are remnants of the extensible resource tracker and metric info in nova.. perhaps you mean that stuff?
19:52:18 efried dansmith https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L213-L217 <== those InstanceInfo fields
19:52:44 efried dansmith Perhaps I do mean that stuff. What stuff do I perhaps mean?
19:53:43 dansmith yeah, I _think_ that stuff is only used for choosing numa nodes
19:54:43 dansmith or maybe not even that, I don't even see that stuff considered in the scheduler
19:54:52 efried dansmith Does that happen in the nova tree? I'm even grepping and not finding any consumption of those fields.
19:55:55 dansmith efried: I think it's all within that file, and all for things like picking cpu topologies and stuff
19:56:05 dansmith but not a generic thing for reporting or choosing whole compute nodes, AFAIK
19:56:14 dansmith definitely not the material of placement though
19:56:45 efried dansmith What I'm considering doing here is leaving my InstanceInfo so it just provides the state. If anything ever gets written to consume any of the other fields, and assuming those code paths get hit in some tempest test, our CI will catch it (by raising AttributeError).
19:57:29 efried And at that time, we can figure out how best to implement those fields. Cause there's a number of options, with different performance characteristics, one of which would be more appropriate than another depending on the actual usage.
19:58:23 dansmith sounds reasonable
19:58:31 mriedem https://review.openstack.org/#/c/133777/
19:58:42 mriedem looks like it was added for something...but very little context
19:58:52 dansmith yeah
19:59:28 cfriesen_ weird python question....how is the "return" value from main() in cmd/manage.py expected to be consumed?
19:59:48 cfriesen_ it doesn't seem to have any effect on the process return value if run from the shell
19:59:49 efried Recently, too - but only relative to the aforementioned "by name (not ID!)" thing ;-)
20:02:14 mriedem goes back to https://github.com/openstack/nova/commit/19da125805eedbfcfd202abac4a90c57e6c538c4
20:02:49 mriedem https://github.com/openstack/nova/blob/c8e8b44ef27e49b3986659ee0cb6bd77b38430d8/nova/virt/libvirt_conn.py#L797
20:02:59 mriedem so, it just always returned that other crap
20:03:05 mriedem because we could
20:03:15 mriedem because the libvirt domain api gave it to us
20:04:00 mriedem https://github.com/openstack/nova/blob/c8e8b44ef27e49b3986659ee0cb6bd77b38430d8/nova/virt/xenapi/vm_utils.py#L686
20:05:51 efried Dig. I'll go with the plan, then. I'll just add a comment explaining it, so my posterity doesn't do a tim-the-tool-man like I did.

Earlier   Later