Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-08-31
16:13:47 dansmith sean-k-mooney: not because it's a good idea :)
16:14:10 gibi dansmith: actually I think that is what happened before consumer_types
16:14:47 gibi dansmith: project_id user_id and consumer creation was each in a separate transaction, then a single transaction created / updated the allocation
16:15:04 dansmith gibi: ah, so this is more fallout from that work?
16:15:09 gibi it seems so
16:15:16 dansmith okay
16:15:22 gibi dansmith: this changed, now the whole PUT /allocations is a single DB transaction
16:15:40 dansmith for something like the project record, it makes sense to do that in a separate transaction I think
16:15:45 gibi and when that transaction founds a duplicate project it dies even if we catch the exception from sqla
16:15:48 sean-k-mooney i wonder if we shoudl drop those tables in the future and just store the uuids direcly in the allcoation table
16:15:51 dansmith gibi: further explains the large-ness of the transaction being a problem I guess
16:16:00 bauzas dansmith: that's why I nearly consider this as a regression
16:16:13 dansmith bauzas: definitely sounds like a regression
16:16:19 bauzas we stepped into this mess in Xena
16:16:39 dansmith sean-k-mooney: only if we want it to be slower and more bloated I think :)
16:16:39 opendevreview Merged openstack/nova master: Parse extended resource request from the port data https://review.opendev.org/c/openstack/nova/+/800085
16:17:15 gibi the reason this become a single transaction is that consumer_type can be updated during PUT /allocations and if that happens in a separate transaction then we leak the update
16:17:17 sean-k-mooney well right now we are going to have to do a select by uuid to get the id in the project/user tabel then join based on that to the allcoation
16:17:39 bauzas I have no idea because I haven't looked at code yet, but is it crazy to switch back to the 2-step transactional model we had before ?
16:17:50 dansmith gibi: but we're just recording projects for relational purposes, so even if the allocation put doesn't succeed, it's fine that we've created the project record right?
16:17:51 sean-k-mooney so im not sure it would be slow to just to a select againt the allcoation table directly with an index on the user_id/project_id columns
16:18:00 bauzas ie. get the projet or create it, first, then do the allocation update
16:18:10 gibi dansmith: yes, for project and user it is fine, for consumer_type it is not fine
16:18:14 bauzas into two transactions
16:18:16 dansmith gibi: right
16:19:03 gibi so we can move back to many transactions but then we need to figure out how to move the consumer_type update to the last big transaction
16:19:19 dansmith yeah, which is surgery for sure
16:19:36 dansmith was melwitt the one that wrote the consumer type patches?
16:19:40 dansmith maybe we should get her consult
16:19:51 gibi it was melwitt who updated it after cdent left
16:20:03 dansmith well, right
16:20:06 gibi so she knows more
16:20:16 dansmith $current_owner = 'melwitt' is what I meant :)
16:20:20 gibi yeah
16:20:44 gibi OK, I guess that is it for now about this bug I will ping melwitt about it and record this discussion inthe bug
16:20:48 gibi moving on
16:21:03 gibi is there any other nova bug (gate or not) we need to discuss?
16:21:20 bauzas did we put the hot potato into someone's hand who isn't there ? excellent outcome of this discussion :p
16:21:33 opendevreview Merged openstack/nova master: Transfer RequestLevelParams from ports to scheduling https://review.opendev.org/c/openstack/nova/+/791506
16:21:39 gibi bauzas: I can still feel the responsibility until I can talk to melwitt
16:21:40 dansmith wasn't it in her hands to begin with? I think it's okay :P
16:21:58 gibi :D
16:22:10 gibi I see there is no other bug to talk about great :D
16:22:12 bauzas moving on
16:22:21 gibi Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly
16:22:25 gibi they are greeen
16:22:44 gibi and last but not least be prepared that the gate will be slow this week due to Milestone 3
16:23:03 gibi #topic Release Planning
16:23:03 gibi which brings us to
16:23:08 gibi Release tracking etherpad #link https://etherpad.opendev.org/p/nova-xena-rc-potential
16:23:16 gibi Feature freeze is 3rd of Sept which is end of this week.
16:23:20 gibi Also we have Milestone 3 end of this week that marks the last release of our client libs. Release patches:
16:23:24 gibi novaclient https://review.opendev.org/c/openstack/releases/+/806592
16:23:27 gibi osc-placement https://review.opendev.org/c/openstack/releases/+/806580
16:23:45 gibi I'm not tracking any open novaclient patches
16:24:06 gibi but for osc-placement the https://review.opendev.org/c/openstack/osc-placement/+/804458 consumer_types support client patch would be nice
16:24:42 gibi the client release should happen this week so we still have a bit of time
16:25:04 gibi We are tracking the release TODOs in #link https://etherpad.opendev.org/p/nova-xena-rc-potential
16:25:04 bauzas I can review it
16:25:34 gibi bauzas: thanks, I'm also plannig to get to it
16:25:51 gibi there are two open todos for the release
16:25:56 gibi We need to produce the cycle highlights
16:26:00 gibi review is there: #link https://review.opendev.org/c/openstack/releases/+/800755
16:26:04 gibi I will do a bp status cleanup tomorrow and along that I will update the highlights patch. But you can help me with the highlight by bringing up features in the comments.
16:26:13 opendevreview Stephen Finucane proposed openstack/nova master: policy: Deprecate field from 'os-extended-server-attributes' policy https://review.opendev.org/c/openstack/nova/+/806131
16:26:13 opendevreview Stephen Finucane proposed openstack/nova master: api: Add support for 'hostname' parameter https://review.opendev.org/c/openstack/nova/+/778550
16:26:14 opendevreview Stephen Finucane proposed openstack/nova master: tests: Address nits for configurable-instance-hostnames series https://review.opendev.org/c/openstack/nova/+/806735
16:26:14 opendevreview Stephen Finucane proposed openstack/nova master: tests: Speed up 'servers' API tests https://review.opendev.org/c/openstack/nova/+/778732
16:26:44 gibi the other todo is
16:26:45 gibi We need a volunteer to write the release notes prelude (deadline for the prelude is RC1)
16:27:04 dansmith gosh I wonder who will do that
16:27:44 bauzas hmmm
16:28:01 gibi :D
16:28:08 bauzas but ok, I can volunteer for it
16:28:12 gibi thanks
16:28:55 gibi anything else about the release before we jump to open bps?
16:29:41 gibi #topic Review priorities
16:30:06 gibi this is a new topic as the gerrit patch enabling the new Review-Priority label has been landed
16:30:47 gibi you can query the label with something like https://review.opendev.org/q/project:openstack/nova+label:Review-Priority%252B1
16:31:15 gibi the doc about the label is here https://review.opendev.org/c/openstack/nova/+/792357
16:31:53 gibi anyhow as we are close the FF sean-k-mooney collected couple of bps from our list that we quickl agree on to mark as priority
16:32:03 gibi instance host name https://review.opendev.org/q/topic:%22bp%252Fconfigurable-instance-hostnames%22+(status:open%20OR%20status:merged)
16:32:14 gibi this is basically approved
16:32:17 gibi as far as I see
16:32:32 bauzas let me ask a stupid question
16:32:41 bauzas do we have a formal process on how to use this flag ?
16:32:47 gmann or we can run this to filter already +W one #link https://review.opendev.org/q/project:openstack/nova+Review-Priority:1+label:Verified%253D1++NOT+label:Workflow%253C%253D-1
16:32:53 bauzas I remember some change I reviewed a while ago
16:32:56 gibi bauzas: this is where we discussing that https://review.opendev.org/c/openstack/nova/+/792357
16:33:01 bauzas but did we get into some direction ?
16:33:08 sean-k-mooney bauzas: yes
16:33:12 gibi I see you have negative comments there :)
16:33:31 sean-k-mooney well it was +w'd so i assuems we had agreed
16:33:38 bauzas I can see some consensus
16:33:46 bauzas so I can rereview this
16:34:09 gibi sure I have to back to that too
16:34:43 gibi lets then just quickly check some of the open bps that close to lend and ignore the new label until we agree on the doc
16:34:53 gibi s/lend/land
16:35:15 gibi so instance hostname is a basically done we can move on
16:35:20 gibi vhost multi queue flavor extra spec https://review.opendev.org/q/topic:%22bp%252Fmultiqueue-flavor-extra-spec%22+(status:open%20OR%20status:merged)

Earlier   Later