Hi,

Going inline.

From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Thursday, June 7, 2018 2:24 PM

I had some additional questions/comments on the Image Synchronization Options ( 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ):


One Glance with multiple backends

  *   In this scenario, are all Edge Clouds simply configured with the one 
central glance for its GLANCE ENDPOINT ?
     *   i.e. GLANCE is a typical shared service in a multi-region environment ?

[G0]: In my understanding yes.


  *   If so,
how does this OPTION support the requirement for Edge Cloud Operation when 
disconnected from Central Location ?

[G0]: This is an open question for me also.


Several Glances with an independent synchronization service    (PUSH)

  *   I refer to this as the PUSH model
  *   I don’t believe you have to ( or necessarily should) rely on the backend 
to do the synchronization of the images
     *   i.e. the ‘Synch Service’ could do this strictly through Glance REST 
APIs
(making it independent of the particular Glance backend ... and allowing the 
Glance Backends at Central and Edge sites to actually be different)
[G0]: Okay, I can update the wiki to reflect this. Should we keep the 
“synchronization by the backend” option as an other alternative?

  *   I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ 
distribution of Images from Central to Edge for Image Synchronization
     *   i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites 
... especially for the small Edge Sites
[G0]: Yes, the question is how to define these synchronization policies.

  *   Not sure ... but I didn’t think this was the model being used in mixmatch 
... thought mixmatch was more the PULL model (below)

[G0]: Yes, this is more or less my understanding. I remove the mixmatch 
reference from this chapter.

One Glance and multiple Glance API Servers   (PULL)

  *   I refer to this as the PULL model
  *   This is the current model supported in StarlingX’s Distributed Cloud 
sub-project
     *   We run glance-api on all Edge Clouds ... that talk to glance-registry 
on the Central Cloud, and
     *   We have glance-api setup for caching such that only the first access 
to an particular image incurs the latency of the image transfer from Central to 
Edge
[G0]: Do you do image caching in Glance API or do you rely in the image cache 
in Nova? In the Forum session there were some discussions about this and I 
think the conclusion was that using the image cache of Nova is enough.

  *
  *   this PULL model affectively implements the location aware synchronization 
you talk about below,  (i.e. synchronise images only to those cloud instances 
where they are needed)?


In StarlingX Distributed Cloud,
We plan on supporting both the PUSH and PULL model ... suspect there are use 
cases for both.

[G0]: This means that you need an architecture supporting both.
Just for my curiosity what is the use case for the pull model once you have the 
push model in place?

Here is the updated wiki: 
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment

Thanks,
Gerg0




From: "Csatari, Gergely (Nokia - HU/Budapest)" 
<gergely.csat...@nokia.com<mailto:gergely.csat...@nokia.com>>
Date: Thursday, June 7, 2018 at 6:49 AM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>, 
"edge-comput...@lists.openstack.org<mailto:edge-comput...@lists.openstack.org>" 
<edge-comput...@lists.openstack.org<mailto:edge-comput...@lists.openstack.org>>
Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible 
architectures for image synchronisation

Hi,

I did some work ont he figures and realised, that I have some questions related 
to the alternative options:

Multiple backends option:

  *   What is the API between Glance and the Glance backends?
  *   How is it possible to implement location aware synchronisation 
(synchronise images only to those cloud instances where they are needed)?
  *   Is it possible to have different OpenStack versions in the different 
cloud instances?
  *   Can a cloud instance use the locally synchronised images in case of a 
network connection break?
  *   Is it possible to implement this without storing database credentials ont 
he edge cloud instances?

Independent synchronisation service:

  *   If I understood [1<https://mixmatch.readthedocs.io/en/latest/>] correctly 
mixmatch can help Nova to attach a remote volume, but it will not help in 
synchronizing the images. is this true?


As I promised in the Edge Compute Group call I plan to organize an IRC review 
meeting to check the wiki. Please indicate your availability in 
[2<https://doodle.com/poll/bddg65vyh4qwxpk5>].

[1]: https://mixmatch.readthedocs.io/en/latest/
[2]: https://doodle.com/poll/bddg65vyh4qwxpk5

Br,
Gerg0

From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Wednesday, May 23, 2018 8:59 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>; 
edge-comput...@lists.openstack.org<mailto:edge-comput...@lists.openstack.org>
Subject: [edge][glance]: Wiki of the possible architectures for image 
synchronisation

Hi,

Here I send the wiki page 
[1<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment>] where I 
summarize what I understood from the Forum session about image synchronisation 
in edge environment [2], [3].

Please check and correct/comment.

Thanks,
Gerg0


[1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[2]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
[3]: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21768/image-handling-in-an-edge-cloud-infrastructure
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to