| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-14 | |||
| 17:48:35 | efried | okay, but not "everywhere that touches flavors" (internally). | |
| 17:48:49 | bauzas | dansmith: I exacly had that concern ! | |
| 17:48:56 | dansmith | so when we do that, it will be not very usable even by the people that think they want it, and we will have to iterate | |
| 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 | .. | |