Hi Prasanna,
I think what Tom and I mentioned is the url provided in registering a
template, which is totally different from the endpoint.url for the object
store. I still could not understand your suggestion.
Thanks
-min
On 7/31/13 2:47 AM, "Prasanna Santhanam" <t...@apache.org> wrote:
>What can be done is to include into validateUrl the port provided in
>the endpoint.url from addImageStore API . That will satisfy both
>objectstore and NFS based storage. The unorthodox port that comes from
>object store will anyway be closed on the SSVM so it will return a
>connection-refused.
>
>Would that solve the problem albeit in a hacky way?
>
>In the future we could dissociate the dependency of the ports for
>download from the validity of the url generated itself.
>
>On Wed, Jul 31, 2013 at 02:58:43PM +0900, Thomas O'Dowd wrote:
>> I guess what I still don't understand is why restrict urls to certain
>> ports? If the ports are not open it will cause an error. If the ports
>> are open it will work (assuming the protocol is implemented on that
>> port). For example, for register template if I choose a closed port then
>> give me a connection error and ask me to try again. Even a currently
>> valid port such as 8080 may be closed so it's the same thing really.
>> Anyway, if I read Prasanna's mail correctly, it seems like there used to
>> be a reason but its probably no harm to open things up?
>>
>> Tom.
>>
>> On Tue, 2013-07-30 at 16:41 +0000, Min Chen wrote:
>> > Prasanna,
>> > Based on your comment, what will happen if we remove that check and
>>still
>> > NFS as secondary storage? In that case, register template is still
>>done
>> > through
>> > SSVM. Any side effect? I had the same question as Tom when I was doing
>> > object store refactoring, but hesitated to remove it because of not
>> > knowing the history of it.
>> >
>> > Thanks
>> > -min
>> >
>> > On 7/29/13 11:45 PM, "Prasanna Santhanam" <t...@apache.org> wrote:
>> >
>> > >On Tue, Jul 30, 2013 at 03:37:39PM +0900, Thomas O'Dowd wrote:
>> > >> Thanks Ian. I had a look at this file. It's an easy fix to remove
>>the
>> > >> check from here but it's a general utility function so will also
>>affect
>> > >> other uris... If there is no reason to limit any uri to those
>>ports then
>> > >> I'd like to remove this check and open them up.
>> > >>
>> > >> Interested to hear opinions,
>> > >
>> > >This is probably because earlier one would interact only with the
>>SSVM
>> > >to download any images off of secondary storage. With 4.2 that
>>ability
>> > >is transferred to the image store like say s3/cloudian and one can
>>get
>> > >direct http access to the image on the object store. The code in
>> > >validateUrl assumes that the url check goes always to the SSVM on
>> > >which only 80/443/8080 are open by default.
>> > >
>> > >--
>> > >Prasanna.,
>> > >
>> > >------------------------
>> > >Powered by BigRock.com
>> > >
>> >
>>
>> --
>> Cloudian KK - http://www.cloudian.com/get-started.html
>> Fancy 100TB of full featured S3 Storage?
>> Checkout the Cloudian?? Community Edition!
>
>--
>Prasanna.,
>
>------------------------
>Powered by BigRock.com
>
