14:00:04 <dkrol> #startmeeting trove
14:00:05 <openstack> Meeting started Wed Feb 27 14:00:04 2019 UTC and is due to finish in 60 minutes.  The chair is dkrol. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:08 <openstack> The meeting name has been set to 'trove'
14:00:14 <dkrol> Hello
14:00:35 <bzurkowski> Hello
14:00:43 <dkrol> Hello
14:00:57 <bzurkowski> Lets' wait few more minutes
14:01:04 <dkrol> Sure
14:06:28 <bzurkowski> Our new colleague is troubling with connection
14:06:34 <bzurkowski> "Too many user sessions"
14:06:42 <dkrol> :/
14:06:53 <bzurkowski> Let's wait one more minute
14:06:59 <dkrol> Sure
14:08:29 <mpiwowarczy> hi all
14:08:37 <bzurkowski> Hi
14:08:52 <dkrol> Hi
14:11:12 <dkrol> Can we start?
14:11:30 <bzurkowski> Yes
14:11:39 <bzurkowski> He cannot log in
14:11:42 <dkrol> #topic recent changes
14:11:44 <bzurkowski> He will try another time
14:11:50 <dkrol> So what's up?
14:13:39 <bzurkowski> Well
14:14:18 <bzurkowski> The first change from Kasper regarding Redis logs has been already merged
14:14:26 <bzurkowski> I am very glad he joined the project
14:15:12 <dkrol> Yes, it is great
14:15:17 <bzurkowski> Soon he will add more changes
14:16:52 <bzurkowski> There is one thing that I would like to put under discussion
14:17:23 <dkrol> Please
14:17:28 <bzurkowski> We have several changes that introduce guest support for Cassandra 3.x
14:17:42 <bzurkowski> However, current guest implementation supports only 2.x
14:18:01 <bzurkowski> The question is: how do we approach datastore versioning?
14:18:16 <bzurkowski> Should we support multiple versions, in that case 2.x and 3.x
14:18:24 <bzurkowski> Or maybe we should only support the latest one
14:18:25 <bzurkowski> ?
14:18:42 <dkrol> Mmmmm....
14:18:50 <bzurkowski> This is problematic in Trove since there is no defined approach
14:19:25 <dkrol> I believe we should support versioning
14:19:59 <dkrol> Guest agent has info about data stare version
14:20:34 <bzurkowski> Yes
14:20:48 <dkrol> So the problem is in loading correct python module based on the version
14:20:57 <bzurkowski> Also
14:21:09 <bzurkowski> Should we have a separate strategy class for each version?
14:21:37 <bzurkowski> Or provide "template" class with subclass for each version?
14:22:27 <dkrol> I'm not sure what do you mean by template class?
14:23:32 <bzurkowski> I mean
14:25:21 <bzurkowski> For example: BaseCassandraStrategy with basic flow using abstract methods for logic that differs between versions
14:25:39 <bzurkowski> That would be our "template" class
14:25:49 <bzurkowski> And then, we could have subclasses such as:
14:26:20 <bzurkowski> Cassandra2Strategy and Cassandra3Strategy inheriting by BaseCassandraStrategy and implementing abstract methods
14:27:31 <bzurkowski> By "flow" I mean the management flow (provisioning, backup, configuration etc.)
14:27:34 <bzurkowski> Is it clear now?
14:28:23 <dkrol> Ok, but it is a way of code sharing between  classes supporting different versions
14:28:45 <bzurkowski> Yes
14:28:49 <dkrol> I'm not sure if this solves issue which class to load
14:28:57 <bzurkowski> It is not
14:29:11 <bzurkowski> Much work would have to be done in order to load appropriate strategies dynamically
14:30:33 <bzurkowski> I am wondering
14:30:42 <dkrol> I don't have an answer now so let's think about it and discuss approaches next time
14:30:56 <bzurkowski> Maybe we should just support the latest version?
14:31:16 <bzurkowski> It would be much easier to follow new versions of the engine
14:31:29 <bzurkowski> Until we find another solution to the problem and implement it into the code
14:32:25 <dkrol> My concern is you will be able to break trove deployment just by upgrading stuff
14:33:00 <dkrol> And most people will run more than one version of a database
14:33:58 <dkrol> Let's take a look at the code first
14:34:46 <bzurkowski> ok
14:35:22 <dkrol> I wanted to thank you for reviewing my documentation change
14:35:48 <dkrol> I committed a new version of it
14:36:13 <bzurkowski> Yes, I will take a look soon
14:36:14 <dkrol> Also there is another change related to documentation in Gerrit
14:36:28 <dkrol> A small update
14:37:34 <dkrol> Please take a look at it also
14:38:07 <mpiwowarczy> dkrol: yw, nice to see have such type of guide :)
14:38:48 <dkrol> Also I've created a page about rabbitmq throttling
14:39:04 <dkrol> You can find a link on trove general
14:39:16 <dkrol> It is related to security and ddos
14:39:58 <dkrol> I need to make some tests
14:40:34 <bzurkowski> I will try to check it out
14:41:01 <dkrol> I would be good to have some answers regarding this issue as it is a major concern
14:41:36 <bzurkowski> What about mailing list?
14:41:45 <bzurkowski> We could ask Lingxian Kong about his opinion
14:42:02 <dkrol> Once I will do tests
14:42:08 <bzurkowski> He seems to have production experience with Trove
14:42:22 <bzurkowski> And recently he is introducing security-related changes
14:43:09 <dkrol> Yes, he is working on production deployment of trove
14:43:31 <dkrol> We should help him in his problems :)
14:43:50 <dkrol> Please take a look and respond to his questions
14:43:55 <bzurkowski> Yes, we should too ;)
14:44:51 <dkrol> This is all from me this week
14:44:58 <dkrol> Do you have anything else?
14:46:16 <bzurkowski> Not from my side
14:46:17 <bzurkowski> But
14:47:03 <bzurkowski> Please, think about the datastore versioning so we could decide next week on how to procees
14:47:06 <bzurkowski> *proceed
14:47:29 <dkrol> Sure
14:47:32 <dkrol> Thanks
14:47:51 <dkrol> See you next time
14:47:54 <bzurkowski> See you
14:47:55 <bzurkowski> Bye
14:47:58 <dkrol> Bye
14:48:02 <dkrol> #endmeeting