14:01:45 <csatari> #startmeeting review_of_dublin_edge_notes
14:01:45 <openstack> Meeting started Thu Jul  5 14:01:45 2018 UTC and is due to finish in 60 minutes.  The chair is csatari. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:48 <openstack> The meeting name has been set to 'review_of_dublin_edge_notes'
14:01:55 <csatari> Hi
14:02:02 <csatari> #topic Roll call
14:02:03 <dpaterson> o/
14:02:07 <csatari> #info csatari
14:02:51 <csatari> Is everyone on vacation?
14:03:57 <timirnich> #info Tim Irnich
14:04:06 <timirnich> Hey csatari
14:04:13 <csatari> Hei timirnich
14:04:14 <timirnich> sorry for being late
14:04:19 <csatari> No worries.
14:05:32 <csatari> As we have low participation we can do some freestyle discussion.
14:06:00 <timirnich> great, since I have a newbie question ;-)
14:06:13 <timirnich> I was looking at the action items at https://etherpad.openstack.org/p/Dublin-edge-notes-wiki
14:06:16 <csatari> Go for it.
14:06:20 <timirnich> Seems all are on you ;-)
14:06:27 <timirnich> Mind if I pick something and help?
14:06:44 <timirnich> (to the best of my ability)
14:06:46 <csatari> No I do not mind.
14:06:53 <csatari> I'm happy to hear.
14:06:56 <csatari> Thanks
14:07:36 <timirnich> Ok, then I'll take a closer look coming days
14:07:45 <csatari> Okay.
14:07:55 <dpaterson> This is not listed in the Dublin page but has a discussion started with the Interop people on how Edge will place into interop testing
14:07:57 <dpaterson> ?
14:08:11 <csatari> I closed most of them, but there are still some open ones.
14:08:28 <timirnich> Not that I know - ain;t that a bit early?
14:08:47 <csatari> Nope. I do not know about any discussion on interop testing.
14:09:02 <dpaterson> Not sure it is, having policies defined in step with development is good practice?
14:09:05 <csatari> We can add it to the agenda of the next "regular" meeting.
14:09:19 <timirnich> I was discussing with Ildiko this morning how to delineate testing in OpenStack and OPNFV
14:09:31 <timirnich> In Keystone context
14:09:56 <csatari> I'm just in the steep part of my tempest learning curve :)
14:10:15 <timirnich> In a nutshell we concluded deployment automation and "beyond devstack" testing seem like good opportunities for OPNFV
14:10:24 <csatari> Yes, I agree.
14:10:42 <dpaterson> +1
14:10:58 <csatari> But we should be able to test K2K federation with tempest also.
14:11:19 <timirnich> Yes but that's no contradiction since OPNFV consumes Tempest
14:11:41 <timirnich> The key thing is to provide a simple pushbutton way to create the required test setup
14:11:45 <csatari> And we need to run an idp for that. I think it is not good to have an external dependency during test execution.
14:11:47 <dpaterson> I can see new interop policies being defined as add-ons or verticals
14:12:14 <timirnich> yes that has been ongoing for some time
14:12:23 <csatari> timirnich no they are not in contradiction, but we need to draw the lines :)
14:12:29 <timirnich> Have loosely been involved with the NFV vertical
14:13:27 <dpaterson> So OPNFV doesn't nec imply edge, is that correct?
14:13:43 <ildikov> dpaterson: I think that level of interop testing for edge might be a little early at this stage
14:14:30 <esarault> Yeah sorry about not being active, had 2 holidays in Canada past weeks and now there's a surprise consultant in our office which needs my attention -.-
14:14:35 <timirnich> dpaterson: didn't get your q
14:14:42 <ildikov> dpaterson: we're doing more focused testing, like finishing some activities in Keystone for basic federation and collaborate with OPNFV as timirnich outlined
14:15:49 <ildikov> esarault: it could still be worse I guess :)
14:15:58 <ildikov> esarault: I mean welcome back from holidays! :)
14:16:57 <esarault> @ildikov: Thanks :) It's a pain in teh ass in Canada/US during the last of June and first of July, there's like 3 statutory holidays within 10 days
14:17:01 <dpaterson> ildikov: understand, having interop involved early instead of late seems wise.  That said I am just getting started with edge.
14:17:10 <dpaterson> Thinking out loud.
14:18:08 <ildikov> dpaterson: that's a valid point, don't get me wrong
14:18:14 <timirnich> Interop test suites have traditionally been defined as a subset of existing tests used for gating or release QA
14:18:36 <csatari> Okay, as now we start to have some participation here, let me as if we should continue the freestyling or should we jump to the review?
14:18:56 <timirnich> Let's do what we're here for originally ;-)
14:18:57 <csatari> I have topics for both of them ;)
14:18:58 <ildikov> dpaterson: however we are in early stages a bit regarding defining the use cases in more details and figuring out what we want, therefore we cannot provide stable input for interop testing at this point as I see it
14:19:19 <csatari> Okay, then let's continue the review.
14:20:12 <csatari> #topic Review of 5.3.2.8 VM images source side
14:20:25 <csatari> #link https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#VM_images_source_side
14:21:26 <csatari> This current description covers only one alternative from https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
14:21:53 <csatari> Should I add a note, that this is under discussion?
14:22:24 <csatari> The other option is to formulate it in a very generic way, but then what is the use of ti?
14:22:29 <csatari> s/ti/it/
14:23:31 <csatari> I prefer to add a note until we figure out which are the good alternatives from the image handling wiki. (I also have a feeling that there will be at least 2 selected alternative :))
14:24:40 <timirnich> Sound good. Also ad ding a cross reference to the image handling page seems in order
14:25:18 <csatari> #action (5.3.2.8): add a note, that this section is daft until the alternatives in the image handling wiki are not analized (also add a link to the image handling wiki)
14:25:31 <csatari> Any other comments to this one?
14:25:44 <dpaterson> In diagrams where ceph is called out as backend is this referring to ceph block or RGW?
14:26:20 <csatari> dpaterson I assume block.
14:26:51 <csatari> But jokke_ knows the final truth.
14:26:57 <dpaterson> If distributed object store is used don't we get syncronization for free, either real swift of RGW?
14:27:02 <timirnich> Q: what's the right way of differentiating between available images (not to be confused with locally available) and locally present ones?
14:27:23 <jokke_> sorry, I'm on glance weekly meeting atm. will read the backlog once we're done
14:27:51 <timirnich> I mean, the total set of available/known images should be viewable and then the actual sync should only take place when and image is used/requested
14:28:17 <csatari> dpaterson Maybe we should clarify this.
14:29:06 <csatari> #action (image-wiki) Clarify if CEPH backed is CEPH block or CEPH RGW in the figures.
14:29:46 <dpaterson> So instead of using block storage for storing images, use a distributed object store.  In the later case edge nodes would be consuming same object store replica.
14:30:11 <csatari> timirnich That is true only in the pull model, but in any case there is a difference between all the available images in the edge cloud infrastructure and the ones locally copyed to an edge cloud instance.
14:30:45 <timirnich> csatari: ok got it thx
14:31:01 <csatari> jokke_ No worries, we will find you with our questions ;)
14:31:52 <csatari> Okay. Moving on...
14:32:02 <timirnich> csatari: so we differentiate between policy when/what to sync and the sync mechanism as such
14:33:01 <csatari> timirnich we did not discuss this in very big details yet, but there is a requirement that we should not synchronise every image to every location.
14:33:09 <csatari> How it is done it is not clear yet.
14:33:36 <csatari> In the pull modell it comes with the package, but on the price that the first use of the image will be slow.
14:33:47 <timirnich> yeah I guess that's the whole point ;-) Ok, don't want to hold us back, let's move on
14:34:14 <csatari> With the push model it could be policy based plus maybe an API to be able to follow the changes.
14:34:35 <csatari> I hope I've added these to the image wiki...
14:34:39 <csatari> #topic Review of 5.3.2.9 VM images receiver side
14:34:54 <csatari> I think the same not should go to here also.
14:35:13 <csatari> #link https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#VM_images_receiver_side
14:35:36 <csatari> #action (5.3.2.9): add a note, that this section is daft until the alternatives in the image handling wiki are not analized (also add a link to the image handling wiki)
14:35:47 <timirnich> We should also copy the note on the versioning since this will be asynchronous by nature
14:35:48 <dpaterson> Is there a glance core attending this meeting typcially?
14:36:29 <timirnich> Or do we conceive if the "original" image gets updated, all the copies have to get updated automatically?
14:36:51 <timirnich> Or is that out of scope?
14:37:01 <csatari> timirnich We did not cover this use cse yet, but a good catch.
14:37:09 <csatari> We should note it.
14:37:46 <timirnich> Maintaining consistency will be key, since data transfers will take long
14:38:07 <timirnich> We can steal concepts from p2p networks like bittorrent
14:39:58 <csatari> Do you think it is important to block the start of VM-s in the edge cloud instances from disk images already updated in the central cloud?
14:40:22 <dpaterson> Good point
14:41:05 <csatari> I agree that in one edge cloud instance there should be only one active instance of every disk image.
14:41:11 <dpaterson> would boot instance have to check image version in master
14:42:13 <csatari> I do not think so that glance manages image versions.
14:43:04 <csatari> I think this is one thing what Glare supports, but Glance does not.
14:44:28 <csatari> I think we should discuss this versioning question with the whole group. We can start with a mail ;)
14:45:08 <csatari> #action Raise the problem of image versioning to the edge-computing-group dl
14:45:11 <timirnich> At closer inspection, I think we should clarify the requirements resulting from "If any of the the synchronised VM images are changed it should be re-synched to all receiving edge cloud instances." for both source & receiver side
14:45:39 <timirnich> Since this is non-trivial and requires "agreed behavior"
14:45:44 <csatari> Yes
14:46:31 <csatari> #action (5.3.2.8/5.3.2.9): clarify the requirements resulting from "If any of the the synchronised VM images are changed it should be re-synched to all receiving edge cloud instances." for both source & receiver side
14:47:40 <csatari> dpaterson Glance weelky meeting is parrallel to this one and Glance cores seem to prefer that one :)
14:48:21 <csatari> jokke_ follows us from the Glance team. He promised to check the meeting logs offline.
14:49:10 <csatari> Any other comments to this chapter? (I plan to cover the image handling wikis also with an IRC review as soon as we are done with this one :))
14:49:45 <csatari> #topic Review of 5.3.2.10 Flavors source side
14:50:05 <csatari> #link https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Flavors_source_side
14:51:20 <csatari> One generic question: now as we have the StarlingX synch service shouldn't I remove the "new Kingbirds"?
14:52:14 <ildikov> csatari: we will have a section on the next weekly call about that so can do it on/after that call
14:52:22 <csatari> We should keep this "projct agnostic".
14:52:29 <csatari> Okay
14:52:39 <ildikov> csatari: I totally agree with that
14:52:41 <csatari> Thanks ildikov
14:52:44 <esarault> Is there a clear statement on how StarlingX will integrate with all of this?
14:52:49 <timirnich> Haven't heard about the StarlinX sync service admittedly - any pointers?
14:52:55 <esarault> I'm seeing this a a mjor question mark for everyone so far
14:53:20 <ildikov> esarault: by "all of this" do you mean the Edge Computing Group?
14:53:24 <esarault> It's not clear if we can rely on it or not unles I'm mistaken
14:53:35 <dpaterson> https://wiki.openstack.org/wiki/StarlingX
14:54:05 <ildikov> timirnich: dpaterson: a few slides on the comparison between that and Kingbird: https://www.dropbox.com/s/ihczi2f5odccn6f/SynchFramework-DC-StarlingX.pptx?dl=0
14:54:12 <timirnich> dpaterson: thx
14:55:03 <ildikov> esarault: they still have a few things to polish till the first release comes out, but the plan is to make it reliable :)
14:55:23 <ildikov> both from code and from community perspective
14:55:28 <jokke_> so there is no image versions in Image service
14:55:51 <jokke_> each image id is unique and immutable once active (which means it's consumable)
14:55:53 <esarault> ildikov: alright thanks, that deck answers a lot of questions, the wiki didn'T so much
14:56:17 <ildikov> esarault: yeah, lot's of things in progress atm
14:56:49 <csatari> Thanks jokke_
14:58:53 <csatari> Sorry guys I need to run soon, so
14:58:57 <csatari> #Closing
14:59:00 <dpaterson> I'm curious if there lessons to be learned from the video streaming alliance and open caching specification, there is a lot of overlap in what we are talking about with glance image synronization for instance and what the open caching specification does.  There could be work they have already done that we could take advantage of.
14:59:04 <csatari> #topic Closing
14:59:40 <csatari> #info We will continue next week same time from 5.3.2.10 Flavors source side
14:59:49 <ildikov> dpaterson: yeah, that would definitely be great to explore either here or on the use cases subgroup call
15:00:03 <dpaterson> http://www.streamingvideoalliance.org/download/4474/
15:00:32 <csatari> dpaterson thanks.
15:01:04 <ildikov> dpaterson: thanks, I know that company, will see whether I can get someone to talk to us :)
15:01:13 <csatari> #info Maybe we could learn from video streaming alliance (http://www.streamingvideoalliance.org/download/4474/) and open caching specifications?
15:01:39 <csatari> #endmeeting