14:05:22 <boris-42> #startmeeting Rally
14:05:23 <openstack> Meeting started Mon Jan 18 14:05:22 2016 UTC and is due to finish in 60 minutes.  The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:05:28 <openstack> The meeting name has been set to 'rally'
14:05:29 <bauzas> boris-42: ;)
14:06:07 <ikhudoshyn> o/
14:06:39 <kun_huang> o/
14:08:14 <ikhudoshyn> boris-42, it's not my turn, I guess, yet I'd really like to start))
14:09:13 <DinaBelova> o/
14:09:16 <boris-42> so
14:09:24 <boris-42> #topic Rally Agaenda
14:09:58 <boris-42> #link https://wiki.openstack.org/wiki/Meetings/Rally
14:10:02 <boris-42> It's here ^
14:10:55 <ikhudoshyn> yep)
14:10:57 <boris-42> @amaretskiy please write topic next in one line
14:11:14 <amaretskiy> hi
14:11:41 <boris-42> @amaretskiy because it's really bad to write whole story in topic because I can't just paste it
14:11:45 <amaretskiy> #topic command 'rally version' always returns version that was determined once during the installation,   so this command lies to those users (mostly developers) who uses rally directly from git repository   without re-installation. Any ideas how to deal with it?
14:12:17 <amaretskiy> developers can update rally in several ways
14:12:21 <boris-42> Any idea how to deal is unnecessary
14:12:29 <boris-42> #topic command 'rally version' always returns version that was determined once during the installation,   so this command lies to those users (mostly developers) who uses rally directly from git repository   without re-installation.
14:12:53 <amaretskiy> one way is re-install rally
14:13:00 <boris-42> amaretskiy: wait for bot
14:13:08 <amaretskiy> ok
14:13:12 <boris-42> amaretskiy: as you see it didn't set up the topic
14:13:36 <boris-42> amaretskiy: seems like it's too long
14:13:50 <amaretskiy> maybe single quotes?
14:13:51 <boris-42> #topic Issues with Rally version & virtual env
14:13:58 <amaretskiy> looks good
14:14:01 <boris-42> amaretskiy: nope just too long
14:14:17 <boris-42> amaretskiy: nobody expects essay in topic
14:14:18 <boris-42> ;)
14:14:26 <amaretskiy> sure
14:14:45 <boris-42> okay so short description of troulbe one more time
14:14:47 <amaretskiy> topic is related to pbr
14:14:59 <amaretskiy> once the rally is installed
14:15:14 <amaretskiy> its version is remembered by pbr
14:15:29 <amaretskiy> so command rally --version shows this version
14:15:46 <amaretskiy> so if we need some specific rally version
14:16:09 <amaretskiy> we can checkout this commit in local rally git repository
14:16:19 <amaretskiy> and then reinstall rally from thi srepository
14:16:44 <amaretskiy> in this case rally --version will show correct (new and actual) version
14:17:00 <amaretskiy> but there is another way, even simpler
14:17:21 <amaretskiy> to point python to load rally code directly from the repository
14:17:33 <amaretskiy> for example, using PYTHON_PATH env var
14:18:03 <amaretskiy> so the only thing needed to get specific rally version available is just checkout the commit
14:18:19 <amaretskiy> but rally --version will show non-actual version
14:18:48 <boris-42> andreykurilin: sorry but seems like you didn't start from the beeging description
14:18:51 <boris-42> amaretskiy: ^
14:19:02 <boris-42> amaretskiy: so it's not clear for me where is the problem
14:19:07 <amaretskiy> if there are some people (not only me) who experience this issue, can we do something with that
14:19:26 <boris-42> amaretskiy: I do not understand from your description issue sorry
14:19:49 <boris-42> amaretskiy: okay I have installed Rally getting right version, doing checkout reinstalling Rally getting new but as well right version
14:19:53 <boris-42> what's the problem?
14:19:53 <amaretskiy> the problem is incorrect version shown by command rally --version if rally is run from the repository, without re-installation
14:20:16 <amaretskiy> if we re-install rally then there is no problem
14:20:35 <boris-42> amaretskiy: so this bug is related to pbr
14:20:38 <amaretskiy> this issue is probably for rally developers
14:20:49 <boris-42> amaretskiy: https://launchpad.net/pbr
14:21:01 <boris-42> amaretskiy: it's not rally issue imho
14:21:19 <boris-42> amaretskiy: did you talk to oslo cores and pbr developers?
14:21:21 <amaretskiy> no
14:21:35 <amaretskiy> maybe - yes
14:21:48 <amaretskiy> the topic to discuss is actually the approach
14:21:58 <amaretskiy> where to get the actual rally version
14:22:03 <amaretskiy> to show it to user
14:22:46 <amaretskiy> if from pbr (as this currently being done) - then this is an expected issue, not a bug in some meaning
14:23:28 <boris-42> amaretskiy: why ?
14:23:45 <boris-42> amaretskiy: I believe it should always go to where rally is actually installed
14:23:58 <boris-42> amaretskiy: and not look at the directory where the command is run
14:24:42 <amaretskiy> no, in the case i mentioned above (using PYTHON_PATH) there is a location 1 where rally actually installed and location 2 where is an initial rally git repository
14:25:04 <amaretskiy> so rally is run from the repository - actual installation is ignored
14:25:17 <amaretskiy> this is a case for developers, not for users, i think
14:25:25 <amaretskiy> this is a specific issue
14:25:40 <amaretskiy> maybe we can consider doing nothing with that at all :)
14:25:47 <boris-42> amaretskiy: seems like so
14:25:52 <amaretskiy> okay
14:26:05 <boris-42> amaretskiy: it's soemthing invalid=)
14:26:12 <ikhudoshyn> i don't think this is an issue
14:26:28 <ikhudoshyn> devs could always do git status
14:26:33 <boris-42> amaretskiy: so if I have installed rally in system-wide and I have installed it in venv
14:26:42 <boris-42> amaretskiy: if I activate venv will the version will be oK?
14:26:46 <amaretskiy> yes, i thought about that, but wanted to ask any case
14:26:54 <amaretskiy> no
14:27:02 <boris-42> amaretskiy: so this is the case when it doesn't work?
14:27:07 <amaretskiy> venv activation does not change anything
14:27:20 <amaretskiy> only re-setting envvar PYTHON_ENV does this
14:27:27 <boris-42> amaretskiy: so why not talking to pbr guys?
14:27:31 <boris-42> amaretskiy: about this?
14:27:56 <amaretskiy> using PYTHON_ENV is something tricky that makes development easier
14:28:08 <amaretskiy> but this is not a standard way, of course
14:28:25 <amaretskiy> so this is can be considered as not a bug
14:28:47 <boris-42> amaretskiy: if it doesn't work in virtualenv
14:28:58 <boris-42> amaretskiy: it's standard way how developers works and it's actually bug
14:29:03 <boris-42> work*
14:30:06 <amaretskiy> using PYTHON_PATH can affect venv, this is normal
14:30:17 <boris-42> amaretskiy: I do not understand what you are doing
14:30:22 <boris-42> amaretskiy: something very dirty
14:30:44 <boris-42> amaretskiy: so if we have venv it won't work as well?
14:30:51 <boris-42> amaretskiy: yes/no?
14:30:53 <amaretskiy> i think we should not consider that we have a bug in pbr or etc, but my idea is consider about getting rally version directly from the source code
14:31:17 <boris-42> amaretskiy: please answer on question, i am still not sure what you are doing
14:31:22 <boris-42> amaretskiy: after 30 minute
14:31:50 <amaretskiy> i always use venv, and rally --version does not work correctly if i change PYTHON_PATH
14:32:19 <boris-42> amaretskiy: so venv + cahnging the PythonPath breaks the things?
14:32:20 <amaretskiy> i will repeat the workflow
14:32:52 <boris-42> amaretskiy: if so you are shooting up in your legs
14:32:54 <amaretskiy> boris-42: both system installation and using venv will broke rally --version
14:32:59 <amaretskiy> if we use PYTHON_PATH
14:33:26 <ikhudoshyn> amaretskiy, Will not using PYTHON_PATH fix the thing?
14:33:47 <rvasilets> o/
14:34:11 <amaretskiy> ikhudoshyn: PYTHON_PATH brokes thing, not fixes it :)
14:34:19 <amaretskiy> *breaks
14:35:02 <boris-42> guys let's move to next topic
14:35:07 <amaretskiy> okay, I think I'm the only man who uses this tricky way, maybe we can skip this topic as invalid?
14:35:18 <ikhudoshyn> amaretskiy, ))) What I ask is: if we not change PYTHON_ENV but have both system-wide rally and rally in venv, and we activate venv, wht version would be shown?
14:35:27 <ikhudoshyn> boris-42, +1
14:35:39 <boris-42> #topic  [rvasilets] Copy-paste code in cinder wrapper. Unification of usage of cinderclient and cinder wrapper in cinder utils.
14:35:48 <rvasilets> typing
14:35:50 <boris-42> There is spec about this
14:35:50 <amaretskiy> ikhudoshyn: using PYTHON_PATH saves a lot of my time :)
14:35:52 <boris-42> rvasilets: ^
14:35:57 <boris-42> rvasilets: don't type to much
14:35:58 <rvasilets> oO
14:36:00 <boris-42> rvasilets: go and review spec
14:36:08 <rvasilets> I don't know about it
14:36:36 <rvasilets> just I noticed that code in wrapper is duplicated
14:36:45 <boris-42> #link https://review.openstack.org/#/c/172831/
14:36:58 <boris-42> rvasilets: it is not only duplicated it's wrongly done
14:37:16 <rvasilets> okey I will review it
14:37:18 <boris-42> rvasilets: unfortunately we had to merge that =(
14:37:22 <rvasilets> it reasonable
14:37:27 <boris-42> rvasilets: because nobody is working on spec
14:37:36 <rvasilets> I will take a look at it
14:37:56 <rvasilets> and maybe update if its needed
14:38:03 <rvasilets> or ping Yair)
14:39:30 <rvasilets> thus I think we could close this topic)
14:40:07 <rvasilets> This topic was covered by spec
14:41:43 <boris-42> rvasilets: ya we need to finish that spec
14:42:03 <boris-42> rvasilets: provide some input if you have =)
14:42:07 <boris-42> okay next topic
14:42:10 <boris-42> #topic * [ikhudoshyn] Issue with DB migration -- alembic fails to create foreign key for a table referring itself
14:42:14 <boris-42> ikhudoshyn: okay now you=)
14:42:17 <ikhudoshyn> so..
14:42:36 <ikhudoshyn> I'm working on DB migrations patch
14:43:03 <ikhudoshyn> The code itself is done (I guess). It does migrations, I checked manually.
14:43:07 <ikhudoshyn> but..
14:43:28 <boris-42> ikhudoshyn: but what?)
14:43:32 <ikhudoshyn> I found an issue while working on tests.. though it is not test related..
14:43:36 <ikhudoshyn> here it is
14:44:08 <ikhudoshyn> in my test I start with EMPTY db, stamp it as 'base', then upgrade it
14:44:36 <ikhudoshyn> after that, DB schema is being analysed against object models
14:44:56 <ikhudoshyn> what i found is: everything works great with sqlite..
14:45:08 <ikhudoshyn> but an issue arises with postgres
14:45:23 <boris-42> ikhudoshyn: and what about mysql?
14:45:39 <ikhudoshyn> we have defined foreign key on table 'deployments', parent_uuid -> uuid
14:45:59 <boris-42> ikhudoshyn: yep we have that thing
14:46:00 <ikhudoshyn> it does not get created in postgres during migration
14:46:23 <boris-42> ikhudoshyn: so you can change the autogenerated alembic migration
14:46:26 <boris-42> ikhudoshyn: to create it
14:46:36 <ikhudoshyn> boris-42, not really..
14:46:41 <ikhudoshyn> let me finish
14:46:44 <boris-42> ikhudoshyn: ok
14:47:39 <ikhudoshyn> the issue is, during migration PGSQL complaints that there is no 'unique' constraint on 'uuid' field -- so it fails to create foreign key
14:48:10 <ikhudoshyn> i could create this 'unique' constraint but in this case tests will fail cause there is no such constraint in the models
14:48:45 <ikhudoshyn> looks like it is a bug in alembic.. (or in psycopg2)
14:49:08 <ikhudoshyn> so we generally have 3 ways:
14:49:32 <ikhudoshyn> 1. find the bug in alembic/psycopg2, try to fix
14:49:57 <ikhudoshyn> 2. change the models _VERY SLIGHTLY_ -- I think that's not an option for us
14:50:11 <ikhudoshyn> 3. tweak the test to skip this error
14:50:30 <ikhudoshyn> boris-42, what d'you think?
14:52:01 <boris-42> ikhudoshyn: the second option is not case for us
14:52:15 <boris-42> ikhudoshyn: we can't change anything especially related to postgress
14:52:17 <ikhudoshyn> boris-42, just as I thought )
14:52:27 <boris-42> ikhudoshyn: so 3 is bad idea
14:52:42 <boris-42> ikhudoshyn: because we will have real bugs that we are trying to hide
14:52:55 <ikhudoshyn> boris-42, aha
14:53:03 <boris-42> ikhudoshyn: it's not clear for me why there is no unqieue constrains on uuid field?
14:53:08 <boris-42> ikhudoshyn: it should be there
14:53:27 <ikhudoshyn> boris-42, pls open the sources -- it's not there
14:53:47 <boris-42> ikhudoshyn: you mean this https://github.com/openstack/rally/blob/master/rally/common/db/sqlalchemy/models.py#L58 ?
14:53:59 <ikhudoshyn> yes
14:54:11 <boris-42> ikhudoshyn: so that field can be changed
14:54:34 <ikhudoshyn> ?? Can I add 'unique' to 'uuid'
14:54:39 <boris-42> ikhudoshyn: yep
14:54:44 <ikhudoshyn> thanks
14:54:45 <boris-42> ikhudoshyn:  it will work with old schemas
14:54:49 <ikhudoshyn> hallelujah
14:54:52 <boris-42> ikhudoshyn: however
14:54:55 <ikhudoshyn> ?
14:55:14 <boris-42> ikhudoshyn: it's metadaa that is used whey you are running create from models schema
14:55:25 <boris-42> ikhudoshyn: https://github.com/openstack/rally/blob/master/rally/common/db/sqlalchemy/models.py#L241
14:55:49 <ikhudoshyn> yes?
14:55:53 <boris-42> ikhudoshyn: yes
14:56:07 <boris-42> ikhudoshyn: you can writing any sh** there
14:56:12 <boris-42> ikhudoshyn: and it will work lol
14:56:39 <ikhudoshyn> boris-42, you mean, write there instead of changing models?
14:57:24 <ikhudoshyn> in our case it would mean removing foreign key from metadata
14:57:34 <ikhudoshyn> or am I wrong?
14:57:46 <boris-42> ikhudoshyn: yes like it is done for other tables https://github.com/openstack/rally/blob/master/rally/common/db/sqlalchemy/models.py#L142
14:58:03 <boris-42> ikhudoshyn: actually we can write separated migration that fixes psql
14:58:28 <boris-42> ikhudoshyn: that will be better plan however it's more complicated
14:58:39 <ikhudoshyn> boris-42, It's just I failed to do that, for a reason..
14:59:01 <ikhudoshyn> we're running out of time..
14:59:10 <boris-42> ikhudoshyn: so if you add this uuid to model & regenerate schema
14:59:19 <boris-42> ikhudoshyn: oh not schema *
14:59:23 <boris-42> ikhudoshyn: alembic migration
14:59:28 <boris-42> ikhudoshyn: it will generate proper migration
14:59:34 <ikhudoshyn> nope))
14:59:36 <boris-42> ikhudoshyn: okay let's go to rally chat
14:59:40 <boris-42> #endmeeting