| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-27 | |||
| 16:37:15 | mdbooth | Others not | |
| 16:37:27 | mdbooth | This is a hard interface | |
| 16:39:55 | mdbooth | hemna: On the terminate_connection front, it could reasonably be a callback for eg | |
| 16:40:05 | mdbooth | Then os-brick wouldn't have to know anything about cinder | |
| 16:40:41 | mdbooth | But 'tell the target to kill this lun now' is a generic concept | |
| 16:41:15 | imacdonn | yeah, that's what I'm envisaging | |
| 16:59:06 | hemna | ok so why does this guy not call brick's disconnect_volume ? | |
| 16:59:07 | hemna | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3616 | |
| 17:00:06 | hemna | This is what a proper disconnect workflow should look like in nova https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2264-L2268 | |
| 17:00:59 | hemna | err | |
| 17:01:01 | hemna | wait...lol | |
| 17:01:09 | hemna | that doesn't call brick either. | |
| 17:01:34 | imacdonn | right ... brick gets called from within driver.destroy .. that's the problem | |
| 17:01:52 | imacdonn | as the comment right there says ;) | |
| 17:02:07 | hemna | boo! | |
| 17:04:08 | imacdonn | the hack that's gotten me by since icehouse is to put a lock on _shutdown_instance() (and a few similar places in manager) and the same lock on connect_volume() in virt.libvirt.volume.iscsi | |
| 17:05:28 | openstackgerrit | Abhishek Sharma M proposed openstack/nova master: Catching OverQuota Exception https://review.openstack.org/460305 | |
| 17:05:58 | johnthetubaguy | mdbooth: that iSCSI question, isn't that backend specific? I thought it was one iSCSI target per volume for some? | |
| 17:11:42 | openstackgerrit | Samantha Blanco proposed openstack/nova master: Remove flavor-rxtx policy https://review.openstack.org/444036 | |
| 17:37:59 | openstackgerrit | Steve Noyes proposed openstack/nova master: Add Cinder v3 detach to local_cleanup https://review.openstack.org/456851 | |
| 17:43:52 | efried | mordred Have a chance to skim https://review.openstack.org/#/c/460337/ yet? | |
| 17:44:05 | efried | mordred I'm working on the nova changes to accomodate. | |
| 17:46:21 | mordred | oh good - they're fixed now | |
| 17:47:03 | efried | trivial pep8 stuff. Still haven't done live testing, just wanting to make sure I'm heading down the right path here. | |
| 18:08:52 | mriedem | johnthetubaguy: i thought we had a policy check for showing fault details? | |
| 18:09:01 | mriedem | but i don't see that here https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/servers.py#L280 | |
| 18:09:08 | mriedem | except the is_admin check | |
| 18:28:12 | efried | sdague Got a sec to talk about [glance]api_server*s* ? | |
| 18:37:16 | linuxman | openstack-nova-scheduler service unable to start how to fix this issue | |
| 18:39:45 | openstackgerrit | Steve Noyes proposed openstack/nova master: Add Cinder v3 detach to shutdown_instance https://review.openstack.org/456877 | |
| 18:40:47 | efried | linuxman I think you want to ask that in #openstack? | |
| 18:41:29 | linuxman | but i hava a problem with nova service | |
| 18:42:10 | efried | Counts as "support of Nova deployments", nah? | |
| 18:42:12 | mriedem | linuxman: see the channel topic please, this is generally not a support channel, especially without any sort of context on the specific issue | |
| 18:42:36 | mriedem | "does not start" is not very helpful for debugging | |
| 18:44:06 | mriedem | thorst: it's snowing here, just fyi | |
| 18:44:22 | linuxman | you have any idea about proper rdo openstack channel | |
| 18:45:25 | mriedem | linuxman: i don't see one on https://wiki.openstack.org/wiki/IRC | |
| 18:45:29 | mriedem | but i'd try #openstack-rdo? | |
| 18:45:47 | mriedem | doesn't look like that's it | |
| 18:46:09 | mriedem | linuxman: https://www.rdoproject.org/community/#discuss | |
| 18:46:18 | imacdonn | just #rdo I think | |
| 18:46:21 | mriedem | yes | |
| 18:46:46 | linuxman | just #rdo i tried but know one is there | |
| 18:47:09 | mriedem | i count 291 people | |
| 18:47:32 | mriedem | make sure you're on freenode | |
| 18:47:40 | imacdonn | I'm there .. I'm not just paying attention ;) | |
| 18:48:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Expose StandardLogging fixture for use https://review.openstack.org/460642 | |
| 18:48:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Do not log live migration success when it actually failed https://review.openstack.org/458958 | |
| 18:48:34 | mriedem | sdague: i made all of your log fixture dreams come true | |
| 18:51:30 | mriedem | dansmith: you want to tickle this little ocata fix in https://review.openstack.org/#/c/459840/ ? | |
| 18:52:11 | mriedem | dansmith: should i be reviewing https://review.openstack.org/#/c/460616/ ? | |
| 18:52:18 | mriedem | is ironic/tripleo testing that out? | |
| 18:52:48 | thorst | mriedem: lol. It's 80 in RTP | |
| 18:53:06 | mriedem | oh now that i look out the window again the snow stopped | |
| 18:53:09 | mriedem | that's like the 3rd time today | |
| 18:53:28 | mriedem | i could just be hallucinating | |
| 18:53:50 | dansmith | mriedem: working with them now and on functional tests | |
| 18:53:54 | mriedem | ok | |
| 18:59:16 | mriedem | EmilienM: "Postgresql support (or call it how you want) is also removed upstream in OpenStack." where was that decided? | |
| 18:59:22 | mriedem | the governance change was abandoned i thought? | |
| 18:59:34 | EmilienM | yeah probably | |
| 18:59:46 | EmilienM | mriedem: AFIK there is a session in Boston about that | |
| 18:59:51 | cfriesen | is it possible to run individual functional tests? | |
| 18:59:55 | mriedem | right, but your email says it was removed | |
| 18:59:58 | mriedem | cfriesen: yes | |
| 19:00:04 | EmilienM | mriedem: we're got some feedback from our users who use postgres, I don't think we'll remove the code in our side. | |
| 19:00:12 | EmilienM | mriedem: I was wrong | |
| 19:00:34 | mriedem | cfriesen: tox -e functional -- nova.tests.functional..... | |
| 19:00:49 | cfriesen | mriedem: thanks, I didn't have the double dash and it didn't like me | |
| 19:01:39 | mriedem | -- is key | |
| 19:06:48 | sdague | mriedem: nice | |
| 19:11:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove legacy v2.0 code from test_flavor_access https://review.openstack.org/460719 | |
| 19:13:44 | openstackgerrit | Dan Smith proposed openstack/nova master: re-Allow adding computes with no ComputeNodes to aggregates https://review.openstack.org/460616 | |
| 19:16:04 | dansmith | mriedem: you can look at this now ^ | |
| 19:16:14 | dansmith | pretty sure that'll do it for them but they're testing now | |
| 19:17:21 | mriedem | will do after jaybird's get_inventory libvirt change | |
| 19:17:39 | abhi89 | johnthetubaguy: Hi.. can you please review https://review.openstack.org/460305.. you had suggested to change the exception message while translating the cinder exception.. | |
| 19:26:11 | mriedem | jaypipes: your patch made me think of this ^ | |
| 19:26:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add a note to *_allocation_ratio options about Ironic hardcode https://review.openstack.org/460722 | |
| 19:41:24 | abhi89 | melwitt: Hi Melanie.. | |
| 19:41:39 | melwitt | abhi89: hi | |
| 19:41:47 | abhi89 | melwitt: regarding https://review.openstack.org/#/c/460305/ | |
| 19:43:22 | abhi89 | in that fix, previously, everytime we had a volume related quota exception ('gigabytes', 'volumes', 'per_volume_gigabytes'), we used to raise VolumeLimitExceeded exception | |
| 19:44:02 | abhi89 | now with my change, we give appropriate exception message for each of those 3 exceptions | |
| 19:45:13 | abhi89 | the bug is not related to "Failure prepping block device". its related to always raising og VolumeLimitExceeded exception in those 3 cases | |
| 19:45:23 | melwitt | abhi89: right. and by appropriate, do you mean saying "volume related" instead of "volume resource" or is there more to it that I missed? | |
| 19:46:09 | melwitt | abhi89: okay, I'm curious why the bug calls out getting the message of "Failure prepping block device" then. because the change doesn't seem related to that | |
| 19:46:15 | abhi89 | there is more to it.. | |
| 19:46:57 | abhi89 | "VolumeLimitExceeded: Maximum number of volumes allowed (5) exceeded for quota 'volumes'." this message will be generated in case of "volumes" quota exceed | |
| 19:47:10 | abhi89 | number there is just an example | |
| 19:48:15 | abhi89 | "VolumeSizeExceedsLimit: Requested volume size 5G is larger than maximum allowed limit 4G." message will be there when 'per_volume_gigabyte' quota is exceeded | |
| 19:48:53 | abhi89 | "VolumeSizeExceedsAvailableQuota: Requested volume or snapshot exceeds allowed gigabytes quota. Requested 5G, quota is 25G and 21G has been consumed." message will be generated when 'gigabyte' quota exceeds | |
| 19:49:48 | melwitt | abhi89: okay, so what you are doing is letting the original overquota exception bubble up which will contain the correct message | |
| 19:50:40 | abhi89 | so these are the 3 specific messages which come as part of OverLimit exception. This OverLimit exception get translated to OverQuota exception. After translation, I embed the appropriate message from OverLImit to OverQuota, so that we have the exact reason why the VM deploy failed | |
| 19:50:52 | abhi89 | original OverLimit message | |
| 19:52:06 | melwitt | abhi89: okay. so I think the main thing your patch needs is a bit of test coverage that shows those scenarios and verifies we get the message we expect in each case. similar to the regression test that I think should be kept | |
| 19:52:39 | abhi89 | I removed the regression test because it was very specific to just 'VolumeLimitExceeded' for all 3 cases | |
| 19:55:06 | abhi89 | we already have a test case to check whehter we have OverQuota exception or not.. for all 3 specific cases, as we have replaced the OverQuota message to OverLimit message, we wont be knowing which of the 3 quota exceeded | |
| 20:00:34 | mriedem | dansmith: jaypipes: comments in https://review.openstack.org/#/c/457782 - overall i don't have anything to block it, but i don't like the tight coupling and assumptions being made in the virt driver about what the RT is going to fil lin for it | |