18:00:27 <hub_cap> #startmeeting trove
18:00:27 <openstack> Meeting started Wed Dec 11 18:00:27 2013 UTC and is due to finish in 60 minutes.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:31 <openstack> The meeting name has been set to 'trove'
18:00:33 <SlickNik> here
18:00:39 <pdmars> present
18:00:48 <datsun180b> hello
18:00:51 <hub_cap> hello all
18:01:00 <robertmyers> o/
18:01:04 <grapex> o/
18:01:08 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:01:10 <cp16net> o//
18:01:12 <kevinconway> 7o7
18:01:23 <juice> o/
18:01:43 <hub_cap> so lets start w/ the fun one
18:01:55 <juice> \o\ <ho>
18:02:03 <esmute> o/
18:02:08 <hub_cap> #topic datastore_types before tempest
18:02:12 <cp16net> <hey> ?
18:02:16 <esmute> juice: Doing aerobics?
18:02:20 <hub_cap> julim: hip hop horray?
18:02:27 <hub_cap> juice: ^ ^
18:02:29 <juice> yup
18:02:32 <juice> hub_cap wins
18:02:39 <vipul> o/
18:02:49 <hub_cap> juice: do i win cuz i said it to someone random instead of u?
18:02:50 <annashen> o/
18:03:12 <hub_cap> ok so back to the topic at hand
18:03:27 <hub_cap> i think that we should allow the existing 3 in before we get around to tempest testing
18:03:35 <hub_cap> cassandra, mongo, and redis
18:03:49 <cp16net> +1
18:03:53 <hub_cap> ill be running them today and taking a look at all 3 of them to make sure they are quite similar
18:03:54 <demorris> +1
18:03:56 <kevinconway> hub_cap: do we just not gate on them?
18:03:59 <hub_cap> id like others to do that as well
18:04:05 <SlickNik> So what about tests for them?
18:04:28 <SlickNik> Do we gate on them to make sure they're not broken?
18:04:43 <hub_cap> kevinconway: we will once we get tempest tests a-goin
18:05:20 <vipul> We do have datastore_types support now, so we could potentially add to our existing gate and spin up the differnt types
18:05:35 <vipul> it would add time to our builds..
18:05:36 <denis_makogon> o/
18:05:41 <hub_cap> the risk we run is that something changes that doesnt properly get tested on all our impls
18:05:45 <cweid> o/
18:06:11 <hub_cap> vipul: we can parallelise it w/ tempest (honestly we probably could w/ the present stuff too i just not sure we should spend too much time on it now)
18:06:19 <kevinconway> wouldn't the new data stores fail the current integration tests though?
18:06:31 <kevinconway> will there be a way to choose tests based on datastore?
18:06:32 <datsun180b> i don't think the extra test time should be considered as a deal-breaker
18:06:41 <denis_makogon> we need image elements asap !
18:07:01 <cp16net> kevinconway: if you ran *all* tests i'm sure they would because some tests do not apply to all datastores
18:07:13 <hub_cap> kevinconway: w/ the tempest tests we will make sure teh different datatypes dont run all the same tests
18:07:23 <denis_makogon> cp16net, kevinconway that why we have test groups
18:07:27 <esmute> if resource/time is a factor, we can just gate on one datastore type... maybe one for sql and one for no-sql
18:07:27 <hub_cap> denis_makogon: SlickNik is working on that
18:07:31 <cp16net> denis_makogon: yup
18:07:43 <denis_makogon> SlickNik, any statuses on that ?
18:08:02 <hub_cap> denis_makogon: thats not what we are talking about right now :)
18:08:08 <hub_cap> there is a topic for that later in the meeting
18:08:11 <denis_makogon> sorry
18:08:12 <kevinconway> so if we merge the new types would we release them before the tempests tests are going?
18:08:14 <hub_cap> np
18:08:19 <SlickNik> denis_makogon: still working on cleaning up the elements before moving to tripleo
18:08:43 <SlickNik> denis_makogon: you can get started writing the tempest tests, though.
18:08:52 <hub_cap> ok so, anyone opposed to merging in these impls?
18:08:59 <SlickNik> denis_makogon: Shouldn't be a blocker until the final integration point.
18:09:00 <kevinconway> hub_cap: ^^ question
18:09:06 <denis_makogon> SlickNik, Dmitriy Iakunchikov already doing that
18:09:06 <hub_cap> kevinconway: go head
18:09:14 <kevinconway> kevinconway: so if we merge the new types would we release them before the tempests tests are going?
18:09:18 <SlickNik> denis_makogon: any update on that?
18:09:35 <denis_makogon> SlickNik, lets talk after meeting, ok ?
18:09:36 <grapex> kevinconway: What do you mean by release?
18:09:44 <SlickNik> What's his IRC handle? I can ask him too.
18:09:51 <grapex> I think having them in as not 100% supported features is ok
18:09:53 <SlickNik> sure.
18:09:53 <denis_makogon> SlickNik, he's out
18:10:00 <grapex> the alternative is to have them decaying in reviews forever
18:10:07 <kevinconway> grapex: as in would they go out in an icehouse release before we tested them
18:10:16 <hub_cap> kevinconway: define release them
18:10:27 <grapex> kevinconway: Yes, I think we should- just tell people not to use them
18:10:32 <vipul> they are released when they land basically
18:10:50 <vipul> use at your own risk
18:10:51 <datsun180b> "We stand behind the completeness and correctness of this feature--just don't use it!" what?
18:10:52 <hub_cap> merged code != fully baked, supported code i think
18:10:58 <denis_makogon> could we add reddwarf job into trove ?
18:11:16 <hub_cap> i dont think its necessary sicne its just a subset of the functionality denis_makogon
18:11:21 <grapex> datsun180b: Well, part of this is happening because we do have tests, but we don't want to add to them for these features since we're trying to get Tempest up and running first.
18:11:27 <hub_cap> we should push forward on tempest and the tasks it takes to get it running
18:11:35 <denis_makogon> hub_cap, but we'll be able to modify it
18:11:39 <datsun180b> gotcha, i'm on the right page now
18:11:47 <vipul> so as part of each Datastore review, we should be requiring that the README be updated
18:12:01 <vipul> i don't know where else we document this sort of stuff
18:12:13 <denis_makogon> vipul, Wiki ?
18:12:29 <SlickNik> Also, we need to make sure that they _work_ at the very least.
18:12:43 <denis_makogon> SlickNik, hup_cap testing them
18:12:55 <hub_cap> maybe we need a functionality matrix
18:12:58 <hub_cap> on the wiki somewhere
18:13:07 <cp16net> thats a good idea
18:13:08 <denis_makogon> hub_cap, elaborate
18:13:34 <cp16net> showing what is supported for each datastore
18:13:40 <demorris> hub_cap: +1 to functionaility matrix
18:13:44 <denis_makogon> cp16net, oh, yes, agreed +100500
18:13:48 <demorris> as well as well defined API docs that detail it
18:13:54 <demorris> :)
18:13:58 <cp16net> and showing what is not fully supported yet
18:14:12 <demorris> anne gentle and mike a. are ready to help there as soon as you are
18:14:15 <denis_makogon> demorris, also how to manage trove to run it
18:14:27 <vipul> kinda like https://wiki.openstack.org/wiki/HypervisorSupportMatrix
18:14:32 <denis_makogon> vipul, +1
18:14:33 <demorris> correct, and operators guide would be good
18:14:51 <SlickNik> vipul: agreed.
18:14:54 <cp16net> yup
18:15:22 <denis_makogon> #action Functional Matrix for Datastores
18:15:47 <grapex> Oh man... updating a matrix like that seems pretty gross.
18:15:47 <grapex> Why not just say "as of Icehouse, no assurances are given for the non-MySQL datastore types"
18:15:53 <grapex> then make sure we have tests for all the datastore types after that
18:16:16 <vipul> even then some things wont' be supported long term right
18:16:19 <grapex> written in Tempest or whatever
18:16:22 <vipul> users? backups?
18:16:35 <denis_makogon> grapex, sound like they are not working, but we let it land to codebase
18:16:48 <grapex> vipul: Could you go into some more detail on that?
18:17:07 <vipul> grapex: the User API for redis will never work
18:17:10 <datsun180b> like hub_cap said before, merged code isn't necessarily a release in itself
18:17:16 <vipul> grapex: some nosql thing may never support taking backups
18:17:24 <datsun180b> not even a nightly or something like that
18:17:31 <SlickNik> So, let me ask you a question. Are there certain sub-teams specifically working on certain implementations? The reason I ask is because, if we're allowing these implementations without tests (or docs), I want to have at least someone responsible for following through on writing these.
18:17:45 <denis_makogon> vipul, same with users in Cassandra
18:17:51 <grapex> vipul: I see what you mean
18:18:18 <datsun180b> well that's an extension anyway
18:18:21 <SlickNik> I'd hate to have code/doc in trove for an impl that's half baked and not fully tested long-tern.
18:18:25 <denis_makogon> SlickNik, submitter is a guy who response for docs
18:18:29 <grapex> vipul: Then I think for the different types, it makes sense to say something will never be supported.
18:18:39 <hub_cap> SlickNik: if the code is not maintained, its removed
18:18:45 <hub_cap> thats always been my stance
18:18:53 <grapex> Ok... n/m. I agree with you on that vipul.
18:19:02 <grapex> I thought we were concocting a matrix to list test IOUs.
18:19:02 <hub_cap> n+1, if no one ponies up to "fix"  issues, then it doesnt need to stay in the code
18:19:08 <vipul> grapex: sure, i just think the support matrix woudl be good for that
18:19:20 <denis_makogon> hub_cap, vipul +1
18:19:28 <hub_cap> ok so, this i taking a while
18:19:29 <hub_cap> *is
18:19:44 <hub_cap> do we feel like we can move on now? is there more to this besides, yes, lets do this
18:19:48 <hub_cap> and some docs
18:19:48 <vipul> ok who's doing the matrix
18:19:55 <SlickNik> hub_cap: okay, if that's the stance, I'm okay with it.
18:20:05 <hub_cap> ill start the matrix today vipul w/ just mysql
18:20:11 <denis_makogon> hub_cap, nice =)
18:20:17 <denis_makogon> hub_cap, <3
18:20:20 <hub_cap> and the maintainers of the code for each service can add what they have
18:20:27 <vipul> sounds good
18:20:37 <denis_makogon> sound like perfect plan
18:20:48 <hub_cap> we will have to make sure thats updated each time things are added to the code
18:20:53 <hub_cap> ok moving on
18:20:56 <grapex> hub_cap: I wonder if we can generate the matrix from the code somehow.
18:21:19 <denis_makogon> grapex, that would be not easy ...
18:21:21 <hub_cap> #topic mount_point and storage directory dependency
18:21:24 <datsun180b> until then the wiki better state that no one can be told what the matrix is
18:21:30 <hub_cap> grapex: im not that worried about it  :)
18:21:30 <denis_makogon> SlickNik, it's our turn
18:21:35 <hub_cap> go go go guys
18:21:41 <hub_cap> put up your #links too :)
18:21:51 <grapex> datsun180b: No one can be told what the working feature matrix is... they have to run the code for themselves.
18:21:52 <SlickNik> Okay, so this one is based on a discussion I was having with denis_makogon
18:22:02 <denis_makogon> #link https://review.openstack.org/#/c/57189/
18:22:03 <SlickNik> #link https://review.openstack.org/#/c/57189
18:22:08 <SlickNik> for context.
18:22:26 <denis_makogon> we need to brink dependency between mount_point and datastore
18:22:36 <denis_makogon> i mean database data_dir
18:22:55 <SlickNik> I'm not sure I like forcing the mount_point and the data_dir to be the same, and this might limit some configurations (where data_dir is not the mount point, but a directory contained within it for example).
18:22:56 <denis_makogon> for now trove allows to make next misconfiguration
18:23:12 <vipul> when do we start taking a stance on backwards-incompatible changes to the RPC api
18:23:13 <denis_makogon> mount_point = /mnt/ , data_dir = /var/lib/mysql
18:23:38 <SlickNik> vipul: That's another reason I don't like this change.
18:24:00 <SlickNik> you might want to store both the database, and the binlogs on the volume for instance.
18:24:08 <grapex> vipul SlickNik: Are you referring to the RPC API or the trove/guestagent/api methods?
18:24:13 <denis_makogon> that is why i suggested ikhudoshyn to make such patch
18:24:35 <vipul> grapex: trove/guestagent/aip
18:24:37 <denis_makogon> which retrieves data_dir from my.cnf and mounts volume into it
18:24:51 <vipul> maybe we can wait for that conversation grapex
18:25:02 <vipul> let denis_makogon and SlickNik do their thing
18:25:22 <grapex> vipul SlickNik: I say we keep allowing it to change wily-nilly until the reference guest moves to its own repo.
18:25:26 * grapex evil laugh
18:25:36 <denis_makogon> i suggest to make strict dependency between mount point and database data directory
18:25:46 <SlickNik> Another reason I don't like this change is because it would mean that the guestagent now has to understand how to parse every datastore config file, and know what value corresponds to the equivalent of a mount_point.
18:26:02 <denis_makogon> SlickNik, it's already knows how to do that
18:26:14 <denis_makogon> example: admin password
18:26:20 <grapex> vipul SlickNik: No, I guess it could cause some pain. We should probably discuss this soon- what I'd like to see is for guestagent/api.py to support calling older versions of the agent within reason. There should be an expectation that the agents can eventually update themselves though, so for instance they'd never be more than a week or so out of date.
18:26:30 <SlickNik> for mysql it does. What's the corresponding data_dir value for redis/cassandra?
18:26:59 <grapex> SlickNik: In theory, the data_dir for redis and caddandra could come from config values.
18:27:01 <denis_makogon> SlickNik, it's very easy
18:27:02 <cweid> data_dir in redis is currently hard coded to /var/lib/redis
18:27:11 <grapex> SlickNik: Though I agree the data dir and mount directory should not have to be the same.
18:27:12 <cp16net> it doesnt parse the config file it just appends
18:27:15 <cp16net> theres a differnce
18:27:17 <denis_makogon> for cassandra /var/lib/cassandra/data
18:27:27 <vipul> does every datastore have a data_dir setting?
18:27:32 <denis_makogon> vipul, yes
18:27:39 <denis_makogon> vipul, everyone has
18:27:42 <grapex> My point though is that the app, which has the get_data_dir() method, could have subclasses for different datastore types.
18:27:47 <denis_makogon> cp16net, not only appends
18:28:04 <denis_makogon> cp16net, somewhere in code it reads admin pass from my.cnf
18:28:10 <vipul> yea i don't think you should limit what you mount to
18:28:30 <vipul> you may have >1 things you want to mount in the future as well
18:28:38 <denis_makogon> vipul, but it need to be chained
18:28:38 <grapex> Sounds like everyone agrees that mount_point doesn't necessarily have to be the same as the data dir, right?
18:28:44 <vipul> grapex: +1
18:28:53 <hub_cap> lol in redi sits just called "dir"
18:28:54 <SlickNik> grapex: yes, I think  so.
18:29:02 <hub_cap> dir /var/lib/redis
18:29:05 <grapex> Let's just make a it a config value. Would there be some case where that wouldn't work?
18:29:10 <denis_makogon> vipul, how to be if mount_point is /dev/null and data_dir = /var/lib/mysql
18:29:16 <denis_makogon> vipul, try to backup it
18:29:27 <vipul> denis_makogon: that's a bad configuration then
18:29:37 <denis_makogon> vipul, because of bad design
18:29:39 <datsun180b> i think if you've got enough bullets and point the gun earthward, shooting yourself in the foot is your fault
18:29:41 <SlickNik> denis_makogon: That's bad configuration
18:29:46 <hub_cap> SlickNik: vipul do you have a specific reason to have data_dir != mount point?
18:29:48 <vipul> tha'ts /dev/null as a service
18:29:54 <vipul> another datastore we will supoprt
18:30:03 <datsun180b> vipul: write-only memory. there's an ancient joke RFC for it
18:30:05 <cp16net> thats the fastest
18:30:25 <cp16net> and sharded
18:30:36 <denis_makogon> i dont like whole idea of keeping 2 values for writing data
18:30:56 <hub_cap> if there is no good reason to have a different directory right now then im not sure why we'd keep 2 values
18:31:08 <denis_makogon> i see a wayout - mysql/config.template : {{mount_point}}/data_dir
18:31:11 <SlickNik> hub_cap: 1. you lose the flexibility of possibly storing > 1 type of object on your volume.
18:31:42 <denis_makogon> another: reading from conf file
18:31:46 <SlickNik> (for example if you want your volume to store databases as well as something like binlogs, for example)
18:31:50 <hub_cap> but do we ever watn to do that SlickNik ?
18:31:59 <denis_makogon> SlickNik, {{mount_point}}/data_dir
18:32:08 <denis_makogon> root directory
18:32:21 <vipul> hub_cap: I could see potntially trove having a secondary volume for some things that are not data
18:32:29 <grapex> Real quick question for vipul / SlickNik: When we're talking about "mount_point", are you guys mixing that up with the "data_dir" variable used throughout the backup code too?
18:32:36 <SlickNik> Yes, you probably don't want to store it on the root partition, because it will grow (you might need them for incremental backups say).
18:32:36 <denis_makogon> data_dir and mount_point __should__ be dependent
18:32:55 <grapex> Because previously that "data_dir" var was named "mount_point"
18:32:58 <denis_makogon> vipul, why do we need more then one volume ??
18:32:59 <SlickNik> denis_makogon: They are _dependent_. They are just not the same value.
18:33:00 <hub_cap> ya i think thats a fair point SlickNik
18:33:20 <denis_makogon> SlickNik, now they are not dependent
18:33:31 <vipul> grapex: No, i think currently we're consistent that mount piont = data_dir for the most part
18:33:39 <vipul> i just don't think it's a good limitation to impose
18:34:05 <imsplitbit> o/
18:34:17 <cp16net> welcome imsplitbit
18:34:21 <imsplitbit> sorry I'm late
18:34:24 <denis_makogon> try to run trove with mount_point /var/lib
18:35:12 <denis_makogon> or another way - we need N sections in trove-taskmanager.conf where different datastore will have it's own mount_point
18:35:16 <hub_cap> so i think we can make it optional, to send the value in a conf if it exists
18:35:22 <grapex> Ok- so I'm game to just change line 97 of this review to say "mount_point = some config value" and then replace the proceeding instances of "data_dir" in the prepare function to "mount_point": https://review.openstack.org/#/c/57189/16/trove/guestagent/datastore/mysql/manager.py
18:35:44 <grapex> With the exception that before doing a restore
18:36:05 <grapex> On line 112, we need to actually pass the _perform_restore function the data_dir, and not the mount_point
18:36:06 <hub_cap> so lets do this, make it optional denis_makogon, if they want to declare a mount_point they can
18:36:37 <hub_cap> and maybe its time we start thinking about putting these things into [cassandra][mysql] sections
18:36:41 <denis_makogon> hub_cap, so then we need N oslo parameters groups
18:37:05 <vipul> the second issue with this patch.. why change the signature of the prepare() API
18:37:21 <hub_cap> vipul: if somethign is not being used...
18:37:31 <denis_makogon> hub_cap, +1
18:37:33 <vipul> we need ot have a deprecation strategy or some way to version
18:37:34 <SlickNik> hub_cap / grapex: I'd be okay with either of your suggestions.
18:37:39 <hub_cap> i know it is sucky for deployment, so i suggest we fix versioned messages
18:37:44 <vipul> this doesn't work when you have and old version
18:37:55 <denis_makogon> #action Start delivering more oslo.config parameters groups
18:38:12 <hub_cap> vipul: yup, and i think we need to fix it in production.. iirc rax deals w/ this every deploy too :)
18:38:28 <SlickNik> denis_makogon: we're still talking about the guest API change, hold your horses.
18:38:39 <vipul> hub_cap: trove should deal with this.. like every other openstack project is trying to do
18:38:48 <vipul> don't just break compatibility
18:38:51 <denis_makogon> SlickNik, API would be never changed in this case
18:38:58 <hub_cap> vipul: i agree trove should handle it :)
18:39:07 <SlickNik> denis_makogon: That patch out there changes the API
18:39:27 <denis_makogon> SlickNik, i'm talking about multiple oslo groups
18:39:33 <hub_cap> we cant say "no one can make the code better until we deal w/ versioned messages" and then no one deal w/ versioned messages
18:39:50 <denis_makogon> hub_cap, agreed
18:40:08 <denis_makogon> lets do not touch API
18:40:16 <denis_makogon> lets make inner code better
18:40:27 <vipul> sure i get that.. but there are ways of doing this w/o breaking compat.. allow the param to be passed in and overridden by guest.conf
18:40:33 <SlickNik> hub_cap: the question is - do we take breaking changes to the API before we have a method to deal with versioned messages?
18:40:36 <hub_cap> denis_makogon: the guest api _is_ an api though
18:40:59 <hub_cap> SlickNik: weve done it many times before :)
18:41:10 <grapex> So I want to point out we've had to deal with breaking changes in the RPC calls for a long time now.
18:41:12 <hub_cap> but we are really bogged down w/ this
18:41:18 <grapex> I think we should fix it, but this problem is hardly new.
18:41:21 <SlickNik> And felt the pain many times before too. :)
18:41:24 <hub_cap> yes rax deals w/ it every release hahah
18:41:33 <datsun180b> gosh, when's the last time i broke some rpc calls everywhere, when was it...
18:41:35 <vipul> grapex: not saying it's new.. jsut something we need to start getting better at gating on
18:41:46 <imsplitbit> +1
18:41:49 <datsun180b> something about backing... maybe hiccups? can't recall
18:41:53 <hub_cap> yes but we need someoene to pony up and do the work too
18:42:06 <hub_cap> that'd be like us not allowing cassandra until tempest hehe
18:42:07 * imsplitbit points at hub_cap
18:42:08 <grapex> vipul: Agreed- I just wonder if its a good reason to hold up this particular pull request.
18:42:19 <hub_cap> but srsly we need to mvoe on
18:42:27 <denis_makogon> moving on
18:42:30 <hub_cap> we will not get thru this meeting hehe
18:42:40 <denis_makogon> hub_cap, not even once
18:42:47 <vipul> grapex: based on what we talke about .. we could probably not break api and get this in with a little rewuire
18:42:49 <vipul> rewrite
18:42:54 <hub_cap> lets table this until after the meeting is over though vipul grapex SlickNik denis_makogon
18:43:02 <vipul> ok move on
18:43:07 <hub_cap> vipul: in golang?
18:43:10 <hub_cap> rewrite?
18:43:12 <hub_cap> :)
18:43:17 <hub_cap> #topic guidestyle
18:43:19 <hub_cap> go denis_makogon
18:43:32 <SlickNik> sounds good. Let's come back to this later.
18:43:33 <denis_makogon> #link https://review.openstack.org/#/c/60277/
18:43:43 <denis_makogon> #link https://review.openstack.org/#/c/60276/
18:43:51 <denis_makogon> we need to deal with this, both
18:44:05 <grapex> I'm cool with it
18:44:13 <denis_makogon> __init__.py - hacking already had rules for that
18:44:29 <vipul> the vim guys might freak
18:44:31 <hub_cap> denis_makogon: im ok w this too, the openstack mailing list has talked about this too
18:44:32 <kevinconway> i vote we add jslint validation to our code
18:44:38 <denis_makogon> #vim - reason, i can edit code without vim, why do i need #vim lines in code
18:44:39 <datsun180b> vipul: i'm a vim guy, idgaf
18:44:45 <hub_cap> vipul: only if they code in goofy vim spacing
18:44:46 <vipul> ok then!
18:44:47 <datsun180b> i have my own settings
18:44:49 <denis_makogon> #link http://openstack-dev.markmail.org/search/?q=modeline#query:modeline+page:1+mid:2a55it3usuqsfsif+state:results
18:45:01 <imsplitbit> datsun180b: you're doing it wrong
18:45:03 <hub_cap> ok good moving on then!
18:45:10 <imsplitbit> go go go
18:45:10 <hub_cap> no emacs vs vim imsplitbit
18:45:12 <kevinconway> jslint will hurt your feelings
18:45:13 <SlickNik> I'm good
18:45:16 <imsplitbit> :)
18:45:20 <imsplitbit> I wasn't gonna start
18:45:24 <hub_cap> #topic updating requirements
18:45:26 <hub_cap> imsplitbit: ;)
18:45:26 <datsun180b> imsplitbit: i don't judge. i leave that for vengeful Bram Moolenaar
18:45:27 <imsplitbit> just a friendly jab
18:45:28 <denis_makogon> moving one
18:45:29 <hub_cap> denis_makogon: gogogogo
18:45:34 <denis_makogon> #link https://bugs.launchpad.net/trove/+bug/1259938
18:45:53 <grapex> I feel like this bug is too general
18:45:57 <denis_makogon> what are you think about dropping mockito out ?
18:46:06 <imsplitbit> +100000000000
18:46:07 <amcrn> +1 w/ grapex
18:46:07 <grapex> I don't know if something like this should be a bug.
18:46:15 <hub_cap> so lets first talk about dropping mockito
18:46:17 <grapex> I marked it as incomplete
18:46:19 <hub_cap> thats a simple one, lets drop it
18:46:19 <grapex> hub_cap: Ok
18:46:20 <datsun180b> +four
18:46:26 <robertmyers> +1
18:46:28 <cweid> +5000
18:46:29 <cp16net> +1
18:46:29 <denis_makogon> grapex, trove unit tests have more than 1000 incorrect assertions
18:46:30 <hub_cap> +infinity
18:46:32 <cp16net> +
18:46:38 <datsun180b> 'incorrect'
18:46:39 <SlickNik> lol
18:46:43 <hub_cap> denis_makogon: ?
18:46:43 <imsplitbit> do we have an official replacement?
18:46:46 <robertmyers> denis_makogon: How so?
18:46:51 <cweid> imsplitbit: Mock?
18:46:53 <grapex> denis_makogon: Can you give some examples?
18:46:54 <imsplitbit> mox?
18:46:59 <denis_makogon> mox, mock
18:47:13 <robertmyers> no mox
18:47:15 <SlickNik> denis_makogon: no moc
18:47:16 <esmute> lol that was fast
18:47:17 <robertmyers> yes mock
18:47:18 <SlickNik> mox*
18:47:18 <juice> please let me take this up with lifeless and openstack
18:47:20 <grapex> I propose we write a Trove specific mock framework and call it Taquito.
18:47:37 <imsplitbit> ba dum dum
18:47:39 <kevinconway> grapex: i'll start on the bash code
18:47:39 <vipul> juice: do it!
18:47:41 <juice> yum
18:47:57 <denis_makogon> #link https://github.com/openstack/trove/search?q=assertEqual&ref=cmdform - huge part of all assertions are wrong
18:48:06 <esmute> juice: Our mockito evangelist
18:48:11 <juice> indeed
18:48:18 <SlickNik> I say we table the mocking framework discussion until juice has a conversation with lifeless / ML
18:48:28 <imsplitbit> why?
18:48:28 <denis_makogon> SlickNik, agreed
18:48:31 <grapex> SlickNik: Sure, agreed.
18:48:39 <denis_makogon> that is why i putted it into agenda
18:48:42 * imsplitbit is curious
18:48:44 <datsun180b> what's wrong with testcase.assertEqual?
18:48:47 <grapex> I don't get why it matters- how much pain is there really to adding it.
18:48:58 <vipul> yea i'm confused why these are 'wrong'
18:49:05 <denis_makogon> datsun180b, incorrect parameters order
18:49:31 <juice> i personally like the assertThat matchers but I wouldn't go back and change anything
18:49:32 <denis_makogon> we should not use Is, KeysEqual, Not etc
18:49:45 <datsun180b> what's the correct form then?
18:49:45 <grapex> denis_makogon: I feel like in JUnit the order being wrong could really screw up the error messages
18:49:59 <robertmyers> denis_makogon: http://docs.python.org/2/library/unittest.html#unittest.TestCase.assertEqual
18:50:01 <grapex> but in Python I feel like if if you mismatch "expected" and "actual" it doesn't affect anything
18:50:18 <datsun180b> ohh it's just expected/actual
18:50:21 <denis_makogon> grapex, but it's not correct
18:50:24 <robertmyers> there is no expected actual
18:50:26 <juice> just the error message grapex
18:50:31 <grapex> robertmyers: Great find
18:51:05 <kevinconway> how about just use 'assert thing1 == thing2, "ITS NOT THE SAME!!!!"'
18:51:08 <denis_makogon> i'd like to make call _correct_ assertions
18:51:21 <robertmyers> denis_makogon: define correct
18:51:29 <cp16net> that doesnt change anything
18:51:31 <hub_cap> denis_makogon: are you proposing to change assert(a, b) to assert(b, a) ?
18:51:37 <grapex> I don't know if I want to make a big deal out of this
18:51:41 <hub_cap> in 1000 places?
18:51:45 <denis_makogon> testtools allow as to use assertIn, assertIs, assertIsInstance
18:52:01 <lifeless> grapex: in testtools there is actually expected, observed
18:52:14 <SlickNik> grapex: I'm still confused if there's anything to make any sort of deal about.
18:52:15 <denis_makogon> but a lot of tests uses assertEqual(type({}), dict)
18:52:19 <lifeless> grapex: but as you say, it doesn't really matter for any of the simple equality relations
18:52:26 <datsun180b> ^^
18:52:34 <greghill> this seems like a colossal waste of time to argue about
18:52:36 <hub_cap> ok we shoudl move on
18:52:43 <hub_cap> ther is no reason to do that work denis_makogon
18:52:48 <hub_cap> yes to remove mockito
18:52:56 <cp16net> +1
18:52:56 <kevinconway> can we remove all test tools asserts for regular asserts
18:53:00 <datsun180b> but i love having three mocking frameworks to juggle
18:53:01 <robertmyers> hub_cap: +1
18:53:08 <hub_cap> #topic tempest
18:53:12 <grapex> kevinconway: We should just use the python assert keyword everywhere
18:53:15 <denis_makogon> hub_cap, all project fixing incorrect assertions, take a look at heat
18:53:16 <hub_cap> diakunchikov__: its all you!
18:53:18 <grapex> It kind of sucks, but it is more pythnoic
18:53:25 <denis_makogon> hub_cap, Dima is out
18:53:30 <denis_makogon> i'm for him
18:53:39 <hub_cap> denis_makogon: you can sway our opinions if we can see all the other projects doing it
18:53:47 <denis_makogon> SlickNik, describe, please last status fro image elements
18:54:05 * imsplitbit wonders if all the other projects are waiting for all the other projects to do it
18:54:30 <hub_cap> imsplitbit: i dont have a /slap anymore
18:54:40 <imsplitbit> :)
18:54:45 <hub_cap> yes SlickNik lets talk status here
18:54:48 <hub_cap> we have 6 min
18:54:51 <datsun180b> i'll say it, it seems like it's a really convenient way to widen someone's pie slice and it seems like our contribution efforts would serve trove directed elsewhere
18:55:14 <SlickNik> denis_makogon: like I mentioned earlier, I'm still cleaning out some of the elements before I push them up to the tripleo-elements repo.
18:55:26 <SlickNik> I plan to have that patch out by end of this week.
18:55:32 <denis_makogon> nice
18:55:35 <denis_makogon> thanks
18:55:38 <denis_makogon> moving on
18:55:46 <hub_cap> well that was easy!
18:55:54 <SlickNik> But like I mentioned, the tempest tests are independent and you can work on it without that happening.
18:56:11 <SlickNik> So I'm not sure why you keep coming back to ask me about the status of that. :)
18:56:14 <hub_cap> cp16net: do u have time to discuss your stuff or do u want to tal about that in the meeting room after?
18:56:30 <hub_cap> go cp16net go
18:56:32 <cp16net> let do it quick
18:56:33 <hub_cap> #topic configurations
18:56:38 <cp16net> #link trove - https://review.openstack.org/#/c/53168/
18:56:38 <cp16net> #link python-troveclient - https://review.openstack.org/#/c/53169/
18:56:38 <cp16net> #link trove-integration - https://review.openstack.org/#/c/58445/
18:56:44 <hub_cap> BAM
18:56:51 <cp16net> give this a spin and test out configuraitons
18:56:59 <SlickNik> nice cp16net
18:57:09 <SlickNik> Will try it out
18:57:13 <cp16net> sweet
18:57:30 <hub_cap> is that it cp16net ?
18:57:39 <cp16net> so config groups and datastores are associated with datastore versions and not the datastore type
18:57:42 <hub_cap> i was oh so hping demorris was gonna talk
18:57:57 * imsplitbit wasn't
18:58:14 <demorris> alright, so I have a question about this one
18:58:17 <vipul> cp16net: yea why is that?  don't config options generally apply to a datastore type
18:58:19 <hub_cap> imsplitbit: good!
18:58:24 <demorris> Given the nature of how the datastore / types code has been implemented in that it is highly configurable, I believe that we we need to adjust the way in which we are associating configuration groups with datastore types and versions.  The main use case that I am considering here is that as a user of the API, I want to be able to associate configurations with a specific datastore type so that I can easily return a list of the
18:58:25 <demorris> configurations that are valid for that database type (Example: Get me a list of configurations for MySQL 5.6).
18:58:43 <demorris> We know that configurations will vary across types (MySQL vs. Redis) as well as across major versions (MySQL 5.1 vs MySQL 5.6).   Presently, the code only keys off the datastore version, and consequently, if I were to set up my datastore type as MySQL X.X and datastore versions as X.X.X, then you would be potentially associating a configuration with a specific minor version such as MySQL 5.1.63.
18:58:48 <hub_cap> omg
18:58:54 <hub_cap> why dont u send us a link
18:59:00 <cweid> ...
18:59:06 <hub_cap> to that ML entry
18:59:06 <hub_cap> fail
18:59:09 <hub_cap> ;)
18:59:12 <grapex> Everyone you have 60 seconds to say if you agree or not with demorris.
18:59:13 <demorris> Given that, I am thinking that it makes more sense to allow a configuration to be associated with both a datastore type AND and datastore version with precedence given to the datastore type (where both attributes are either optional – or at least one is required).  This would give the most flexibility to associate configurations with either the type, version, or both and would allow it to work across providers given that they are likely
18:59:14 <demorris> to configure types/versions differently.
18:59:18 <hub_cap> omt
18:59:20 <hub_cap> omg
18:59:20 <imsplitbit> hly crap
18:59:21 <cp16net> well instance was associated with an instance so this made it seem good
18:59:21 <hub_cap> :)
18:59:23 <cp16net> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/021945.html
18:59:25 <cp16net> ftw
18:59:27 <demorris> I don't know how to do all the fancy stuff
18:59:28 <hub_cap> cp16net: <3
18:59:28 <greghill> I concur!
18:59:31 <cp16net> :-P
18:59:31 * amcrn throws on the bean boots, there's a flood happening
18:59:39 <demorris> just read it
18:59:41 <cp16net> wow
18:59:49 <hub_cap> amcrn: lollll
18:59:49 <demorris> :)
19:00:03 <cp16net> reply on the ML about this topic :)
19:00:15 <cp16net> we done
19:00:17 <hub_cap> #endmeeting