Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-02-09
13:39:11 bauzas gibi: I didn't remember whether we discussed about the workflow
13:39:14 bauzas but yeah we did
13:39:16 gibi bauzas: there is only neutron resource request and the PCI request it handled for interface attach
14:43:25 stephenfin lyarwood: You've done the next patch in the series but any chance you could hit this? https://review.opendev.org/c/openstack/nova/+/741663/
14:52:31 lyarwood ops my bad, sure
14:53:02 openstackgerrit Stephen Finucane proposed openstack/placement master: policy: Deprecate 'admin_api' rule https://review.opendev.org/c/openstack/placement/+/772334
14:53:03 openstackgerrit Stephen Finucane proposed openstack/placement master: policy: Add note about keystone's expansion of roles https://review.opendev.org/c/openstack/placement/+/772752
14:53:04 openstackgerrit Stephen Finucane proposed openstack/placement master: Move policy deprecation to base rules https://review.opendev.org/c/openstack/placement/+/772784
14:53:05 openstackgerrit Stephen Finucane proposed openstack/placement master: policy: Add releasenote for RBAC work https://review.opendev.org/c/openstack/placement/+/774654
14:53:35 stephenfin gmann: ^
14:53:44 bauzas gibi: had an open question with some nits too https://review.opendev.org/c/openstack/nova/+/756530
14:53:54 stephenfin release note fresh out of the oven
14:53:59 bauzas tl;dr: should we delete the QoS allocations on interface detach ?
14:54:13 gmann stephenfin: ack. mostly rebase right
14:54:22 stephenfin yeah, I just reapplied +W
14:54:31 stephenfin the releasenote is the only real change
14:56:06 gmann ok
15:05:29 gmann stephenfin: lgtm 1 comment on adding link to keystone doc https://review.opendev.org/c/openstack/placement/+/774654
15:07:13 lyarwood does anyone know if there's an easy way to list instances by cell via an existing cli?
15:07:41 lyarwood context being a nova-status check I've added lists cell uuids and not instance uuids which isn't that useful
15:08:10 lyarwood before I go and write something to list instances by cell uuid or instances that fail my check I wanted to ensure something didn't already exist
15:08:22 lyarwood I can't see anything obvious in osc
15:08:30 openstackgerrit Stephen Finucane proposed openstack/placement master: policy: Add releasenote for RBAC work https://review.opendev.org/c/openstack/placement/+/774654
15:08:31 stephenfin gmann: done ^
15:08:43 lyarwood or novaclient
15:09:51 stephenfin lyarwood: A quick search through api-ref suggest we don't expose anything about cells v2 to the REST API
15:10:11 lyarwood stephenfin: gah, well I guess I'm writing a nova-manage command then
15:10:24 lyarwood or rewriting this status check to list instance uuids
15:10:35 lyarwood but given the table output that's going to look awful
15:36:03 kashyap sean-k-mooney: That 'DEVSTACK_PARALLEL' thing in your config - is that merged, or were you testing something from Git?
15:36:19 sean-k-mooney oh no thats not merged yet
15:36:24 sean-k-mooney i was testing dans patch
15:37:00 sean-k-mooney kashyap: https://review.opendev.org/c/openstack/devstack/+/771505
15:37:07 sean-k-mooney it works pretty well
15:37:24 sean-k-mooney tested it on ubuntu and fedora
15:38:49 kashyap sean-k-mooney: Thanks; also, remind me again, 'g-reg' can be avoided right?
15:47:32 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Add support for microversion v2.88 https://review.opendev.org/c/openstack/python-novaclient/+/770573
15:53:36 sean-k-mooney kashyap: yes
15:53:42 sean-k-mooney do i still have it in min
15:53:52 sean-k-mooney you just need thet glance api now i think
16:03:36 kashyap sean-k-mooney: You don't, though. I just kept in as a old habit
16:03:38 kashyap Thx
16:03:48 kashyap lyarwood: Aside - have you tried DevStack on F33 yet?
16:06:15 openstackgerrit Stephen Finucane proposed openstack/os-vif master: Resolve dependency issues https://review.opendev.org/c/openstack/os-vif/+/774694
16:06:18 stephenfin sean-k-mooney: ^
16:06:27 stephenfin as promised
16:07:01 stephenfin it sounds like the general consensus has been to remove these lower-constraint jobs entirely though. They're gone in most of oslo land now as well as neutron
16:08:12 lyarwood kashyap: I have but couldn't get it to work
16:08:17 lyarwood kashyap: even when forcing py38
16:08:21 kashyap lyarwood: Okay ... thought so; F32?
16:08:32 lyarwood kashyap: iirc virtualenv tries to use py39 in places and that breaks
16:08:37 lyarwood kashyap: yeah f32 should work
16:09:05 kashyap Thx
16:10:17 kashyap sean-k-mooney: On your word, I'm trying the _PARALLEL thing ... hope it won't turn into a yak :D
16:10:36 kashyap I'll report back my result, if it works
16:10:55 sean-k-mooney stephenfin: lets try keeping it for this cycle
16:11:16 sean-k-mooney stephenfin: if it break agian before the end of the cycle we can drop it
16:12:39 sean-k-mooney stephenfin: our lower constratis job is a littel different since we actully run our unit tests and docs
16:14:13 stephenfin lyarwood: Is there any way to map a migration request (via '/servers/{server_id}/action (migrate)') to a migration record ('/servers/{server_id}/migrations')
16:14:31 stephenfin I can't see any. It's weird that the former doesn't return an ID in the success case
16:15:34 sean-k-mooney stephenfin: tthe request id might be usable if you are looking at logs
16:15:58 stephenfin I'm thinking of OSC
16:15:59 stephenfin https://review.opendev.org/c/openstack/osc-lib/+/773877
16:16:21 stephenfin Rather than polling the server status, I'd like to map the migration request to the record as above and check the status of that
16:16:37 stephenfin but there doesn't appear to be any way to do that :-\
16:18:50 sean-k-mooney /servers/{server_id}/migrations
16:18:56 sean-k-mooney so you can list the migrates for a server
16:19:02 sean-k-mooney and get the last one
16:19:25 stephenfin Yeah, I was hoping to avoid that
16:19:42 sean-k-mooney maybe via the server events?
16:19:52 stephenfin Hmm, that could work
16:20:06 stephenfin I think the issue is that the Migration object isn't created until we land on a compute noe
16:20:09 stephenfin *node
16:20:24 stephenfin and we use a cast so can't wait for that
16:20:44 stephenfin sounds like a potential usability RFE for Xena
16:22:33 lyarwood yeah I did wonder why we didn't list the request-id in https://docs.openstack.org/api-ref/compute/?expanded=show-migration-details-detail#show-migration-details tbh
16:22:44 lyarwood so you could then lookup by request-id or something
16:22:58 dansmith stephenfin: we didn't originally expose any details of migrations to users other than a resize I think, which is why we don't have a lot of stuff baked around making that trackable by a user
16:22:59 lyarwood definitely something to improve in X
16:23:02 sean-k-mooney well the issue is that we return nothing for the action
16:23:15 lyarwood we should always have the request-id
16:23:41 sean-k-mooney lyarwood: sure but we dont save request ids normally
16:23:41 dansmith stephenfin: there's also the migration context on the instance, so we can stash things like that there before we create the migration if that helps
16:23:42 dansmith like that being the req-id
16:24:18 sean-k-mooney dansmith: ya we do but there is not realy a good way to acess that form the api
16:24:36 lyarwood well that's my point sean-k-mooney, stashing it in the migration record
16:24:43 dansmith sean-k-mooney: no, I mean as support for making the connection possible between the migration request and the actual migration
16:26:36 sean-k-mooney we coudl certenly improt the api respocne to make that eaiser ya
16:26:53 gibi bauzas: thanks for the review, I will reply hopefully tomorrow
16:27:10 bauzas gibi: not sure about my question if it's a problem, honestly
16:27:23 bauzas gibi: wdyt about this ?
16:27:28 sean-k-mooney dansmith: just looking at what currently avaiable however its non trivial for osc to figure out in a way that will work with existing clouds
16:27:48 dansmith yes, clearly
16:28:02 gibi bauzas: the detach case has already implemented couple of cycles ago
16:28:09 gibi let me dig out the lunk
16:28:11 gibi link
16:28:35 dansmith I was just saying I think the lack of obvious linkage is because we haven't always exposed much, and was suggesting to stephenfin that the migration context could likely be used to stash things before we've created the migration record if indeed that happens late as he says (I don't really remember
16:29:15 gibi bauzas: the detach has functional test coverage already on master https://github.com/openstack/nova/blob/941f4624638090b27e9e18601cde0529fcdbd22f/nova/tests/functional/test_servers.py#L6134
16:30:11 gibi bauzas: it was implemented in https://review.opendev.org/c/openstack/nova/+/622421 in stein
16:31:27 bauzas gibi: ah ok

Earlier   Later