| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-05 | |||
| 20:58:37 | dansmith | and unless we had multiple real cells we wouldn't hit it anyway | |
| 20:58:53 | mriedem | we had == in ci? | |
| 20:59:27 | dansmith | yeah | |
| 20:59:33 | mriedem | i thought we were going to have the/a multinode job have 2 cells with 1 compute each? | |
| 20:59:44 | dansmith | yeah but not one downlevel | |
| 20:59:49 | dansmith | not yet anyway | |
| 20:59:51 | mriedem | sure, but we could with grenade | |
| 20:59:52 | mriedem | eventually | |
| 20:59:55 | dansmith | eventually | |
| 21:00:07 | mriedem | but then we're stuck back with the grenade not running interesting tests issue | |
| 21:00:18 | dansmith | that helper doesn't appear to be in tree, but I know I wrote it.. might've been for a thing that we ended up not doing and so never committed it | |
| 21:00:44 | dansmith | don't we run smoke first and then full tempest post-upgrade? | |
| 21:00:49 | mriedem | nope | |
| 21:00:50 | mriedem | smoke both ways | |
| 21:00:55 | sdague | no, it's smoke on both sides | |
| 21:01:11 | mriedem | smoke'em if you got'em | |
| 21:01:54 | dansmith | okay | |
| 21:02:03 | sdague | honestly, for the multi node, multi cell version testing, we should probably purpose build something for that. Because it feels like we want to be pushing very specific edges on test cases | |
| 21:02:45 | dansmith | you mean a specific list of tests? | |
| 21:02:50 | mriedem | dansmith: https://bugs.launchpad.net/nova/+bug/1695993 | |
| 21:02:50 | openstack | Launchpad bug 1695993 in OpenStack Compute (nova) "supports_device_tagging check in /servers API won't work with multiple cells" [High,Triaged] | |
| 21:03:00 | mriedem | dansmith: i think he means not grenade | |
| 21:03:13 | sdague | yeh, maybe not grenade either | |
| 21:03:15 | mriedem | sdague: you're talking about the ansible idea from the PTG? | |
| 21:03:21 | dansmith | hmm | |
| 21:03:26 | sdague | mriedem: I'm not honestly sure | |
| 21:03:34 | mriedem | i remember you saying something like that once | |
| 21:03:40 | mriedem | when i was monkeying with d-g and cells v2 setup | |
| 21:04:01 | sdague | it just feels like we might be better off building something that builds out the mixed cell version environment from scratch | |
| 21:04:17 | sdague | instead of glomming too much onto the existing stuff | |
| 21:04:35 | mriedem | might have also been when talking about what rolling upgrades look like for cells v2 | |
| 21:04:36 | dansmith | I'm not sure why | |
| 21:04:38 | mriedem | with doing api at the end | |
| 21:04:47 | mriedem | since devstack/grenade starts/upgrades API first? | |
| 21:04:55 | mriedem | it had something to do with the upgrade order for api | |
| 21:05:03 | mriedem | we have notes from the BCN summit | |
| 21:05:57 | mriedem | anyway, i'm not proposing we tackle testing mixed-level cells in ci right now | |
| 21:06:37 | dansmith | mriedem: I will keep looking for my multicell service lookup patch in a couple dead end branches, but if I don't find it I'll just write it.. it's not hard | |
| 21:06:56 | mriedem | sure - you want to take that bug? | |
| 21:07:02 | mriedem | or just going to provide the helper? | |
| 21:07:31 | dansmith | mriedem: lemme write the helper and I'll survey the other uses... might be easy for me to just fix them uses too | |
| 21:07:50 | mriedem | dansmith: here it is https://review.openstack.org/#/c/442787/1/nova/objects/service.py | |
| 21:08:05 | dansmith | haha | |
| 21:08:15 | dansmith | no wonder I couldn't find it. that patch is dead to me | |
| 21:08:19 | mriedem | i know | |
| 21:08:24 | dansmith | lol | |
| 21:08:42 | mriedem | i was looking at it on friday considering taking it over | |
| 21:09:04 | mriedem | anyway, we should split that piece out into a separate change, and then the bug fix stuff on top probably | |
| 21:09:07 | dansmith | I've been working on sql injection attacks at gerrit so I can reassign it to you | |
| 21:09:08 | dansmith | yeah | |
| 21:09:10 | dansmith | I shall | |
| 21:28:49 | edleafe | jaypipes: dansmith: cdent: Started a thread on the ML: http://lists.openstack.org/pipermail/openstack-dev/2017-June/117913.html | |
| 21:29:02 | jaypipes | edleafe: thx ed | |
| 21:35:24 | openstackgerrit | Steve Noyes proposed openstack/nova master: WIP: update live migration to use v3 cinder api https://review.openstack.org/463987 | |
| 21:39:35 | openstackgerrit | Steve Noyes proposed openstack/nova master: objects: Add old_attachment_id to BlockDeviceMapping https://review.openstack.org/471142 | |
| 21:40:24 | mriedem | stvnoyes: that's not going to work | |
| 21:40:32 | stvnoyes | no? | |
| 21:40:42 | mriedem | primarily because you haven't added a column to the block_device_mappings table | |
| 21:41:28 | mriedem | however, we should talk to johnthetubaguy about this since i'd really hope we could avoid something like this | |
| 21:41:43 | stvnoyes | I was following this pattern that did somethng about the same - https://review.openstack.org/#/c/437665/ | |
| 21:42:04 | mriedem | right but you missed https://review.openstack.org/#/c/437597/ | |
| 21:42:22 | stvnoyes | ah ok. one of john's comments on the initial migrate review was for a place to keep the old attach id | |
| 21:43:09 | mriedem | john garbutt? | |
| 21:43:11 | mriedem | or griffith? | |
| 21:43:13 | stvnoyes | ah. ok (i am impressed that you remember all these things) | |
| 21:43:16 | stvnoyes | garbutt | |
| 21:43:35 | mriedem | hmm, i'd like to avoid an old/new attachment id column in the bdms table/object | |
| 21:44:01 | mriedem | initial thought if we have 2 bdms, one for the source host attachment and one for the dest host attachment | |
| 21:44:06 | mriedem | but that might break other things | |
| 21:44:40 | stvnoyes | did you have another idea? I originally tried to do without i, by creating a new bdm. but had problems down in libvirt driver distinguishing between what was source and destination | |
| 21:44:50 | stvnoyes | without 'it' | |
| 21:44:53 | mriedem | right that's one of the issues | |
| 21:45:31 | mriedem | the other problem is we have a BlockDeviceMapping.get_by_volume_and_instance method | |
| 21:45:32 | stvnoyes | so after going thru it a number of times, this came out to be less new code | |
| 21:45:46 | mriedem | which expects to get 0 or 1 results | |
| 21:46:11 | jgriffith | any way to do a "new/old" bdm? | |
| 21:46:42 | mriedem | probably not in a way that's any less bad than a single bdm with new/old attachmnets | |
| 21:46:43 | mriedem | *attachments | |
| 21:46:57 | mriedem | and like i said, a bunch of the code assumes volume id + instance id is uniqueu | |
| 21:47:01 | mriedem | *unique even | |
| 21:48:34 | stvnoyes | the other stringe thing I found is that when you have a connector present in the bd, the attachment_id is in the bdm twice (bdm.attachment_id, and in the connection_info string) | |
| 21:48:44 | stvnoyes | that's not terrific | |
| 21:49:12 | mriedem | stvnoyes: long-term i think we want to stop setting connection_info | |
| 21:49:15 | mriedem | when we have attachment_id | |
| 21:49:20 | mriedem | because cinder will store the connection_info for us | |
| 21:49:41 | mriedem | that probably happens in the attach patch | |
| 21:49:45 | jgriffith | stvnoyes that's because the attachment_id comes form that | |
| 21:49:52 | stvnoyes | that seems like a good idea (later) | |
| 21:50:07 | mriedem | nova wants to not store the connection_info | |
| 21:50:12 | mriedem | b/c it can be stale | |
| 21:50:43 | mriedem | and, well, we just don't want to duplicate all of this state modeling in two services | |
| 21:51:23 | stvnoyes | so how would you like to resolve whether we want to go with old_attachment_id? talk with John Garbutt? I can update the rv in the meantime with that missing change. | |
| 21:53:05 | mriedem | stvnoyes: yeah i'd say do what you're doing now, fix the db api thing, and then we talk to john to see if he had other idea | |
| 21:53:06 | mriedem | *ideas | |
| 21:53:21 | stvnoyes | ok cool | |
| 21:53:22 | mriedem | i don't like it but it's probably the lesser of many evils | |
| 21:53:48 | mriedem | unless of course dansmith has bright ideas he'd like to share about BDMs modeling and multi-attach | |
| 21:53:49 | mriedem | ... | |
| 21:54:12 | dansmith | barf | |
| 21:54:32 | jgriffith | You guys running some kinda vomitorium in here? | |