Earlier  
Posted Nick Remark
#openstack-nova - 2020-03-30
14:20:12 gibi I see: https://review.opendev.org/#/c/708436/ and https://review.opendev.org/#/c/701430/ and https://review.opendev.org/#/c/693828/ as API changes. But lyarwood's patch is still on 2.83
14:20:57 gibi dansmith: as far as I see stephenfin's https://review.opendev.org/#/c/708436/ patch is up to date and I'm +2 of if some other can can review then that can be the next
14:21:16 gibi nvm
14:21:20 gibi 2.85 is the next
14:21:25 dansmith yeah, that's out of date now
14:21:28 gibi so none of the current API patches is up to date
14:21:29 dansmith and I just started on 2.85
14:21:37 dansmith argh
14:22:32 gibi stephenfin, lyarwood : do you plan to update your patches to 2.85 soon?
14:22:35 dansmith gibi: should I keep reversioning for 2.85 or do you want one of those to go first?
14:22:55 stephenfin gibi: Yeah, I'm respinning it at the moment
14:23:13 stephenfin lyarwood is out 'til Friday though so I guess his will be a while
14:23:27 gibi stephenfin: ack, then you and dansmith are up for the 2.85
14:23:53 stephenfin how ready is your patch, dansmith?
14:24:01 gibi dansmith: stephenfin would need a second core (besides me) to merge on 2.85
14:24:43 dansmith stephenfin: slightly less than yours I imagine, since it was already +2, but it's fairly close I think
14:27:45 stephenfin okay, I'll push this now so
14:27:46 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Add framework for extra spec validation https://review.opendev.org/704643
14:27:47 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs https://review.opendev.org/710037
14:27:47 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Add microversion 2.84, extra spec validation https://review.opendev.org/708436
14:27:58 stephenfin and go review that PUT volume attachments patch
14:28:04 gibi stephenfin: you have nothing to loose if you already made the change to 2.85
14:29:21 stephenfin gibi: Yup, fair. That second patch needs your +2 _yet again_ so :(
14:29:54 gibi I have to drop offline untill 16:00 UTC but I will be back
14:46:17 gmann dansmith: replied on volumeId as optional comment- https://review.opendev.org/#/c/693828/20/nova/api/openstack/compute/volumes.py@447
14:46:40 gmann dansmith: what if request is for both swap as well as update delete flag ?
14:46:52 gmann i think that is brinzhang_ question also ? but not sur
14:46:52 openstackgerrit Stephen Finucane proposed openstack/nova master: Pass the actual target in os-instance-usage-audit-log policy https://review.opendev.org/715089
14:46:52 openstackgerrit Stephen Finucane proposed openstack/nova master: Add new default roles in os-instance-usage-audit-log policies https://review.opendev.org/715085
14:46:54 gmann sure
14:49:31 dansmith gmann: okay got it
15:14:33 dansmith artom: around?
15:19:47 artom dansmith, sup
15:19:55 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Feature matrix: update AArch64 information https://review.opendev.org/715979
15:20:30 hrw few new entries. mostly volumes related
15:20:32 dansmith artom: if I wanted to support changing a volume attachment tag, I'd need to make a call to the compute node? I haven't looked at all, but what is the procedure when volume attach specifies a tag?
15:20:55 dansmith artom: could I reasonably just change it on the BDM and expect the virt driver to pick it up on the next reboot or something?
15:20:59 artom dansmith, I believe just saving the new tag to the DB is enough
15:21:04 dansmith oh?
15:21:28 artom Lemme refresh my memory on how we actually build metadata
15:22:04 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing hypervisors policies https://review.opendev.org/715029
15:22:20 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-hypervisors https://review.opendev.org/715036
15:23:08 hrw missed 'nova boot'
15:23:08 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Feature matrix: update AArch64 information https://review.opendev.org/715979
15:24:55 artom dansmith, ah, no, we have to call down to the virt driver to rebuild the instance metadata
15:25:13 dansmith okay, that's what I thought
15:29:53 gmann hrw: firs example is from python-novaclient which is python client only for nova (from starting) and has cmd like volume-attach etc. every project has their separate python client. Now we have new unified CLI for the whole openstack which is openstackclient and making all project CLI in standard way for example 'openstack volume attach'.
15:30:36 gmann not all project has finished the new client migration so both are maintained for now.
15:38:09 hrw gmann: I am aware of migration. it started in ocata times or earlier iirc ;D
15:39:22 gmann yeah, it still going on :). hope to make it commnity goal for V cycle if it happens. it is second try
15:40:48 hrw gmann: I like building openstack, solving some aarch64 architecture related issues. but I really dislike using it. two ways of using cli, commands having missing subcommands, missing sane features...
15:41:24 hrw gmann: 'openstack hypervisor list' but no 'hypervisor up' - have to find 'service somethingsomething --up'
15:41:50 hrw 'openstack volumes list' but 'nova volume-attach'
15:42:19 hrw and not found yet 'openstack create image --from-url'
15:45:31 gmann its openstack image create.
15:46:56 gmann but yeah, if you compare naming convention for both its different.
15:47:31 gmann i do not know which one is best though i hardly use CLI:)
15:47:44 hrw gmann: 'openstack image create' allows to create image from file.
15:48:09 hrw which sucks when you fetch 1GB image from US to pipe it through thin pipe back to US
15:48:34 hrw gmann: I prefer to use cli rather than horizon ;D
15:49:44 hrw asymetric home networks suck
15:58:01 donnyd glance used to be able to be told to go download an image for you. not sure if this is still a thing it can do
15:58:11 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-hypervisors policies https://review.opendev.org/716003
15:59:24 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-hypervisors policies https://review.opendev.org/715071
16:00:05 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-hypervisors policy https://review.opendev.org/715074
16:02:48 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-agents policies https://review.opendev.org/701648
16:03:01 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-agents policy https://review.opendev.org/701649
16:10:18 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in limits policies https://review.opendev.org/715760
16:10:32 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in limits policy https://review.opendev.org/715761
16:21:37 huaqiang stephenfin: I saw your comments on the WIP 'pcpuset alternative' patch,
16:22:25 huaqiang Now I dropped the 'cpu_pinning' approach. I am still working on the them, and I'll send out all patches
16:22:40 huaqiang I'll send out all of them tomorrow
16:22:46 stephenfin Perfect (y)
16:43:55 stephenfin gibi: Do we need to worry about notification responses changing? Are those versioned? https://review.opendev.org/#/c/715362/1/doc/notification_samples/instance-live_migration_rollback_dest-start.json
16:44:24 stephenfin (it's changing because of https://review.opendev.org/#/c/715362/1/nova/compute/manager.py@a8644)
17:01:14 gibi stephenfin: is it just the content but not the structure? (I'm still reading that patch)
17:14:58 gibi stephenfin: replied in https://review.opendev.org/#/c/715362 No worries about the notificatins. The format are versioned sure but the task_state value change is not part of the contract, just the structure
17:18:53 gibi stephenfin: +2 on the flavor extra spec verification again.
17:19:38 gibi stephenfin: but the doc patch on top failed the functional test
17:19:46 gibi stephenfin: and that feels relevant
17:19:52 gibi https://07b92d57b5f1a612a74b-4cebd80e32fd7e7586df4103c9478cce.ssl.cf5.rackcdn.com/710037/6/check/nova-tox-functional-py36/c7d4b1e/testr_results.html
17:21:11 gibi I just don't know how
17:22:53 Sundar dansmith, gibi: Can one of you give W+1 for the patches in https://review.opendev.org/#/q/project:openstack/nova+bp/nova-cyborg-interaction+status:open ? Thanks
17:23:35 dansmith Sundar: I haven't reviewed those to +2 status yet and I'm working on something else right now
17:23:39 dansmith but it's on my list of course
17:23:42 gibi stephenfin: found it, left a -1 with details
17:24:54 gibi Sundar: I'm +2 all the way, so we have to wait for dansmith or others to +2
17:25:11 gibi dansmith: can I do something for you before I finish for today?
17:26:16 dansmith gibi: I'm just working on all the changes to that d-o-t series.. should I rebase against stephenfin's 2.85 patch as 2.86? If we're not going to strictly order them then I'll wait until that one merges
17:26:46 dansmith gibi: I think an etherpad with an intended line of succession would be appropriate at this point that cores try to hold to
17:27:27 gmann gibi: updated the policy description for this - https://review.opendev.org/#/c/715071/4
17:28:13 gibi dansmith: thanks. If I know who will be the second for for stephenfin's series then I would put that first in the order as that is ready
17:29:15 gibi lately efried reviewed stephenfin's patch besides me so we are missing a core there
17:29:37 efried something I can look at quickly gibi?
17:30:01 dansmith okay, not sure what you're saying, so I will just push this up at 2.85 since I had already started tat re-version, and will hope to have some coordination
17:30:14 gibi efried: stephenfin's extra spec validation series is mostly ready (there are a small test issue due to microversion bump)
17:30:26 gibi efried: but I totally understand if that is a big piece to chew
17:30:43 efried oh, yeah, I never gave that a thorough review in the first place, just had one isolated comment on something I noticed out of context.
17:30:51 gibi dansmith: even if I put stephen first, we dont have a second core for that series
17:31:09 dansmith I was assuming he was first

Earlier   Later