Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-03
11:40:18 johnthetubaguy I attempted to describe that in the review comments
11:40:39 johnthetubaguy ildikov: don't know
11:40:47 ildikov I saw that, but if I don't mess with the code purely because of multi-attach that check wouldn't be there
11:41:20 ildikov it's not part of the regular detach flow by design
11:41:58 johnthetubaguy ildikov: so I think it would be much easier for me to review this if we can write up your thinking around the change, and how all these checks should be done
11:42:32 johnthetubaguy ildikov: a few notes in the git commit message might be the best way to start it, but honestly, it feels like it needs a spec, because its API sensitive
11:43:08 ildikov and even for multi-attach case as we have the attachment_id stored in the bdm that approach should help
11:43:24 johnthetubaguy ildikov: I am not sure how that helps the old code flow
11:43:31 johnthetubaguy that would still be broken
11:43:43 ildikov johnthetubaguy: I will look into that later, on a conference this week
11:44:19 ildikov johnthetubaguy: I will test the old flow case and if I hit that error message I will look into how to fix that
11:44:32 ildikov johnthetubaguy: but the status checks should go regardless
11:44:44 ildikov johnthetubaguy: that shouldn't be in Nova
11:45:23 johnthetubaguy ildikov: its the error handling where we hit problems, bad volume-uuids, volume-uuids that are not attached, volume-uuids attached to other instances, volume-uuids for volumes that are already part way through the detach process, we want to give the user an API error, rather than a 200
11:45:59 johnthetubaguy ildikov: as I said, agreed with the goal, just the new flow doesn't have an API for that right now, as I see it, and it seems the old flow still needs these checks
11:47:43 ildikov johnthetubaguy: I will look into that, I cannot tell you more now from te top of my head about this
11:48:06 johnthetubaguy ildikov: that no problem, I just think we need to get this all written down / agreed first
11:49:01 ildikov johnthetubaguy: I just really hope we can clean up the code more, if we can't I'm not going make anything more complicated just to delete 10-20 lines
11:50:08 johnthetubaguy ildikov: me too, I am just trying to understand how this doesn't break the existing flow
11:50:16 johnthetubaguy the error handling in it
11:50:31 ildikov sure, let me look into that later
11:50:57 ildikov thanks for raising your concerns, the goal isn't to break the API
11:51:05 johnthetubaguy ildikov: I think this might actually just be when the Cinder and Nova state drift appart, but thats possible with force-detach
11:51:34 johnthetubaguy ildikov: we do check with the BDM further up (that logic really shouldn't be in there, but it is): https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/volumes.py#L431
11:53:44 ildikov johnthetubaguy: so you check the volume_id in the BDM
11:54:52 ildikov johnthetubaguy: if it does not match you don't do anything
11:56:54 johnthetubaguy ildikov: yeah, I missed all that logic, it certainly protects against the worse bits of what I was worried about
11:57:07 johnthetubaguy ildikov: hence the fresh link above
11:57:48 ildikov johnthetubaguy: it would've been weird to be honest if that checks points that out first as it wasn't part of a bugfix or anything like that
11:58:10 ildikov s/checks/check/
12:19:40 markus_z Is anyone aware of issues with centos nodes and oslo.serialization? Our s390x CI is centos based and goes mad since a few day, other upstream test jobs fail too: http://logstash.openstack.org/#dashboard/file/logstash.json?from=7d&query=message%3A%5C%22Malformed%20request%20body%5C%22
12:20:11 markus_z oslo.serialization 2.18 merged to u-c a a few days ago: https://github.com/openstack/requirements/commit/f0952e715c247ac570ed86341580bbe82fd85760
12:20:51 markus_z And the requirements project doesn't have a centos job: https://review.openstack.org/#/c/450508/
12:22:22 markus_z I checked all test jobs of that logstash query, all with the same issue, at the same "server tagging" tests.
12:22:43 markus_z Might be the PUT with an empty body.
12:25:25 openstackgerrit Pushkar Umaranikar proposed openstack/nova-specs master: Stop using Neutron admin token https://review.openstack.org/439890
12:26:09 markus_z And, IIUC, json decode issue won't get logged because that message https://github.com/openstack/nova/blob/94671e279fddc0d8eba29375750dd85410a0b9b9/nova/api/openstack/wsgi.py#L266-L271 gets overwritten by https://github.com/openstack/nova/blob/94671e279fddc0d8eba29375750dd85410a0b9b9/nova/api/openstack/wsgi.py#L635-L637
13:01:58 cdent Is tomorrow the planned spec sprint day?
13:03:26 dane-fichter cdent: yes
13:03:36 cdent thanks dane-fichter
13:03:44 dane-fichter no problemo
13:11:05 jaypipes dane-fichter: you see my review on the trusted flavors spec?
13:11:16 dane-fichter jaypipes: yes.
13:11:26 dane-fichter jaypipes: working on another draft currently
13:11:26 jaypipes dane-fichter: k. any questions for me?
13:11:30 jaypipes dane-fichter: gotcha
13:12:13 dane-fichter jaypipes: we considered doing this in the way you suggested a couple cycles ago
13:12:28 dane-fichter jaypipes: but I think another core shot it down.
13:12:29 jaypipes dane-fichter: oh? who blocked that idea?
13:12:55 dane-fichter jaypipes: I don't recall, I'll try to find a comment or something on it
13:13:00 jaypipes dane-fichter: I wasn't a specs core until a few weeks ago, so def wasn't me ;)
13:13:19 dane-fichter jaypipes: lol
13:13:39 jaypipes dane-fichter: now whenever I do a specs review I shout "By the power of Grayskull" in my home office.
13:14:03 dane-fichter jaypipes: w great spec power comes great spec responsibility
13:14:10 jaypipes dane-fichter: indeed.
13:19:29 mordred jaypipes: I imagine the pugs REALLY enjoy the shouting
13:19:48 jaypipes mordred: my Pug secretary is deaf and mostly blind, so no, it's cool.
13:20:50 jaypipes mordred: the black one is my secretary: https://pbs.twimg.com/media/C2ylYN-WgAES_p8.jpg:large
13:21:13 jaypipes mordred: the white one, as you can probably tell, is retarded.
13:21:50 jaypipes mordred: sorry, I meant "learning challenged".
13:21:50 cdent I think your secretary may be ready for a relaxed retirement
13:21:58 mordred jaypipes: :)
13:22:11 mordred jaypipes: they both look _very_ excited
13:22:24 jaypipes mordred: oh, that's "active mode". trust me.
13:23:40 mordred it feels active. like they're about to spring forth and maybe change their head position slightly
13:25:26 mordred stillness, after all, does not equal stasis. in every instant of stillness exists the potential for movement, so proper stillness is extremely active
13:36:48 jaypipes how very metaphysical of you, mordred
13:38:36 openstackgerrit Samantha Blanco proposed openstack/nova master: Make flavor-rxtx policy more granular https://review.openstack.org/444036
13:42:28 openstackgerrit Scott Moser proposed openstack/nova master: Limit exposure of network device types to the guest. https://review.openstack.org/400883
13:43:03 sdague alex_xu: you able to revise https://review.openstack.org/#/c/450834 ?
13:44:05 johnthetubaguy sdague: do you remember when we said nova-cert would die?
13:44:26 johnthetubaguy sdague: did we say wait until we arise the API min_version? or kill it sooner?
13:44:35 sdague I thought it was going to die sooner
13:45:00 sdague when did it deprecate?
13:49:01 johnthetubaguy sdague: https://github.com/openstack/nova/commit/789edad0e811d866551bec18dc7729541105f59d
13:49:42 johnthetubaguy sdague: it might be time already, macsz was putting a spec together to delete it, not strictly required, but there is API impact
13:51:38 macsz sdague: as a reference https://review.openstack.org/#/c/448882/
13:53:04 sdague yeh, honestly, it's probably fair to delete, it's been deprecated for newton and ocata
13:53:29 sdague and it's arguably a security risk given the entropy problem
13:54:57 johnthetubaguy sdague: yeah, I am certainly leaning that way
13:55:14 johnthetubaguy macsz: I think you just need to cover more details on what the API does, now the implementation is deleted
13:55:27 edleafe Scheduler subteam meeting in 5 minutes in #openstack-meeting-alt
13:58:21 macsz thanks for insights, johnthetubaguy
15:04:33 openstackgerrit Béla Vancsics proposed openstack/nova master: Reduced the complexity of the _init_instance method (3) https://review.openstack.org/420619
15:09:52 sneti_ johnthetubaguy, can you please review https://review.openstack.org/#/q/topic:bp/additional-notification-fields-for-searchlight+status:open when you have time.. getting merge conflicts every time a versioned notification patch gets merged.
15:12:19 openstackgerrit Lee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597
15:14:36 openstackgerrit Scott Moser proposed openstack/nova master: Limit exposure of network device types to the guest. https://review.openstack.org/400883
15:26:58 openstackgerrit Roman Podoliaka proposed openstack/nova-specs master: Ironic: add support for instance RAID configuration https://review.openstack.org/408151
15:29:04 openstack Launchpad bug 1663315 in cloud-init " identify openstack kvm platform on ppc64" [Medium,Confirmed]
15:29:04 andreas_s thorst, Hey Drew, is this already on your radar? https://bugs.launchpad.net/cloud-init/+bug/1663315
15:29:39 thorst andreas_s: looking...
15:30:40 thorst andreas_s: actually, it hasn't been (as I'm more PowerVM). Though PowerVM does have the same issue and we've been scratching our head how to solve.
15:30:51 thorst but let me see if I can get someone to take a peak at this.
15:31:01 mriedem artom: i looked at your tempest test for the tagged vif / volume attach test https://review.openstack.org/#/c/391947/
15:31:15 mriedem artom: looks like you're not waiting for the interface to be used before checking the device tags on the guest
15:31:25 andreas_s thorst, ok - cause we have the same issue on s390...
15:31:42 artom mriedem, that's possible...
15:31:46 mriedem artom: what's odd is that the test fails because it doesn't find any tagged devices on the guest, but the attach_volume method will wait for the volume to be in-use, so that should be on the guest
15:31:47 thorst andreas_s: yeah...I know burgerk has been working that issue from a cloud-init perspective rather than a pure OpenStack perspective
15:31:52 mriedem unless things just aren't working yet in that series

Earlier   Later