| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-23 | |||
| 09:55:11 | pkoniszewski | hello, can I have some eyes on this series https://review.openstack.org/#/q/topic:lm-downtime ? Freeze is near, those 3 are simple patches to increase live migration success rate and reduce configuration complexity | |
| 09:55:46 | Kevin_Zheng | alex_xu: you can represent me :), I'm about to driving | |
| 09:56:17 | alex_xu | Kevin_Zheng: yea, just focus on driving :) | |
| 09:58:36 | mikal | were | |
| 09:58:42 | mikal | Doh, sorry | |
| 10:03:30 | snikitin | BobBall: thank you for review! | |
| 10:03:53 | BobBall | snikitin: Thank you for your perseverence with the CI ;) | |
| 10:04:25 | gmann | alex_xu: hi | |
| 10:04:43 | gmann | alex_xu: actually problem is we cannot not know whether rule is overridden or not right? | |
| 10:04:57 | bauzas | johnthetubaguy: hola, got a sec ? | |
| 10:05:13 | bauzas | johnthetubaguy: not sure you saw my ML thread about the placement API | |
| 10:05:33 | gmann | alex_xu: it can be with same default value RULE_ADMIN_API and operator can claim this was our overridden value why you broke us | |
| 10:05:41 | bauzas | johnthetubaguy: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110661.html | |
| 10:05:57 | alex_xu | gmann: I thought we have some way, just like this https://github.com/openstack/oslo.policy/blob/master/oslo_policy/generator.py#L216 | |
| 10:06:02 | bauzas | johnthetubaguy: but I'd love your operator insights, in particular wrt the CachingScheduler | |
| 10:07:51 | gmann | alex_xu: yea but if they have overridden with RULE_ADMIN_API then they expect to work on same way which makes 1st and 2nd case same | |
| 10:08:11 | openstackgerrit | Duong Ha-Quang proposed openstack/nova: Remove mox in nova/tests/unit/compute/test_shelve.py (3) https://review.openstack.org/342648 | |
| 10:09:33 | gmann | alex_xu: making old rule to RULE_ANY breaks the old operator as johnthetubaguy pointed | |
| 10:11:35 | alex_xu | gmann: so we expect 1st and 2nd cases work as old behaviour? | |
| 10:12:01 | lyarwood | reviews on the following findmnt removal change would be appreciated if anyone has time, currently hitting EL based distros pretty hard - https://review.openstack.org/#/c/420146/ | |
| 10:12:10 | gmann | alex_xu: only 1st but it is hard to differentiate those cases | |
| 10:12:50 | alex_xu | gmann: so we expect 2nd case as new behaviour | |
| 10:13:23 | gmann | alex_xu: yea | |
| 10:14:13 | alex_xu | gmann: if we can check whether there is override, then we can implement all three cases. | |
| 10:15:12 | gmann | alex_xu: even override with default value we consider that as 1st case right ? | |
| 10:15:49 | alex_xu | gmann: yes, I think it is fine | |
| 10:16:11 | alex_xu | gmann: that is way for operator to enforce a old behaviour | |
| 10:16:29 | gmann | alex_xu: so how to check if overridden ? | |
| 10:16:58 | alex_xu | gmann: i'm thinking this way https://github.com/openstack/oslo.policy/blob/master/oslo_policy/generator.py#L176 | |
| 10:17:37 | alex_xu | gmann: if the rule in the enforcer.file_rules, then it should mean the rule in the policy.json | |
| 10:19:35 | sahid | jaypipes: could you ack https://review.openstack.org/#/c/400874 i repin it to change the variable name | |
| 10:19:35 | gmann | alex_xu: but i think we say, generate the policy with all default rules and then override if needed, it means all rules will be in policy.json ?(not sure how operator prepare policy.json) | |
| 10:19:56 | gmann | i am just assuming how people use config file | |
| 10:24:20 | alex_xu | gmann: we expect the policy.json empty. the policy.json should only have override rule | |
| 10:24:21 | gmann | alex_xu: like this - http://docs-draft.openstack.org/30/415330/16/check/gate-nova-docs-ubuntu-xenial/13f51ca//doc/build/html/sample_policy.html | |
| 10:24:36 | gmann | alex_xu: and operator just override the interested one | |
| 10:24:58 | gmann | alex_xu: but m not sure about that this is how they use or they have only overriden rules in policy.json | |
| 10:27:13 | alex_xu | gmann: if the user really have override rule, there will be a warning message :) | |
| 10:28:31 | gmann | alex_xu: yea that case is fine as you said but if anyone assuming overridden rule even with default value only and expect to work same way | |
| 10:29:10 | gmann | they do not believe the nova policy default values and want to make sure by overriding the rule even with same default value | |
| 10:30:04 | claudiub|2 | sfinucan: moshele: hello. If you have a tiny bit of time, can you take a look at the hyper-v pci passthrough patch? it is quite small too: https://review.openstack.org/#/c/420614/ | |
| 10:32:07 | sfinucan | claudiub|2: Just back from vacation so I'm chowing down on (a crazy amount of) mails and other reviews. If you stick me on the review though, I'll aim to get around to it today or tomorrow | |
| 10:32:39 | claudiub|2 | sfinucan: sure, ty. :) | |
| 10:34:01 | alex_xu | gmann: emmm....maybe johnthetubaguy and sdague can ensure that whether we expect a empty policy.json for new installation | |
| 10:35:27 | mdbooth | sfinucan: Looking now. | |
| 10:36:35 | mdbooth | sfinucan: Incidentally, this one needs to get into Ocata: https://review.openstack.org/#/c/423392/ . It's a continuation of a previous code removal. Needs to be phased for upgrades, hence need for Ocata. | |
| 10:36:50 | mdbooth | It's very simple. | |
| 10:37:37 | sfinucan | mdbooth: Sure thing. I'll chuck that on my review queue :) | |
| 10:41:03 | gmann | alex_xu: yea, that will be nice to know for me too | |
| 10:47:19 | moshele | claudiub|2: sure I will take a look later today | |
| 10:51:33 | cdent | bauzas, jaypipes : was just reading back through the log about something to do with noauthmiddleware and fixtures and placement, but can't really piece together the gist. Were you able to work things out? | |
| 10:51:45 | bauzas | cdent: I fixed the problem | |
| 10:52:01 | bauzas | cdent: it was merged on Friday by adding a PlacementFixture | |
| 10:52:39 | cdent | bauzas: In any case there is a functional test of placement api that does not use gabbi: https://github.com/openstack/nova/blob/master/nova/tests/functional/api/openstack/placement/test_report_client.py | |
| 10:52:40 | bauzas | cdent: now I have another question about having resource usage call being optionals given the existing filters | |
| 10:52:55 | bauzas | cdent: I know | |
| 10:53:01 | cdent | bauzas: and the noauthmiddleware is _not_ something I wrote special, it is the nova one adapted | |
| 10:53:06 | cdent | do you have a link to the new fixture? | |
| 10:53:12 | cdent | (I mean the review that made it) | |
| 10:53:15 | bauzas | cdent: the problem was with the existing other functional tests that call the scheduler | |
| 10:53:35 | bauzas | cdent: see nova.fixtures.PlacementFixture | |
| 10:53:39 | cdent | Yeah, I've seen the mail about the optionals, it's next on my list to look at more closely | |
| 10:53:56 | bauzas | cdent: I'll be pushing a new PS by today | |
| 10:54:00 | cdent | cool | |
| 10:54:06 | bauzas | that would +1 the functional tests | |
| 10:55:02 | bauzas | I had a shit ton of problems related to the functional tests, but that's done | |
| 11:02:32 | cdent | bauzas: did you consider using wsgi-intercept (as in the pre-existing functional test) instead of doing a server.run()? | |
| 11:02:45 | bauzas | yup | |
| 11:02:59 | cdent | and that wouldn't work? | |
| 11:03:06 | bauzas | but we agreed with sdague on using the Server directly | |
| 11:03:22 | bauzas | cdent: honestly, that looks a nit | |
| 11:03:37 | cdent | I'm not complaining, I'm just trying to understand the decision process | |
| 11:03:40 | bauzas | cdent: given the short deadline, I don't want to discuss again about it | |
| 11:03:49 | bauzas | yeah, I can understand | |
| 11:03:58 | bauzas | but sometimes you need to find solutions that work easily | |
| 11:06:04 | hachi | hello | |
| 11:06:15 | bauzas | cdent: just one point | |
| 11:06:26 | bauzas | cdent: I'm not sure I like https://github.com/openstack/nova/blob/master/nova/tests/functional/api/openstack/placement/test_report_client.py#L89-L92 | |
| 11:06:42 | bauzas | cdent: because we are mocking an internal attribute here | |
| 11:06:44 | hachi | how i can use the policy: | |
| 11:06:50 | hachi | "owner" : "user_id:%(user_id)s" | |
| 11:06:59 | hachi | in nova api 2.1 | |
| 11:07:09 | bauzas | cdent: in case keystone changes its interface, we wouldn't have mock complaning at all | |
| 11:07:15 | hachi | with newton release | |
| 11:07:18 | bauzas | cdent: but then we would have huge problems | |
| 11:07:53 | bauzas | cdent: I rather preferred to use the keystone public way of avoiding the SC | |
| 11:08:17 | cdent | keystoneauth1 has made a commitment to not change the interface on its public methods without changing the entire name of the package? | |
| 11:08:21 | bauzas | but like I said previously, that looks a nit to me and we could discuss on that later on | |
| 11:08:38 | bauzas | cdent: sure, we can trust them | |
| 11:08:47 | bauzas | cdent: that's just riskier, that's it | |
| 11:08:52 | bauzas | anyway | |
| 11:09:17 | cdent | and even if it did break, we could just fix it when it broke: the tests will have done their job in that case | |
| 11:09:19 | bauzas | I'm totally up discussing on that after FF :) | |
| 11:09:52 | bauzas | probably we could accept not to fake our scheduler client methods and rather mock the Service object | |
| 11:10:22 | bauzas | but I think we could still use the Server proxy to really run an wsgi server and not intercept | |
| 11:10:47 | bauzas | but that's my thoughts - just coming along while tests are running on my local desktop and that I have a bit of time :) | |
| 11:11:46 | cdent | Out of curiosity why do you prefer the server proxy? | |
| 11:14:58 | bauzas | cdent: because that's running our internals | |
| 11:15:13 | cdent | What are "our internals"? | |
| 11:15:21 | bauzas | internal piece of code | |