Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-02-23
16:18:58 swatson_ Right. And even with both master branches updated on my machine I don't see it coming up after running setup for both projects
16:19:20 swatson_ ankur-gupta-f4 the paste was via "openstack help | grep cluster"
16:20:45 ankur-gupta-f4 :( time to pick dean's brain
16:23:40 ankur-gupta-f4 swatson_: master branch with no local changes
16:23:47 swatson_ Correct
16:25:13 ankur-gupta-f4 😕
16:27:42 dtroyer fresh venv, "pip install -e ." in both master osc and magnumclient
16:27:50 dtroyer openstack help | grep cluster
16:27:51 dtroyer Could not load EntryPoint.parse('cluster_template_list = magnumclient.osc.v1.cluster_templates:ListTemplateCluster')
16:28:06 dtroyer so I'm clearly not in the same place either of you guys are yet
16:28:29 swatson_ dtroyer Just to verify: you pulled down python-magnumclient?
16:28:45 dtroyer yes, from git.o.o
16:29:06 dtroyer I see the same thing installing both from PyPI
16:29:07 swatson_ OK, just double-checking. We have a magnumclient directory in magnum
16:29:18 dtroyer ah, that's confusing
16:29:53 swatson_ I agree. We have plans for it but that's after I can get this plugin working :P
16:30:04 dtroyer full disclosure, this is on OS/X 10.10.5
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_ "
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: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"

Earlier   Later