| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-02-23 | |||
| 16:30:23 | dtroyer | but that hasn't been an issue for a long time | |
| 16:30:51 | swatson_ | I would hope that doesn't have much of an impact for this | |
| 16:31:03 | swatson_ | I'm on Ubuntu 14.04 with mine | |
| 16:31:20 | swatson_ | Though I have had to use sudo on my setup commands because of complaints about ownership of the /usr/local/lib dir | |
| 16:31:39 | swatson_ | specifically /usr/local/lib/python2.7/dist-packages | |
| 16:32:06 | dtroyer | that is normal if you are installing into the system python and not a venv | |
| 16:32:18 | ankur-gupta-f4 | i avoided pip and cloned repos from git. Don't have magnum installed, just python-magnumclient | |
| 16:32:56 | dtroyer | you shouldn't need magnum at all | |
| 16:33:34 | swatson_ | so far Ankur is the only one who's gotten the expected result from this | |
| 16:34:06 | dtroyer | I get the same thing on 14.04 in a venv | |
| 16:34:14 | dtroyer | from PyPI | |
| 16:34:27 | swatson_ | The EntryPoint.parse eror? | |
| 16:34:31 | swatson_ | s/eror/error | |
| 16:34:37 | dtroyer | is magnumclient master different from latest release in this area? | |
| 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 | |