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 >