| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-09 | |||
| 13:35:44 | sean-k-mooney | unless its conflicting with your home/work network | |
| 13:37:17 | sean-k-mooney | kashyap: you also done need the data dirs stuff but you are using a non default location so not minimal but i guess its what you need | |
| 13:37:23 | bauzas | gibi: no spec for the attach/detach case, right? https://review.opendev.org/c/openstack/nova/+/756530/21//COMMIT_MSG | |
| 13:37:43 | bauzas | I was thinking about the workflow, do we have other resources for attach/detach ? | |
| 13:38:01 | gibi | bauzas: there is spec for the qos series | |
| 13:38:05 | kashyap | sean-k-mooney: Reading ... | |
| 13:38:30 | bauzas | I know | |
| 13:38:31 | bauzas | https://review.opendev.org/c/openstack/nova-specs/+/755477 | |
| 13:38:48 | kashyap | sean-k-mooney: The data dirs stuff -- that is intentional; as I want it to be in a non-default location | |
| 13:38:49 | bauzas | okay okay, will lookup | |
| 13:38:51 | kashyap | sean-k-mooney: Thanks! | |
| 13:38:55 | gibi | bauzas: then I don't get your question | |
| 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 | |