There seems to be an agreement that the production configuration of Openstack should run in HTTPD using SSL etc. I'd like to propose the following URL scheme for the web Apps so that the various pieces can be installed on a single machine without conflict.
All pieces will be served on port 443 using the https protocol.
#If and only if this is installed, we should put in a forward from / to /dashboard https://hostname/dashboard
#should this be keystone or identity? https://hostname/keystone/main https://hostname/keystone/admin
#should this be glance or image? https://hostname/glance/api https://hostname/glance/registry
#should this be nova or compute? https://hostname/nova/api https://hostname/nova/crt https://hostname/nova/object https://hostname/nova/cpu https://hostname/nova/network https://hostname/nova/volume https://hostname/nova/schedule https://hostname/nova/novnc https://hostname/nova/vncx https://hostname/nova/cauth
#should this be swift or storage? https://hostname/swift/account https://hostname/swift/object https://hostname/swift/container
#should this be quantum or network? https://hostname/quantum/service https://hostname/quantum/agent
Please let me know if this list is accurate and complete.
Hello Adam.
On 04/27/2012 11:25 PM, Adam Young wrote:
#should this be keystone or identity?
I would prefer using always the development name of the project, in this case keystone.
Regards, Christian.
On 04/27/2012 05:33 PM, Christian Berendt wrote:
Hello Adam.
On 04/27/2012 11:25 PM, Adam Young wrote:
#should this be keystone or identity?
I would prefer using always the development name of the project, in this case keystone.
Regards, Christian.
Thanks, Christian. I suspect that will work better with documentation as well.
Pete Zaitcev also has pointed out that Swift probably won't play nicely with this, as the URL scheme is pretty much driven by Amazon, and it assumes a top level URL along the lines of
http://test-1235163301.kvm-rei.zaitcev.lan/testdata https://s3.amazonaws.com/test-1235163301/testdata http://kvm-rei.zaitcev.lan/test-1235163301/testdata
On Fri, Apr 27, 2012 at 05:37:32PM -0400, Adam Young wrote:
On 04/27/2012 05:33 PM, Christian Berendt wrote:
Hello Adam.
On 04/27/2012 11:25 PM, Adam Young wrote:
#should this be keystone or identity?
I would prefer using always the development name of the project, in this case keystone.
Regards, Christian.
Thanks, Christian. I suspect that will work better with documentation as well.
Pete Zaitcev also has pointed out that Swift probably won't play nicely with this, as the URL scheme is pretty much driven by Amazon, and it assumes a top level URL along the lines of
http://test-1235163301.kvm-rei.zaitcev.lan/testdata https://s3.amazonaws.com/test-1235163301/testdata http://kvm-rei.zaitcev.lan/test-1235163301/testdata
If Swift is the only exception, then we would probably be ok, since I think our other top level name prefixes would be unique enough to not clash with what Swift used at the top level
Daniel
On Mon, Apr 30, 2012 at 10:24 AM, Daniel P. Berrange berrange@redhat.com wrote:
On Fri, Apr 27, 2012 at 05:37:32PM -0400, Adam Young wrote:
Pete Zaitcev also has pointed out that Swift probably won't play nicely with this, as the URL scheme is pretty much driven by Amazon, and it assumes a top level URL along the lines of
http://test-1235163301.kvm-rei.zaitcev.lan/testdata https://s3.amazonaws.com/test-1235163301/testdata http://kvm-rei.zaitcev.lan/test-1235163301/testdata
If Swift is the only exception, then we would probably be ok, since I think our other top level name prefixes would be unique enough to not clash with what Swift used at the top level
Even more, Swift should be a separate hostname, so clashing would only be a possibility in all-in-one which is a toy/development setup.
Alan
On 04/28/2012 12:25 AM, Adam Young wrote:
#should this be quantum or network? https://hostname/quantum/service https://hostname/quantum/agent
I am not sure that the agent is relevant. In some cases the agent accesses the database directly to retrieve the working configuration. In my opinion this should be treated in the same manner as the AMQP communication in nova.
Thanks Gary
Please let me know if this list is accurate and complete.
cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
On 04/27/2012 05:25 PM, Adam Young wrote:
There seems to be an agreement that the production configuration of Openstack should run in HTTPD using SSL etc. I'd like to propose the following URL scheme for the web Apps so that the various pieces can be installed on a single machine without conflict.
All pieces will be served on port 443 using the https protocol.
<snip>
Is this something that we should be discussing upstream on the main OpenStack list?
On Sat, Apr 28, 2012 at 11:30:40PM -0400, Russell Bryant wrote:
On 04/27/2012 05:25 PM, Adam Young wrote:
There seems to be an agreement that the production configuration of Openstack should run in HTTPD using SSL etc. I'd like to propose the following URL scheme for the web Apps so that the various pieces can be installed on a single machine without conflict.
All pieces will be served on port 443 using the https protocol.
<snip>
Is this something that we should be discussing upstream on the main OpenStack list?
Indeed, I don't think that Fedora should be the people standardizing this kind of thing. We should aim to get upstream to declare this the standard so that all distros follow the same pattern.
Regards, Daniel
On 04/30/2012 04:21 AM, Daniel P. Berrange wrote:
On Sat, Apr 28, 2012 at 11:30:40PM -0400, Russell Bryant wrote:
On 04/27/2012 05:25 PM, Adam Young wrote:
There seems to be an agreement that the production configuration of Openstack should run in HTTPD using SSL etc. I'd like to propose the following URL scheme for the web Apps so that the various pieces can be installed on a single machine without conflict.
All pieces will be served on port 443 using the https protocol.
<snip>
Is this something that we should be discussing upstream on the main OpenStack list?
Indeed, I don't think that Fedora should be the people standardizing this kind of thing. We should aim to get upstream to declare this the standard so that all distros follow the same pattern.
Regards, Daniel
Yeah. My origianly thought was that this is a packing issue, but I realize now that it is more fundamental. I'm going to clean this up, integrate in some of hte comments, and post to the overall openstack list this afternoon.