Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-09
15:56:39 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation-extended' spec https://review.openstack.org/638734
16:08:32 openstackgerrit François Palin proposed openstack/nova master: nova diagnostics command is not working with all interfaces https://review.openstack.org/648123
16:15:48 stephenfin kaboom
16:15:53 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove cells v1 jobs https://review.openstack.org/651289
16:15:54 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'nova-cells' service https://review.openstack.org/651290
16:15:54 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove '/os-cells' REST APIs https://review.openstack.org/651291
16:15:55 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop handling cells v1 in '/os-hypervisors' API https://review.openstack.org/651292
16:15:55 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop handling cells v1 in '/os-servers' API https://review.openstack.org/651293
16:15:56 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'nova-manage cell' commands https://review.openstack.org/651294
16:15:56 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop handling cells v1 for console authentication https://review.openstack.org/651295
16:15:57 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove old-style cell v1 instance listing https://review.openstack.org/651296
16:15:57 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'bdm_(update_or_create|destroy)_at_top' https://review.openstack.org/651297
16:15:58 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'instance_fault_create_at_top' https://review.openstack.org/651298
16:15:58 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'instance_info_cache_update_at_top' https://review.openstack.org/651299
16:15:59 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'get_keypair_at_top' https://review.openstack.org/651300
16:15:59 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'instance_update_at_top', 'instance_destroy_at_top' https://review.openstack.org/651301
16:16:00 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'instance_update_from_api' https://review.openstack.org/651302
16:16:00 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop handling 'update_cells' on 'BandwidthUsage.create' https://review.openstack.org/651303
16:16:01 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop handling cells v1 for instance naming https://review.openstack.org/651304
16:16:01 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop handling 'cell_name' field on Instance.save() https://review.openstack.org/651305
16:16:02 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove cells code https://review.openstack.org/651306
16:16:16 sean-k-mooney cells v1 removal
16:16:27 stephenfin I _think_ all but the last two or three should be passing unit test, functional tests and pep8
16:16:34 stephenfin sean-k-mooney: yuuup
16:16:47 sean-k-mooney well the gate is going to be busy for a while
16:17:17 stephenfin First time in days that my laptop hasn't sounded like a rocket
16:17:32 mriedem stephenfin: are you going to throw that blueprint in the meeting agenda for thursday since it's a specless blueprint?
16:17:43 stephenfin mriedem: Good call. Sure
16:17:55 gmann mriedem: I would like to keep only first 3 fixes in this spec, hoping that will not be big for review/doc ? - https://review.openstack.org/#/c/603969/9
16:18:11 mriedem because i may or may not have several new edge use cases and features for cells v1 and will block it's removal
16:18:48 gmann mriedem: success code change is something need more audit and can be done later ?
16:19:17 mriedem gmann: those first 3 are probably ok and straight-forward enough
16:19:41 gmann ok. let me update the spec.
16:25:25 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.openstack.org/650963
16:25:46 bauzas stephenfin: thanks for reviewing https://review.openstack.org/#/c/650963/, just wrote PS2
16:33:46 tssurya mordred, mriedem, dansmith: after the back and forths on changing the type of the "locked" response key since all of you are for the seperate key style and no change on type I will just update the spec then to that approach.
16:34:02 dansmith tssurya: thanks
16:34:06 tssurya separate*
16:34:06 mordred ++
16:34:18 dansmith I was shocked to have mordred come in and agree with me
16:34:40 dansmith he might not have realized what he was doing though
16:39:32 dansmith stephenfin: melwitt bauzas mriedem: I didn't see any discussion about how stephenfin only created five placeholders for the main db this time, but I do think that's probably more than enough and would be good for the future
16:39:59 bauzas yeah, I just feel 5 is enough given the history
16:39:59 stephenfin dansmith: I _think_ I called it out in the commit message or a comment, so I figured everyone was ok with that
16:40:14 dansmith stephenfin: I didn't see it anywhere
16:40:14 stephenfin (did it because you mentioned that we'd never used them anyway)
16:40:19 mordred dansmith: wait. I change my mind. whatever the opposite things is please
16:40:30 dansmith mordred: :)
16:41:06 stephenfin dansmith: Yeah, it wasn't as obvious as it should have been but it's there alright https://review.openstack.org/#/c/650964/1/nova/tests/unit/db/test_migrations.py@183
16:41:24 dansmith ack, okay
16:44:11 mriedem he put it in a comment
16:44:17 mriedem oh yeah i'm late
16:44:52 dansmith I didn't read that deep since it was already merged, just saw the fewer file count
17:06:10 gmann dansmith: mriedem mordred can we remove 'locked' field in favor of 'locked_by' in https://review.openstack.org/#/c/638629/9/specs/train/approved/add-locked-reason.rst@198
17:06:40 dansmith I'd rather we didn't
17:06:43 mordred gmann: it would be nicer to not remove the field
17:06:44 gmann it will be change for old user so no strong opinion just a thought.
17:06:50 dansmith it's just senseless change for no real gain
17:06:51 gmann yeah
17:07:09 mriedem pretty sure that was discussed in some of the earlier patch sets
17:07:19 gmann ok.
17:09:39 bauzas stephenfin: I'm a terrible man, I left you a -1 on https://review.openstack.org/#/c/555081 after you left
17:10:07 bauzas but I feel it's worth discussing on the upgrade path
17:10:09 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969
17:10:31 bauzas I'm in favor of just saying "heh dude, migrate your workloads first before touching anything or your compute will blow up"
17:10:52 gmann mriedem: mordred updated the API cleanup spec with only 3 cleanups to target. https://review.openstack.org/603969
17:11:17 dansmith bauzas: um, really?
17:11:38 dansmith bauzas: you want cern to have to migrate all their workloads before/during an upgrade?
17:11:49 bauzas dansmith: no, that's not what I meant
17:12:05 bauzas dansmith: I meant, before changing the opts
17:12:26 bauzas if you upgrade and just keep the same conf, you're not impacted
17:12:41 bauzas actually, I left another comment saying this
17:13:04 bauzas ie. keep existing behaviour in Train exactly like in Stein if untouched
17:13:12 dansmith okay let me re-read
17:13:36 bauzas dansmith: context being https://review.openstack.org/#/c/555081/22
17:13:54 dansmith right I know :)
17:14:13 bauzas https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@171 is the existing backwards compat concern I have => don't change anything
17:14:38 mriedem tssurya: gmann: i left some comments on the locked reason spec regarding filtering and sorting, but i'm not sure why locked is not a valid sort/filter parameter but locked_by is - even though we dont currently expose the latter
17:14:47 mordred gmann: all of those fields with OS-EXT prefixes are readonly aren't they?
17:14:49 bauzas https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst@181 is the "what happens when you start playing with those new opts"
17:15:09 tssurya mriedem: I was just about to push :)
17:15:26 dansmith bauzas: okay, so what happens if you do make those changes on a compute node with instances?
17:15:28 bauzas oh man, I really thought the locked reason spec was not controversial :)
17:15:28 tssurya oh had just added filtering based on the new keys will be allowed
17:15:30 mordred gmann: in any case - we expose all of those without the prefix in sdk already - so I'm definitely in favor of that cleanup :)
17:16:02 mriedem tssurya: you can't filter on something that's stored in system_metadata
17:16:05 dansmith bauzas: as long as the same config means you don't have to move stuff that's okay, I thought you were kindof implying that they would have to move everything at some point though
17:16:06 bauzas dansmith: that's my point, in the spec, we say we reshape
17:16:18 bauzas when we start using those opts
17:16:22 tssurya bauzas: I thought so too! (when I initially proposed it)
17:16:30 mordred (although I think I need to add a way to express inside of sdk "this property comes from whichever of OS-EXT-AZ:availability_zone or availability_zone exists"
17:16:48 bauzas dansmith: nope, nope, keep same things in Train if config unchanged
17:16:56 dansmith bauzas: I would expect someone like CERN to really care about enabling this sort of thing and requiring everyone to move many gigs of data around just so we don't have to reshape is kinda icky
17:17:01 dansmith I mean, really icky
17:17:11 bauzas dansmith: I totally agree
17:17:21 tssurya mriedem: oh yea forgot ! I guess we discussed this too earlier in the spec when we were deciding where to put it
17:17:26 mriedem mordred: not necessarily, OS-DCF:diskConfig is on server create
17:17:40 gmann mriedem: they are all in response so did not get readonly thing completely
17:17:46 bauzas dansmith: that's why I'm in favor of a full service stop if operators start playing with new config opts in Train and have existing instances
17:17:58 mordred mriedem: ah - so it is. ok - that one will take a little extra effort - but shouldn't be too bad

Earlier   Later