Open Stack

On Fri, Sep 29, 2017 at 6:35 AM, Arnaud MORIN <arnaud.morin at gmail.com> wrote:
> My objective is to be able to download and upload from glance/computes to
> swift in a faster way.
> I was thinking that if glance could parallelizes the connections to swift
> for a single image (with chunks), it would be faster.
> Am I wrong ?
> Is there any other way I am not thinking of?
>
> Arnaud.

Lets take an example, image download as everyone wants their instances
booting really quickly. We have a cold image. What happens now is Nova
requests the image from Glance, glance-api requests the bits from
Swift and streams it through to Nova. If you have caching enabled in
Glance (which should be your first point of improvement to get you hot
images quickly), the glance-api will tee that data to it's local
cache, where the later requests will be served from. If your Swift and
networking between Glance and Swift are scaled appropriately, I have
hard time believing that you would get performance improvement by
waiting Glance first caching all the segments, composing them back to
an image and then sending that image over to Nova. This would likely
speed up caching, depending how fast you cache storage is, but the
first instance likely would still boot slower. Your really hot images
will be delivered directly from Glance cache anyways easing the load
on Swift.

Then we look image upload. We're again on the same situation,
currently we stream the image to Swift as soon as we start receiving
the bits from the client. With your proposal to gain any benefit we
would need to have Glance caching basically the first segment x the
number of threads amount of data we are using before we initiate the
upload to swift and the upload to glance would need to be able to keep
up with the swift sink not just throttling the connections there.
Based on the real world data we've seen so far user clients suffer
rather slow connection to their Glance nodes than Glance throttling
their transfers down due to Swift not keeping up.

Now lets say we have 10 concurrent image operations per glance-api
node which of 7 is actually interfacing with the swift. The proposed
multi threading would put totally different scaling pressure to the
Glance nodes just for example cope with all this short term caching
that needs to happen. That needs either ridiculous amounts of memory
or array of very fast disks. Do you have any data you can share that
would show us getting the performance boost worth of the overhead
cost? Just remember the connection between Glance and the client (that
being user, nova, cinder...) is single stream anyways.

- jokke
>
> Le 28 sept. 2017 6:30 PM, "Erno Kuvaja" <ekuvaja at redhat.com> a écrit :
>>
>> On Thu, Sep 28, 2017 at 4:27 PM, Arnaud MORIN <arnaud.morin at gmail.com>
>> wrote:
>> > Hey all,
>> > So I finally tested your pull requests, it does not work.
>> > 1 - For uploads, swiftclient is not using threads when source is given
>> > by
>> > glance:
>> >
>> > https://github.com/openstack/python-swiftclient/blob/master/swiftclient/service.py#L1847
>> >
>> > 2 - For downloads, when requesting the file from swift, it is
>> > recomposing
>> > the chunks into one big file.
>> >
>> >
>> > So patch is not so easy.
>> >
>> > IMHO, for uploads, we should try to uploads chunks using multithreads.
>> > Sounds doable.
>> > For downloads, I need to dig a little bit more in glance store code to
>> > be
>> > sure, but maybe we can try to download the chunks separately and
>> > recompose
>> > them locally before sending it to the requester (compute / cli).
>> >
>> > Cheers,
>> >
>>
>> So I'm still trying to understand (without success) why do we want to
>> do this at all?
>>
>> - jokke
>>
>> >
>> > On 6 September 2017 at 21:19, Arnaud MORIN <arnaud.morin at gmail.com>
>> > wrote:
>> >>
>> >> Hey,
>> >> I would love to see that reviving!
>> >>
>> >> Cheers,
>> >> Arnaud
>> >>
>> >> On 6 September 2017 at 21:00, Mikhail Fedosin <mfedosin at gmail.com>
>> >> wrote:
>> >>>
>> >>> Hey! As you said it's not possible now.
>> >>>
>> >>> I implemented the support several years ago, bit unfortunately no one
>> >>> wanted to review it: https://review.openstack.org/#/c/218993
>> >>> If you want, we can revive it.
>> >>>
>> >>> Best,
>> >>> Mike
>> >>>
>> >>> On Wed, Sep 6, 2017 at 9:05 PM, Clay Gerrard <clay.gerrard at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> I'm pretty sure that would only be possible with a code change in
>> >>>> glance
>> >>>> to move the consumption of the swiftclient abstraction up a layer
>> >>>> from the
>> >>>> client/connection objects to swiftclient's service objects [1].  I'm
>> >>>> not
>> >>>> sure if that'd be something that would make a lot of sense to the
>> >>>> Image
>> >>>> Service team.
>> >>>>
>> >>>> -Clay
>> >>>>
>> >>>> 1.
>> >>>> https://docs.openstack.org/python-swiftclient/latest/service-api.html
>> >>>>
>> >>>> On Wed, Sep 6, 2017 at 9:02 AM, Arnaud MORIN <arnaud.morin at gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi all,
>> >>>>>
>> >>>>> Is there any chance that glance can use the multiprocessing from
>> >>>>> swiftclient library (equivalent of xxx-threads options from cli)?
>> >>>>> If yes, how to enable it?
>> >>>>> I did not find anything useful in the glance configuration options.
>> >>>>> And looking at glance_store code make me think that it's not
>> >>>>> possible...
>> >>>>> Am I wrong?
>> >>>>>
>> >>>>> Regards,
>> >>>>> Arnaud
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> __________________________________________________________________________
>> >>>>> OpenStack Development Mailing List (not for usage questions)
>> >>>>> Unsubscribe:
>> >>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> __________________________________________________________________________
>> >>>> OpenStack Development Mailing List (not for usage questions)
>> >>>> Unsubscribe:
>> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> __________________________________________________________________________
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe:
>> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >
>> >
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>