| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 21:54:49 | dansmith | well, john and I have been hitting that hard in the last day expecting to get it in, but I dunno. I guess we'll wait for melwitt to get back and advise | |
| 22:09:05 | bauzas | if someone could tell me how we can raise keystoneclient.Unauthorized exceptions when calling https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/session.py#L616 ... | |
| 22:09:24 | bauzas | I'm puzzled | |
| 22:09:51 | bauzas | mmmmmpf nvm https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/session.py#L652 | |
| 22:14:39 | bauzas | mriedem: still around? | |
| 22:15:16 | bauzas | mriedem: I'd love more context about https://review.openstack.org/#/c/416810/ | |
| 22:20:07 | mriedem | bauzas: context how? | |
| 22:20:09 | mriedem | did you read the bug report? | |
| 22:20:37 | mriedem | or the related change - nova.conf was misconfigured for how to connect to placement for awhile with keystone v3 | |
| 22:20:41 | mriedem | so you'd get 401 | |
| 22:21:11 | bauzas | mriedem: yup, saw the change in devstack lib/placement | |
| 22:21:33 | bauzas | but I'm hitting the same 401 in grenade job | |
| 22:22:19 | bauzas | AFAICS, the value is still "Default" https://github.com/openstack-dev/devstack/blob/7a1e6f042f00ac94ec30bb8c6bf5d05b34623832/lib/keystone#L107 | |
| 22:24:21 | mriedem | not sure, would have to see that everything is configured the same and if not, what's different and what's missing | |
| 22:24:26 | mriedem | but i'm taking maya to the pool so back in a few hours | |
| 22:25:08 | bauzas | no worries | |
| 23:15:59 | bauzas | dansmith: still around? | |
| 23:16:23 | bauzas | dansmith: I wonder if we don't run init_placement() method within grenade | |
| 23:16:58 | bauzas | just verifying the grenade log, but in case you know... | |
| 23:17:00 | dansmith | bauzas: if you don't see it, then we don't | |
| 23:17:16 | dansmith | bauzas: if we don't in neutron devstack, and you don't see it in grenade then, we don't | |
| 23:17:42 | bauzas | sec, verifying the grenade deployment | |
| 23:18:52 | bauzas | dansmith: confirmed | |
| 23:19:03 | bauzas | dansmith: can't find it in http://logs.openstack.org/30/424730/6/check/gate-grenade-dsvm-neutron-ubuntu-xenial/16175d7/logs/grenade.sh.txt.gz | |
| 23:19:29 | bauzas | lemme fix that quickly | |
| 23:20:47 | bauzas | dansmith: do you think we should do that in the from_newton script or in upgrade.sh ? | |
| 23:21:26 | dansmith | from-newton | |
| 23:22:25 | bauzas | ok | |
| 23:23:51 | bauzas | dansmith: done editing | |
| 23:24:11 | bauzas | dansmith: I'll have to bail out soon, I need to wake up early | |
| 23:24:18 | dansmith | okay | |
| 23:24:30 | bauzas | but in case it works, could you please look at the change ? | |
| 23:24:49 | bauzas | I'll review your own change tomorrow morning | |
| 23:25:34 | dansmith | grr | |
| 23:25:34 | dansmith | cripes I keep failing this one test, but nothing has changed since it was passing | |
| 23:26:00 | bauzas | which one ? | |
| 23:27:03 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/424828 | |
| 23:28:30 | dansmith | bauzas: go to sleep | |
| 23:28:37 | openstackgerrit | Sylvain Bauza proposed openstack/nova: Fix server group functional test by using all filters https://review.openstack.org/425185 | |
| 23:28:37 | openstackgerrit | Sylvain Bauza proposed openstack/nova: Scheduler calling the Placement API https://review.openstack.org/417961 | |
| 23:28:48 | bauzas | voila... all the changes are now rebased | |
| 23:29:34 | bauzas | dansmith: I'll at least wait a few mins to see if we have at least one grenade job done | |
| 23:32:18 | dansmith | oh jeez | |
| 23:36:22 | openstackgerrit | Dan Smith proposed openstack/nova: Move instance creation to conductor https://review.openstack.org/319379 | |
| #openstack-nova - 2017-01-26 | |||
| 00:44:36 | openstackgerrit | Takashi NATSUME proposed openstack/nova: Enable cold migration with target host(1/2) https://review.openstack.org/408955 | |
| 00:44:49 | openstackgerrit | Takashi NATSUME proposed openstack/nova: Enable cold migration with target host(1/2) https://review.openstack.org/408955 | |
| 00:45:59 | openstackgerrit | Takashi NATSUME proposed openstack/nova: Enable cold migration with target host(2/2) https://review.openstack.org/408964 | |
| 00:46:58 | openstackgerrit | Takashi NATSUME proposed openstack/nova: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 00:47:26 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient: Microversion 2.42 - Enable cold migration with target host https://review.openstack.org/406707 | |
| 00:47:54 | openstackgerrit | Takashi NATSUME proposed openstack/nova: Add functional tests for cold migration to same host https://review.openstack.org/414926 | |
| 00:58:08 | alex_xu | gmann: johnthetubaguy if we think 403 is behaviour change. Then this is a behaviour change https://review.openstack.org/#/c/415142/33/nova/api/openstack/compute/servers.py@1230 ? | |
| 00:58:15 | alex_xu | Kevin_Zheng: ^ | |
| 00:59:57 | alex_xu | gmann: johnthetubaguy but expose host and node to the user is kind of bug fix. it isn't same case with all_tenants which is filter we support it public | |
| 01:00:09 | alex_xu | s/bug fix/bug/ | |
| 01:05:01 | dansmith | melwitt: this is good again: https://review.openstack.org/#/c/319379/ | |
| 01:05:17 | dansmith | melwitt: I broke it in a very subtle way when fixing johnthetubaguy's comment, but it's good now | |
| 01:13:09 | mriedem | did bauzas get the grenade thing figured out? | |
| 01:13:47 | mriedem | dansmith: simple change needed in https://review.openstack.org/#/c/424243/ and then i'm +2 | |
| 01:14:08 | dansmith | mriedem: we're waiting for a run I think | |
| 01:16:07 | gmann | alex_xu: | |
| 01:16:15 | gmann | alex_xu: humm, | |
| 01:17:22 | dansmith | mriedem: | |
| 01:17:34 | dansmith | gah | |
| 01:17:53 | mriedem | _LW _MFER | |
| 01:18:13 | openstackgerrit | Dan Smith proposed openstack/nova: Only warn about hostmappings during ocata upgrade https://review.openstack.org/424243 | |
| 01:18:18 | dansmith | there | |
| 01:21:05 | gmann | alex_xu: IMO, that as bug fix makes it valid | |
| 01:24:10 | oomichi | alex_xu: Does it mean the patch changes 403 to 400 ? | |
| 01:26:13 | oomichi | alex_xu: we are discussing error status code changes on https://review.openstack.org/#/c/421846 . I am ok to allow error status code changes anyways | |
| 01:26:30 | openstackgerrit | Dan Smith proposed openstack/nova: Only warn about hostmappings during ocata upgrade https://review.openstack.org/424243 | |
| 01:29:33 | gmann | oomichi: policy change for all_tenant will change 403->200 | |
| 01:29:53 | gmann | oomichi: so its kinnda behavior change | |
| 01:30:37 | gmann | oomichi: and on sort key change it is bug fix (not expose host and node to non admin user) and 200->400 | |
| 01:31:02 | gmann | alex_xu: correct me if am wrong on sort key which used to me 200 now? | |
| 01:32:54 | oomichi | gmann: humm, 200->400 seems against on changing policy: "The following types of changes are generally **not** considered acceptable:" | |
| 01:33:18 | oomichi | "A change such that a request which was successful before now results in an error response" | |
| 01:33:49 | oomichi | if that is not security bug | |
| 01:34:56 | oomichi | gmann: "not expose host and node to non admin user" seems a little bit security thing, which means abstraction doesn't work correctly for non-admin users | |
| 01:35:08 | mriedem | melwitt: this is an easy one https://review.openstack.org/#/c/424243/ | |
| 01:35:09 | oomichi | but I am not sure at this time | |
| 01:37:52 | gmann | oomichi: yea that seems security bug for me too. but johnthetubaguy alex_xu mriedem can give better feedback on this - last paragraph in https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/add-whitelist-for-server-list-filter-sort-parameters.html#proposed-change | |
| 01:39:24 | oomichi | gmann: yeah I see "For the non-admin user, the sort key ‘host’ and ‘node’ will be excluded. Those two columns are about the cloud internal. It can’t be leaked to the end user." | |
| 01:41:56 | oomichi | gmann: if we consider it as security issue, the bug should be fixed on stable branches. But we need different patch for fixing it because it is difficult to backport the whole patches related to the bp | |
| 01:43:03 | gmann | oomichi: hummm | |
| 01:46:07 | gmann | alex_xu: johnthetubaguy oomichi on policy all_tenant changes, should we first change the spec ? - https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/add-whitelist-for-server-list-filter-sort-parameters.html#rest-api-impact | |
| 02:04:44 | melwitt | dansmith: I left a comment on https://review.openstack.org/#/c/319379/ it looks like the IBM CI failure might be legit, OrphanedObjectError raised from L1790 | |
| 02:05:12 | melwitt | I don't yet understand how the instance could be orphaned at that point | |
| 02:19:04 | alex_xu | oomichi: yea, just as gmann said, this probably is a fix for key we didn't want to expose. I feel that is different with all_tenants | |
| 02:20:00 | alex_xu | gmann: i'm not sure about the spec. but give th time i'm not sure we can get all thing done. maybe worth a email also to get widely suggestion | |
| 02:20:14 | mriedem | dansmith: bauzas: jaypipes: well it looks like the scheduler + placement stuff is failing grenade multinode because of this test: | |
| 02:20:15 | mriedem | https://github.com/openstack/tempest/blob/8bdd42766a7f02180d07e6ab75f0914e5d876a91/tempest/scenario/test_server_multinode.py#L49 | |
| 02:20:16 | gmann | alex_xu: i did not fully understood your comment about capability discovery on this https://review.openstack.org/#/c/415330/24 | |
| 02:20:26 | mriedem | i believe because we have 2 computes, but one is newton and one is ocata, and the newton one doesn't have placement configured, | |
| 02:20:45 | mriedem | so when the scheduler tries to place an instance on the newton compute, the scheduler pukes because there isn't a resource provider for that node | |
| 02:21:22 | gmann | alex_xu: you mean 403->200 is ok to change and discover with capabilities of all_tenant ? | |
| 02:21:36 | gmann | alex_xu: correct me if other way around | |
| 02:21:41 | alex_xu | gmann: whether the user is allowed to execute on a API, that should be discovered by capabilities discovery https://review.openstack.org/386555 | |
| 02:21:49 | owalsh | dansmith, mriedem, melwitt: big thanks for https://review.openstack.org/424243 | |
| 02:22:33 | dansmith | mriedem: with my backported change the newton one should keep trying | |
| 02:22:42 | dansmith | mriedem: this: https://review.openstack.org/#/c/419217/ | |