14:00:02 <ddieterly> #startmeeting freezer
14:00:03 <openstack> Meeting started Thu May 26 14:00:02 2016 UTC and is due to finish in 60 minutes.  The chair is ddieterly. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:06 <openstack> The meeting name has been set to 'freezer'
14:00:20 <ddieterly> agenda at https://etherpad.openstack.org/p/freezer_meetings
14:00:26 <ddieterly> welcome ice cubes
14:01:07 <EinstCrazy> HELLO
14:01:08 <ddieterly> attendance please
14:01:09 <ddieterly> o/
14:01:12 <szaher> ddieterly: Hi
14:01:13 <ddieterly> hello
14:01:20 <thatsdone> o/
14:02:11 <jonaspf> hi
14:02:17 <yangyapeng> hi
14:02:24 <ddieterly> is fresco back?
14:02:56 <jonaspf> yes but I think he is unavailable at the moment
14:04:19 <ddieterly> ok, let's get started
14:05:42 <ddieterly> #topic enforce content-type
14:05:54 <ddieterly> https://blueprints.launchpad.net/freezer/+spec/contenttype
14:06:01 <yuval> Hi, Yuval from Smaug here
14:06:11 <jonaspf> Ok, let me explain
14:06:31 <daemontool> o/
14:06:36 <jonaspf> A recent change broke the API by making content-type mandatory
14:06:50 <jonaspf> the clients currently do not send the content-type
14:07:03 <jonaspf> I reverted it back to the original state (i.e. content-type is not mandatory)
14:07:32 <jonaspf> So it is working again but I do think enforcing content-type is the correct way
14:07:57 <ddieterly> can you implement it so that it is lenient and does not break backward compatiblilty
14:08:05 <ddieterly> like warn and make deprecated
14:08:21 <szaher> ddieterly: It should be mandatory by design
14:08:45 <ddieterly> how do we deal with backward compat?
14:08:58 <szaher> Also starting from Netown backword compatibility will be broken
14:09:00 <jonaspf> Yeah deprecating graciously sounds like a good idea
14:09:14 <jonaspf> @szaher: Why?
14:09:28 <szaher> The way we are storing backups will be changed
14:09:39 <jonaspf> So will we change the API version?
14:09:42 <szaher> take a look here https://review.openstack.org/#/c/319182/
14:10:06 <ddieterly> so, if we upated freezer-scheduler at the same time that we update the freezer-api, then there should not be a problem, right?
14:10:06 <szaher> and here https://blueprints.launchpad.net/freezer/+spec/freezer-metadata
14:10:19 <szaher> We agreed on that in the mid-cycle meetup
14:11:54 <ddieterly> i'm not sure what that has to do with content-type
14:12:35 <szaher> ddieterly: We don't care about backward compatibility starting from this release
14:12:43 <ddieterly> ok
14:12:47 <ddieterly> got that
14:13:06 <ddieterly> how are metadata linked to content-type, though?
14:13:15 <daemontool> I think a new api version should be considered
14:13:20 <szaher> so I would say if the clients are broken upstream we shouldn't care about it
14:13:47 <jonaspf> metadata and content-type are both part of the api interface
14:14:00 <jonaspf> so if we break one, we can just as well break the other
14:14:11 <ddieterly> metadata is the payload, content-type describes the payload
14:14:47 <daemontool> content type is an http header field, does it needs to be linked to the metadata?
14:14:56 <daemontool> I don't think so
14:15:02 <ddieterly> right
14:15:26 <szaher> daemontool: No, The intersection point here is we don't care about backward compatibility anymore :)
14:15:29 <ddieterly> seems like a trivial problem
14:15:41 <ddieterly> oh, i see
14:16:05 <daemontool> so
14:16:10 <ddieterly> ...because metadata will break backward compat anyway...
14:16:17 <daemontool> if the agent does not support content-type
14:16:28 <daemontool> and for the api is mandatory
14:16:34 <daemontool> do we care?
14:16:54 <szaher> agent has nothing to do with the API
14:17:00 <daemontool> sorry
14:17:02 <daemontool> the scheduler
14:17:05 <szaher> The scheduler is the one communicating with the API
14:17:08 <daemontool> yes
14:17:11 <szaher> daemontool: https://blueprints.launchpad.net/freezer/+spec/switch-to-python-freezer-client
14:17:17 <daemontool> I understand that
14:17:24 <daemontool> but if the scheduler
14:17:30 <daemontool> does not use content-type
14:17:31 <szaher> We need to switch from using apiclient to python-freezerclient
14:17:36 <daemontool> ok
14:17:48 <szaher> daemontool: No the scheduler is not using content-type :) :d
14:17:56 <daemontool> so the scheduler would use the python-freezerclient right?
14:18:12 <szaher> daemontool: Yes, we should implement this in Newton
14:18:31 <daemontool> my question is
14:18:55 <daemontool> if the scheduler that is using the python-freezerclient does not support content-type
14:19:03 <daemontool> and for the API is mandatory...
14:19:07 <daemontool> do we care?
14:19:12 <daemontool> or we don't
14:20:07 <szaher> daemontool: we do care
14:20:16 <daemontool> ok
14:20:19 <m3m0> should be enforce by the freezerclient
14:20:26 <szaher> daemontool: but the problem here is not the API the problem is the client :)
14:20:29 <daemontool> ok
14:20:39 <jonaspf> I guess the question is do we enforce the content-type? By this I mean do we send an error message if the content-type is not present?
14:20:56 <jonaspf> At the moment we ignore it so it doesn't matter if the client sends a content-type or not.
14:21:39 <jonaspf> I checked other openstack projects and they all send an error back if there is no content-type
14:21:41 <ddieterly> well, if we don't fix it, and the client sends the wrong content type, then there will be an error
14:22:09 <ddieterly> if we do fix it, and the client does send the right type, but for some reason has not been updated to send the header, then send an error
14:22:19 <m3m0> ok, so we add the header and should we backport this back to kilo?
14:22:29 <daemontool> m3m0,  nope
14:22:34 <ddieterly> why backport?
14:22:47 <m3m0> just asking...
14:22:54 <ddieterly> not sure that this is a big issue that needs immediate attention
14:23:06 <daemontool> I think we have to place all these changes in API v2 and python-freezerclient >= this.version needs to be used with API v2
14:23:35 <daemontool> and return error for http header without content-type field
14:23:57 <daemontool> or alternatively check how other projects are doing it
14:24:03 <m3m0> is it really necessary a version bump just for this?
14:24:15 <jonaspf> it's not a huge issue as it is working at the moment. This is mostly about consistency with other apis and making it future proof (e.g. if we want to accept XML and JSON at some point in the future)
14:24:37 <jonaspf> I think we have multiple options:
14:24:37 <jonaspf> 1. Change it in all clients (scheduler, client, ui) and in the api at the same time and hope nobody will notice (and everybody will update everything at the same time)
14:24:37 <jonaspf> 2. We deprecate graciously (i.e. we send a warning if the client doesn't send a content type)
14:24:37 <jonaspf> 3. We just keep it the way it is (ignore the content-type completely)
14:24:37 <jonaspf> 4. We change it when we change the API in newton to V2
14:25:06 <daemontool> wthere is the metadata thing that would make the client and api backwards incompatible, so why not mark that with a new api version
14:25:14 <daemontool> and place all the incompatible changes from there on
14:25:16 <szaher> https://specs.openstack.org/openstack/barbican-specs/specs/juno/barbican-enforce-content-type.html
14:25:23 * daemontool reading jonaspf options
14:25:43 <ddieterly> daemontool +1
14:26:57 <daemontool> I think 4
14:27:04 <ddieterly> daemontool +1
14:27:25 <daemontool> and 4 would implicitly include 1
14:27:40 <daemontool> let'see also what slashme says
14:28:23 <ddieterly> that sounds like a plan
14:28:28 <daemontool> anyway with 4, the freezerclient would be backward compatible
14:28:45 <daemontool> if content-type is sent now, there's any error_
14:28:46 <daemontool> ?
14:28:52 <jonaspf> no
14:29:07 <daemontool> then the new freezerclient would work in both cases
14:29:23 <ddieterly> #agreed discuss enforce content type with slashme
14:29:25 <daemontool> users in general always tend to use last versions of the os clients
14:29:31 <ddieterly> let's move on
14:29:38 <jonaspf> ok
14:29:39 <daemontool> ok
14:29:48 <ddieterly> is fresco around?
14:30:00 <daemontool> jonaspf, good conversation thought :)
14:30:06 <ddieterly> +1
14:30:16 <daemontool> frescof__, ping
14:30:21 <ddieterly> #topic python-freezerclient instead of apiclient
14:30:31 <ddieterly> https://blueprints.launchpad.net/freezer/+spec/switch-to-python-freezer-client
14:30:57 <daemontool> that needs to be done in the scheduler ?
14:31:02 <szaher> We need to remove apiclient from the scheduler
14:31:06 <szaher> Yes
14:31:24 <daemontool> m3m0,  the web ui is already using the freezerclient ?
14:31:26 <daemontool> ok
14:32:19 <ddieterly> this sounds reasonable to me
14:32:32 <m3m0> no, but is the plan for newton
14:32:58 <m3m0> it works, but is not officially there, the same for the scheduler
14:33:10 <daemontool> ok
14:33:25 <daemontool> so to achieve that what needs to be done?
14:33:26 <m3m0> as soon as I finish some internal tickets I will move with this
14:33:45 <daemontool> change requirements.txt, test-requirements.txt, namespaces and imports within the modules
14:33:50 <daemontool> ?
14:34:01 <m3m0> yes, and testing for the scheduler and agent
14:34:12 <daemontool> ok
14:34:15 <m3m0> documentation, which I'm doing right now
14:34:27 <daemontool> ok
14:34:40 <daemontool> all in favor for this to happen in Newton?
14:34:45 <m3m0> aye
14:34:56 <ddieterly> +1
14:34:58 <daemontool> yay :)
14:35:18 <m3m0> so that will be done next week
14:35:22 <daemontool> ok
14:35:26 <ddieterly> #topic We need to close implemented blueprints/bugs in launchpad
14:35:39 <ddieterly> somebody keeps inserting agenda items at the front of the list
14:35:45 <daemontool> ddieterly that's a good one
14:35:47 <daemontool> lol
14:35:49 <daemontool> not me
14:35:55 <ddieterly> sneaky
14:36:15 <szaher> ddieterly: it's me :) :D
14:36:30 <ddieterly> clever
14:36:32 <daemontool> someone new to the project could do that_
14:36:33 <daemontool> ?
14:36:49 <ddieterly> ok, enough said about closing bp's?
14:37:01 <ddieterly> #topic reviews
14:37:10 <ddieterly> https://review.openstack.org/#/c/312430/
14:38:01 <yangyapeng> backup nova and restore, if multiple network , it is error,
14:38:21 <yangyapeng> it is need to nodify the network id
14:38:22 <daemontool> +2 ed
14:38:25 <daemontool> yangyapeng,
14:38:29 <yangyapeng> thanks
14:38:40 <daemontool> if anyone has nothing against that
14:38:44 <daemontool> please +A it
14:38:50 <ddieterly> just like that? did you read the code? lol
14:38:50 <daemontool> and move forward
14:38:53 <daemontool> yes
14:38:54 <daemontool> I did
14:39:03 <ddieterly> ok
14:39:08 <szaher> I've some comments
14:39:09 <szaher> :)
14:39:16 <ddieterly> did you download it and test it ;-)
14:39:18 <ddieterly> haha
14:39:19 <daemontool> I've already +2ed that in th past
14:39:29 <daemontool> ddieterly,  no I didn't
14:39:45 <ddieterly> https://review.openstack.org/#/c/315939/
14:40:21 <szaher> it contains comments already
14:40:34 <daemontool> szaher,  then put -1
14:40:43 <yangyapeng> str cmp int is error. restore cindernative-vol-id
14:40:56 <ddieterly> is reldar here?
14:41:09 <szaher> daemontool: OK
14:41:13 <ddieterly> btw, where did eldar go?
14:41:20 <szaher> Microsoft
14:41:28 <szaher> Bing :)
14:41:40 <ddieterly> ah
14:41:42 <szaher> He is in Canada now and will move to US soon
14:41:58 <ddieterly> probably not going to contrib much anymore to freezer, i quess
14:42:03 <ddieterly> guess
14:42:31 <szaher> I think so
14:42:36 <ddieterly> i'll make sure border patrol does not let him in
14:42:37 <ddieterly> lol
14:42:41 <ddieterly> https://review.openstack.org/#/c/318551/
14:43:07 <m3m0> hahahahaha
14:43:08 <daemontool> haha
14:43:18 <yangyapeng> this patch increase th judment creage cinder-volume.
14:43:32 <ddieterly> yangyapeng you've been very busy
14:43:34 <yangyapeng> if volume is creating, the image is deleted
14:43:44 <daemontool> yangyapeng, ok I need to review both of them, well done thought
14:43:57 <daemontool> I'll try to do that today or tomorrow
14:44:02 <ddieterly> https://review.openstack.org/#/c/320964/
14:44:19 <ddieterly> szaher are you going to use RST or MD?
14:44:47 <ddieterly> that's for the doc move
14:44:52 <szaher> I think rst is the default format
14:45:01 <szaher> manuals are using rst
14:45:22 <ddieterly> so, does the paste deploy work  with wsgi?
14:45:58 <szaher> Yes
14:46:10 <szaher> this one https://review.openstack.org/#/c/320964/ the devstack itself failed to be deployed :)
14:46:14 <szaher> http://logs.openstack.org/64/320964/6/check/gate-freezer-api-devstack-dsvm/e75d8c7/logs/devstacklog.txt.gz
14:46:16 <ddieterly> awesome
14:46:46 <szaher> I submitted a recheck
14:46:59 <yangyapeng> i have a recheck
14:47:01 <ddieterly> szaher ok
14:47:13 <ddieterly> https://review.openstack.org/#/c/300080/
14:47:39 <szaher> this one has been there for sooo long !
14:47:49 <szaher> if this is Okay and tested let's merge it
14:47:51 <daemontool> yes and it is good
14:48:02 <ddieterly> is cynthia in the meeting?
14:48:03 <szaher> so +2 +A plz
14:48:28 <clsacramento> Hi guys! Sorry, I was on another meeting... :)
14:48:44 <daemontool> +2ed
14:49:32 <szaher> merged
14:49:36 <szaher> :) Cool
14:49:43 <ddieterly> #topic Newton plans
14:49:51 <daemontool> well done clsacramento
14:49:58 <ddieterly> which bp's are going into newton? anyone have a list?
14:50:11 <daemontool> I think we have a roadmpa
14:50:12 <daemontool> map
14:50:15 <ddieterly> i guess slashme is supposed to do that?
14:50:26 <daemontool> not sure if there's a bp for each roadmap item
14:50:36 <daemontool> and we have to place it in freezer-specs repo
14:50:49 <daemontool> yes that should be slashme
14:50:58 <clsacramento> thanks guys!
14:51:06 <clsacramento> I am very happy that it finally merged
14:51:17 <clsacramento> szaher: special thanks to Saad :)
14:51:31 <szaher> clsacramento: It's my pleasure to help :)
14:51:48 <daemontool> ok
14:52:02 <daemontool> ddieterly, I think we can move next
14:52:02 <ddieterly> #topic mid-cycle meetup
14:52:08 <ddieterly> when, where?
14:52:11 <daemontool> CAn we do this
14:52:13 <ddieterly> we need to make plans now
14:52:25 <daemontool> in september please?
14:52:30 <ddieterly> is that canada, you mean?
14:52:36 <daemontool> haha
14:52:50 <daemontool> I'm OK for Galway anytime in September
14:53:12 <ddieterly> that's late isn't it?
14:53:23 <ddieterly> last time we talked we were thinking june
14:53:36 <daemontool> June I can't :(
14:53:41 <daemontool> july or september
14:53:52 <ddieterly> july would be better than september
14:54:03 <ddieterly> early july
14:54:06 <daemontool> ok for me July
14:54:12 <ddieterly> anyone else have an opinion?
14:54:16 <daemontool> any date
14:54:23 <szaher> I will be in Egypt till 23 of July
14:54:30 <szaher> You can go for it without me guys :)
14:54:30 <clsacramento> yes, september is too close to the next summit...
14:54:44 <daemontool> well Sumit is November
14:55:04 <daemontool> last week of July?
14:55:15 <szaher> I am Ok with that :)
14:55:22 <daemontool> vote?
14:55:41 <ddieterly> #vote
14:56:01 <ddieterly> #vote mid-cycle meeting in july?
14:56:19 <daemontool> #vote +1
14:56:26 <ddieterly> yes
14:56:32 <szaher> #vote +1
14:56:44 <daemontool> last week of July
14:57:02 <ddieterly> ok, let's discuss with slashme when he gets back
14:57:04 <daemontool> ok
14:57:12 <ddieterly> but it seems like last week in july looks good/tentative
14:57:17 <ddieterly> july 25
14:57:43 <jonaspf> ah, I just found out I won't be here end of july
14:57:52 <ddieterly> oh no!
14:58:00 <daemontool> ok let's thing about this
14:58:06 <daemontool> is there any other topic?
14:58:09 <daemontool> item?
14:58:18 <ddieterly> ok, next week, fresco should run this meeting
14:58:20 <daemontool> s/thing/think/
14:58:41 <ddieterly> somebody in galway, light a fire under him, please
14:58:46 <daemontool> haha
14:58:47 <daemontool> ok
14:58:55 <daemontool> so anyone wants to help me with rsync restore?
14:59:01 <daemontool> I have a full week in June
14:59:08 <daemontool> I can dedicate to freezer
14:59:11 <daemontool> 100% of my time
14:59:18 <daemontool> so I'll do that
14:59:19 <ddieterly> great
14:59:21 <daemontool> but anyone?
14:59:24 <daemontool> interested also?
14:59:27 <ddieterly> ciao, everybody!
14:59:37 <daemontool> please respect the queue!
14:59:42 <szaher> daemontool: Let
14:59:57 <daemontool> :)
15:00:01 <daemontool> ok
15:00:01 <szaher> daemontool: Let's have a code feast after the midcycle meetup
15:00:09 <ddieterly> #endmeeting