Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-30
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
17:31:20 gibi dansmith: will you review stephenfin's series then?
17:32:00 dansmith gibi: I have zero context on it, and need to finish this one, finish the cyborg, etc
17:32:31 dansmith so, maybe, but it won't be soon
17:32:41 gibi dansmith: totally understand this is why I did want to put thing in order as I don't know who will +A stephenfin series and without that it would block the whole queue
17:32:55 gibi s/ did want/did not want/
17:33:11 dansmith well, putting them in order helps communicate importance, but it also just helps the rest of the queue burning time re-versioning a lot
17:33:15 dansmith i.e. time they can spend reviewing
17:33:42 dansmith surely melwitt could review stephenfin's series?
17:34:33 gibi if somebody signs up for it then I'm OK to put stephenfin's first.
17:34:41 gibi but I feel we are in cycles
17:34:51 dansmith well, we had a bunch of support for the d-o-t series,
17:35:05 dansmith and it's already at 2.85, so we could put that at the front too
17:35:12 gibi dansmith: I can review d-o-t first thing in the morning
17:35:30 dansmith okay, I will have it up before long
17:35:38 gibi dansmith: so let's put that first and stephen next, and lyarwood 3rd
17:35:45 dansmith okay
17:35:49 gibi dansmith: thanks
17:36:23 gibi and thank you being patient. this situation is obviously new to me and I'm not up to speed yet to coordinate the release.
17:36:43 dansmith the d-o-t one is also just one patch to claim the microversion
17:36:50 dansmith so anything not version related could be done in a fup to avoid blocking the queue further
17:37:01 gibi dansmith: good point
17:37:02 dansmith but I think the extra specs one is multiple before the microversion right?
17:37:25 gibi the second patch is the microversion in the extra spec, so yes
17:37:37 dansmith two, okay
17:38:20 gibi I'm leave for today. See you tomorrow
17:39:18 dansmith o/
17:39:33 gibi o/
19:14:08 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing lock server policies https://review.opendev.org/716057
19:34:13 openstackgerrit Dan Smith proposed openstack/nova master: Separate update and swap volume policies https://review.opendev.org/711194
19:34:13 openstackgerrit Dan Smith proposed openstack/nova master: Allow PUT volume attachments API to modify delete_on_termination https://review.opendev.org/693828
20:08:56 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Fix unlock server policy to be admin_or_owner https://review.opendev.org/716071
20:20:32 openstackgerrit Merged openstack/nova master: Add new default roles in os-instance-usage-audit-log policies https://review.opendev.org/715085
20:20:37 openstackgerrit Merged openstack/nova master: Pass the actual target in os-instance-usage-audit-log policy https://review.opendev.org/715089
20:35:46 openstackgerrit Victor Coutellier proposed openstack/python-novaclient master: Microversion 2.83 - Add more filters for the nova list command https://review.opendev.org/713089
22:36:37 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing lock server policies https://review.opendev.org/716057
23:29:03 gmann dansmith: we are not updating 'tag' in same version ? - https://review.opendev.org/#/c/693828/21
23:53:11 brinzhang_ gmann: hi, https://review.opendev.org/#/c/693828/20/nova/api/openstack/compute/volumes.py@447
23:54:07 brinzhang_ gmann: dansmith: I mean, the 'volumeId' is optional now, should we support to update the swaping volume's delete_ontermination?
23:55:47 gmann brinzhang_: it's not optional, it is kept same way it was. but yes dansmith latest PS does the same swap+update if requested

Earlier   Later