| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-04 | |||
| 21:29:59 | mriedem | edleafe: if the test is no longer needed, did you also remove the code that's checking for empty instance_uuids? | |
| 21:30:09 | mriedem | edleafe: and if so, that should be split into a separate change | |
| 21:32:37 | dansmith | edleafe: the rpc api still allows for it to be empty right? | |
| 21:32:47 | melwitt | hm, devstack post-config happens after keystone is started. would not have expected that | |
| 21:33:02 | dansmith | edleafe: you don't just get to drop rpc compat when it's been long enough, you have to do the version work | |
| 21:33:13 | clarkb | melwitt: we were just talking about why that is in the keystone channel | |
| 21:33:25 | clarkb | melwitt: long story short there is no default default domain | |
| 21:33:34 | dansmith | edleafe: otherwise people that have version mismatches get uncool error messages instead of "this is too old for that" | |
| 21:33:36 | clarkb | melwitt: so you have to get keystone fully up and running before you can configure anything else | |
| 21:33:51 | dansmith | edleafe: I just dealt with one of those yesterday, where they thought they had upgraded conductor but hadn't | |
| 21:34:14 | melwitt | clarkb: hah, good coincidence. thanks for sharing | |
| 21:36:28 | mriedem | rybridges: ^ | |
| 21:36:28 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: note that project_id filter only works with all_tenants https://review.openstack.org/509650 | |
| 21:42:38 | openstackgerrit | Merged openstack/nova master: Remove unused get_all_instance_*metadata methods https://review.openstack.org/508299 | |
| 21:43:07 | openstackgerrit | Merged openstack/nova master: Remove old compat code from servers ViewBuilder._get_metadata https://review.openstack.org/508326 | |
| 21:44:28 | edleafe | dansmith: so if filter_scheduler gets a request without instance_uiuds, it has to return the old-style host_states without alternates? | |
| 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. | |