Re: [openstack-dev] URLs

2014-11-17 Thread Jay Pipes

++ from me.

On 11/11/2014 05:35 PM, Adam Young wrote:

Recent recurrence of the Why ios everything on its own port question
triggered my desire to take this pattern and put it to rest.

My suggestion, from a while ago, was to have a naming scheme that
deconflicts putting all of the services onto a single server, on port 443.

I've removed a lot of the cruft, but not added in entries for all the
new *aaS services.


https://wiki.openstack.org/wiki/URLs

Please add in anything that should be part of OpenStack.  Let's make
this a reality, and remove the  specific ports.

If you are worried about debugging, look into rpdb.  It is a valuable
tool for debugging a mod_wsgi based application.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-17 Thread John Dickinson
Adam,

I'm not sure why you've marked Swift URLs as having their own scheme. It's true 
that Swift doesn't have the concept of admin URLs, but in general if Swift 
were to assume some URL path prefix, I'm not sure why it wouldn't work (for 
some definition of work).

Other issues might be the fact that you'd have the extra complexity of a broker 
layer for all the OpenStack components. iie instead of clients accessing Swift 
directly and the operator scaling that, the new scheme would require the 
operator to manage and scale the broker layer and also the Swift layer.

For the record, Swift would need to be updated since it assumes it's the only 
service running on the domain at that port (Swift does a lot of path parsing).

--John






 On Nov 11, 2014, at 2:35 PM, Adam Young ayo...@redhat.com wrote:
 
 Recent recurrence of the Why ios everything on its own port question 
 triggered my desire to take this pattern and put it to rest.
 
 My suggestion, from a while ago, was to have a naming scheme that deconflicts 
 putting all of the services onto a single server, on port 443.
 
 I've removed a lot of the cruft, but not added in entries for all the new 
 *aaS services.
 
 
 https://wiki.openstack.org/wiki/URLs
 
 Please add in anything that should be part of OpenStack.  Let's make this a 
 reality, and remove the  specific ports.
 
 If you are worried about debugging, look into rpdb.  It is a valuable tool 
 for debugging a mod_wsgi based application.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-12 Thread Chris Dent

On Tue, 11 Nov 2014, Adam Young wrote:

My suggestion, from a while ago, was to have a naming scheme that deconflicts 
putting all of the services onto a single server, on port 443.


+1

The current state of affairs is indeed weird.

Is this something that ought to be considered in the api-wg's
discussions?

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-12 Thread Darren Kenny

Chris Dent wrote:

On Tue, 11 Nov 2014, Adam Young wrote:

My suggestion, from a while ago, was to have a naming scheme that deconflicts putting all of the 
services onto a single server, on port 443.


+1

The current state of affairs is indeed weird.


It is, and as BUIs move more towards client's doing the access of the URLs, it
is something we need to fix - since most browsers restrict cross-domain 
access (including different ports on the same host) for security reasons.


This is the reason that the Horizon guys wrote a kind of reverse-proxy 
WSGI to enable demonstrations of the AngularJS work last week - so that

all the REST API calls were back to the origin of Horizon itself.



Is this something that ought to be considered in the api-wg's
discussions?



That would appear to fit within the aims of that working group.

Thanks,

Darren.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-12 Thread Anton Zemlyanov
For the REST API to be visible from browser it should either be on the same
domain and port or it should implement CORS spec (Cross-site HTTP requests,
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS).

If REST API implements CORS, then every HTTP request will be preceded with
OPTIONS request to check the real invocation is allowed. In practice, all
the API services are usually proxied from a single location, so URL naming
scheme is very desirable.

Anton

On Wed, Nov 12, 2014 at 3:21 PM, Darren Kenny darren.ke...@oracle.com
wrote:

 Chris Dent wrote:

 On Tue, 11 Nov 2014, Adam Young wrote:

  My suggestion, from a while ago, was to have a naming scheme that
 deconflicts putting all of the services onto a single server, on port 443.


 +1

 The current state of affairs is indeed weird.


 It is, and as BUIs move more towards client's doing the access of the
 URLs, it
 is something we need to fix - since most browsers restrict cross-domain
 access (including different ports on the same host) for security reasons.

 This is the reason that the Horizon guys wrote a kind of reverse-proxy
 WSGI to enable demonstrations of the AngularJS work last week - so that
 all the REST API calls were back to the origin of Horizon itself.


 Is this something that ought to be considered in the api-wg's
 discussions?


 That would appear to fit within the aims of that working group.

 Thanks,

 Darren.



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-12 Thread Dean Troyer
On Wed, Nov 12, 2014 at 4:11 AM, Chris Dent chd...@redhat.com wrote:

 The current state of affairs is indeed weird.

 Is this something that ought to be considered in the api-wg's
 discussions?


It does and I think that is where the proposed mapping of URL-to-API should
reside.  Proposed at least until it is actually implemented.

FWIW, I've played with this in the past in DevStack using mod_rewrite and
IIRC there is (may be) some proxy-like transformations required.  I don't
recall the details but I'll dig up that branch and see where things are ATM.

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-12 Thread Adam Young

