14:04:25 <andreykurilin> #startmeeting Rally
14:04:26 <openstack> Meeting started Mon Sep 12 14:04:25 2016 UTC and is due to finish in 60 minutes.  The chair is andreykurilin. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:04:30 <openstack> The meeting name has been set to 'rally'
14:04:58 <rvasilets__> Hi
14:04:59 <andreykurilin> hi all
14:05:19 <astarove> hi
14:06:25 <amaretskiy> hi
14:07:02 <andreykurilin> #topic future of optional-requirements
14:07:57 <andreykurilin> we added optional-requirements long time ago to cover those libraries which we could not be added to main requirements due to global-requirements
14:08:24 <andreykurilin> Currently we can add whatever we want libraries to our main requirements.txt
14:08:38 <andreykurilin> and all such requirements will be handled by intallation of `pip`
14:08:51 <amaretskiy> we could remove them at all and care about missing clients in runtime
14:09:00 <andreykurilin> From this point of view, optional-requirements is redundant
14:09:29 <andreykurilin> amaretskiy: it is already done
14:09:41 <andreykurilin> in required_client validator
14:10:01 <rvasilets__> Does we need to use optional-requirement before\after we cut the release?
14:10:22 <rvasilets__> because openstack requirements
14:10:52 <rvasilets__> *because of global- requirements to the projects
14:11:24 <andreykurilin> rvasilets__: it doesn't relate to release at all
14:11:25 <andreykurilin> :)
14:11:44 <andreykurilin> and we are not depend on global-requirements any more
14:11:44 <rvasilets__> Okey, do we have side effect of removing them at all?)
14:11:56 <andreykurilin> rvasilets__: sure :)
14:12:42 <andreykurilin> So if we just remove optional-requirements without moving them to requirements.txt, we will miss ability to say waht client version we support and which not
14:14:27 <rvasilets__> Sure, after moving optional-requirements into requirements is there other problems|steps to remove optional-requirements?)
14:15:32 <amaretskiy> how about moving all clients from requirements.txt and optional-requiremets.txt into openstack-requirements.txt
14:15:41 <andreykurilin> one more problem: for example, we have fuelclient in our optional-requirements. And it doesn't support Python 3. If we move it to main requirements it will be great step back for Rally
14:16:16 <andreykurilin> amaretskiy: as far as I know, pip cares about only requirements.txt
14:16:42 <amaretskiy> i have no idea, let's keep this as-is
14:16:44 <rvasilets__> hm? maybe for the projects like fuel we will left them?)
14:17:07 <rvasilets__> s/hm?/hm,
14:17:38 <andreykurilin> rvasilets__: yes. we should. So my proposal to decide for what purpose we will use optional-requirements in future
14:18:00 <andreykurilin> and let's save this decision at the top of optional-requirements
14:18:19 <rvasilets__> Oh? now I see
14:18:45 <andreykurilin> for me, first rule: if package doesn't support the same python versions as Rally project, it should be added only in optional-requirements
14:19:07 <amaretskiy> #agree
14:19:29 <andreykurilin> rvasilets__ your vote:)
14:19:59 <rvasilets__> agree with this rule, is it the only one?)
14:20:06 <andreykurilin> I have one more:)
14:20:56 <andreykurilin> rule #2: if package doesn't have releases, it is hard to manage dependencies, so it should be added to optional-requirements
14:21:36 <amaretskiy> #agree
14:21:43 <rvasilets__> agree
14:21:50 <andreykurilin> nice
14:21:58 <andreykurilin> I have no more ideas :)
14:22:06 <rvasilets__> Will we left clients in requirements?
14:22:24 <andreykurilin> yes
14:23:04 <rvasilets__> Okey, packages that are not maintained by global-requirements
14:23:26 <rvasilets__> Does they go into optional or into requirements?
14:23:51 <andreykurilin> rvasilets__: when you finish refactoring validators, we will be able to move rally/plugins/openstack to separate repo and all not rally-framework requirements will move there
14:24:06 <rvasilets__> оО
14:24:08 <rvasilets__> )
14:24:22 <rvasilets__> More repos)
14:24:33 <rvasilets__> Okey
14:24:43 <andreykurilin> rvasilets__: about "packages that are not maintained by global-requirements". we abandoned g-r to be able to add more packages to our requirements.txt
14:25:05 <rvasilets__> Okey, its clear
14:25:12 <andreykurilin> any other ideas?
14:25:28 <rvasilets__> No, I think that we don't need them for now)
14:25:48 <rvasilets__> I mean new ideas)
14:25:51 <andreykurilin> ok, we have agreement about two rules and it is good
14:25:56 <andreykurilin> I'll propose a patch soon
14:26:07 <andreykurilin> oh...
14:26:17 <andreykurilin> I have another rule to discuss
14:26:18 <andreykurilin> :)
14:26:18 <rvasilets__> Need to write those rules somewhere
14:26:21 <rvasilets__> in the docs
14:26:34 <andreykurilin> rvasilets__: I'll add rules at the top of optional-requirements
14:26:43 <rvasilets__> Great!
14:27:08 <andreykurilin> so it will like description of purpose of "optional-requirments"
14:28:22 <andreykurilin> Another topic to discuss/rule . What we should do we clients who doesn't support keystone v3 ? should it be handled just by validators `required_services("keystone": "2")` or we should move such clients to optional-requirements too ?
14:29:03 <rvasilets__> Lets left them in requirements with others
14:29:42 <rvasilets__> I think that this is the problems of "operators" to configure cloud in right way)
14:30:03 <amaretskiy> handle by validators looks enough
14:30:10 <astarove> are requirements will contain description for PIPpackages?
14:30:48 <rvasilets__> No, setup.py contains it
14:31:24 <astarove> <andreykurilin> and all such requirements will be handled by intallation of `pip`
14:31:46 <astarove> is it true?
14:31:50 <rvasilets__> *setup.cfg
14:32:50 <astarove> probably `required_services("keystone": "2")` is good enouth?
14:35:40 <andreykurilin> ok, let's use required services for this purpose
14:35:49 <andreykurilin> anything else?
14:36:07 <rvasilets__> No
14:36:17 <andreykurilin> okay, let's finish meeting
14:36:22 <andreykurilin> #endmeeting