| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-28 | |||
| 19:48:22 | efried | I try to do it for the most part. | |
| 19:48:36 | efried | Though I can't bring myself to say 'openstack server list' when 'nova list' will do ;-) | |
| 19:48:43 | mriedem | well root beer scratch n sniff for you then | |
| 19:49:11 | efried | mriedem Yup, looks like you're right about the default version: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/client.py#L26 | |
| 19:49:26 | efried | From what I can tell, that gets used for anything that doesn't have an explicit override in the env. | |
| 19:50:10 | mriedem | makes sense | |
| 19:50:15 | efried | or, duh, that file is just the compute client. | |
| 19:50:27 | melwitt | I think one challenge with osc is the different client CLIs don't do the same thing by default. nova's defaults to latest but I think ironicclient defaults to base? | |
| 19:51:00 | mriedem | i think cinderclient also wanted to default to base | |
| 19:51:00 | melwitt | so if one were to implement version discovery in osc, you'd have to do it differently per client to make it act the same as the corresponding component CLIs | |
| 19:51:32 | smcginnis | It would be good anyway if we all got consistent on that. | |
| 19:51:35 | mriedem | i think other clients default to base for cli for backward compatibility, but i don't think we've ever said the cli is a contract so we allow going to latest | |
| 19:51:52 | mriedem | if you wanted to pin the cli for novaclient you have to specify the microversion | |
| 19:51:54 | melwitt | yeah, I agree I think that's why | |
| 19:52:01 | smcginnis | mriedem: We've treated it more as a gentlemans agreement. | |
| 19:52:14 | mriedem | smcginnis: that's the most sexist thing i've ever heard | |
| 19:52:22 | smcginnis | :P | |
| 19:52:29 | melwitt | :) | |
| 19:52:35 | mriedem | maybe you need to bring it up at the forum as session topic | |
| 19:52:43 | mriedem | "what should the default cli microversion behavior be?" | |
| 19:53:20 | jroll | fwiw, I applaud nova for having cli default to latest | |
| 19:53:26 | jroll | trying to push that in ironic as well | |
| 19:53:42 | jroll | this is not a bash sdk ಠ_ಠ | |
| 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, | |