| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-28 | |||
| 19:54:12 | melwitt | yeah, I have thought it would kind of suck to get the latest CLI and then not be able to use what, 20+ new microversions out-of-the-box and have to do something extra? | |
| 19:54:42 | jroll | yeah | |
| 19:55:01 | jroll | then the same people that want default at base complain they need to do work to get features, sigh | |
| 19:55:59 | melwitt | sounds about right :P | |
| 19:56:43 | mriedem | bash sdk, i like that | |
| 19:56:48 | mriedem | sounds like somthing sdague would say | |
| 19:56:57 | melwitt | I like the look of disapproval on that too | |
| 20:00:14 | sdague | smcginnis: part of the reason for nova client defaulting to latest is it also demonstrates how you could discover the server version and just do all the newest things the server will allow you | |
| 20:00:33 | smcginnis | sdague: I actually have come around to that. | |
| 20:00:45 | smcginnis | sdague: We originally wanted to avoid accidentally getting unexpected behavior. | |
| 20:01:00 | smcginnis | sdague: But I think that isn't as clean of UX. | |
| 20:02:59 | efried | I assume this conversation would be moot if we weren't breaking backward compatibility all the time? | |
| 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 | |