| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-04 | |||
| 20:47:23 | sdague | because you end up in exactly this situation | |
| 20:47:36 | melwitt | okay, so paste install wasn't skipped by pip for already existing because the version probably didn't satisfy | |
| 20:47:37 | sdague | I think the answer is to remove paste & paste-deploy from the dpkg list | |
| 20:47:44 | sdague | yes | |
| 20:47:48 | sdague | because of upper-constraints | |
| 20:47:49 | melwitt | guuhh | |
| 20:47:51 | melwitt | okay | |
| 20:48:14 | clarkb | isn't paste-deploy coming in transitively in the dpkg list though? that could get tricky to remove | |
| 20:48:23 | melwitt | it's coming in through ceph package | |
| 20:48:29 | sdague | http://logs.openstack.org/32/508432/1/check/gate-tempest-dsvm-full-devstack-plugin-ceph-ubuntu-xenial/575e932/logs/devstacklog.txt.gz#_2017-10-04_01_51_18_464 | |
| 20:48:59 | sdague | melwitt: yeh, well that's going to be non compatible with the way we do things | |
| 20:49:36 | sdague | you could hack in a: pip install -U --force paste.deploy | |
| 20:49:41 | sdague | at the right part of the process | |
| 20:50:35 | sdague | that's probably the best option if the ceph package is dragging that stuff in | |
| 20:51:22 | melwitt | sdague: okay, yeah thanks. I'll see where I could put something like that in the devstack ceph plugin | |
| 20:51:35 | melwitt | thanks for your help cracking this | |
| 20:55:55 | mriedem | omfg cells meeting in 5 minutes | |
| 20:56:03 | melwitt | !!! | |
| 20:56:04 | openstack | melwitt: Error: "!!" is not a valid command. | |
| 20:56:13 | melwitt | haha | |
| 20:56:32 | melwitt | my alarm alarmed openstack too | |
| 21:03:14 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP(5): PowerVM driver: ovs vif https://review.openstack.org/422512 | |
| 21:22:16 | edleafe | dansmith: I may get to slap you yet | |
| 21:23:13 | edleafe | dansmith: The test removed from test_filter_scheduler was testing pre-pike conductors that didn't pass instance_uuids. Now that we're in Queens, that test is no longer needed | |
| 21:24:15 | cali_boxer | hello all | |
| 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 | 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:36:28 | mriedem | rybridges: ^ | |
| 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 | oh heh | |
| 22:08:18 | mriedem | is_plugin_enabled | |
| 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 | melwitt | saweet | |
| 22:08:35 | mriedem | fi | |
| 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. | |