Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-28
20:03:15 efried (which is my nice way of saying, are we breaking backward compatibility all the time?)
20:10:48 mriedem efried: different people define what's backward compatible in different ways, like some don't consider adding things to a response payload as backward incompatible
20:11:47 mriedem if you pin the microversion, then you're not impacted by anything 'all the time'
20:12:01 efried Is the philosophy that the CLI is supposed to be for human consumption, and if you want to automate, you use the APIs?
20:12:06 mriedem yes
20:12:13 efried That's fair.
20:12:27 mriedem if you're really tied to the CLI behavior, there are ways to pin the microversion with the CLI
20:12:30 efried And in that case, I agree that "use latest by default" is a good approach.
20:17:29 sdague efried: yeh, I 100% agree with mriedem's statements there
20:17:46 sdague the CLI is a user interface. We have a programming interfaces, it's the REST API.
20:18:47 efried I dig it. Though it's a significant barrier to entry for someone who wants a quick-and-dirty script.
20:19:13 sdague efried: not really
20:19:32 efried PowerVM CI uses shell scripting with CLI commands to set up the env. esberglu Sounds like we should either look to convert to the REST API, or explicitly pin the microversion...
20:19:33 sdague quick-and-dirty doesn't mean - guarunteed to work for all time in production in 10 years
20:19:38 jroll quick and dirty scripts shouldn't be long lived enough to.. ^
20:19:43 sdague jroll: ++
20:19:44 efried Okay, okay.
20:19:55 efried But you know how that goes...
20:20:00 jroll though I know what you mean, they do last forever :)
20:20:08 sdague jroll: heh, sure
20:20:25 sdague but it's hard to make an argument about "why doesn't my quick and dirty thing work forever"
20:20:30 jroll totes
20:21:11 sdague efried: honestly, you'll probably be a ton more performant if you write just to the API, having been poking at run and load times on osc earlier today
20:22:12 efried sdague Duly noted. A bit scared of the learning curve there. Also of rewriting something that "works for now"...
20:28:39 mriedem my first python script ever was a testing thing for internal CI using novaclient
20:28:47 mriedem we used it for 4 years
20:28:53 mriedem i'm glad i didn't use bash
20:29:00 mriedem camel-cased that like a mofo though
20:31:28 sdague heh
20:33:50 lbragstad mriedem are you still planning on three proposals for nova sessions at the forum
20:33:51 lbragstad ?
20:34:33 robcresswell mriedem: btw, what did you mean when you said about the nova-net code not mattering when novaclient 8 is released?
21:03:20 openstackgerrit christopher.uhler proposed openstack/nova master: Libvirt volume driver for Veritas HyperScale https://review.openstack.org/443951
21:34:09 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/451043
21:35:58 openstackgerrit OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/451049
21:41:07 mriedem robcresswell: for horizon?
21:41:21 mriedem lbragstad: we have a few, more than 3
21:41:26 mriedem would have to look at the latest
21:41:54 mriedem robcresswell: novaclient 8.0 will have dropped the proxy API / CLI stuff that was deprecated in microversion 2.36
21:41:57 mriedem which includes nova-network
21:42:45 lbragstad mriedem in the keystone meeting we talked about the current proposals we had and which ones seemed to match the criteria for a proposal
21:43:22 lbragstad mriedem curious if nova would be interested in a cross-project session with keystone on unified limits and policy/rbac next steps (two separate sessions)
21:43:27 lbragstad cc sdague
21:45:20 mriedem lbragstad: there is already a session proposed for hierarchical quotas http://forumtopics.openstack.org/
21:45:39 mriedem http://forumtopics.openstack.org/cfp/details/9
21:45:50 mriedem in fact that's sean's
21:47:01 lbragstad mriedem sweet
21:47:32 mriedem otherwise i already count at least 7 proposed sessions relevant to nova
21:47:51 mriedem make that 8 or 9
21:48:14 mriedem i'm not sure if johnthetubaguy was thinking about specific sessions for policy and rbac
21:49:15 mriedem oh i was also going to submit one for claims in the nova scheduler
21:49:20 mriedem maybe next week
21:49:36 robcresswell mriedem: ah okay, so for pike nova-net wont be supported regardless of microversion?
21:49:43 mriedem sh*t, actually friday since the due date is 4/2
21:49:56 lbragstad mriedem ok - thanks for the info, i'll follow up with johnthetubaguy
21:50:31 mriedem robcresswell: nova-network has been deprecated since newton. in the 2.36 microversion we deprecated a bunch of network-related resource APIs. in ocata, nova-network will only start in a cells v1 config.
21:50:49 mriedem robcresswell: in pike, nova-network support will likely be the same as ocata for deployment and APIs
21:50:59 mriedem however, novaclient will not be the same in 8.0.
21:51:15 mriedem robcresswell: we're gradually making it more painful to be using nova-network
21:51:18 mriedem to get ready for the removal
21:51:28 openstack Launchpad bug 1677047 in OpenStack Compute (nova) "glance download fsync raises EINVAL for FIFOs" [Undecided,New]
21:51:28 efried mdbooth Not sure if you saw my message the other day, but I figured out why fsync was raising with EINVAL: https://bugs.launchpad.net/nova/+bug/1677047
21:52:36 robcresswell mriedem: My thinking is drop horizon support for it in Pike then...
21:52:50 robcresswell Would that work with your agenda?
21:53:41 mriedem robcresswell: per my reply in the ML, i don't think you really have a choice,
21:53:51 mriedem unless we cap novaclient at 7.1.0 in upper-constraints, which i don't want to do
21:54:34 robcresswell mriedem: Ah! Gotcha. Sorry, sleepy reading.
21:54:41 robcresswell Thats fine with me as well
21:55:04 mriedem cool. an ack reply in the thread would be helpful.
21:55:18 robcresswell Will do
21:55:23 mriedem i might have totally screwed up some words in my reply too, i should re-read
21:56:00 mriedem "The messy part about this is when we release novaclient 8.0 then that code is gone and microversions don't matter."
21:56:08 mriedem to be clear, microversions don't matter at that point *for the client*
21:56:11 mriedem for novaclient
21:56:14 mriedem as the code is deleted
21:56:25 mriedem that doesn't mean we removed the actual nova-network code, or the REST APIs
21:56:29 mriedem server-side
21:56:39 mriedem robcresswell: ^ does that help?
21:56:50 robcresswell mriedem: Right, that clears things up, thanks
21:56:56 mriedem cool
22:16:49 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Glance download: only fsync files https://review.openstack.org/451094
22:18:02 efried mdbooth ^^
#openstack-nova - 2017-03-29
01:07:43 openstackgerrit Huan Xie proposed openstack/nova master: WIP: Fix race condition when neutron is using minimized poll https://review.openstack.org/444230
01:45:32 openstackgerrit Huan Xie proposed openstack/nova master: WIP: Fix race condition when neutron is using minimized poll https://review.openstack.org/444230
01:54:18 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix calling super function in setUp method https://review.openstack.org/451137
03:21:47 gaoyuan I am working on 'Remove mox from testing infrastructure - Pike'. I noticed in the blue print that we shouldn't remove any stub_out function call in the scope of this bp. But, my question is, what should I do when I came up with a self.stub.Set? Just change to stub_out, or use mock? anyone can tell me ?
05:49:31 openstackgerrit jichenjc proposed openstack/nova master: Remove the extension check for os-quota-class-sets https://review.openstack.org/451193
05:49:32 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for '/servers' endpoint instead of stevedore https://review.openstack.org/445864
05:49:33 openstackgerrit Alex Xu proposed openstack/nova master: Remove the stevedore extension point for server create https://review.openstack.org/451195
05:49:33 openstackgerrit Alex Xu proposed openstack/nova master: Remove the json-schema extension point of server create https://review.openstack.org/451194
05:54:16 openstackgerrit Alex Xu proposed openstack/nova master: Remove the stevedore extension point for server create https://review.openstack.org/451195
05:54:17 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for '/servers' endpoint instead of stevedore https://review.openstack.org/445864
06:01:00 openstackgerrit jichenjc proposed openstack/nova master: no extension for multiple create https://review.openstack.org/396622
06:02:23 openstackgerrit jichenjc proposed openstack/nova master: remove keypair server extension https://review.openstack.org/396611
06:09:02 openstackgerrit jichenjc proposed openstack/nova master: WIP: remove extension of scheduler hints totally https://review.openstack.org/331202
06:09:03 openstackgerrit jichenjc proposed openstack/nova master: WIP: remove scheduler_hints https://review.openstack.org/331194
06:10:40 alex_xu jichen: you probably want to check this https://etherpad.openstack.org/p/api-no-more-extensions-pike
06:11:25 alex_xu jichen: this is the new plan https://review.openstack.org/#/c/445864/5/nova/api/openstack/compute/routes.py@117
06:12:00 jichen alex_xu: ok, you are saying that my previous patches is no use now?
06:12:34 alex_xu jichen: I think it is still useful, but may need a little change

Earlier   Later