Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-14
17:49:14 bauzas dansmith: and I said 'well, let's not overthink over that API, it's the operator's responsibility to stuff in it'
17:49:22 mriedem bauzas: do they counter the capacity management argument with "we'll just use watcher to fix things in post"
17:49:41 bauzas watcher never went into discussion
18:11:06 openstackgerrit sean mooney proposed openstack/nova master: block rebuild when numa topology changed https://review.opendev.org/687957
18:11:07 openstackgerrit sean mooney proposed openstack/nova master: Disable NUMATopologyFilter on rebuild https://review.opendev.org/689861
18:37:33 efried What does "signed-off-by" actually mean in a commit message, to those who care about it?
18:38:20 jroll efried: it means it was signed by that person's GPG key
18:38:39 jroll wait, no
18:39:28 jroll https://git-scm.com/docs/git-commit#Documentation/git-commit.txt--s
18:39:46 efried specifically for the vtpm patch, which bears almost no resemblance to when it was last touched by cfriesen or Paul-Emile, I'm wondering if I should remove their Signed-off-by lines
18:40:10 jroll I think I would
18:40:25 efried I was actually considering putting it under a new change-id.
18:40:38 efried but decided no harm in having the history in one place.
18:40:55 dansmith efried: S-o-B is a legal construct from the linux kernel community
18:41:16 dansmith efried: it's their accepted mechanism to declare that you have permission to submit the code you're submitting
18:41:40 dansmith some people have hooks in their git config to add it automatically, and/or some orgs may require people to put it in there regardless of the community for some perceived legal shield
18:42:07 efried Okay. So it's really only relevant when it's the same as the uploader for a given patch set, because otherwise it's n/a whether you have permission to submit, because you're not submitting.
18:42:43 dansmith well, not quite
18:42:47 efried Really in the case of openstack gerrit, you've already declared that by signing the things, which are a prereq to being able to submit code at all.
18:43:01 dansmith right which is why it's just noise for our patches
18:43:04 dansmith and really shouldn't be in there
18:43:33 efried ack, makes sense. I'll just axe it.
18:43:55 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Add emulated TPM support to Nova https://review.opendev.org/631363
18:43:55 openstackgerrit Eric Fried proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files https://review.opendev.org/639934
18:44:58 efried jroll: I should do a visual inspection quick, but I think the bottom patch ^ is "done" from the impl & docs side. Test is basically not started, but if you want to skim the non-test bits and let me know if anything stands out horribly, that would be helpful.
18:45:12 efried dansmith: I fully expect you to say "split this sucker".
18:45:13 jroll efried: can do today or tomorrow sometime
18:45:19 efried jroll: cool, thanks.
18:45:36 dansmith efried: noted
18:53:19 sean-k-mooney by the way anyone know what might be preventing us form using self.assertRaises in nova as a context manager
18:53:33 sean-k-mooney i have worked around it for now
18:54:02 sean-k-mooney but i suspect we have some legcy code form the py2.6 days
18:54:44 sean-k-mooney im doing "with self.assertRaisesRegex(ValueError, '.*'):" instead for now
19:07:07 efried dansmith, mriedem: offhand, do you have a problem adding a context param to the `unrescue` compute driver method?
19:07:15 efried Will heads-up the ML etc.
19:07:43 dansmith what I have a problem with is notifying the ML when we change an internal interface
19:07:46 dansmith but otherwise, no
19:08:50 sean-k-mooney well its a heads up not asking permission but i get what you mean
19:08:59 efried Heh, it has ever been thus.
19:09:38 efried I have the scars from my initial contact with nova when the oot powervm driver was my whole world.
19:09:44 sean-k-mooney i ment the ml message by they way
19:10:08 sean-k-mooney yes is anyone looking after that now
19:11:15 sean-k-mooney i found out recently a vendor is bypassing the blocks we put in place to prevent people form import stuff form the os-vif internal module
19:11:17 efried yeah, there's a new team struggling to come to grips with it.
19:11:53 efried barely treading water keeping up with nova changes that break it, and still trying to resurrect the CI.
19:15:56 mriedem it's only a problem for tonyb
19:22:09 openstackgerrit Merged openstack/nova master: Filter duplicates from compute API get_migrations_sorted() https://review.opendev.org/636224
19:24:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Block deleting compute services with in-progress migrations https://review.opendev.org/694389
19:30:04 openstackgerrit Matt Riedemann proposed openstack/nova master: Block deleting compute services with in-progress migrations https://review.opendev.org/694389
19:43:00 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Fail compute service delete if resource provider delete fails https://review.opendev.org/678100
19:52:25 openstackgerrit Merged openstack/nova master: Start functional testing for cross-cell resize https://review.opendev.org/636253
19:52:34 openstackgerrit Merged openstack/nova master: Helper to start computes with different HostInfos https://review.opendev.org/686832
20:11:13 mriedem dansmith: can you hit these 3 bug fix backports to train from gibi https://review.opendev.org/#/q/owner:balazs.gibizer%2540est.tech+status:open+project:openstack/nova+branch:stable/train ?
20:11:25 mriedem i think at least 2 of those still have to go to stein
20:14:22 efried mriedem: grenade seems very ill lately. Do we have any idea what the deal is, yo?
20:16:22 dansmith mriedem: so, there was a bug recently under security review that makes me think about this stuff now...
20:16:46 mriedem efried: yes
20:16:54 mriedem efried: have you seen my recent state of the gate thread?
20:17:14 mriedem dansmith: the qos ports stuff?
20:17:21 efried mriedem: Recent like a week or two ago? Yes.
20:17:28 mriedem efried: yeah halloween
20:17:30 dansmith mriedem: any chance the user could provide someone else's port id and get access to it or even just validate that they guessed right?
20:17:33 mriedem efried: same problems, no progress
20:17:38 efried mmph
20:17:50 dansmith mriedem: I'm not sure what the actual call path on this actual patch is,
20:17:57 mriedem dansmith: provide where? during server create?
20:17:59 dansmith but the move to using an admin client makes me think..
20:18:14 dansmith mriedem: either there or anything that calls this
20:18:30 mriedem ports are under a project so you'd have to be able to GET the port given your token
20:19:02 mriedem fwiw we use admin client all over the place for dealing with ports b/c the binding stuff is admin-only by default policy in neutron
20:19:17 dansmith mriedem: I know we do and that was the problem this other bug indicated
20:19:32 mriedem i think the resource_request stuff is the same issue - admin only like port binding details
20:20:27 dansmith I don't understand how we've gotten to this point but it seems kinda wrong
20:21:12 mriedem if it makes you feel better, ports are better protected than volume attachments - those leak host connector details weeeee
20:21:56 mriedem https://bugs.launchpad.net/cinder/+bug/1740950
20:21:56 openstack Launchpad bug 1740950 in Cinder "Volume details shows attached compute host for non-admins" [Undecided,New]
20:22:24 sean-k-mooney the port binding_profile is admin only by default as only nova or ironic e.g. not an end user should ever write to it
20:22:36 sean-k-mooney and the binding_detials are readonly i think
20:23:03 mriedem the volume attachment stuff is admin or owner ever since the nova/cinder split
20:23:20 mriedem because that's how nova gets the connection_info and passes the host connector
20:23:50 mriedem changing that now would break a lot of deployments unless they configured nova with service creds to talk to cinder with an admin role, which is what we've required for working with neutron b/c of port binding details since forever
20:23:54 sean-k-mooney ya whcih is not ideal as that means your ceph mon ips/fqdns are exposed
20:24:02 sean-k-mooney among other things
20:29:35 dansmith mriedem: I hope it's clear that I'm not arguing that this is doing something new, or not consistent with behavior "since forever", just that the other bug made me think about how often we use the neutron admin client to do stuff on behalf of the user and wonder why that's not a problem
20:31:40 mriedem i suspect it's not a problem b/c the non-admin can't GET the port details with the host binding details
20:31:41 sean-k-mooney dansmith: in the port bining case you are not exactly doing it on behalf of the user in all cases. nova is setting admin only filed to comninciate infomation to neutron that the network backend needs to know to wire up the port that the teant should not known
20:31:51 sean-k-mooney mriedem: yep
20:32:16 mriedem unlike that volume attachment bug
20:32:50 dansmith sean-k-mooney: yeah, understand that for the binding case
20:33:32 sean-k-mooney for what its wroth im not realy sure why we chose to make the port resouce requests admin only
20:33:48 sean-k-mooney the allocations sure
20:33:53 mriedem huh, looks like as a non-admin I can also do GET /v3/{project_id}/attachments/{attachment_id} on any volume attached to my server and get the host connection info
20:33:57 mriedem which is great
20:34:12 sean-k-mooney well that is needed for standalone cinder
20:34:20 mriedem heh
20:34:21 mriedem ok
20:34:23 mriedem ..
20:34:30 mriedem there is no policy rule on GET /v3/{project_id}/attachments/{attachment_id}
20:34:33 openstackgerrit Merged openstack/nova master: libvirt: Ignore DiskNotFound during update_available_resource https://review.opendev.org/685391
20:34:37 sean-k-mooney i assume you mean the conintion info

Earlier   Later