Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-23
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 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:35 sahid jaypipes: could you ack https://review.openstack.org/#/c/400874 i repin it to change the variable name
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
11:15:59 bauzas and we're not emulating a socket, we *run* it
11:16:08 bauzas which makes possible to debug the app outside of the test
11:16:26 bauzas but meh.
11:16:58 bauzas anyway, back to work
11:17:00 cdent okay, but when the placement api runs for real, it doesn't use any of the nova Server() handling
11:23:11 openstackgerrit Bob Ball proposed openstack/nova: Use physical utilisation for cached images https://review.openstack.org/353862
11:25:00 openstackgerrit Claudiu Belu proposed openstack/nova: hyper-v: Adds support for VMs with nested virtualization https://review.openstack.org/398509
11:26:42 cdent bauzas: I've got a couple questions on the CoreFilter issue that are probably easier to track here than email. You got time to answer them now or should I just post a response to the email?
11:27:25 bauzas cdent: just throw me a bit of them
11:29:02 cdent In the world before Placement API existed, if I disabled the CoreFilter, that means that select_destinations could return some compute nodes that would reject a "placement" and cause a retry because it didn't have enough cores. Is that right?
11:31:28 openstackgerrit Alex Xu proposed openstack/nova: Limit the min length of string for integer JSON-Schema https://review.openstack.org/415103
11:31:47 cdent bauzus: If it is right, then asking the placement api for vcpu resources is simply short circuiting that retry and we should do that?
11:31:57 johnthetubaguy alex_xu: I would expect no policy.json file in a new install, empty I guess is OK too.
11:32:12 alex_xu johnthetubaguy: got it, thanks
11:32:13 johnthetubaguy alex_xu: in the future I was thinking a fully commented out yaml file, a bit like what we do for config
11:32:27 alex_xu johnthetubaguy: ok
11:33:26 alex_xu johnthetubaguy: I probably figure out a way to implement the 3 cases you pointed out. so I will work with Kevin_Zheng to update the patch.

Earlier   Later