| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-04 | |||
| 21:57:46 | melwitt | sigh, I need to be able to do something after devstack does pip installs but before keystone starts and I'm not seeing a way | |
| 21:57:53 | melwitt | (in a devstack plugin) | |
| 22:00:35 | mriedem | https://github.com/openstack-dev/devstack/blob/master/stack.sh#L1196 ? | |
| 22:00:43 | mriedem | melwitt: look at the run phases in stack.sh | |
| 22:00:48 | mriedem | those are the hook points i think | |
| 22:01:44 | melwitt | yeah. but I noticed keystone starts before post-config, which it's not supposed to (or originally wasn't). clarkb explained about that a little bit ago | |
| 22:01:46 | mriedem | it looks like everything is started after post-config, EXCEPT keystone | |
| 22:01:51 | mriedem | yup | |
| 22:02:25 | mriedem | ah yup here https://github.com/openstack-dev/devstack/blob/master/stack.sh#L1064 | |
| 22:03:07 | mriedem | i'm guessing b/c the accounts are needed to configure the other services? | |
| 22:03:14 | mriedem | like configure nova to talk to cinder/glance/neutron | |
| 22:03:24 | mriedem | you have to have those things created in keystone first, which means starting keystone | |
| 22:03:36 | melwitt | he said it's because there's no default default domain | |
| 22:03:46 | mriedem | so besides a pre-start phase being added, | |
| 22:03:59 | mriedem | you could probably hack something up in stack.sh to at least test the theory, | |
| 22:04:05 | mriedem | by checking to see if ceph is configured for the backend | |
| 22:05:37 | mriedem | like, if [[ $ENABLE_CEPH_CINDER == "True" ]]; then | |
| 22:05:44 | mriedem | https://github.com/openstack/devstack-plugin-ceph/blob/master/devstack/override-defaults | |
| 22:06:10 | melwitt | ah, I see. yeah, thanks | |
| 22:06:25 | mriedem | so like check that right here https://github.com/openstack-dev/devstack/blob/master/stack.sh#L1062 | |
| 22:06:32 | mriedem | and if ceph is enabled, do the dirty package thing | |
| 22:06:52 | melwitt | yeah, thanks. I was thinking, "how can I tell that if it's the ceph devstack plugin" but you were already on it | |
| 22:07:06 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: fix nova accepting invalid availability zone name with ':' https://review.openstack.org/509656 | |
| 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 | |