| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-02-23 | |||
| 16:34:39 | dtroyer | yes | |
| 16:35:03 | swatson_ | I don't believe it's different. The cluster template list command was merged 4 weeks ago | |
| 16:36:02 | dtroyer | heh, you may want to reconsider using oslo_log in clients | |
| 16:36:20 | swatson_ | Dare I ask why? | |
| 16:36:29 | dtroyer | most of oslo makes assumptions about being used in servers, not clients | |
| 16:36:40 | swatson_ | ah | |
| 16:36:49 | dtroyer | sometimes it is safe, but as a default it may not be | |
| 16:37:02 | dtroyer | so you need to verify, and then hope it doesn't change out from under you | |
| 16:37:12 | dtroyer | what do you get from oslo_log here? | |
| 16:37:36 | swatson_ | I'm not sure, to be honest. This was implemented some time before I joined :P | |
| 16:39:21 | dtroyer | ok, just an observation | |
| 16:39:50 | swatson_ | I'll bring it up in the next magnum meeting :) | |
| 16:42:05 | swatson_ | In any case I'm grabbing the latest python3 so I can try a venv on this | |
| 16:43:54 | dtroyer | so, turns out my problem was in fact oslo_log | |
| 16:44:10 | dtroyer | it isn't in requirements.txt for magnumclient so was not installed | |
| 16:44:12 | dtroyer | installing it and I see the command in help | |
| 16:45:01 | swatson_ | I might need to add that to requirements.txt then, good catch | |
| 16:45:06 | swatson_ | That means there's something wrong on my system then | |
| 16:45:09 | dtroyer | or remove the import | |
| 16:45:31 | dtroyer | I don't see anything that need it over the syslib logging | |
| 16:45:42 | swatson_ | or that | |
| 16:47:34 | dtroyer | fwiw, python-manilaclient is the only other client that uses oslo_log | |
| 16:47:54 | dtroyer | ugh, they import oslo.config too | |
| 16:48:20 | swatson_ | Copy pasting is good, right? Right?! | |
| 16:49:55 | swatson_ | new venv, ran setup.py for both projects, no dice | |
| 16:49:57 | dtroyer | heh, OpenStack does that? | |
| 16:50:18 | dtroyer | try using pip | |
| 16:50:31 | dtroyer | IIRC that is the only way we test installing anymore | |
| 16:50:35 | swatson_ | "pip install -e"? | |
| 16:50:45 | dtroyer | yes | |
| 16:50:53 | dtroyer | I think there are some subtle differences | |
| 16:51:05 | ankur-gupta-f4 | pip install -e . | |
| 16:51:20 | swatson_ | ankur-gupta-f4 Thanks for that, was about to ask | |
| 16:52:09 | swatson_ | "error in setup command: Error parsing /home/intel/osc_venv/build/cliff/setup.cfg: SyntaxError: '<' operator not allowed in environment markers | |
| 16:52:09 | swatson_ | " | |
| 16:52:31 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix can not set is_default in network https://review.openstack.org/434602 | |
| 16:53:26 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/python-openstackclient master: Add new parameter "is_default" to Network QoS policy. https://review.openstack.org/432260 | |
| 16:53:40 | swatson_ | dtroyer ankur-gupta-f4 A-ha! Pip did it | |
| 16:54:31 | swatson_ | I went outside my venv and ran "pip install -e ." in python-magnumclient, then did the same in python-openstackclient and the command came up as expected | |
| 16:54:41 | ankur-gupta-f4 | woot woot | |
| 16:54:51 | ankur-gupta-f4 | All board the container train | |
| 16:55:31 | swatson_ | Thanks for the help, guys. I appreciate it | |
| 16:56:26 | ankur-gupta-f4 | np gl | |
| 17:36:34 | swatson_ | Got another question for the channel: Since another group has already used "cluster" for their OSC plugin, magnum needs to differentiate their commands. Is there any kind of guideline for these collisions? i.e. should I just preface each magnum-specific command with "container-infra"? | |
| 17:38:52 | ankur-gupta-f4 | swatson_: what is the service type name? | |
| 17:39:15 | swatson_ | ankur-gupta-f4 I'm not sure what you mean | |
| 17:39:35 | dtroyer | swatson_: it is a subtle distinction, but we do not namespace commands like that as a group. look for a specific name for each resource to fully-qualify it | |
| 17:40:20 | dtroyer | sometimes it will look like it is a simple namespace; volume is an example, everything they do involves volumes. | |
| 17:40:37 | ankur-gupta-f4 | just container then i would think | |
| 17:41:04 | dtroyer | there are multiple kinds of containers, and multiple OpenStack projects that want to manipulate them | |
| 17:41:07 | dtroyer | that is tto generic | |
| 17:41:30 | swatson_ | ankur-gupta-f4: We didn't like using container because it implied we were creating containers as opposed to container orchestration engines | |
| 17:42:05 | dtroyer | fwiw, this is the hardest part of a single CLI | |
| 17:42:09 | swatson_ | dtroyer: My concern is best case we would be able to use "openstack cluster list" and know magnum was handling the listing of clusters | |
| 17:43:01 | swatson_ | dtroyer: Maybe I'm misunderstanding what you're referencing | |
| 17:43:10 | dtroyer | we were able to handle the switching between Nova-net and Neutron just by looking in the service catalog for a network endpoint. | |
| 17:43:32 | dtroyer | but those commands that overlapped did mostly the same thing so we could hide the differences | |
| 17:44:00 | swatson_ | so if I call "openstack network list" and both nova-net and neutron implement the same command, what would happen? | |
| 17:44:09 | swatson_ | Or is that a case of needing a different name? Or am I misunderstanding? | |
| 17:44:18 | dtroyer | that is not a thing, it is mutually exclusive | |
| 17:44:34 | dtroyer | nova-net vs neutron. you can not have both in a single cloud | |
| 17:44:42 | sindhu | dtroyer: ping? | |
| 17:46:02 | dtroyer | senlin also has a claim on the resource "cluster" | |
| 17:46:38 | dtroyer | but they did not put it in our list: https://docs.openstack.org/developer/python-openstackclient/commands.html#objects | |
| 17:46:55 | dtroyer | duh, plugin list is separate | |
| 17:47:09 | dtroyer | it is in this one: https://docs.openstack.org/developer/python-openstackclient/commands.html#plugin-objects | |
| 17:48:36 | ankur-gupta-f4 | well that doesn't leave much choices that make sense | |
| 17:48:40 | swatson_ | dtroyer: So magnum needs to just prepend a name to differentiate in this case? | |
| 17:49:47 | dtroyer | again, I use the phrase "fully-qualify" | |
| 17:50:17 | dtroyer | mostly to let people the flexibility to come up with better names than <api-name>-<thing> | |
| 17:50:37 | ankur-gupta-f4 | but that could cause confusion. i.e. 'container' is object storage but then 'container infra' would be magnum... | |
| 17:51:27 | dtroyer | which is one reason I do not want folks using their service typethere. name the resource, not the api | |
| 17:52:26 | dtroyer | "infra cluster" is an example, it isn't the service type, but should be easily distinguishable from senlin's cluster, whatever that actually is | |
| 17:52:46 | ankur-gupta-f4 | i was about to say. I don't even know what senile does.... | |
| 17:52:52 | ankur-gupta-f4 | senlin | |
| 17:52:58 | dtroyer | I like that typo! :) | |
| 17:53:21 | ankur-gupta-f4 | autocorrect :| | |
| 17:54:35 | swatson_ | dtroyer: I'm still a little hazy I guess, probably because I'm a little new to OSC in general | |
| 17:55:12 | swatson_ | Are you recommending going forward with the "best case" commands for magnum (e.g. "openstack cluster list") because OSC provides some way to fully qualify the command in case of collision? | |
| 17:55:49 | swatson_ | :P | |
| 17:56:38 | openstackgerrit | Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025 | |
| 17:57:02 | dtroyer | swatson_: we have no aut-disambiguation in OSC. We do have a check queue job that looks for collisions, that is the only way to detect them | |
| 17:57:48 | dtroyer | so no, using "cluster" is not an option | |
| 17:57:48 | dtroyer | and it should not have been for senlin either FWIW | |
| 17:58:04 | dtroyer | because it is too generic and likely that a cloud has more than one kind of cluster associated with it | |
| 17:58:33 | swatson_ | I think I'm mostly on the same page now | |
| 17:59:04 | dtroyer | Nova got the bare "flavor" because it was first, and it was 3 years before another project wanted to use that word. We do plan to qualify it to "server flavor" at some point, but the bare "flavor" will always work | |
| 17:59:54 | dtroyer | I can enforce that because it is in the OSC repo. I can not prevent a plugin from using any specific word, except by the plugin not working if there actually is a collision | |
| 18:01:01 | swatson_ | Is your primary concern in this case finding a good, single word so we aren't just jamming "container-infra" (or something like it) in front of everything? | |
| 18:01:45 | dtroyer | first concern is "think of the users". properly describing the resources is a big step in usability | |
| 18:02:27 | dtroyer | the more descriptive the better. balanced with length | |
| 18:03:19 | swatson_ | Is OSC's goal to be more-or-less project-agnostic? I.e. enable a user to use industry-standard cloud terms without having to know openstack-specific ones? | |
| 18:03:42 | dtroyer | and yes, we do not want blind namespacing. congress did that, and unfortunately used their project name. | |
| 18:04:47 | swatson_ | Hmm | |
| 18:04:58 | dtroyer | we have always tried to hide the project lines from users, ie, a user should not need to know that "cinder" managed volumes and "manila" manages shared filesystems. they should just have to know "volume" and "share" (or whatever manila used there) | |
| 18:04:59 | ankur-gupta-f4 | 'openstack infrastructure *' . No collisions. Then when you append the magnum commands you would get something like 'openstack infrastructure cluster create' and descriptive ... Thoughts??? | |
| 18:05:34 | dtroyer | it is long but that is the idea | |
| 18:06:29 | ankur-gupta-f4 | no longer than some of the ironic commands | |
| 18:07:19 | dtroyer | right. but we do need to consider the balance. buth then, tab-completion is also a thing | |
| 18:07:24 | swatson_ | Would "infra" be a decent-enough prefix? | |