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
