| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-04 | |||
| 22:07:55 | mriedem | there is probably also a way to find out if the ceph plugin is enabled, but this is an easier hack most likely | |
| 22:08:18 | mriedem | is_plugin_enabled | |
| 22:08:18 | mriedem | oh heh | |
| 22:08:22 | melwitt | oh hey | |
| 22:08:28 | mriedem | if [[ is_plugin_enabled "ceph" ]]; then | |
| 22:08:32 | mriedem | do that dirty package thing | |
| 22:08:35 | mriedem | fi | |
| 22:08:35 | melwitt | saweet | |
| 22:09:49 | mriedem | melwitt: devstack also has the ceph job in it's experimental queue so you can test it right in the devstack change itself | |
| 22:10:10 | melwitt | yesss | |
| 22:10:20 | mriedem | eglynn can send checks to my house directly | |
| 22:10:28 | melwitt | lol | |
| 22:11:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: fix nova accepting invalid availability zone name with ':' https://review.openstack.org/509659 | |
| 22:11:56 | efried | jaypipes Is <SELECT Traits.id, Traits.name FROM Traits JOIN ResourceProviderTraits ON Traits.id == ResourceProviderTraits.trait_id and ResourceProviderTraits.resource_provider_id == $rp_id> more efficient than (or equivalent to) <SELECT id, name from Traits where id in (SELECT trait_id from ResourceProviderTraits WHERE resource_provider_id == $rp_id)> ?)> | |
| 22:19:37 | jaypipes | efried: yes. | |
| 22:19:59 | efried | jaypipes Which, more efficient, or equivalent? | |
| 22:20:05 | jaypipes | efried: former is more efficient. | |
| 22:20:11 | efried | Because no sub-query | |
| 22:20:21 | efried | Dig, thanks. | |
| 22:20:23 | jaypipes | efried: though many modern optimizers will rewrite the subquery in the WHERE clause to be a JOIN | |
| 22:20:31 | efried | Yeah, I figured that was probably the case. | |
| 22:21:15 | efried | jaypipes The stuff we're using here, that looks like python code doing the joins and stuff - is that actually doing the magic in the database layer or in python? | |
| 22:21:56 | jaypipes | efried: DB | |
| 22:22:15 | efried | Must be some pretty heavy logic in there, like when some of those "methods" have conditionals embedded in 'em. | |
| 22:22:31 | jaypipes | efried: when using ORM queries that use things like joined_load eager and all that jazz, the SQL produced is less efficient. | |
| 22:23:35 | efried | jaypipes Like, how does something like ``sa.and_(t.c.id == rpt.c.trait_id, rpt.c.resource_provider_id == rp_id)`` *not* interpret those `==`s in python? | |
| 22:26:24 | dansmith | edleafe: yeah, you need to adjust the return value of that rpc method as well | |
| 22:26:39 | jaypipes | efried: oh, that's actually the beauty of SQLAlchemy's core expression API... it *does* interpret those things actually :) it's just what rpt.c.resource_provider_id == rp_id turns into is an expression object in SQLAlchemy that is processed with the __eq__ magic function... | |
| 22:27:05 | efried | ahhhh, __eq__, of course. Very cool. | |
| 22:28:11 | efried | jaypipes So I guess that means the order of the arguments in there is crucial. (rpt.c.resource_provider_id == rp_id) is cool, but (rp_id == rpt.c.resource_provider_id) is nonsense. | |
| 22:28:26 | jaypipes | efried: no... | |
| 22:28:35 | dansmith | edleafe: that's the next patch though right? | |
| 22:28:44 | efried | Wouldn't it try to use rp_id's __eq__ in that case? | |
| 22:29:14 | jaypipes | efried: there's some magic reflection happening in the sa.and_() function. | |
| 22:29:27 | jaypipes | efried: where it's looking at the structure of the parameters supplied to it. | |
| 22:29:58 | efried | before the interpreter gets hold of it? That *is* magic. | |
| 22:30:25 | efried | jaypipes Because http://paste.openstack.org/show/622705/ | |
| 22:30:42 | dansmith | efried: if rp_id is an integer, then yes | |
| 22:30:47 | dansmith | the order would matter | |
| 22:31:07 | efried | dansmith Phew, that makes me feel more sane. | |
| 22:32:08 | jaypipes | efried: there's lots o magic happening in https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/sql/operators.py | |
| 22:32:13 | jaypipes | efried: have fun reading :) | |
| 22:32:25 | efried | This is my first day looking at this sqlalchemy business. Appreciate the pointers. | |
| 22:32:57 | jaypipes | no prob. BTW, zzzeek is the author of SQLAlchemy. I am sure he would be the best person to ask about magicalities in the core expression API. :) | |
| 22:37:45 | efried | I'm pleased to report that nothing in that file blew my freaking mind, or made me expect (int == magic_sqlalchemy_object) not to explode. | |
| 22:38:31 | mriedem | so, dansmith, | |
| 22:38:40 | mriedem | have you and edleafe been up to something you're not telling the rest of us? | |
| 22:40:06 | dansmith | mriedem: um, what? | |
| 22:40:16 | mriedem | https://github.com/jaypipes/articles/commit/1a3dffb5f6fe688874c4f6617d139bf7af8f94c3 | |
| 22:40:18 | dansmith | mriedem: the banter was about the alternate hosts patch | |
| 22:40:35 | dansmith | WAT | |
| 22:40:53 | efried | dansmith Oh. On the other hand, it looks like __eq__ may internally handle the left-hand side not understanding the right: http://paste.openstack.org/show/622706/ | |
| 22:41:09 | efried | So it probably *would* work. | |
| 22:41:34 | dansmith | efried: I dunno how that works, | |
| 22:41:41 | dansmith | unless it only works against primitives or something | |
| 22:41:44 | melwitt | mriedem: lol | |
| 22:42:04 | efried | I imagine it's like 'except TypeError: try_the_other_guy's___eq___method' | |
| 22:42:09 | mriedem | i enjoy getting to do a pull request once per year | |
| 22:43:31 | dansmith | efried: see the second answer: https://stackoverflow.com/questions/3588776/how-is-eq-handled-in-python-and-in-what-order | |
| 22:43:49 | edleafe | mriedem: dansmith and I were trying to keep that a secret until the Forum! | |
| 22:44:41 | efried | dansmith Beaut, thanks. | |
| 22:44:54 | dansmith | efried: I did not think that worked that way | |
| 22:45:01 | efried | dansmith TIL, for sure. | |
| 22:45:20 | dansmith | and I might be remembering really old behavior, pre-new-style classes and all | |
| 22:45:36 | efried | Makes sense. Very prescient of those who wrote python itself. | |
| 22:45:43 | edleafe | dansmith: well, both patches change what is returned: this adds alternates, and the next changes them all to Selection objects | |
| 22:46:01 | edleafe | Old conductors won't know what to do with alternates | |
| 22:46:43 | dansmith | edleafe: yeah, then you need to pass a flag that says "give me the new stuff", or as mikal would say "do it to me big boy" | |
| 22:47:38 | dansmith | edleafe: I was thinking with all the "make this look like the existing return, change in next patch" stuff that we were remaining compatible here | |
| 22:50:04 | edleafe | dansmith: what's returned from the scheduler manager is the same. These changes are all internal to the scheduler | |
| 22:50:23 | edleafe | the next patch in the series is where all hell breaks loose | |
| 22:50:35 | dansmith | edleafe: okay but not all internal to the scheduler if the rpc api changes | |
| 22:50:37 | edleafe | I hope to have that in a decent state by tomorrow | |
| 22:50:57 | edleafe | the rpc api isn't changing in these | |
| 22:52:00 | edleafe | e.g.: https://review.openstack.org/#/c/486215/13/nova/scheduler/filter_scheduler.py@114 | |
| 22:55:00 | dansmith | I'm confused | |
| 22:55:41 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif stable/pike: Updated from global requirements https://review.openstack.org/493146 | |
| 22:55:45 | dansmith | edleafe: you said that new conductors will always be passing uuids now.. that is an rpc interface between conductor and scheduler.. we're agreed that you need to keep the test and compat behavior there, yes? | |
| 22:56:23 | dansmith | and the other question is if you're changing the return type of the rpc call that conductor is making.. | |
| 22:56:49 | edleafe | dansmith: the instance_uuid change was in Pike | |
| 22:57:04 | dansmith | right | |
| 22:57:05 | edleafe | yeah, I'm keeping the test | |
| 22:57:25 | dansmith | okay, so .. the return value of the rpc call is changed here or no? | |
| 22:57:30 | edleafe | not yet | |
| 22:57:43 | edleafe | I am working on the next patch in the series where is changes | |
| 22:57:56 | edleafe | Needless to say, that breaks a lot of tests | |
| 22:58:40 | dansmith | edleafe: this one right? https://review.openstack.org/#/c/495854/5 | |
| 22:59:10 | dansmith | or that one is just internal still and then another one after will change what the rpc consumer gets? | |
| 22:59:20 | edleafe | no, that just changes the scheduler driver's return value to the manager | |
| 22:59:36 | edleafe | the next patch will change what the manager returns, which is the rpc boundary | |
| 22:59:41 | dansmith | right, okay | |
| 22:59:56 | dansmith | so in _that_ one you'll need a flag to say "give me the new stuff" | |
| 23:00:14 | dansmith | and in these before, as long as you keep that test for the empty uuids I think you're good | |
| 23:01:17 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add alternate hosts https://review.openstack.org/486215 | |
| 23:01:18 | openstackgerrit | Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854 | |
| 23:01:18 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239 | |
| 23:01:22 | edleafe | dansmith: ^^ fixed per your comments | |
| 23:01:37 | edleafe | only the first patch changed; the rest are rebases | |
| 23:03:14 | edleafe | and with that it's time to make dinner | |
| 23:05:33 | dansmith | edleafe: cool, thanks | |