| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-10 | |||
| 12:04:23 | elod | lyarwood: about this patch: https://review.opendev.org/#/c/706716 | |
| 12:04:35 | elod | lyarwood: do we need the change in .zuul.yaml? | |
| 12:07:03 | lyarwood | elod: I was confused by that at first but it allows the nova-live-migration jobs to run against changes to nova/tests/live_migration/hooks/utils.sh | |
| 12:07:06 | elod | lyarwood: I think it would be better to leave that as it was originally. If something changes in live_migration/hooks, then it can be tested with a depends-on tagged (dummy) patch | |
| 12:08:11 | lyarwood | elod: I don't really mind either way | |
| 12:08:20 | lyarwood | elod: it would be cleaner to do this across all branches tbh | |
| 12:08:21 | elod | lyarwood: and there are 3 py files that triggers all dsvm based jobs now | |
| 12:09:13 | elod | lyarwood: and of course it would be good to finally fix the rocky branch :) | |
| 12:12:07 | elod | lyarwood, gmann : do you mind if I remove the .zuul.yaml changes (in https://review.opendev.org/#/c/706716 ) ? | |
| 12:15:02 | lyarwood | elod: I don't but I'd also like to fix the branch :) | |
| 12:15:17 | lyarwood | elod: if you do remove it can you push a DNM change on top that does test that job | |
| 12:16:50 | elod | lyarwood: yes, of course, though I think it's already tested now (with the .zuul.yaml change :)) | |
| 12:24:14 | lyarwood | elod: right but if we change it we still need to test it :) | |
| 12:24:20 | lyarwood | but yeah I get your point | |
| 12:25:32 | openstackgerrit | Elod Illes proposed openstack/nova stable/rocky: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706716 | |
| 12:27:08 | openstackgerrit | Elod Illes proposed openstack/nova stable/rocky: DNM: Test live-migration hook https://review.opendev.org/706812 | |
| 12:27:21 | lyarwood | thanks | |
| 12:27:44 | elod | lyarwood: thanks, too! | |
| 12:27:51 | lyarwood | once we've sorted this out I'll start burning down the remaining stable/rocky changes btw | |
| 12:29:21 | elod | ok, I will also look at the rocky patches :) | |
| 12:58:59 | gmann | elod: lyarwood we need those irrelevant file change otherwise liver migration job can break on run_tests.py changes. what i can do is to run only nova-live-migration job for run_test.py | |
| 13:03:14 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/rocky: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706716 | |
| 13:03:29 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/queens: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706714 | |
| 13:03:58 | rosmaita | efried: need a favor when you have a few minutes, let me know what you think of https://review.opendev.org/#/c/706298/ | |
| 13:05:01 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/pike: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706715 | |
| 13:05:12 | gmann | lyarwood: elod ^^ | |
| 13:17:11 | elod | gmann: looks ok to me | |
| 14:42:23 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-aggregates policies https://review.opendev.org/701651 | |
| 14:42:59 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-aggregates policies https://review.opendev.org/701651 | |
| 14:43:23 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-aggregates policy https://review.opendev.org/701652 | |
| 14:43:47 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-aggregates policies https://review.opendev.org/701654 | |
| 14:44:08 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-aggregates policy https://review.opendev.org/701656 | |
| 14:44:49 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-agents policies https://review.opendev.org/701644 | |
| 14:45:05 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-agents policies https://review.opendev.org/701644 | |
| 14:45:19 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-agents policy https://review.opendev.org/701645 | |
| 14:45:31 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-agents policies https://review.opendev.org/701648 | |
| 14:45:43 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-agents policy https://review.opendev.org/701649 | |
| 14:48:01 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-console-auth-tokens policies https://review.opendev.org/706687 | |
| 14:48:16 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-console-auth-tokens https://review.opendev.org/706688 | |
| 14:48:33 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-console-auth-tokens policies https://review.opendev.org/706689 | |
| 14:48:47 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-console-auth-tokens policy https://review.opendev.org/706690 | |
| 14:50:46 | openstackgerrit | Merged openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Ussuri https://review.opendev.org/693844 | |
| 14:53:16 | gmann | elod: thanks | |
| 14:54:10 | lyarwood | gmann: just waiting for CI before I ack it btw | |
| 14:54:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1862633 https://review.opendev.org/706867 | |
| 14:54:31 | openstack | bug 1862633 in OpenStack Compute (nova) "unshelve leak allocation if update port fails" [Medium,Triaged] https://launchpad.net/bugs/1862633 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 14:54:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Clean up allocation if unshelve fails due to neutron https://review.opendev.org/706868 | |
| 14:56:40 | gmann | lyarwood: ok, thanks. i did not backport to ocata but i can see open backport for nova ocata which will have same issue. should I backport this fix there too ? | |
| 14:57:13 | lyarwood | gmann: if it's an easy cherry pick sure | |
| 14:57:23 | gmann | lyarwood: ok | |
| 15:03:00 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/queens: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706714 | |
| 15:04:39 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/pike: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706715 | |
| 15:05:37 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/ocata: Use stable constraint for Tempest pinned stable branches https://review.opendev.org/706872 | |
| 15:06:13 | gmann | lyarwood: done ^^. updated with cherry-pick -x | |
| 15:07:38 | Sundar | gibi: Re. https://review.opendev.org/#/c/631244/61/nova/tests/functional/test_servers.py@7621, I have a question. Please LMK when you have a few min. | |
| 15:08:50 | gibi | Sundar: hi! I'm available now | |
| 15:09:02 | dansmith | efried: I'm thinking we should do a release of train now that the hidden instances fix is in, given its criticality | |
| 15:12:32 | efried | dansmith: fine by me. You proposing? | |
| 15:12:57 | dansmith | efried: I can yea, I was just looking to see when we last did it | |
| 15:13:40 | Sundar | gibi: The Cyborg fixture itself is a mock, and is returning pre-fabricated data. Any queries to it will only return the prefabricated data. Specifically, fake_get_arqs_for_instance will return a single bound ARQ in the current implementation, and hence the first 2 assertions will always be true. | |
| 15:13:57 | Sundar | Did you have something else in mind? | |
| 15:14:43 | gibi | Sundar: is this mean that there is no state stored in the fixture that is changed by nova during the boot? | |
| 15:15:34 | efried | Sundar: Re: blocking unsupported operations: If that's the only objection, I feel like we could get around it by making the blockers error 500 rather than 400. We're allowed to "fix a 500" without a microversion if I understand the rules correctly. | |
| 15:15:56 | efried | But if that's not the case, meh. I've backed down from this argument before, won't make a big deal of it now. | |
| 15:16:13 | Sundar | gibi: The only two variables that are from the test case are the host name and device_rp_uuid. I could assert for those. | |
| 15:16:28 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing attach_interfaces policies https://review.opendev.org/705126 | |
| 15:16:55 | gibi | Sundar: yes, those are the thing that is stored in the fixture in the bindings_by_instance | |
| 15:17:10 | gibi | Sundar: asserting only for device_rp_uuid and hostname works for me | |
| 15:17:10 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-attach-interfaces https://review.opendev.org/705799 | |
| 15:17:11 | Sundar | efried: Good. sean-k-mooney, dansmith, gibi: Are we all good if we block the unsupported ops with HTTP 500 as efried said? | |
| 15:17:22 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-atttach-inerfaces policies https://review.opendev.org/706672 | |
| 15:17:38 | dansmith | Sundar: sorry, I'm working on something else, but 500 does not seem appropriate to me | |
| 15:17:42 | efried | rosmaita: Looking. | |
| 15:18:02 | Sundar | gibi: Sure, thanks. | |
| 15:18:08 | rosmaita | efried: ty | |
| 15:18:31 | dansmith | isn't 401/403 the right thing here? tell the user they're not allowed, which could be for any reason which may change in the future (when we allow it or implement it) | |
| 15:18:43 | efried | dansmith: my reasoning is, if you try it before we've coded it up, you're going to get a 500 anyway; it'll just be with some really obscure and hard-to-understand error message. We're just making the 500 understandable as a courtesy before we actually add the support. | |
| 15:18:46 | gibi | efried, Sundar: for qos we used HTTP 400 for rejecting unsupported moves, and we fixed those 400 without new microversion | |
| 15:19:08 | Sundar | dansmith: If it is 400, do we need a microversion change? We are not changing anything, just clarifying what happens with this new feature i.e. accelerator support. | |
| 15:19:10 | efried | okay, I thought that was the objection, that you can't put in explicit blockers and then unblock without a microversion. | |
| 15:20:03 | dansmith | efried: to me 500 means either server-side code needs fixing, or some infra failure in the backend. and converting 500s to 400s is allowed without a microversion because they're all bugfixes | |
| 15:20:07 | efried | I agree strictly it would be best to add support with new microversions, since that's the only way the feature would be discoverable. That makes sense. So... why are we opposed to that strategy in the first place? Just because microversions are a bunch of paperwork? | |
| 15:20:51 | dansmith | making them all 40x now with no microversion is fine with me | |
| 15:21:19 | dansmith | I think the microversion purists would expect a 400->200 to be a microversion because otherwise people can't know whether or not they should try a thing | |
| 15:21:33 | efried | exactly | |
| 15:21:43 | Sundar | dansmith, efried: Agreed. We could do it now without a microversion change. Unblocking in the future will need a microversion change, since it is a change in semantics. | |
| 15:22:09 | dansmith | I'd much rather do the paperwork than cheat with 500 | |
| 15:22:15 | efried | agreed | |
| 15:22:35 | gibi | I'm OK to have 400 -> 200 with microversion, I just remember that I was asked not to do that for qos | |
| 15:22:37 | efried | even leaving it "unsupported" in some way now and then "fixing" without a microversion seems like cheating. | |
| 15:23:00 | efried | gibi: do you remember why? | |
| 15:23:06 | gibi | trying to find it... | |
| 15:23:15 | dansmith | to me, | |
| 15:23:38 | dansmith | a thing that doesn't work because of some subtle detail returning "you can't do that right now" and then later returning "okay now you can" is not a huge violation | |
| 15:23:52 | dansmith | it's an operation that you can do normally, but can't for some policy reason | |
| 15:24:07 | dansmith | so I've never really had a problem with enabling a thing to work by implementing a detail, | |
| 15:24:20 | dansmith | because I think a lot of client code that does this is ignorant of the fact that makes the instance special | |
| 15:25:19 | gibi | efried: http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001881.html | |
| 15:26:03 | dansmith | yup, that ^ :) | |
| 15:26:38 | gibi | mriedem was OK with that too http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001887.html | |