18:01:17 <SlickNik> #startmeeting trove
18:01:18 <openstack> Meeting started Wed May 21 18:01:17 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:22 <openstack> The meeting name has been set to 'trove'
18:01:28 <denis_makogon> o/
18:01:29 <iccha1> o/
18:01:30 <mattgriffin> o/
18:01:34 <kevinconway> o/
18:01:39 <imsplitbit> o/
18:01:40 <vipul> o/
18:01:40 <pdmars> o/
18:01:42 <amcrn> o/
18:01:43 <peterstac> \o
18:01:45 <amytron> o/
18:01:51 <amrith> \0/
18:01:52 <grapex> ~o~
18:01:59 <vgnbkr> o/
18:02:02 <Barker> o/
18:02:14 <cp16net> o/
18:02:17 <robertmyers> o/
18:02:17 <mat-lowery> o/
18:02:21 <peoplemerge> o/
18:02:27 <cp16net> grapex: is doing the wave
18:02:46 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Agenda_for_May_21
18:02:48 <amcrn> pop and lock
18:02:54 <glucas> o/
18:03:03 <grapex> cp16net: I hope your PSA involves a cartoon mascot singing about logging safety.
18:03:07 <dougshelley66> o/
18:03:26 <SlickNik> #topic Informational PSA on Openstack Logging Standards
18:03:30 <esp> o/
18:03:38 <SlickNik> cp16net: all yours
18:03:47 <cp16net> #link http://media0.giphy.com/media/Zjh1dptLNm5Qk/200_s.gif
18:03:57 <cp16net> #link https://wiki.openstack.org/wiki/LoggingStandards
18:04:24 <cp16net> so there was a review for removing the translations for debug messages
18:04:34 <vipul> the image also seems to go well with the topic ;)
18:04:36 <grapex> cp16net: I was about to say please add an underscore to that picture so we can localize it
18:04:45 <cp16net> i was not aware of this link so i thought i would share so we can all be on the same page
18:04:52 <grapex> but thanks to that other link I now know that isn't how we roll in Trove. Thanks cp16net!
18:05:31 <cp16net> but this also leads to us making sure we make log messages at the right level
18:05:50 <cp16net> currently *almost* everything is in debug
18:05:55 <iccha1> +1
18:05:59 <denis_makogon> ++
18:06:05 <cp16net> and this is not helpful for operations to turn down logging
18:06:16 <vipul> yea without debug turned on.. you're SOL
18:06:24 <denis_makogon> agreed, we need more INFO level logging
18:06:28 <cp16net> i think getting some input from people running this in a prod env would help a ton
18:06:57 <iccha1> also the note on running other libraries at different log levels is useful note for deployments
18:06:59 <cp16net> so i think the action here is to audit out logging levels throughout trove
18:07:35 <denis_makogon> sound reasonable
18:07:36 <vipul> +1 we should be looking at this during reviews as well
18:07:41 <cp16net> #action make a bug to audit logging levels throughout trove code code with deployers
18:08:00 <grapex> I like this policy much better than the "put underscores in front of every string ever" policy
18:08:01 <cp16net> #agree vipul
18:08:15 <denis_makogon> grapex, +1
18:08:16 <amcrn> and if someone is planning on helping out with this, please be holistic vs. pushing a couple dozen reviews, fixing it file by file :)
18:08:39 <kevinconway> there goes my strategy of one commit per log line
18:08:49 <cp16net> amcrn: i think either way would be fine as long as its not considered done after the first review
18:08:52 <denis_makogon> amcrn, agreed, hard to review a 2k lines patch with only one type of change
18:09:05 <dougshelley66> seems like we should break it up logically?
18:09:08 <cp16net> because you might not know what the guest agent logging should be for c*
18:09:18 <denis_makogon> dougshelley66, file by file
18:09:27 <kevinconway> cp16net: but we use a python guest agent?
18:09:29 <SlickNik> #action cp16net make a bug to audit logging levels throughout trove code code with input from deployers
18:09:32 <denis_makogon> dougshelley66, or per package
18:09:33 <vipul> denis_makogon: no please don't do file by file
18:09:46 <cp16net> amcrn: but i agree to make sure it includes at least the whole module of changes
18:09:54 <SlickNik> cp16net: add your name to the #action line. :)
18:09:58 <amcrn> i think my comma was misplaced, i was against file by file :D
18:10:05 <cp16net> gotcha thanks :)
18:10:07 <vipul> those commas
18:10:11 <dougshelley66> i was referring to some reasonable grouping that could be split across multiple devs?
18:10:14 <cp16net> gotcha
18:10:29 <denis_makogon> amcrn, get it =)
18:10:29 <cp16net> dougshelley66: sure
18:10:50 <kevinconway> can we get the implementors of datastores to fix their guest logs?
18:10:51 <denis_makogon> but first we need policy
18:10:52 <cp16net> ok any othe questions
18:10:56 <cp16net> i'm done
18:11:25 <denis_makogon> kevinconway, first implement postgresql then convince us to re-write our code =))
18:11:38 <amcrn> hashtag rekt
18:11:39 <kevinconway> denis_makogon: sick burn
18:11:45 <SlickNik> So guys, while I think this is important. I don't think it's a high-pri item.
18:12:09 <cp16net> SlickNik: i agree its a low at most
18:12:10 <SlickNik> If you're interested in helping out with it, I'd suggest you touch base with cp16net rather than submit a competing patch.
18:12:10 <denis_makogon> yeah, i agree
18:12:20 <SlickNik> Okay, 'nuff said.
18:12:23 <cp16net> ok
18:12:43 <SlickNik> #topic Follow up on ATL discussion on Code Reviews
18:12:58 <SlickNik> #link https://etherpad.openstack.org/p/trove-review-juno
18:13:45 <SlickNik> So at ATL we decided to use a custom dashboard to focus our review efforts.
18:13:54 <vipul> here's another one that we tried to take notes in during the session, but etherpad was a flake: https://etherpad.openstack.org/p/juno-trove-reviews
18:14:00 <denis_makogon> #link bit.do/trove-reviews
18:14:16 <SlickNik> This dashboard is at: http://bit.do/trove-reviews
18:14:39 <SlickNik> A couple of you mentioned that this doesn't capture reviews from the client and integration projects.
18:15:02 <cp16net> SlickNik: you can include the other ones as well
18:15:04 <SlickNik> So I created another that does at: http://bit.do/all-trove-reviews
18:15:26 <SlickNik> #link http://bit.do/all-trove-reviews
18:15:38 <denis_makogon> SlickNik, amazing =)
18:15:45 <vipul> nice
18:15:52 <iccha1> sweet!
18:15:53 <grapex> SlickNik: really great stuff!
18:15:56 <amcrn> <3 SlickNik
18:16:17 <grapex> Someone at Rax just pointed this out, so quick reminder that you need to be signed in first for the link to work.
18:16:41 <SlickNik> Also wanted to touch upon a couple of other issues that came up.
18:16:46 <cp16net> nice
18:17:01 <mat-lowery> This is great SlickNik. Can you elaborate on the meaning of "No Negative Feedback"?
18:17:11 <SlickNik> I'm still looking into the beginning of meeting stats, so I'll keep you posted on that
18:17:14 <mat-lowery> (Or I could read the query.)
18:17:23 <denis_makogon> mat-lowery, has no -1 for now
18:17:32 <SlickNik> mat-lowery: Passed unit tests, passed integration tests, and no −1 from other reviewers.
18:17:50 <imsplitbit> so I see a fundamental problem here, if I may, metadata is no where on here
18:18:07 <mat-lowery> If I remember correctly, I was told that core does look at -1s. This seems to contradict that.
18:18:11 <vipul> does it have a -1? imsplitbit
18:18:16 <grapex> Also... let's talk about it
18:18:20 <denis_makogon> imsplitbit, is is abandoned due to hang timeout?
18:18:21 <grapex> I think core should in general look at more stuff
18:18:25 <denis_makogon> *is it
18:18:35 <imsplitbit> and that's because Auston asked to hold the client changes until the server piece is reviews
18:18:40 <imsplitbit> reviewed
18:18:45 <grapex> but looking at -1 explicitly is a little silly- its like saying "we must be better at looking at the lowest priority items."
18:19:01 <denis_makogon> i would say that we need another section "Abandoned due to time expiration"
18:19:04 <imsplitbit> and the server will fail jenkins until client patch is merged
18:19:08 <grapex> imsplitbit: That seems like a good case for making blueprints the starting point of where core looks.
18:19:12 <SnowDust> mat-lowery: +1
18:19:18 <SlickNik> imsplitbit: And why isn't the server piece in here?
18:19:34 <imsplitbit> because jenkins -1 it
18:19:35 <SlickNik> because of a −1 dependency on the client?
18:19:46 <imsplitbit> cause tests fail due to the client not having metadata support in it
18:20:11 <vipul> yea this is the fun of having a cross dependency :D
18:20:16 <grapex> So I think this is a good start, but we probably won't be able to go off a filter alone
18:20:23 <imsplitbit> so I just wanted to point that out
18:20:25 <grapex> I think we should look at this and at the blueprints
18:20:37 <imsplitbit> this dashboard is nice but that is a rather large flaw for any new features
18:20:39 <mat-lowery> grapex: good start. can't be the only list
18:20:53 <grapex> if there's a -1'd pull request in Gerrit that is part of a blueprint which is low priority that hasn't been well-discussed, I'm personally ok if Core looks at that dead-last / not-at-all
18:21:11 * grapex runs for cover
18:21:23 <SlickNik> This comes back to our core-standup. We'll have to discuss bps that don't show up because of cross dependencies like this separately.
18:21:40 <imsplitbit> *unless* we merge client code first which is scary since changes made on the reviews for server code could necesitate a change in the client
18:21:56 <cp16net> make sure we know where bp stands
18:21:57 <imsplitbit> kk I just wanted to point this out
18:21:59 <SlickNik> I'm still need to work something out here with the other core folks - so stay tuned for info regarding this.
18:22:14 <imsplitbit> Rax is looking to use metadata asap so I get asked about it daily
18:22:33 <SlickNik> imsplitbit: Historically we've had to merge client code first so that we can make sure that tests pass.
18:23:05 <SlickNik> imsplitbit: Issue duly noted. Will figure out what the best way to handle such cases is.
18:23:12 <grapex> SlickNik: I don't see that changing unless we move to writing Tempest tests in the Trove repo with the copy/pasta client
18:23:41 <SlickNik> grapex: same here.
18:23:49 <SlickNik> okay moving on to another point that came up.
18:24:11 <SlickNik> The 2 +2 reviews needed for approval.
18:24:38 <SlickNik> So I talked to multiple folks, and this is definitely a cross OpenStack thing.
18:25:05 <SlickNik> #link https://wiki.openstack.org/wiki/GerritJenkinsGit#Reviewing_a_Change
18:25:29 <SlickNik> "When a review has two +2 reviews and one of the core team believes it is ready to be merged, he or she should leave a +1 vote in the "Approved" category."
18:25:56 <vipul> so it's just a practice, but not enforced by gerrit?
18:26:01 <iccha1> yes
18:26:04 <SlickNik> vipul: yes
18:26:12 <vipul> ok, sounds good
18:26:14 <esmute> doesnt the core who gave the 2nd +2 also does a +1 approved?
18:26:32 <iccha1> all cores have +1 approved at any time
18:26:38 <denis_makogon> esmute, it seems - 3d one
18:26:39 <iccha1> its when they choose to use it
18:26:40 <SlickNik> Also IMHO, it's a good thing. We've caught issues in the past during a second review.
18:26:51 <SlickNik> So I suggest keeping it exactly like it is today.
18:26:57 <SlickNik> And not changing this.
18:27:04 <esmute> so does that mean we need 3 cores to get a patch merged?
18:27:19 <iccha1> 2nd core can approve it
18:27:23 <vipul> just 2 cores
18:27:27 <SlickNik> esmute: Nope, the second +2 also does an approve.
18:27:32 <SlickNik> so 2 cores.
18:27:48 <denis_makogon> so, basically, nothing changed
18:27:59 <vipul> I think it's been working.. let's just keep doing it the way we have
18:28:00 <esmute> ahh ok.. so this is just to ensure that the core who gave the second +2 also gives a +1 when approving
18:28:36 <SlickNik> esmute: This is a follow up to the conversation some folks had in ATL where they wanted to move to a system that required only 1 core approval.
18:28:54 <SlickNik> esmute: And I'm clarifying that we're NOT moving to that. :)
18:28:54 <cp16net> sounds good
18:29:10 <esmute> ok.. thanks for the clarification SlickNik
18:29:32 <SlickNik> Okay, that's pretty much all I had on the follow up.
18:29:44 <vipul> SlickNik: when is the core standup?
18:30:08 <esmute> are you guys doing a hangout?
18:30:28 <SlickNik> vipul: haven't gotten around to figuring that out just yet. Working on a doodle. Expect a link in your inbox sometime today. :)
18:30:34 <vipul> ok
18:30:43 <SlickNik> Any other questions?
18:30:44 <grapex> vipul: I vote for not during my lunch
18:30:53 <amcrn> i vote for grapex's lunch hour
18:30:57 <vipul> grapex: how about your yoga hour
18:30:58 <cp16net> fail
18:31:07 <grapex> As a former resident of the third most obese city in America I think us Texans have given up enough of our most precious resource... food.
18:31:07 <amcrn> ;D
18:31:21 <esmute> grapex: where did you move to?
18:31:29 <SlickNik> #topic Open Discussion
18:31:36 <vipul> i thought amcrn had something
18:31:49 <denis_makogon> SlickNik, we missed last section
18:31:53 <SlickNik> oops, let me refresh
18:31:55 <amrith> I'll wait on amcrn
18:31:56 <SlickNik> my mistake
18:31:57 <denis_makogon> SlickNik, Clustering python-troveclient Interface
18:32:06 <amcrn> i snuck it in last minute due to the sparse agenda, apologies
18:32:10 <grapex> From San Antonio to Austin. Here all the hip food is in trucks so over-eaters have to run after it.
18:32:30 <SlickNik> #topic Clustering python-troveclient Interface
18:32:43 <SlickNik> amcrn: apologies. the floor is yours.
18:32:59 <amcrn> so, with the clustering spec ironed out, i was looking into the python-troveclient and quickly found out that modeling heterogenous instances is a tad awkward
18:33:12 <amcrn> #link https://gist.github.com/amcrn/c4ae2210e9d9864c21fd
18:33:58 <denis_makogon> yeah, looks pretty huge =)
18:33:58 <amcrn> so, two questions: does anyone have a better option for the heterogenous case?
18:34:12 <amcrn> denis_makogon: that's mostly formatting to deal with gist.github.com's weird text-wrap
18:34:26 <amcrn> and the other question is under the "Thoughts" subheader
18:34:44 <denis_makogon> amcrn, can we table it for at least 1-2 day to think about that ?
18:34:47 <vipul> so nova does something pretty weird with the block-device-mapping argument
18:34:47 <grapex> amcrn: So is there any other client that can take basically a "vaargs" for some series of values?
18:34:52 <hub_cap> amcrn: i think the other projects just punt on complex stuff in the client
18:34:56 <hub_cap> at least in the cli portion
18:35:09 <vipul> it's not quite json, but an ordered list of thing colon-delimited
18:35:14 <vipul> http://docs.openstack.org/trunk/openstack-ops/content/attach_block_storage.html
18:35:14 <amcrn> hub_cap: how does something like horizon then make use of that then? raw http request?
18:35:19 <SlickNik> amcrn: I know the neutron-cli does something similar. They use key=value pairs as args though.
18:35:34 <amcrn> vipul: nice, thanks for the reference
18:35:51 <amcrn> grapex: we already take json for configuration-group parameter updates
18:36:35 <grapex> amcrn: I think I'm kind of ok with the JSON approach
18:36:42 <grapex> but it isn't consistent
18:36:51 <grapex> it seems like a heterogenous cluster is sort of a power user thing though
18:36:53 <denis_makogon> i guess for now it's a pretty good way to describe complex shell request ( vipul's link )
18:37:07 <hub_cap> amcrn: make it work _in_ the client, not in the cli
18:37:09 <hub_cap> does that make sense?
18:37:15 <peterstac> what about allowing the same option to be specified multiple times?
18:37:17 <amcrn> hub_cap: ah, thanks for the clarification
18:37:21 <kevinconway> we could do something goofy like a bunch of delimeted strings
18:37:27 <vipul> it's a bit difficult to expect someone to write json in a terminal.. so i would be ok with something like nova
18:37:28 <kevinconway> --sizes="1,2,3,4"
18:37:28 <peterstac> i.e.  --flavor=1 --flavor=2 etc.
18:37:32 <cp16net> yeah just not in the shell is what hub_cap is saying
18:37:59 <amcrn> ok, so shell assumes homogenous, and if you want heterogenous we can tap into the client
18:38:13 <hub_cap> im ok w that for now
18:38:19 <denis_makogon> another question, about volumes
18:38:20 <grapex> vipul: my issue with the colon delimited list is it still switches from the format typical to the CLI to something different
18:38:21 <peterstac> kevinconway: I thought of that, but it would turn numerics into strings ...
18:38:22 <amcrn> and whether that's colon delim'd, or json, or whatever, we can hash that out over the coming days
18:38:29 <denis_makogon> do volume size is required by the default ?
18:38:40 <amcrn> denis_makogon: the cli claims it isn't, but it is afaik
18:38:56 <grapex> if it's different JSON seems easier to get right than making it a colon / fabric style approach we'd semi-invent for this.
18:38:57 <vipul> grapex: sure.. maybe we need to look at more examples like that to see if there is a precedent..
18:39:02 <grapex> vipul: +1
18:39:13 <amcrn> cool, i'll draw up more examples and drop it in the official channel
18:39:21 <denis_makogon> amcrn, thanks
18:39:30 <SlickNik> amcrn: I'm good with making this (heterogenous) work in the client, and punting on the cli till later.
18:39:31 <grapex> amcrn: Good point
18:39:33 <cp16net> #agreed
18:39:38 <iccha1> +1
18:39:42 <amcrn> definitely all agreed on the cli vs. client thing, thanks guys
18:39:49 <hub_cap> you might be able to make a subparser for --instance --flavor 1 --blah
18:39:49 <SlickNik> I think it might be a useful ML question as well.
18:39:55 <hub_cap> and --instance --flavor 2 --blah
18:40:08 <kevinconway> hub_cap: yeah that's going to be a super messy subparser i think
18:40:09 * hub_cap is not sure how it works, but think github
18:40:16 <hub_cap> err git cmd line
18:40:28 <SlickNik> okay, let's move on.
18:40:32 <SlickNik> Thanks amcrn
18:40:32 <kevinconway> i guess you could grab nargs=? and pipe that into another parser
18:40:41 <SlickNik> #topic Open Discussion
18:40:50 <amrith> \0/
18:40:55 <grapex> -1 to a subparser vs just using JSON. I think everyone would be more ok with JSON than having to own something else. :/
18:40:57 <SlickNik> amrith: go for it.
18:41:02 <hub_cap> amrith: wants to discuss a stickfigure
18:41:10 <SnowDust> anyone reviewing "vertica datastore" patch ?
18:41:14 <amrith> Trove Mid-Cycle meetup is going to be on August 20, 21, 22 in Boston/Cambridge.
18:41:16 <SnowDust> we need reviews ...!!!
18:41:19 <denis_makogon> SnowDust, me
18:41:21 <amrith> If you are going to attend, please register at
18:41:22 <amrith> https://trove-midcycle-meetup-2014.eventbrite.com
18:41:27 <amrith> There are three questions you have to answer (in addition to basic information such as name, email, and telephone number).
18:41:28 <amrith> We're working on a location and once we have a better idea on the number of registrations, I will have details like hotels and if required a block reservation.
18:41:28 <amrith> Finally, if you are arriving on the 19th, please consider coming in a bit early. We're trying to arrange an evening openstack event with the local openstack group. Details to follow.
18:41:30 <SnowDust> denis_makogon : thanks ..
18:41:42 <vipul> SnowDust: i'll look later today
18:41:51 <kevinconway> amrith: are you organizing a key-signing party?
18:41:52 <SnowDust> vipul : thx !
18:41:56 <kevinconway> i hear those go really well
18:41:57 <iccha1> thanks for setting it up amrith
18:42:03 <amcrn> kevinconway: lol
18:42:09 <denis_makogon> amrith, cool, Cambridge =)
18:42:10 <yogeshmehra> SlickNik: If you could also give the review comments...You had few in mind, right?
18:42:21 <SnowDust> amrith: not interested ? :)
18:42:22 <yogeshmehra> will help us move faster
18:42:23 <amrith> kevinconway, I will think about it (very hard)
18:42:31 <amrith> iccha1, thanks.
18:42:33 <cp16net> lol
18:42:36 <SlickNik> yogeshmehra / SnowDust: Yes, will do it today.
18:42:41 <SnowDust> cp16net : not interested ?
18:42:51 <amrith> SnowDust, not interested in what?
18:42:54 <yogeshmehra> awesome....thanks much
18:43:01 * cp16net confused
18:43:05 <SnowDust> reviews .. on "vertica datastore" patch
18:43:10 <amrith> key signing party? no, very interested. I hear that kevinconway is organizing one.
18:43:14 <amrith> oh, vertica review.
18:43:14 <denis_makogon> cp16net,  amrith, i guess in reviewing vertica patch
18:43:17 <cp16net> thats fine its on the list
18:43:24 <amrith> will do that later today
18:43:37 <cp16net> my comment was not to you
18:43:40 <amrith> have been stuck with a bunch of "stuff" after being on the road for two weeks
18:43:56 <amrith> SlickNik, I'm done.
18:44:03 <SlickNik> amrith thanks!
18:44:04 <denis_makogon> i've got one question
18:44:14 <denis_makogon> can i ask for it ?
18:44:14 <SlickNik> denis_makogon: sure
18:44:24 <SlickNik> go for it.
18:44:37 <denis_makogon> What about troveclient CLI style ?
18:44:48 <denis_makogon> since we plan to have cluster-create
18:44:53 <cp16net> plz elaborate
18:45:09 <denis_makogon> cp16net, we have now "trove create" call for instances
18:45:18 <mattgriffin> amrith, details will be added to https://wiki.openstack.org/wiki/Trove/JunoCycleMeetup ?
18:45:22 <denis_makogon> cp16net, i guest we should move to "trove instance-create"
18:45:34 <denis_makogon> cp16net, heat as the example
18:45:56 <vipul> denis_makogon: +1
18:46:01 <denis_makogon> they have "heat list" which is going to be deprecated and they have "heat stack-list"
18:46:18 <vipul> we might have to support both for a while.. but at least we should introduce instance-create
18:46:39 <dougshelley66> wasn't there some discussion about trying to move away from the term "instance"? or has that ship sailed?
18:46:43 <grapex> vipul: Then we can change it to "instance create"
18:46:43 <denis_makogon> vipul, yes, they will point out to same API call, but will have different signature for awhile
18:46:53 <cp16net> we need to be mindful of when we can depricate such a thing...
18:46:55 <grapex> and then after that, back to just "create"... and the cycle will be complete. :)
18:47:01 * cp16net doesnt know the answer to that
18:47:21 <cp16net> grapex: lolz back to the beginning?
18:47:24 <denis_makogon> grapex, we can't use "instance create", it should contain dash
18:47:28 <vipul> it's a cli.. not an API.. not sure what the 'rules' are
18:47:36 <denis_makogon> i meant "-"
18:47:37 <cp16net> vipul: yea
18:47:40 <kevinconway> we need to make sure we don't break the client too
18:47:46 <grapex> vipul: I thought the rules were "do whatever Nova did"
18:47:47 <amcrn> as long as the client is versioned, which is fairly trivial, we should be able to do what we want
18:47:49 <denis_makogon> kevinconway, we wouldn't
18:47:52 <kevinconway> so if you mean add an instance-create that mirrors trove create then sure
18:48:13 <denis_makogon> kevinconway, yes, that's what i was asking for
18:48:18 <vipul> grapex: isn't that what we do anyway
18:48:19 <SlickNik> btw, the clis are on a continuous release cycle and don't follow OS milestones.
18:48:30 <iccha1> therehttps://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis
18:48:34 <SlickNik> So we have some more leeway with changing them as we see fit.
18:48:41 <iccha1> i mean https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis is a good etherpad from the summit
18:48:47 <iccha1> on cross api consistency
18:48:56 <cp16net> what benifit do we really get from changing the cli
18:48:57 <vipul> that's a long etherpad
18:49:01 <grapex> cp16net: +1
18:49:05 <denis_makogon> cp16net, generic format
18:49:20 <cp16net> its not generic enough?
18:49:26 <cp16net> it does what it has to do
18:49:36 <denis_makogon> cp16net, this questions are came from python-openstackclient and python-openstacksdk
18:49:40 <cp16net> its no the client binding you are talking about
18:49:42 <grapex> I would rather we have it as it once was than the way we have it now, but I don't really care. I can't imagine anyone who uses it does either beyond some fleeting sense of annoyance it doesn't use their personally preferred convention
18:49:57 <cp16net> its just the shell cmds which work and i dont really see a reason to change them again
18:50:08 <SlickNik> afaik, the API is the word set in stone. We have freedom to change the clis as we see fit.
18:50:52 <denis_makogon> i'm not saying that we should do that, i just wondering what cores are other contributors feeling about that ?
18:51:18 <SlickNik> But yes, we probably should look at moving  "trove create" to "trove instance-create" once we have clustering.
18:51:23 <vipul> the shell commands are important though.. since 'trove create' seems like the first step thing to do, you're misleading the user into creating a single instance
18:52:01 <SlickNik> vipul: agreed.
18:52:08 <denis_makogon> sounds good
18:52:20 <amcrn> so as a part of the python-troveclient drop, "create" should be moved to "instance-create" ?
18:52:32 <denis_makogon> i guess this change should land right after/before clustering
18:52:44 <denis_makogon> amcrn, yes
18:52:44 <vipul> or at least add 'instance-create' if we want to support both for a while amcrn
18:52:44 <amcrn> i'd say right after, that way clustering can land without impacting existing usecases
18:52:47 <kevinconway> i think we have to keep "create" or we version the client
18:52:51 <SlickNik> amcrn: can we make it a different dependent patchset?
18:52:52 <denis_makogon> vipul, ++
18:53:25 <amcrn> SlickNik: sure.
18:53:26 <denis_makogon> SlickNik, seems like yes
18:53:33 <hub_cap> why not leave create = instance-create and add a cluster-create
18:53:41 <hub_cap> since in the beginning instance was kinda our "primary" resource
18:53:47 <grapex> hub_cap: +1
18:53:48 <hub_cap> and we can fix it in a v2
18:53:49 <cp16net> i'm personally not in favor of changing the cli to object-create
18:54:10 <vipul> hub_cap: because we have two top level things..
18:54:19 <hub_cap> but it gives us a way to not muck up the expected behaviro in a _already in trusty tahr system_
18:54:25 <denis_makogon> hub_cap,  /instance      /clusters
18:54:26 * hub_cap 's parrot squaks
18:54:30 <hub_cap> i get that guys
18:54:34 <grapex> I mean I think if we wanted to have "blah-create" we should have kept it as "instance create", where we got CLI and suggestions when we tried "instance" without create. It seemed so much easier to reason about back then.
18:54:39 <hub_cap> but we also have an _expected behavior_
18:54:45 <hub_cap> so we rev the client before we rev the api (odd)
18:54:50 <hub_cap> or ew add cluster-create
18:54:58 <grapex> I thought one big reason was so we could have a plain "create" echoing the Nova CLI's "boot" command
18:55:01 * hub_cap votes on the easier and more expected one
18:55:23 <vipul> grapex: but nova's boot command is all there is .. there is no other type of server you would boot
18:55:38 <cp16net> i'd be ok adding cluster-create to work differently
18:55:38 <vipul> we have two types of 'instances' you can 'boot'
18:55:41 <cp16net> that makes sense
18:55:55 <kevinconway> vipul: marshmallows
18:55:59 <denis_makogon> hub_cap, let me ask nova cores and cinder core what they think about their CLI style
18:56:00 <hub_cap> but we have an expected behavior too vipul
18:56:11 <peterstac> vipul: +1 and potentially more down the road
18:56:13 <vipul> sure, which is why i'm saying support both.. add a deprecated warming
18:56:17 <hub_cap> denis_makogon: what would that accoomplish? im not sure what u mean by that
18:56:32 <SlickNik> I'm good with supporting both and adding a deprecation warning.
18:56:34 <hub_cap> so yer saying just symlink instance-create to create?
18:56:38 <vipul> yes
18:56:41 <denis_makogon> hub_cap, common CLI style across all projects
18:56:43 * hub_cap shrugs why not
18:56:44 <amcrn> i'm ok with that
18:56:54 <hub_cap> denis_makogon: im not sure its needed, looks like we have consensus
18:57:01 <denis_makogon> ok
18:57:18 <SlickNik> Okay, anything else?
18:57:19 <denis_makogon> if it'll work for all of us then i'm fine with that
18:57:21 * cp16net looks at the otherside of the room
18:57:34 <robertmyers> #vote no client
18:57:39 <grapex> robertmyers: +1
18:57:42 <robertmyers> curl for all
18:57:47 <grapex> Let's just wait for the OpenStack SDK
18:57:48 <SlickNik> lol @ robertmyers
18:57:50 <amcrn> +1
18:57:53 <amcrn> lol
18:57:53 <SlickNik> #endmeeting