| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-28 | |||
| 17:56:12 | dansmith | I've been in a hole for a while, have a pointer to what was being resolved? | |
| 17:57:08 | efried | dansmith No, I didn't follow it that closely, just did some rechecks and walked away whistling when I saw green... | |
| 17:57:21 | dansmith | hmm, okay | |
| 17:57:28 | efried | But maybe I can resurrect a link to a failed one so we can see if it's the same. | |
| 17:57:34 | efried | I wanna say mine wasn't even getting that far, though. | |
| 17:57:47 | dansmith | this is the one from yesterday: http://logs.openstack.org/25/438025/32/check/gate-nova-tox-functional-py35-ubuntu-xenial/a773f20/testr_results.html.gz | |
| 17:58:41 | efried | The ones I was seeing yesterday were actually in gate-nova-python35 | |
| 17:58:53 | efried | So - never mind \o/ | |
| 17:59:01 | dansmith | oh those are devstack on py35 right? | |
| 17:59:30 | efried | Dunno about devstack. Example: http://logs.openstack.org/04/409404/19/check/gate-nova-python35/f8976ec/ | |
| 17:59:34 | efried | Didn't even run any tests. | |
| 18:00:26 | dansmith | ah, unit tests | |
| 18:00:27 | dansmith | hmm | |
| 18:01:11 | dansmith | well, I have to upgrade locally before I can run py35 tests so I guess I'll do that | |
| 18:01:57 | efried | Actually, that one is still failing, same way. So now I'm worried again. | |
| 18:06:26 | efried | mriedem I'm getting the error "nics must be a list" when attempting to do openstack server create with --nic none. It looks like you added _validate_create_nics via https://review.openstack.org/#/c/353018/ which doesn't seem to account for 'none' (or None). Am I missing something, or can I open a bug? | |
| 18:28:22 | mriedem | efried: --nic | |
| 18:28:24 | mriedem | see the test https://review.openstack.org/#/c/353018/8/novaclient/tests/functional/v2/test_servers.py | |
| 18:28:35 | mriedem | are you specifying the 2.37 microversion or using a client new enough to support that? | |
| 18:45:15 | jaypipes | sfinucan: please see my comment/question to sahid on https://review.openstack.org/#/c/385364... | |
| 18:47:32 | efried | mriedem I'm not specifying a microversion. How do I tell how old/new my client is? | |
| 18:48:01 | efried | mriedem Oh, I see; I shouldn't have hit that branch if I was using 2.37+ | |
| 18:48:30 | efried | Does openstackclient get installed as part of devstack? Cause I *just* restacked. | |
| 18:53:37 | efried | Perhaps not; but my installation appears to be from 3/10. So it's surely new enough to support. I don't know how to specify it, though. | |
| 18:59:30 | efried | --os-compute-api-version 2.37 - that did the trick. | |
| 19:42:20 | openstackgerrit | Samantha Blanco proposed openstack/nova master: Make flavor-rxtx policy more granular flavor-rxtx currently only has one policy it checks against, which is not restrictive enough when used in conjunction with other policies (e.g., flavor-manage). This allows users a greater degree of customization. https://review.openstack.org/444036 | |
| 19:43:34 | mriedem | efried: that's kind of odd because the default behavior in the CLI is to use the latest available supported version in the client if the server is new enough | |
| 19:44:07 | mriedem | efried: which is 2.41 now https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L28 | |
| 19:44:11 | efried | mriedem I would have expected so. I checked my openrc and it wasn't specifying OS_COMPUTE_API_VERSION before. | |
| 19:44:19 | mriedem | so --nic none should work automatically with latest devstack | |
| 19:44:21 | melwitt | mriedem: I think he's using openstackclient, it must not do the same thing of defaulting to latest? | |
| 19:44:28 | mriedem | if you're using osc, then idk | |
| 19:44:31 | mriedem | all bets are off | |
| 19:44:35 | melwitt | heh | |
| 19:44:58 | efried | I had somehow gotten the impression that we were supposed to use osc rather than individual component CLIs. Not so? | |
| 19:44:59 | mriedem | would have to ask stevemar or dtroyer, | |
| 19:45:11 | melwitt | efried: if you use the novaclient 'nova boot ...' it should Just Work(tm) | |
| 19:45:11 | mriedem | but i woudn't be surprised if osc defaults the cli to 2.1 | |
| 19:45:26 | mriedem | right the default cli behavior i was talking about was for novaclient | |
| 19:47:58 | mriedem | efried: we should be using osc for cli stuff more now | |
| 19:48:02 | melwitt | efried: no, I think that's right, we do say use osc for the most part but it doesn't know anything about microversions. it will work if you pass the api version the way you did, as that will get passed through to novaclient | |
| 19:48:10 | mriedem | i personally haven't forced myself to do that yet | |
| 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 | 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:00 | mriedem | i think cinderclient also wanted to default to base | |
| 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 | |