16:00:58 <m3m0> #startmeeting openstack-freezer 19-11-2015
16:00:59 <openstack> Meeting started Thu Nov 19 16:00:58 2015 UTC and is due to finish in 60 minutes.  The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:02 <openstack> The meeting name has been set to 'openstack_freezer_19_11_2015'
16:01:25 <m3m0> first order of business pbr
16:01:33 <m3m0> #topic pbr
16:02:20 <m3m0> we currently have this commit that will enable the installation of freezer on windows and linuz
16:02:21 <m3m0> linux
16:02:22 <m3m0> https://review.openstack.org/#/c/246428/5
16:02:51 <m3m0> the problem is os specific dependencies and that pbr version on kilo doesn't support environment_markers
16:03:10 <m3m0> so we need to do this within the setup.py file
16:03:26 <m3m0> any objections or comments on this regard?
16:04:22 <Slashme> Yes.
16:05:37 <daemontool_> Slashme, what comments and objections? :)
16:05:41 <m3m0> hahahaha
16:05:53 <daemontool_> we are blocked
16:05:53 <daemontool_> :)
16:05:54 <daemontool_> lol
16:06:04 <m3m0> he is buffering
16:06:13 <daemontool_> haha
16:06:28 <Slashme> With this, the package gets installed even on operations that shouldn't install anything. Like "pip wheel"
16:06:56 <Slashme> or python setup.py egg_info
16:07:10 <m3m0> so this approach is not optimal?
16:07:43 <daemontool_> thought patchset 5 was OK? https://review.openstack.org/#/c/246428/5..6/setup.py
16:08:12 <daemontool_> just doing try: except: finally would do it?
16:08:25 <daemontool_> Slashme,  if that's the idea (from patchset 6) then patchset 5 was OK
16:08:26 <daemontool_> sorry
16:08:27 <daemontool_> my bad
16:09:05 <Slashme> My concerns also apply on the stable/kilo current state. This patch just has the thing working in non activated venv's
16:09:54 <Slashme> So what is the difference between try finaly and try except raise finaly ?
16:10:23 <m3m0> the value in sys.exc_info
16:10:40 <Slashme> So which is the best solution ?
16:10:41 <daemontool_> Slashme,  I think is the same
16:10:56 <daemontool_> try finally probably is the best
16:10:58 <daemontool_> less code to write
16:11:20 <m3m0> if we need to know which exception was raised we need to re-reaise
16:11:33 <m3m0> otherwise try finally is enough
16:12:06 <Slashme> Ok. So it is better to re-raise
16:12:17 <daemontool_> my concern is, if we have to stop the program execution anyway
16:12:19 <m3m0> but we still have the problem with the virtual environments right?
16:12:31 <daemontool_> when the block in try throw an exception
16:12:37 <daemontool_> then why have a finally statement
16:13:17 <daemontool_> I think
16:13:38 <Slashme> daemontool_: unless it gets killed by a kill -9 the finaly will be executed
16:13:53 <daemontool_> and after that the program keep running?
16:14:22 <Slashme> No, it stops
16:14:52 <daemontool_> ok, so why we do that if the program stops anyway
16:15:14 <daemontool_> I think probably I'm missing something :)
16:16:01 <m3m0> raise will prevent the installation to continue so that's what we want
16:16:16 <daemontool_> yes
16:16:53 <daemontool_> ok let's talk about this after the meeting
16:17:00 <daemontool_> and we'll solve this once for all
16:17:09 <daemontool_> is that ok?
16:17:51 <m3m0> yes, we need to solve this soon
16:18:04 <m3m0> ok, does anyone has anything else to add on this topic?
16:18:15 <Slashme> Yes
16:18:22 <Slashme> On liberty this tim e
16:19:22 <Slashme> If an old version of PBR is already installed, we get an error because the setup_requires does not update pbr before doing the install
16:19:41 <m3m0> so the problem will persist?
16:19:45 <Slashme> Just worth noticing. I don't think we can do anything against that
16:19:57 <daemontool_> if we set the pbr version in setup.py will that be solved?
16:20:02 <Slashme> Nope
16:20:15 <daemontool_> ok then nothing
16:20:21 <daemontool_> it's a common problem everybody has
16:20:34 <m3m0> even for setup_requires? instead of install_requires?
16:20:50 <daemontool_> or both?
16:20:59 <Slashme> m3m0: both
16:21:07 <daemontool_> ok
16:21:10 <Slashme> No easy solution here
16:21:12 <Slashme> Maybe we should still create a bug and describe the workaround
16:21:18 <daemontool_> noop then
16:21:19 <daemontool_> yes
16:21:22 <Slashme> ie: uninstalling pbr
16:21:23 <m3m0> #agree
16:21:31 <daemontool_> like a troubleshooting guide section in the wiki
16:21:33 <daemontool_> ?
16:21:41 <Slashme> +1
16:21:43 <daemontool_> #agreed
16:22:33 <daemontool_> or we can add pip as requirement
16:22:34 <m3m0> don't like this, but if there is no other way....
16:22:40 <daemontool_> and skip the easy_install pip part
16:23:16 <daemontool_> I'd like to understand if this is an issue that everybody has or only us...
16:23:48 <daemontool_> because it looks to me a bit strange honestly... that also the other project has the same issue and no one fixed it
16:24:19 <Slashme> I checked a bit other projects
16:24:39 <daemontool_> what they do in kilo?
16:24:58 <daemontool_> well... probably they don't have this issue.. cause the packages are all in requirements
16:25:03 <daemontool_> and there's no windows support
16:25:20 <daemontool_> or did you find anything different Slashme ?
16:25:22 <Slashme> Mainly, either the don't support windows or if they do, they don't have weird plateform dependancies (ie: openstack clients)
16:25:34 <daemontool_> ok
16:26:16 <daemontool_> I think that code needs to be removed...
16:26:53 <daemontool_> then we put pep3143daemon in requirements.txt of stable/kilo
16:27:00 <daemontool_> and remove the windows module
16:27:14 <daemontool_> and add it as requirement to install in the documentation
16:27:17 <daemontool_> so kilo is solved
16:27:20 <Slashme> But then it breaks windows
16:27:31 <daemontool_> then we use env markers  in liberty
16:27:35 <Slashme> pep3143daemon doesn't install on windows
16:27:41 <daemontool_> ah yes
16:27:46 <daemontool_> that's true sorry
16:27:47 <daemontool_> :(
16:27:59 <Slashme> I know .....
16:28:21 <m3m0> we can solve this by having a windows installer?
16:28:25 <m3m0> a .msi?
16:28:36 <daemontool_> that wouldn't be a bad idea
16:28:50 <daemontool_> or distributing the win binary package from pypi?
16:29:10 <Slashme> m3m0: Yes but this is a big change then. No ? Is that something we want to backport to stable/kilo ?
16:29:38 <m3m0> yes, that's true, we need to solve this problem and soon
16:29:44 <daemontool_> like bdist_msi
16:30:03 <daemontool_> Slashme,  I think we can it's not a feature change
16:30:15 <daemontool_> it's just a change on how we manage the packages and reqs
16:30:18 <m3m0> and what about to write the dependencies in the readme? bad idea?
16:32:09 <daemontool_> m3m0,  yes
16:32:30 <daemontool_> that's probably is the easiest thing to do
16:32:51 <daemontool_> do you mean the pepdaemon dependancy?
16:32:53 <daemontool_> for linux?
16:32:54 <daemontool_> mmhhh
16:33:08 <daemontool_> or put in the readme the window steps
16:33:19 <daemontool_> and put pepdaemon in requirements?
16:33:22 <Slashme> How about we remove the pep3143 dependancy an rewrite that part in the freezer-scheduler
16:33:44 <daemontool_> even that is ok
16:33:45 <Slashme> It wouldn't be a big amount of work said vannif
16:34:28 <Slashme> And we put the win32 dependancy in the readme
16:34:49 <daemontool_> that works for me
16:35:06 <Slashme> Anyone againt that last solution ?
16:35:17 <vannif> I like it
16:35:22 <m3m0> not me
16:35:41 <m3m0> no problem for me :)
16:36:04 <daemontool_> vannif,  do you want to do it?
16:36:07 <vannif> not sure it can be done in 1 day though :)
16:36:12 <vannif> sure
16:36:13 <daemontool_> why not?
16:36:39 <daemontool_> ok
16:36:40 <daemontool_> anyway
16:36:42 <daemontool_> ++
16:36:48 <daemontool_> let's go for this approach
16:37:04 <daemontool_> vannif,  just in stable/kilo puts it in a lib directory
16:37:08 <daemontool_> and we'll import it locally
16:37:15 <daemontool_> then remove that code in setup.py
16:37:31 <daemontool_> as Slashme  said
16:37:41 <daemontool_> all good?
16:37:45 <vannif> ok
16:37:50 <daemontool_> let's move forward now
16:37:51 <daemontool_> :)
16:38:40 <m3m0> next topic
16:38:56 <m3m0> #topic stable/kilo bug fixes
16:39:14 <m3m0> who has commits that needs to be included in stable/kilo and why?
16:39:57 <daemontool_> https://review.openstack.org/#/q/project:openstack/freezer+status:open+branch:stable/kilo,n,z
16:40:10 <daemontool_> https://review.openstack.org/#/q/project:openstack/freezer-api+status:open+branch:stable/kilo,n,z
16:40:11 <reldan> I have this one https://review.openstack.org/#/c/247518/
16:40:26 <daemontool_> project:openstack/freezer-web-ui status:open branch:stable/kilo
16:40:54 <daemontool_> in the freezer-api repo, I think the changes are ok
16:40:56 <daemontool_> just minor
16:41:01 <m3m0> https://review.openstack.org/#/c/246957/
16:41:07 <m3m0> I have this commit
16:41:09 <daemontool_> remember we need to bumpt the minor version in setup.cfg when we modify stable/kilo
16:41:12 <m3m0> is a minig bug fix
16:41:28 <daemontool_> ok
16:41:30 <daemontool_> that's ok
16:41:33 <daemontool_> in freezer
16:41:36 <daemontool_> we have two commits
16:41:39 <daemontool_> https://review.openstack.org/#/q/project:openstack/freezer+status:open+branch:stable/kilo,n,z
16:41:54 <daemontool_> the platform specific thing we were discussing so far
16:42:14 <daemontool_> and the fix metadata storage from reldan
16:42:33 <m3m0> for the api we are good?
16:42:40 <daemontool_> I think so
16:42:47 <m3m0> so please everyone review those commits
16:43:41 <daemontool_> ok
16:44:07 <daemontool_> reldan,  why this needs to go to stable/kilo? https://review.openstack.org/#/c/246460/
16:44:10 <daemontool_> it's critical?
16:44:21 <daemontool_> or we need that for backwards compatibility?
16:44:32 <reldan> Not this https://review.openstack.org/#/c/247518/
16:44:44 <reldan> I should abandon 246460/
16:44:57 <reldan> Because get_metadata is broken completely in stable/kilo
16:45:41 <daemontool_> so it's a critical bug?
16:45:48 <m3m0> yes
16:45:50 <m3m0> very
16:45:53 <daemontool_> ok so it needs to go
16:46:03 <daemontool_> then all the current commits looks in order
16:46:45 <m3m0> so we have 3 bug fixes
16:46:50 <m3m0> please lets merge those
16:47:00 <m3m0> so we can move forward with liberty
16:47:31 <daemontool_> I agree, but we can move forward with liberty anyway :)
16:47:32 <m3m0> does anyone has anything to say about this topic?
16:47:49 <m3m0> yeah but let's not carry those bugs for more time
16:47:54 <daemontool_> I agree
16:47:57 <daemontool_> #agreed
16:48:45 <m3m0> next topic
16:48:50 <m3m0> #topic free4all
16:49:26 <daemontool_> m3m0,  please make sure the meeting notes are recorderd in freezer_meetings in launchpad
16:49:30 <m3m0> does anyone has something to say unrelated to pbr and stable/kilo
16:49:36 <m3m0> I will
16:49:37 <daemontool_> yes
16:49:49 <daemontool_> we need to define when we'll branch stable/kilo
16:50:21 <daemontool_> so Jokke_  was pointing me to https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
16:50:36 <daemontool_> December 1-3 will be the first release milestone of Mitaka
16:50:44 <daemontool_> if we want to match that
16:50:51 <daemontool_> we need to branch stable/kilo
16:50:53 <daemontool_> before that date
16:51:09 <daemontool_> in order to do that, I think we need to do the following:
16:51:11 <daemontool_> - parallel
16:51:17 <m3m0> in that case we have to do the same for liberty but our times doesn't match
16:51:30 <daemontool_> - all these bugs fixed
16:52:08 <daemontool_> - most probably we need to move freezer-api to testr
16:52:18 <daemontool_> - enable as voting the dvsm gate jobs on the 3 repos
16:52:42 <daemontool_> question is: can we make all of this happen by Fri next week?
16:52:48 <daemontool_> 27th?
16:53:06 <m3m0> reldan, vannif?
16:53:08 <Slashme> daemontool_: You mean stable/liberty ?
16:53:09 <daemontool_> anyone disagree with the previous items?
16:53:11 <daemontool_> yes
16:53:20 <daemontool_> yes sorry
16:53:25 <daemontool_> stable/liberty
16:53:58 <reldan> daemontool_: I hope so. But you know this week we had 1) Broken test by pytest 2) Broken gerrit
16:54:15 <daemontool_> so
16:54:22 <vannif> we should
16:54:38 <daemontool_> I think we can make happen all the items
16:54:41 <daemontool_> the only one is parallel
16:54:50 <daemontool_> reldan,  can we do that?
16:54:51 <m3m0> and then release stable/liberty next friday?
16:54:55 <daemontool_> yes
16:55:02 <daemontool_> Mon 30th
16:55:11 <daemontool_> or next Fri if all looks good
16:55:18 <daemontool_> no later Mon 30th
16:55:19 <m3m0> so 3 weeks before the previous agreement?
16:55:50 <daemontool_> the hos 2.1 release and upstream stable/liberty branch
16:55:59 <daemontool_> doesn't have to happen on the same time
16:56:03 <reldan> I hope so, now I’m testing it. But now we have storage and container in metadata. And actually it wasn’t in my plan to adopt it for parallel backup
16:56:05 <daemontool_> we can have the features ready
16:56:11 <daemontool_> and branch
16:56:22 <daemontool_> then work on patches, bugs and fixes
16:56:23 <reldan> And I actually have no idea what I should return for metadata for several storages
16:56:45 <daemontool_> reldan,  ok that's a blocker
16:57:05 <reldan> I can return None for example
16:57:10 <daemontool_> now we are running out of time
16:57:14 <reldan> And then we define it
16:57:15 <m3m0> do you want to have a separate meeting for this? reldan?
16:57:16 <daemontool_> let's do a meeting tomorrow
16:57:34 <Jokke_> daemontool_: stable/liberto brnached you mean?
16:57:37 <reldan> I suppose meeting is too much
16:57:40 <daemontool_> Jokke_,  yes
16:57:48 <reldan> We can have None, we can have a list of strings
16:57:58 <Jokke_> daemontool_: and remember you can backport bugfixes, you can't travel in time :P
16:58:11 <daemontool_> Jokke_,  yes :)
16:58:12 <reldan> Oh, no
16:58:12 <m3m0> but I need to know the structure in order to integrate it with the ui
16:58:20 <reldan> We have ssh-username as well :)
16:58:40 <daemontool_> we have two options:
16:58:51 <daemontool_> 1) we miss mitaka-1 milestone and we have more time
16:59:22 <daemontool_> 2) we send the code in and branch stable liberty and then solve the bugs
16:59:34 <daemontool_> if we need to add a data structure internally it's not a big deal, not a new feature
17:00:01 <daemontool_> reldan,  can we release  in liberty parallel with limited features?
17:00:24 <m3m0> we are running out of time
17:00:27 <reldan> Sure. I don’t know what to do with new metadata
17:00:27 <daemontool_> ok
17:00:36 <reldan> But I can just skip these field
17:00:37 <reldan> fields
17:00:54 <daemontool_> ok let's talk about this tomorrow
17:00:57 <daemontool_> new meeting
17:01:11 <m3m0> thanks to everyone
17:01:18 <reldan> I actually hate our metadata
17:01:22 <reldan> completelly
17:01:35 <m3m0> #endmeeting