14:00:52 <nikhil> #startmeeting glance
14:00:52 <openstack> Meeting started Thu Jun  9 14:00:52 2016 UTC and is due to finish in 60 minutes.  The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:54 <jokke_> o/
14:00:56 <openstack> The meeting name has been set to 'glance'
14:01:01 <mfedosin> o/
14:01:02 <kairat> o/
14:01:03 <bpoulos> o/
14:01:21 <nikhil> welcome
14:01:26 <nikhil> #topic agenda
14:01:33 <nikhil> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:44 <jokke_> hmm-m should add o/ recognition to meetbot and make it adding summary of attendees based on that ;)
14:01:56 <croelandt> o/
14:02:07 <nikhil> thanks for populating the agenda with interesting items
14:02:16 <tsufiev> o/
14:02:23 <mfedosin> nikhil: my pleasure
14:02:34 <rosmaita> 0/
14:02:44 <nikhil> We'd have a full meeting today, so may be small time for open discussion. But the items looks new and good.
14:02:55 <nikhil> Let's get started
14:03:00 <nikhil> #topic Updates
14:03:11 <nikhil> #info Glare updates ( mfedosin )
14:03:18 <mfedosin> so...
14:03:36 <mfedosin> last two days we have been focused on several items
14:03:47 <mfedosin> 1. updating the spec, based on ppl comments
14:04:08 <mfedosin> we added several new descriptions there and fixed typos
14:04:23 <mfedosin> the last version is on review
14:04:33 <nikhil> #link https://review.openstack.org/#/c/283136/ Glare API spec
14:04:40 <mfedosin> nikhil: thanks
14:04:55 <mfedosin> 2. we started prepare our code for review
14:05:14 <mfedosin> we found several things that we want to fix before
14:05:17 <jokke_> mfedosin: the latest you mean :P
14:05:28 <kairat> ))
14:05:35 <mfedosin> jokke_: I hope
14:05:38 <mfedosin> :)
14:06:14 <nikhil> yep, glare API is to reach stable state by newton-3
14:06:15 <mfedosin> so, code updates are more code refactoring
14:06:18 <nikhil> then evolve slowly
14:06:46 <mfedosin> and also we defined the set of patch sets for review
14:06:57 <mfedosin> there will be 7 commits
14:07:07 <sabari> o/ (made it!)
14:07:09 <jokke_> mfedosin: ref 2. Please lets start reviewing those patches even if you have known bug you're going to fix ... time is flying and if we postpone the reviews until you think it's perfect, we are releasing Ocata before the reviews are done ;)
14:07:25 <jokke_> Lets all get used to that we need to start reviewing Glare code as well
14:07:41 <kairat> mfedosin, doc is here
14:07:43 <kairat> https://docs.google.com/document/d/1u2qNFHycEAP-pgkbPTm2mFLrhhSSkyRtIrFVfssZ1WY/edit
14:08:09 <kairat> sorry, wrong link
14:08:12 <mfedosin> kairat: it's inner document
14:08:16 <mfedosin> Simple DB
14:08:16 <mfedosin> Objects infrastructure
14:08:16 <mfedosin> Base AT + store_api
14:08:16 <mfedosin> Engine + Engine infra
14:08:16 <mfedosin> API
14:08:17 <mfedosin> Middlewares
14:08:19 <mfedosin> Test AT + functional tests
14:08:33 <nikhil> jokke_: well said. indeed the point I keep making, let's iterative develop upstream.
14:08:50 <mfedosin> nikhil: jokke_ absolutely agree
14:09:06 <nikhil> I think I need to sync with interested parties soon
14:09:10 <mfedosin> next week they will be published 100%
14:09:30 <nikhil> I have taken the time to think thoroughly , all the problems that we may face. (that doesn't include code reviews.)
14:09:59 <mfedosin> also, we got some feedback from Heat team - they promised to review the spec
14:10:08 <nikhil> mfedosin: nice!
14:10:15 <mfedosin> murano as well
14:10:59 <mfedosin> so, next week we'll start developing in upstream
14:11:08 <mfedosin> sorry for delay
14:11:46 <sigmavirus24> Good work mfedosin & co.
14:11:53 <jokke_> mfedosin: I think it's more problem for you than for most of us
14:11:55 <nikhil> == sigmavirus24
14:12:06 <mfedosin> thanks :)
14:12:22 <nikhil> mfedosin: should we move to nova updates?
14:12:41 <mfedosin> also we're working hard on tests
14:12:54 <mfedosin> big update will be able tomorrow
14:13:07 <jokke_> woohoo!
14:13:12 <mfedosin> thanks Ilya Menkov and Darja Shakray :)
14:13:19 <mfedosin> yeah, let's go to Nova
14:13:25 <nikhil> #info Nova v1, v2 updates ( mfedosin )
14:13:25 <mfedosin> there are good news ;)
14:13:34 <nikhil> indeed
14:13:46 <mfedosin> this happened!
14:13:47 <jokke_> I think there is the best news of Glance history!
14:14:08 <kairat> +100500
14:14:10 <mfedosin> xen is still on review
14:14:21 <mfedosin> but sudipto is working on it
14:14:32 <mfedosin> and I believe it will be merged soon
14:14:47 <mfedosin> all tests pass
14:15:20 <mfedosin> And Jay Pipes rejoiced yesterday
14:15:55 <nikhil> #link https://review.openstack.org/321551 default to using glance v2
14:16:10 <mfedosin> I want to discuss next steps in this adoption
14:16:23 <mfedosin> but it's better to do it in next topics
14:16:32 <jokke_> and based on the mailing list discussion the expectation is that Images API v1 is deprecated ... We can finally do it!!!
14:17:26 <nikhil> mfedosin: want to move on to next topic ?
14:17:30 <mfedosin> nikhil let's move on :)
14:17:39 <nikhil> #topic Announcements
14:17:41 <mfedosin> we have a lot to discuss today
14:17:55 <nikhil> So, only one announcement today
14:18:08 <nikhil> #info Glance virtual midcycle is next week
14:18:25 <nikhil> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/096180.html for more info
14:18:38 <nikhil> etherpad will be out soon
14:18:56 <nikhil> I have been given some time preferences already
14:19:36 <nikhil> so as per FIFO protocol, I will give them a preference for the topic they want to discuss earlier, later, etc.
14:20:02 <nikhil> #info and next week's meeting is cancelled.
14:20:20 <nikhil> So, please reach out to me or on ML for any questions that come up.
14:20:29 <nikhil> moving on.
14:20:38 <nikhil> #topic At what stage should we make the glance_store tests. Un-experimental/voting. (Bunting)
14:20:42 <bunting> Its me
14:20:55 <nikhil> bunting: please go ahead
14:21:10 <bunting> So the glance_store functional tests are nearly ready, once the infra thing lands I can test them
14:21:38 <bunting> I was just wondering what the process of moving from experimental non voting is
14:22:12 <nikhil> I thought only the plumbing of the tests was done?
14:22:15 <jokke_> bunting: effectively when the jobs have been running for a while and are deemed stable, it's ok to turn them voting
14:23:02 <bunting> nikhil: I don't understand what you mean
14:23:06 <jokke_> bunting: if there is tests suites for them, they should not be experimental for too long but lets not rush it
14:23:07 <nikhil> for example, I saw test only for swift store. are there plans for single vs. multi tenant separation?
14:23:15 <bunting> jokke_: So we should make them non-expermiental in that case
14:23:48 <jokke_> bunting: what's current test coverage we have there?
14:24:12 <nikhil> bunting: I am asking along the same lines of what jokke_ said above
14:24:31 <nikhil> converage, separation of test cases (single tenant vs multi -- swift backend)
14:24:39 <nikhil> then let's think of other stores
14:24:49 <bunting> Pretty small, thats why I was wondering do we want to run them on every job as we grow them? Or just when someone uses "check experimenal"
14:25:17 <jokke_> bunting: in that case we should not take up infra resources to run them on every commit, yet
14:25:30 <jokke_> we should have decent coverage before we start doing that
14:25:55 <bunting> Okay, works for me, just didn't really know how this stuff works out
14:26:05 <nikhil> I also want to add that we need to have separate tests for each driver type. (some will be experimental and some won't)
14:26:34 <jokke_> nikhil: I may disagree
14:26:57 <nikhil> jokke_: on what particularly?
14:27:12 <jokke_> nikhil: we should need the 3rd party CI set up when the base suite is working, but infra will never be able to accommodate functional or integration tests for all the drivers
14:27:50 <nikhil> sure
14:28:40 <jokke_> so lets take one step at the time and worry about the driver suites after the base lib is covered and we can start gating on it ;)
14:29:02 <nikhil> jokke_: I am saying that if we've test for say swift single tenant (non-experimental), multi (experimental), ceph (non-experimental), filesystem (non-experimental), then we can run the expriemental one on case by case basis.
14:29:22 <jokke_> nikhil: ah ... that makes sense
14:29:27 <nikhil> cool
14:29:32 <bunting> Also it means if you only have a certain store to test loacally you could just use that
14:29:41 <bunting> Rather than having to run the all
14:29:44 <nikhil> ++
14:30:15 <bunting> I think you can probably move on now
14:30:20 <nikhil> cool
14:30:23 <nikhil> #topic Glance v2 integration in Horizon (robcresswell, tsufiev, mfedosin)
14:30:41 <nikhil> robcresswell: hello
14:30:42 <robcresswell> o/
14:30:49 <tsufiev> and hello again :)
14:30:54 <nikhil> :)
14:30:55 <robcresswell> tsufiev wanted to talk this one through I think
14:30:56 <mfedosin> and hi
14:31:04 <tsufiev> okay
14:31:06 * nikhil not sure who's supposed to talk, and picked the first nick
14:31:34 <nikhil> !ping
14:31:34 <openstack> pong
14:31:36 <tsufiev> yesterday on a horizon meeting we discussed the Horizon's transition to Glance V2
14:31:55 <jokke_> :o
14:32:03 * nikhil guesses copy-from
14:32:14 <tsufiev> and a famous copy-from feature that Horizon users are very, very fond of
14:32:19 <tsufiev> seriously
14:32:28 * jokke_ haz been told for ~year that horizon is supporting Images API v2 already
14:32:40 <jokke_> ah
14:32:47 <tsufiev> jokke_, who has been telling you that?
14:33:19 <tsufiev> also I heard from kairat that technically speaking, copy-from is not big problem implementing in Glance V2
14:33:39 <kairat> glanceclient
14:33:43 <tsufiev> yep
14:33:44 <jokke_> tsufiev: can't quote anyone by name ... pretty much as long as the Nova move have been on the table for our priority, the consensus has been that Nova is the absolute last depending on v1
14:33:46 <mfedosin> tsufiev: yeah, on client side
14:34:24 <mfedosin> jokke_: we discussed on the summit - also we have Heat and Horizon
14:34:25 <tsufiev> implementing it on clientside is marginally better than Horizon doing the same thing on server-side, but still is better
14:34:30 <jokke_> tsufiev: I've been proposing that every now and then for quite a while and got pushback for it every single time
14:34:35 <nikhil> mfedosin: kairat tsufiev : let me voice this proposal (and not issue) with a concerning tone
14:34:48 <mfedosin> and it turned out that Murano as well - and they need copy-from to comlete v2 adoption
14:35:05 <nikhil> I would encourage all those who think this is even a remotely good idea to join us for a DefCore sync/session sometime.
14:35:38 <kairat> hm, how it is related to defcore?
14:35:45 <tsufiev> nikhil, even if it's done inside glanceclient?
14:35:49 <nikhil> it affects end users
14:35:52 <mfedosin> nikhil: if it's done in glance client
14:35:54 <nikhil> tsufiev: yep
14:36:17 <jokke_> nikhil: defcore really does not care about the end user
14:36:18 <nikhil> whatever happens for the end-users define adoption of an API
14:36:25 <nikhil> jokke_: let me finish
14:37:23 <nikhil> if a particular way is supported by official project then it creates a contract to not break the API (CLI is to be maintained for at least 2 years after deprecation)
14:37:39 <nikhil> so, if we implement copy-from the new import refactored API
14:37:59 <nikhil> the 'old way' and the 'new way' of copy-from will need to be maintained
14:38:00 <kairat> nikhil, why do we need to change api to support that feature?
14:38:14 <kairat> it can be done in shell, iiuc
14:38:27 <nikhil> kairat: that's why I am asking you to join the DefCore sessions
14:38:46 <nikhil> 'why' is not a irc conversations to be done in 10 mins :)
14:38:52 <jokke_> nikhil: since when defcore has had anything to say about the client? Only thing what is their concern is the API interoperability between the clouds and their tests are based on tempest that does not use native clients
14:40:20 <jokke_> if there is client X that does Y and Z offline and then upload image via Images API without needing any special tweaks to that API, that should not be defcores business by the slightest
14:40:36 <nikhil> jokke_: DefCore is tied to endusers, and client side development that include OSC is tied to these conversations as well. Overall, this is focussed around getting a single maintainable API for end users and client that hides all the details for the user and that needs to be OSC. However, osc is not the only client when defcore thinks of adoption.
14:41:16 <nikhil> so, we need to be consistent in our development, approach, documentation and support for features.
14:41:28 <mfedosin> nikhil: we changed glance api interface countless times and there were no concerns from defcore
14:41:53 <nikhil> because we don't have a API for defcore
14:42:43 <nikhil> the API and development around it needs to be here http://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html
14:43:05 <nikhil> people are more than welcome to join the conversations and give their input
14:43:08 <jokke_> tsufiev, mfedosin, nikhil: lets solve this issue ... after the meeting I fork python-glanceclient, we can put the functionality in there and who sees it filling their need, can feel free to use it ;)
14:43:17 <kairat> heh
14:43:39 <nikhil> yes, you are free to create a wrapper on top of glaceclient to implement copy-from
14:43:39 <kairat> nikhil, it will be synchronous copy-from
14:43:45 <kairat> it is a new feature
14:43:46 <mfedosin> jokke_: :D +1
14:44:04 <kairat> not replacement of image import
14:44:23 <nikhil> kairat: that sort of copy-from has a different small use case
14:44:29 <kairat> does every new feature should be approved with defcore?
14:44:32 <sabari> IMO, Horizon is not supposed to be do heavy lifting ops like copy-from (even if that's implemented on the client).
14:44:36 <jokke_> kairat: pass-thru copy-from ;)
14:44:46 <mfedosin> sabari they fixed it
14:44:52 <tsufiev> jokke_, I like the proposal :)
14:45:07 <kairat> if it will be enough for horizon to move to v2
14:45:11 <kairat> let's do it
14:45:15 <tsufiev> robcresswell, seems not everything is lost here
14:45:40 <nikhil> tsufiev: let add add, this will break large scale clouds
14:45:44 <robcresswell> It seems we are yet to get a blessing from nikhil :)
14:45:54 <nikhil> kairat: copy-from is actually useful for asynchronous data transfer for large scale public clouds. that's why it's very important to be part of glance import call.
14:46:00 <sabari> mfedosin i am saying even if glanceclient has this feature, I wouldn't recommend horizon using it
14:46:00 <jokke_> robcresswell: beauty of opensource :P
14:46:02 <nikhil> robcresswell: no, that's not what I meant
14:46:36 <robcresswell> If we must follow the defcore route, when would be the next opportunity to discuss this?
14:46:40 <jokke_> sabari: I do agree ... I think it would be even better if it was implemented in js, so that the web client would do it ;)
14:46:55 <nikhil> robcresswell: you are on your own, I may come screaming for not using standard way of implementation. I am not encouraing you to do this, just letting you know that this approach is equivalent to implementing on horizon side.
14:47:06 <tsufiev> jokke_, that's not that simple
14:47:21 <mfedosin> sabari now it's okay to upload big images with Horizon, because it doesn't store the data on controller (thanks CORS and tsufiev)
14:47:27 <tsufiev> jokke_, we would need NodeJS runtime to do that kind of stuff - piping streams
14:47:33 <mfedosin> the same story with copy-from
14:47:44 <kairat> so we can create a spec for this feature
14:48:01 <kairat> and let users decide if they need syncronous copy-from
14:48:09 <robcresswell> nikhil: Right, thats why I'm asking how you'd like us to proceed addressing it in a standard way
14:48:21 <sabari> mfedosin: that's different from copy-from because the Horizon has to spawn a thread to keep uploading
14:48:21 <tsufiev> mfedosin, but, according to people who are actually using Horizon on large scale clouds, local image upload is almost never used there
14:48:36 <nikhil> robcresswell: let me re-emphasize the importance of scale here. If a large scale public cloud provider comes screaming as copy-from is doing streaming behind the scenes, then we've a issue in glance.
14:49:12 <tsufiev> sabari, Horizon server isn't involved at all whey you're using CORS
14:49:14 <nikhil> robcresswell: the very fact the import conversation is happening is because it involves, defcore, large ops, end users and developers who represent sub set of these domins.
14:49:21 <tsufiev> it's the browser which does all the job
14:49:56 <sabari> tsufiev: right, but for that you don't need this funtionality on the glanceclient right, you are free to do even now, righ ?
14:49:58 <tsufiev> still you need to download the image iso to the workstation with browser, which isn't quite convenient as using an image url
14:49:58 <robcresswell> nikhil: I'm really confused by what argument you're attempting to have with me here. I've asked twice how you'd like us to proceed with working with defcore, and when would be a suitable time to discuss doing this in a standard way :)
14:50:07 <nikhil> robcresswell: the right way would be to push for copy-from support in glance import refactor in newton and use that starting ocata. I can add your name to the list for notification for the next sync.
14:50:26 <nikhil> robcresswell: sorry, that was added input . not argument.
14:50:49 <nikhil> robcresswell: mostly because I see a lot of chatter and messages could get lost.
14:50:50 <tsufiev> sabari, for CORS? no, we don't, it's already there
14:51:21 <robcresswell> nikhil: Right, that would be very useful, then we can join the discussion from there
14:51:32 <tsufiev> but again, CORS is not a solution suitable for everyone
14:51:43 <jokke_> tsufiev: ++
14:52:02 <jokke_> tsufiev: but at least it is current workaround for those who needs the functionality
14:52:12 <sabari> tsufiev: i believe it's for local file upload. But not for copy-from..right ?
14:52:12 <tsufiev> yes, kind of
14:52:20 <jokke_> then it's matter of priorisation and deciding which is more important
14:52:21 <tsufiev> sabari, exactly
14:52:30 <nikhil> robcresswell: on a side-note, we do want to start deprecating glanceclient soon after osc support is complete. but that's a separate conversations. so, we can discuss all these things further with wider audience.
14:53:19 <jokke_> nikhil: so osc has nothing to do with horizon use. AFAIK horizon does not call the python-glanceclient over the shell cli interface
14:53:25 <jokke_> or does it?
14:53:27 <jokke_> :o
14:53:27 <robcresswell> nikhil: I'm okay to move forward without this option, but if we get people knocking on Horizons door asking for it, they will only end up being directed here, which is why we wanted to discuss before that happens :)
14:53:30 <kairat> ++ to jokke_
14:53:36 <kairat> untill openstack sdk is not ready
14:53:53 <kairat> does it worth to create a spec about that
14:53:58 <kairat> to start a discussion?
14:54:00 <nikhil> jokke_: sure, I am talking general things about not adding support to glanceclient.
14:54:03 <jokke_> kairat: and the bikeshedding done, so I'd say earliest arouns 2020
14:54:04 <kairat> WDYT?
14:54:07 <mfedosin> kairat: I think we can
14:54:25 <mfedosin> and get feddback from DefCore if it's required
14:54:37 <nikhil> robcresswell:  you are welcome to direct them here
14:55:03 <jokke_> nikhil: as said multiple times, we need to provide the support to access our API because osc consumes the functionality to their cli implementation vial our python client
14:55:10 <nikhil> robcresswell: as a part of defcore conversations (which are complex, involve lots of teams/stakeholders) I have attempted to gather feedback on what are the requirements.
14:55:38 <briancurtin> jokke_: OSC will likely soon work through openstacksdk, fyi
14:55:42 <nikhil> jokke_: that approach is planned to go away
14:55:47 <briancurtin> (specifically for glance, i mean)
14:55:49 <nikhil> == briancurtin
14:56:19 <nikhil> through openstacksdk and implement some other logic that may not exist in sdk (say for import)
14:56:21 <jokke_> briancurtin: oh cool, so soon enough we don't need to worry about the client at all?
14:56:30 <nikhil> jokke_: exactly
14:56:52 <jokke_> I thought the sdk is not even close to up to speed with our API yet, but nice if that's the case
14:57:08 <mfedosin> is there any code on review?
14:57:17 <nikhil> we've exhausted the meeting time on this
14:57:22 <robcresswell> nikhil: Fair enough. If you could add my name to the notifications for the next sync on this, that would be great
14:57:22 <kairat> oops
14:57:36 <nikhil> so sorry for not going to other mfedosin 's topics :)
14:57:47 <mfedosin> nikhil: np
14:57:58 <mfedosin> next time
14:58:10 <nikhil> robcresswell: absolutely, I am trying to huddle as many people as possibly practical :)
14:58:16 <robcresswell> sorry for taking your time mfedosin :)
14:58:22 <mfedosin> I just wanted to say, that we need some kind of docs
14:58:37 <mfedosin> that describe transition from v1 to v2
14:58:44 <nikhil> #topic open discussion
14:58:52 <tsufiev> mfedosin, +++
14:58:53 <mfedosin> I may start doing this, but I need support
14:59:00 <mfedosin> maybe from rosmaita
14:59:02 <tsufiev> that's exaclty what I've been asking for :)
14:59:08 <jokke_> mfedosin: iirc that has been discussed since the release of p-gc 1.0.0 ... no-one has just written them ;)
14:59:20 <nikhil> mfedosin: that's what the api-ref docs are for
14:59:36 <nikhil> mfedosin: what you are asking looks more like of user story to me
14:59:46 <mfedosin> they don't expose some hidden v1 features
14:59:50 <nikhil> user story, operator story, etc
14:59:56 <rosmaita> mfedosin: let's sync later today
15:00:11 <jokke_> Brian is alive! :)
15:00:14 <mfedosin> rosmaita: great! thanks
15:00:21 <nikhil> mfedosin: yep, let's sync later today.
15:00:28 <nikhil> We're officially out of time.
15:00:32 <nikhil> Thanks all for joining.
15:00:37 <jokke_> yup, thanks all!
15:00:37 <nikhil> #endmeeting