Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-19
19:28:42 mriedem lbragstad: and i'm assuming that keystone-manage bootstrap creates the identity service endpoint in the catalog?
19:28:50 lbragstad it does
19:29:01 mriedem so if hte docs say "--bootstrap-public-url http://controller:5000/v3/"
19:29:12 mriedem then that's probably what the nova docs should use
19:29:25 mriedem or internal url i guess, but they are the same in the docs
19:30:16 mriedem ok i'll push a change to fix the nova install guide docs to remove auth_uri and change auth_url to use port 5000
19:30:20 mriedem thanks
19:32:11 lbragstad mriedem: cool - that's a good idea..
19:32:16 lbragstad i just left a comment on that bug
19:32:51 lbragstad the only things is that people started noticing this when moving from one installation guide to another (and different services were referencing different ports)
19:38:06 mriedem yeah. i've also always been confused by auth_uri and auth_url, glad i wasn't the only one
19:38:25 melwitt mriedem: nova queens 17.0.3 release patch https://review.openstack.org/#/c/562806
19:40:40 mriedem lgtm
19:48:10 jaypipes lol. turning off @safe_connect blows up unit tests but functional tests work just fine...
19:48:40 jaypipes turns out our unit tests are depending on the behaviour of safe_connect hiding placement connectivity problems.
19:50:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Update docs for [keystone_authtoken] changes since Queens https://review.openstack.org/562812
19:54:00 melwitt I'm still +1 on https://review.openstack.org/#/c/560690 but bauzas had some concerns
19:57:57 efried jaypipes: I noticed something like that in https://review.openstack.org/#/c/562060/ (except my func tests failed too, obviously)
20:01:45 mriedem melwitt: i can't tell if bauzas is concerned about the encryption thing that was added, or because of the os-brick masssage-a-roo
20:01:48 mriedem *massage
20:02:40 melwitt I assumed both
20:04:48 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: libvirt: disconnect volume from host during detach https://review.openstack.org/560690
20:05:43 melwitt I think the fix itself is important, we had customers hit the problem and then cfriesen's org also hit the problem. and AFAIK what we did to handle the lack of refactoring stuff and os-brick non lower-constraints stuff was the proper thing to do
20:06:07 mriedem i don't disagree
20:06:14 melwitt *encryption refactoring
20:08:15 mriedem so https://review.openstack.org/#/c/562739/ passed except for an rpc messaging timeout in the live migration job
20:08:28 mriedem given stable/ocata is blocked otherwise, i think i'm going to just fast approve that revert
20:10:22 melwitt k, makes sense
20:10:24 openstackgerrit Eric Fried proposed openstack/nova master: WIP: placement: Granular GET /allocation_candidates https://review.openstack.org/517757
20:12:15 mriedem cfriesen: this might be something you can docify https://bugs.launchpad.net/nova/+bug/1764729
20:12:16 openstack Launchpad bug 1764729 in OpenStack Compute (nova) "doc: live migration missing part about different cpu models/flags" [Medium,Confirmed]
20:30:17 jackie-truong mriedem: For the trusted certs policy rules, since we're looking for a single admin_or_owner rule for all trusted certs related API calls, there's no need to split things up like this?: https://github.com/openstack/nova/blob/master/nova/policies/server_tags.py
20:30:52 jackie-truong Or are splitting individual calls up like that preferred?
20:31:46 melwitt dansmith: wanna send this in for novaclient stable/pike? fixes a user-facing error message https://review.openstack.org/#/c/562392
20:32:56 mriedem jackie-truong: it's not really the same thing, tags are their own resource, we aren't implementing trusted_certs as a subresource on the server resource like that, i.e. POST /servers/{id}/trusted_certs
20:33:26 openstackgerrit Giridhar Jayavelu proposed openstack/nova-specs master: VMware: place instances on resource pool https://review.openstack.org/549067
20:33:29 mriedem jackie-truong: so i think a single policy rule for allowing trusted_certs for POST /servers (server create) and POST /servers/{id}/action (rebuild) is ok
20:33:48 dansmith melwitt: done
20:33:56 melwitt thank ye
20:34:03 mriedem jackie-truong: furthermore, i don't think we need to apply the policy rule to omit 'trusted_certs' from the server response body, it would just always be empty if the user can't create a server with trusted certs
20:34:06 efried melwitt: Sending https://review.openstack.org/#/c/553277/ (sorry for the delay)
20:34:25 openstackgerrit Merged openstack/nova master: Use Queens UCA for nova-multiattach job https://review.openstack.org/554317
20:35:13 jackie-truong mriedem: I think Nova API extension concept was removed in Pike: https://github.com/openstack/nova/commit/f2d18c2e9989f007a6576be6c9a6fcc5bcd67322
20:35:18 melwitt efried: coolness, thanks
20:35:53 mriedem jackie-truong: ? i'm not talking about extensions
20:35:57 jackie-truong For example, security_groups policy rules are deprecated for POST /servers https://github.com/openstack/nova/blob/master/nova/policies/security_groups.py
20:36:01 jackie-truong Sorry, I'm confused
20:36:25 mriedem this is similar, imo, to os_compute_api:servers:attach_volume
20:36:40 mriedem which blocks boot from volume on server create, if for example, you don't have cinder in your cloud
20:36:56 mriedem if i don't have barbican, i can't support trusted certs
20:37:10 mriedem s/barbican/any castellan implementation'
20:38:26 mriedem heh looks like we don't have os_compute_api:servers:attach_volume documented
20:38:42 mriedem oh os_compute_api:servers:create:attach_volume
20:39:17 mriedem jackie-truong: yeah so i'd expect to see a policy rule like os_compute_api:servers:trusted_certs
20:39:21 jackie-truong oh okay, i see
20:39:24 mriedem use that for both server create and rebuild
20:39:36 mriedem and no need to check the policy rule on the response (in the view builder)
20:40:20 mriedem if we wanted to get super granular we could have both os_compute_api:servers:create:trusted_certs and os_compute_api:servers:rebuild:trusted_certs
20:40:28 mriedem i do'nt know why we would need to, maybe edmondsw has a preference
20:40:32 mriedem he dreams about this stuff
20:41:03 openstackgerrit Merged openstack/nova stable/ocata: Refactor a test method including 3 test cases https://review.openstack.org/561603
20:41:16 edmondsw lol
20:41:33 mriedem you know it's true, waking up in a sweat,
20:41:38 edmondsw why are we creating a policy for this?
20:41:39 mriedem "what was it honey? bad dream?"
20:41:42 mriedem "POLICY?!!?!"
20:41:49 edmondsw definitely a bad dream
20:42:03 mriedem edmondsw: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129494.html
20:42:23 edmondsw I saw that, haven't gotten to replying... but seems more like a conf than policy thing
20:42:32 dansmith heh
20:42:36 edmondsw policy is when you want to allow some folks to do it but not others
20:42:45 edmondsw not when you want to enable/disable something entirely
20:42:59 edmondsw did I misunderstand?
20:43:24 mriedem well,
20:43:25 dansmith 🍿
20:43:26 jaypipes zzzeek_: noticed this littering unit test output nowadays: http://paste.openstack.org/show/719587/. I'm actually not sure how to fix... any ideas?
20:43:36 mriedem consider you have some tenants that want/can do the trusted certs thing,
20:43:53 mriedem and you have those tenants tied to host aggregates via the tenant isolation multitenancy filter
20:43:59 melwitt well, can be both right? if one cloud wants to disable something but another wants to enable it, having it controlled by policy at least gives a consistent behavior where you can get 403 if you're not allowed or if that cloud doesn't allow
20:44:02 mriedem and you know those hosts are configured for cert validation
20:44:11 mriedem melwitt: yes
20:44:23 mriedem i'm looking for consistent api behavior with a 403
20:44:45 edmondsw ok, so that's what I missed... you DO want to allow it for some folks and not for others in a single cloud
20:44:59 melwitt dansmith: good job putting emoji in here, didn't know we could do that
20:45:25 dansmith melwitt: really? cdent does it incessantly
20:45:30 openstackgerrit Merged openstack/os-traits master: GPU: define traits for maximum display heads https://review.openstack.org/553277
20:45:53 melwitt oh, that checkmark thing. I have seen that
20:45:57 edmondsw dansmith cdent who wants to teach the rest of us? ;)
20:46:13 dansmith um.. paste?
20:46:20 melwitt but the popcorn has at least three colors in it
20:46:26 edmondsw oh, that simple
20:46:28 dansmith https://emojipedia.org/popcorn/
20:46:31 dansmith click copy
20:46:33 dansmith then paste
20:46:35 dansmith it's like
20:46:37 dansmith rocket surgery
20:46:45 edmondsw lol
20:46:50 melwitt wah, that's hard
20:47:49 zzzeek_ jaypipes: this is the context for that: https://bitbucket.org/zzzeek/sqlalchemy/commits/63a7b2d2d940#chg-test/orm/test_evaluator.py
20:48:05 zzzeek_ jaypipes: it means you are doing query.update({Object.foo = column('bar')})

Earlier   Later