On 11/12/2014 06:21 AM, Darren Kenny wrote:

Chris Dent wrote:

On Tue, 11 Nov 2014, Adam Young wrote:

My suggestion, from a while ago, was to have a naming scheme that 
deconflicts putting all of the services onto a single server, on 
port 443.


+1

The current state of affairs is indeed weird.


It is, and as BUIs move more towards client's doing the access of the 
URLs, it
is something we need to fix - since most browsers restrict 
cross-domain access (including different ports on the same host) for 
security reasons.


This is the reason that the Horizon guys wrote a kind of reverse-proxy 
WSGI to enable demonstrations of the AngularJS work last week - so that

all the REST API calls were back to the origin of Horizon itself.


Well, CORS issues are related.  If we do follow through with this 
proposal, and the Horizon server was working as the proxy for all of the 
endpoints, we'd have to make sure we were comfortable with the security 
implications of all traffic (tokens) going through one server, as well 
as come up with a means to allow for multiple endpoints on one proxy server.







Is this something that ought to be considered in the api-wg's
discussions?



That would appear to fit within the aims of that working group.

Thanks,

Darren.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-11 Thread Ian Cordasco
On 11/11/14, 16:35, Adam Young ayo...@redhat.com wrote:

Recent recurrence of the Why ios everything on its own port question
triggered my desire to take this pattern and put it to rest.

My suggestion, from a while ago, was to have a naming scheme that
deconflicts putting all of the services onto a single server, on port 443.

I've removed a lot of the cruft, but not added in entries for all the
new *aaS services.


https://wiki.openstack.org/wiki/URLs

Please add in anything that should be part of OpenStack.  Let's make
this a reality, and remove the  specific ports.

If you are worried about debugging, look into rpdb.  It is a valuable
tool for debugging a mod_wsgi based application.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Is the reason subdomains aren’t being suggested because of the expense of
*.hostname certificates?

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-11 Thread Richard Jones
On 12 November 2014 09:47, Ian Cordasco ian.corda...@rackspace.com wrote:

 On 11/11/14, 16:35, Adam Young ayo...@redhat.com wrote:

 Recent recurrence of the Why ios everything on its own port question
 triggered my desire to take this pattern and put it to rest.
 
 My suggestion, from a while ago, was to have a naming scheme that
 deconflicts putting all of the services onto a single server, on port 443.
 
 I've removed a lot of the cruft, but not added in entries for all the
 new *aaS services.
 
 
 https://wiki.openstack.org/wiki/URLs
 
 Please add in anything that should be part of OpenStack.  Let's make
 this a reality, and remove the  specific ports.


What do those URLs map to? For example, what does
https://hostname/identity/main map to, and does this scheme intend to
handle multiple endpoints per service?



 Is the reason subdomains aren’t being suggested because of the expense of
 *.hostname certificates?


Well, it's also much more effort even without certs :)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-11 Thread Adam Young

On 11/11/2014 05:47 PM, Ian Cordasco wrote:

On 11/11/14, 16:35, Adam Young ayo...@redhat.com wrote:


Recent recurrence of the Why ios everything on its own port question
triggered my desire to take this pattern and put it to rest.

My suggestion, from a while ago, was to have a naming scheme that
deconflicts putting all of the services onto a single server, on port 443.

I've removed a lot of the cruft, but not added in entries for all the
new *aaS services.


https://wiki.openstack.org/wiki/URLs

Please add in anything that should be part of OpenStack.  Let's make
this a reality, and remove the  specific ports.

If you are worried about debugging, look into rpdb.  It is a valuable
tool for debugging a mod_wsgi based application.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Is the reason subdomains aren’t being suggested because of the expense of
*.hostname certificates?
No, more due to the preponderance of all-in-one install options for 
smaller deployments.  Having one hostname per service should work just 
as well,  this being the more restrictive approach.





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] URLs

2014-11-11 Thread Adam Young

On 11/11/2014 06:31 PM, Dave Walker wrote:

On 11 November 2014 22:35, Adam Young ayo...@redhat.com wrote:

Recent recurrence of the Why ios everything on its own port question
triggered my desire to take this pattern and put it to rest.

My suggestion, from a while ago, was to have a naming scheme that
deconflicts putting all of the services onto a single server, on port 443.

I've removed a lot of the cruft, but not added in entries for all the new
*aaS services.


https://wiki.openstack.org/wiki/URLs

Please add in anything that should be part of OpenStack.  Let's make this a
reality, and remove the  specific ports.

If you are worried about debugging, look into rpdb.  It is a valuable tool
for debugging a mod_wsgi based application.


I am really encouraged by this proposal to be able to support url
prefixes.  I am currently working through arbitrary url prefix for
keystone, glance-api and keystone.  The services currently have quite
naive support for an arbitrary prefix and expect to own document root.

Whilst your proposal does head into solving this issue, I'd like to
stress that it should be a default prefix and not a hardcoded value.
That sounds reasonable.  Its really just a way to provide a standard for 
interoperability, but certainly there would be nothing that would break 
if a different scheme was proposed.





--
Kind Regards,
Dave Walker

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev