Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-02-23
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 and it should not have been for senlin either FWIW
17:57:48 dtroyer so no, using "cluster" is not an option
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?
18:08:09 dtroyer maybe? the hesitation is that is often used to refer to our Infrastructure team in OpenStack-speak and may be confusing in some contexxts.
18:08:36 dtroyer usually we discourage abbreviations, but some are just obvious like "ip"
18:09:37 swatson_ This is a tougher nut to crack than I thought it would be
18:10:46 dtroyer yup
18:11:51 dtroyer infra cluster is probably good enough, at least to start.
18:13:12 swatson_ I'll go with that for now, then
18:13:22 ankur-gupta-f4 +1 for teamwork
18:13:33 swatson_ d-(^_^)z
18:14:17 ankur-gupta-f4 sindhu: u had a question too?
18:15:19 dtroyer I suspect it was about https://review.openstack.org/#/c/383025/
18:16:37 reedip_1 sindhu : hey
18:16:42 dtroyer sindhu: make sure you have https://review.openstack.org/#/c/435735/ in your git history. rebase your patchset on master if you have not done that since 435735 merged.
18:17:41 ankur-gupta-f4 I think she may be at lunch
18:26:23 ankur-gupta-f4 dtroyer: https://review.openstack.org/#/c/391331/
18:29:17 openstackgerrit Merged openstack/python-openstackclient master: add keystone and glance -> osc mapping https://review.openstack.org/437112
18:30:01 openstackgerrit Merged openstack/python-openstackclient master: minor tweaks to mapping table https://review.openstack.org/437119
18:30:21 openstackgerrit Merged openstack/python-openstackclient master: Revert unit tests for quota commands https://review.openstack.org/437366
18:37:00 dtroyer ankur-gupta-f1: the definition "an auto-allocated topology for a project" doesn't add much information. including something about when or where the topology is used would be helpful. "A project-specific network topology used when xxxx is yyyy". what are simple xxx and yyy here?
18:41:06 dtroyer is "… used to create servers connected to a pre-defined network." close?
18:44:09 ankur-gupta-f4 dtroyer: I didn't want it to make it too verbose. which is why i linked the Neutron documentation on it
18:55:56 openstackgerrit Terry Howe proposed openstack/python-openstacksdk master: Fix the object store set metadata functional test https://review.openstack.org/437558
19:32:08 openstackgerrit Lars Kellogg-Stedman proposed openstack/python-openstacksdk master: the role resource should not have put_create=True https://review.openstack.org/437571
19:55:23 openstackgerrit Lars Kellogg-Stedman proposed openstack/python-openstacksdk master: don't force image download to memory https://review.openstack.org/437588
19:56:48 sindhu dtroyer: Okay will do :) thanks
19:56:58 sindhu reedip_1: hey
19:57:33 reedip_1 sindhu : nothing, I wondered why ypu stated that we dont need port in openstack floatin IP set /unset . But it makes sense now :)
19:57:51 sindhu ankur-gupta-f4: yeah, Dean responded. It was related to his comment on one of my patches
19:58:10 ankur-gupta-f4 yup
19:58:18 sindhu reedip_1: yea, it's needed only for set. unset doesn't need it
20:05:48 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
20:21:16 openstackgerrit Lars Kellogg-Stedman proposed openstack/python-openstacksdk master: don't force image download to memory https://review.openstack.org/437588
20:24:47 openstackgerrit Lars Kellogg-Stedman proposed openstack/python-openstacksdk master: don't force image download to memory https://review.openstack.org/437588
20:25:25 openstackgerrit Lars Kellogg-Stedman proposed openstack/python-openstacksdk master: the role resource should not have put_create=True https://review.openstack.org/437571
20:49:39 mordred dtroyer, jamielennox: maybe we should chat about osc/occ related thigns at some point?
20:50:11 jamielennox mordred, dtroyer: i'm easy - now or tomorrow?
21:03:22 dtroyer now is good for me
21:03:30 dtroyer mordred, jamielennox ^^^
21:04:26 jamielennox want morgan? he's in the same room as me making a nuisance of himself
21:06:24 mordred dtroyer, jamielennox: which room are y'all in?
21:07:05 dtroyer I'll relocate to wherever
21:08:01 jamielennox in the keystone cave
21:08:05 jamielennox tell me where
21:08:25 dtroyer I'll head down to the 1st floor lobby…. coffee area
21:09:20 mordred I'll wander down in just a sec
21:09:28 jamielennox yep
21:46:07 openstackgerrit Lars Kellogg-Stedman proposed openstack/python-openstacksdk master: keystone api v2.0 does not paginate roles or users https://review.openstack.org/437691
21:56:03 openstackgerrit Reedip proposed openstack/python-openstackclient master: Introduce quota unset command https://review.openstack.org/376311
21:58:56 reedip_1 sindhu , ankur-gupta-f1, stevemar : https://review.openstack.org/#/c/376311/ for review, if you have some time ?
21:59:09 ankur-gupta-f4 yea looking at it right now
22:01:40 reedip_1 great, thanks :)

Earlier   Later