Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-16
14:45:41 mriedem ildikov: i actually wish they were in a chain
14:45:44 mriedem rather than depends-on
14:46:07 mriedem but you don't need a topic branch if you don't want,
14:46:16 mriedem you can do refresh_connection_info for new style attachments in a separate patch,
14:46:25 ildikov mriedem: working together with someone on a chain is highly painful
14:46:28 mriedem have the live migration patch depends-on that, and have the final api patch depends on the live migration patch, which it already does
14:47:18 ildikov but if we do that changes in the refresh_conn_info I don't know how those will be picked up with only a depends-on
14:47:33 mdbooth Incidentally, I'm also looking for re-approval of lyarwood 's previously approved stable rescue spec: https://review.openstack.org/#/c/510106/
14:51:56 ildikov mriedem: I get your point, I still think it would really be easier and quicker to merge the live_migrate patch; it works and functional and what we need to do is a refactor only
14:53:25 mriedem ildikov: i don't see the problem with splitting them out,
14:53:31 mriedem yo'uve managed things with depends-on up to this point anwyay
14:53:34 mriedem how is this any different?
14:53:56 mriedem ideally i like changes in a series, but as you said that gets hard with multiple owners in that series
14:54:52 ildikov just adds to the timeline which seems somewhat unnecessary
14:55:20 ildikov and still extra work and coordination
14:56:19 ildikov but as I usually don't win in these debates, I will look into splitting that out :)
14:58:21 dansmith efried: I don't think it needs a spec
15:01:32 sahid dansmith: don't you think that could be interesting for the contributors/reviewers to understand the design here?
15:02:03 sahid perhaps a related specs
15:02:22 dansmith sahid: of passing request information into the virt driver? like a port or network? No, I think it's pretty clear
15:03:12 sahid yes that si clear, but it's not the only method to update, and what is the aim, are you going to update all the drivers methods to add that new param
15:03:15 sahid ?
15:03:20 efried In this case I agree the intent can be expressed adequately in the commit message.
15:03:39 efried We're not impacting APIs or objects or configs or anything.
15:03:49 sahid well you are impacting the drivers
15:04:01 dansmith sahid: he's already updating all the drivers' method signatures
15:04:03 efried Yup. And updating them accordingly in the scope of the change.
15:04:22 efried With a nice docstring on the new param.
15:04:34 sahid ok fair, just asking... that change is happening like that without explaining, i was expected some
15:05:13 efried Definitely a reasonable point sahid, thanks for bringing it up.
15:06:36 sahid efried: if you can update the commit message that would be nice so we are all on the same page
15:06:45 efried sahid Will do.
15:08:56 mriedem ildikov: so to recap what i think the changes are, please correct me if i'm wrong: 1. split out the refresh_connection_info change to the bottom of the series. for old style attachments we still call os-initialize_connection, for new style we call attachment_get. 2. you or stvnoyes updates the live migration patch on top of that and do an explicit attachment_update call since refresh_connection_info won't do that for you anym
15:08:57 mriedem 3. the new attach api flow goes on top of those other 2 (maybe not changes needed except splitting that code out)
15:09:36 mriedem ildikov: stvnoyes: once those bottom 2 are done i think they are easy to get merged this week
15:09:40 openstackgerrit Merged openstack/nova-specs master: Spec for limiting GET /allocation_candidates https://review.openstack.org/504540
15:09:46 mriedem as i think that's the only hold up on the live migration patch at this point
15:11:49 efried ice_auth.py#L31
15:11:49 efried mriedem sdague This may have happened before you came on, but niraj_singh was testing out the service_user token thing and got a really cryptic exception. Turns out the issue was not having specified auth creds in the conf. I thought we could do a better job by blowing up here if _SERVICE_AUTH comes back None (which is what happens if you don't specify an auth_type): https://github.com/openstack/nova/blob/master/nova/serv
15:12:00 efried Nice. https://github.com/openstack/nova/blob/master/nova/service_auth.py#L31
15:12:30 sdague efried: yeh, that would be cool
15:13:32 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix nova-manage commands that do not exist https://review.openstack.org/512324
15:14:12 efried niraj_singh You open that bug yet? I don't see it.
15:15:04 ildikov mriedem: sorry, on a call
15:15:53 ildikov mriedem: your summary looks good to me
15:23:55 mriedem bauzas: you might find this ML thread about an interesting bug to be very interesting, interestingly enouh http://lists.openstack.org/pipermail/openstack-operators/2017-October/014393.html
15:25:01 dansmith hmm, I'm not seeing things I submitted a few minutes ago in the zuul queue
15:27:48 openstackgerrit Eric Fried proposed openstack/nova master: Service user token requested with no auth https://review.openstack.org/512329
15:27:55 efried sdague ^
15:30:08 openstackgerrit garyk proposed openstack/nova master: Add debug information to metadata requests https://review.openstack.org/511895
15:30:26 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306
15:30:45 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Change 'InstancePCIRequest' spec field https://review.openstack.org/449257
15:33:24 sahid mriedem or perhaps johnthetubaguy, we have an interesting fix here https://review.openstack.org/#/c/400384/18, perhaps you can have a look
15:53:54 johnthetubaguy sean-k-mooney: mriedem: the upgrade bits seem super complicated in that port binding spec, I though we were going to just follow the Cinder attachments model there?
15:55:11 mriedem i need to look at the latest revision, but i mentioned something about that in earlier review
15:56:30 mriedem gibi: thanks re https://review.openstack.org/#/c/510938/ +2
15:56:42 sean-k-mooney johnthetubaguy: i am not that familire with how things are done for cinder but im happy to implement something similar if you can provide the wording
15:57:00 johnthetubaguy sean-k-mooney: no worries, adding a comment
15:57:12 johnthetubaguy sean-k-mooney: really I was thinking, we do nothing until everything is upgraded
15:57:24 johnthetubaguy would that work for this case?
15:58:27 sean-k-mooney johnthetubaguy: yes it would i think i have that in the alternitives
15:59:11 sean-k-mooney basically we would fall back to todays behavior unless all partys support the new workflow else execut new workflow
15:59:25 johnthetubaguy sean-k-mooney: that sounds safest and easiest to test and get right
16:00:13 johnthetubaguy sean-k-mooney: am I missing something big we gain by supporting this across mixed compute nodes?
16:01:12 sean-k-mooney johnthetubaguy: its slightly simpler to change neutron backend as part of a upgrade
16:01:26 johnthetubaguy sean-k-mooney: yeah, that just needs to be the next upgrade I guess
16:02:01 sean-k-mooney without the mixed mode basically you upgrade everything to queens then upgrade your neutron again to different network backend.
16:02:59 johnthetubaguy right, only affects the first upgrade to queens though right?
16:03:07 sean-k-mooney i have to join a call sorry but if you leave that comment ill swap the mixed migration and alternitves sections
16:03:16 sean-k-mooney yes
16:03:25 johnthetubaguy sean-k-mooney: no worries
16:03:43 openstackgerrit Chris Dent proposed openstack/nova master: [placement] manage cache headers for inventories https://review.openstack.org/510954
16:03:48 sean-k-mooney with mixed mode you can do a roleing upgrade and change the backend at the same time. with out you do one then the other
16:05:10 johnthetubaguy sean-k-mooney: OK, so I am missing a bit, will re-read
16:14:50 mriedem melwitt: am i missing something or is nothing calling InstanceList.get_count_by_vm_state ?
16:15:58 mriedem can someone remind me if there was supposed to be some quota advantage to shelving an instance?
16:16:04 mriedem because i'm not seeing it
16:18:09 alaski When I implemented shelving it did not reduce quota to shelve an instance
16:18:29 mriedem https://blueprints.launchpad.net/nova/+spec/shelve-instance
16:18:32 mriedem yeah was just reading
16:18:50 mriedem alaski: also, why do you have a keyword match on "shelve"? :)
16:19:54 alaski hah. I just felt a twitch when it was mentioned. And happened to have this channel open
16:23:31 mriedem trying to see if a shelved offload instance affects the simple tenant usage result
16:23:55 mriedem i don't think we make any distinction even though the instance isn't consuming local disk or ram or cpu
16:25:31 alaski I can't recall what simple tenant usage is tracking. But shelve offload frees up the space for the usage tracker and scheduling, but doesn't return the quota to the user.
16:26:05 mriedem sure, but as a user i don't care about freeing up space for others :)
16:26:23 mriedem if i'm still going to get charged
16:26:33 alaski yeah
16:26:53 alaski I know that freeing up the quota has come up a few times, and there's no strong argument for not doing it
16:27:20 alaski the thing to figure out is how to properly tell the user that they can't unshelve something if they've subsequently filled up their quota
16:27:57 mriedem 409 overquota on unshelve
16:28:05 mriedem we'd do a count during unshelve and fail if there is no room
16:28:13 mriedem similar to resize up to a larger flavor i'd tihnk
16:28:38 mriedem but, os-simple-tenant-usage doesn't check quota usage at all... :)
16:28:50 mriedem sort of redundant in that way
16:30:26 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
16:31:42 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove dead parameter from '_create_domain_and_network' https://review.openstack.org/512352
16:34:25 alaski I'll just apologize again for introducing shelve :) it's an interesting idea, but it really messes with the model of how things work
16:35:06 mriedem heh
16:35:07 mriedem oh laski

Earlier   Later