Open Stack

Admin and Service start on different ports (and potentially different
networks). That's a deployment option we are trying to support from the
get go to allow for deployments where the Admin APIU cannot be exposed on
a public-facing network.

Z



On 8/23/11 9:55 AM, "Ewan Mellor" <Ewan.Mellor at eu.citrix.com> wrote:

>If the Admin API is a superset of the Service API, then what's the
>difference between "keystone-control admin start" and "keystone-control
>ALL start"?
>
>Thanks,
>
>Ewan.
>
>> -----Original Message-----
>> From: Ziad Sawalha [mailto:ziad.sawalha at rackspace.com]
>> Sent: 23 August 2011 20:24
>> To: Ewan Mellor; Mark Nottingham; <ksankar at doubleclix.net>
>> Cc: openstack at lists.launchpad.net
>> Subject: Re: [Openstack] Default ports for services
>> 
>> Yes, we'll probably be getting rid of some of those. They've been
>> useful
>> for testing (you can chose one, the other, or both) while we waited for
>> a
>> more robust implementation following other OpenStack service patterns.
>> Keystone-control has been added to the bin folder to support the more
>> OpenStack-like commands, but is not yet working. I think the pattern in
>> keystone-control now is:
>> 
>> 	keystone-control ALL start
>> or
>> 	keystone-control auth start
>> or
>> 	keystone-control admin start
>> 
>> (probably should be `keystone-control service' start for the second
>> one).
>> 
>> 
>> 
>> 
>> 
>> 
>> On 8/23/11 9:45 AM, "Ewan Mellor" <Ewan.Mellor at eu.citrix.com> wrote:
>> 
>> >OK, now I'm confused.  We have three scripts in the bin directory:
>> >keystone-admin, keystone-auth, and keystone.  If the Admin API is a
>> >superset of the Service API, then why do we need these three variants?
>> >Wouldn't we just need two?  (Or maybe just one with a flag that said
>> >"enable admin functions")
>> >
>> >Ewan.
>> >
>> >> -----Original Message-----
>> >> From: Ziad Sawalha [mailto:ziad.sawalha at rackspace.com]
>> >> Sent: 23 August 2011 19:37
>> >> To: Ewan Mellor; Mark Nottingham; <ksankar at doubleclix.net>
>> >> Cc: openstack at lists.launchpad.net
>> >> Subject: Re: [Openstack] Default ports for services
>> >>
>> >> The Admin API is a superset of the Service API. My thinking was that
>> by
>> >> default Keystone starts up and exposes the Admin API on 35357
>> allowing
>> >> services on the local machine to find it and register themselves and
>> >> their
>> >> endpoints (especially if they are picking up ports dynamically).
>> This
>> >> is a
>> >> simple use case for installing on one machine.
>> >>
>> >> What I haven't fully worked out yet is how to handle multiple
>> machine
>> >> deployments. I'm thinking we should then register a DNS SRV record
>> (or
>> >> listen to broadcasts) to be discoverable by other machines on the
>> >> network
>> >> (or even a remote network).
>> >>
>> >>
>> >>
>> >> On 8/23/11 5:49 AM, "Ewan Mellor" <Ewan.Mellor at eu.citrix.com> wrote:
>> >>
>> >> >Are you intending to use 35357 for the admin API or the service
>> API?
>> >> And
>> >> >what port will be the default for the other one?
>> >> >
>> >> >Thanks,
>> >> >
>> >> >Ewan.
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: openstack-
>> bounces+ewan.mellor=citrix.com at lists.launchpad.net
>> >> >> [mailto:openstack-
>> >> bounces+ewan.mellor=citrix.com at lists.launchpad.net]
>> >> >> On Behalf Of Ziad Sawalha
>> >> >> Sent: 16 August 2011 22:17
>> >> >> To: Mark Nottingham; <ksankar at doubleclix.net>
>> >> >> Cc: openstack at lists.launchpad.net
>> >> >> Subject: Re: [Openstack] Default ports for services
>> >> >>
>> >> >> Keystone has been assigned TCP port 35357 by IANA.
>> >> >>
>> >> >> We'll make that the default port.
>> >> >>
>> >> >> Thanks,
>> >> >> Z
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 6/24/11 12:46 AM, "Mark Nottingham" <mnot at mnot.net> wrote:
>> >> >>
>> >> >> >On 24/06/2011, at 3:31 PM, <ksankar at doubleclix.net>
>> >> >> ><ksankar at doubleclix.net> wrote:
>> >> >> >
>> >> >> >> Couple of quick points:
>> >> >> >>
>> >> >> >> a) Once the ports are fixed, we should register them with IANA
>> as
>> >> >> well
>> >> >> >>known ports, which is the right
>> >> >> >>place.[http://www.iana.org/assignments/port-numbers]
>> >> >> >
>> >> >> >That would be a friendly thing to do. See below for potential
>> >> >> conflicts.
>> >> >> >
>> >> >> >> b) I was going to suggest something like a ZooKeeper, may be
>> the
>> >> >> >>service catalog serves that purpose.
>> >> >> >> c) Also, on the port numbers, I assume they will manifest as
>> >> >> universal
>> >> >> >>constants and/or a configuration file in a universally (or
>> >> >> >>intergalactically ;o)) known place.
>> >> >> >> Cheers
>> >> >> >> <k/>
>> >> >> >> -------- Original Message --------
>> >> >> >> Subject: [Openstack] Default ports for services
>> >> >> >> From: Ziad Sawalha <ziad.sawalha at rackspace.com>
>> >> >> >> Date: Wed, June 22, 2011 9:52 pm
>> >> >> >> To: "openstack at lists.launchpad.net"
>> >> <openstack at lists.launchpad.net>
>> >> >> >>
>> >> >> >> Where's the best place to keep track of default ports for
>> >> services
>> >> >> to
>> >> >> >>avoid conflicts? A wiki page on wiki.openstack.org?
>> >> >> >>
>> >> >> >> We had a discussion while working on Keystone about default
>> ports
>> >> >> for
>> >> >> >>OpenStack services
>> >> (https://github.com/rackspace/keystone/issues/31).
>> >> >> We
>> >> >> >>want OpenStack to work 'out-of-the-box' without built-in port
>> >> >> conflicts,
>> >> >> >>so we should coordinate which ports new services start on.
>> >> >> >>
>> >> >> >> At a minimum, we need that for Keystone as it isn't
>> discoverable.
>> >> >> Other
>> >> >> >>services can be discovered using the service catalog that
>> Keystone
>> >> >> >>returns as part of an auth request (Sample response below at
>> end
>> >> of
>> >> >> >>email).
>> >> >> >>
>> >> >> >> Here's a list of ports we talked about on
>> >> >> >>https://github.com/rackspace/keystone/issues/31
>> >> >> >> 80: Swift proxy server (swift/etc/proxy-server.conf-sample)
>> >> >> >
>> >> >> >Already taken by HTTP, of course. If it's just an HTTP API,
>> that's
>> >> >> fine.
>> >> >> >
>> >> >> >> 6000: Swift object server
>> >> >> >> 6001: Swift container server
>> >> >> >> 6002: Swift account server
>> >> >> >
>> >> >> >These are already registered for X-windows.
>> >> >> >
>> >> >> >> 6080: Nova VNC proxy
>> >> >> >
>> >> >> >free
>> >> >> >
>> >> >> >> 8001: Nova direct API
>> >> >> >
>> >> >> >taken by vcom-tunnel
>> >> >> >
>> >> >> >> 8080: Swift proxy server (swift/bin/swift-proxy-server)
>> >> >> >
>> >> >> >already HTTP alternate. Again, if it's an HTTP server (NOT http
>> >> >> proxy),
>> >> >> >that's OK.
>> >> >> >
>> >> >> >> 3306: MySQL
>> >> >> >
>> >> >> >already registered to mysql
>> >> >> >
>> >> >> >> 5672: AMPQ (RabbitMQ)
>> >> >> >
>> >> >> >already AMPQ
>> >> >> >
>> >> >> >> 9292: Glance API
>> >> >> >
>> >> >> >ArmTech Daemon (whatever that is)
>> >> >> >
>> >> >> >> 9191: Glance Registry
>> >> >> >
>> >> >> >Sun AppSvr JPDA
>> >> >> >
>> >> >> >> 5900...590?: qemu-system for VNC
>> >> >> >
>> >> >> >5901-5909 are Unassigned, 5900 is already remote framebuffer.
>> >> >> >
>> >> >> >
>> >> >> >> We've moved Keystone to 5000/5001 (for Service and Admin API,
>> >> >> >>respectively).
>> >> >> >
>> >> >> >commplex-main and commplex-link, respectively.
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> Sample Response with service catalog:
>> >> >> >> {
>> >> >> >>   "auth":{
>> >> >> >>     "token":{
>> >> >> >>       "id":"asdasdasd-adsasdads-asdasdasd-adsadsasd",
>> >> >> >>       "expires":"2010-11-01T03:32:15-05:00"
>> >> >> >>     },
>> >> >> >>     "serviceCatalog":{
>> >> >> >>       "nova":[
>> >> >> >>         {
>> >> >> >>           "region":"NorthAmerica",
>> >> >> >>           "publicURL":"https://service1-public:9000/v1/blah-
>> >> blah",
>> >> >> >>           "internalURL":"https://service1-
>> internal:9001/v1/blah-
>> >> >> blah"
>> >> >> >>         },
>> >> >> >>         {
>> >> >> >>           "region":"Europe",
>> >> >> >>           "publicURL":"https://service1-public-eu/v1/blah-
>> blah",
>> >> >> >>           "internalURL":"https://service1-internal-eu/v1/blah-
>> >> blah"
>> >> >> >>         }
>> >> >> >>       ],
>> >> >> >>       "swift":[
>> >> >> >>         {
>> >> >> >>           "region":"regionOne",
>> >> >> >>           "publicURL":"https://service2-public-dat/v1/blah-
>> blah"
>> >> >> >>         }
>> >> >> >>       ]
>> >> >> >>     }
>> >> >> >>   }
>> >> >> >> }
>> >> >> >> _______________________________________________
>> >> >> >> Mailing list: https://launchpad.net/~openstack
>> >> >> >> Post to : openstack at lists.launchpad.net
>> >> >> >> Unsubscribe : https://launchpad.net/~openstack
>> >> >> >> More help : https://help.launchpad.net/ListHelp
>> >> >> >> _______________________________________________
>> >> >> >> Mailing list: https://launchpad.net/~openstack
>> >> >> >> Post to     : openstack at lists.launchpad.net
>> >> >> >> Unsubscribe : https://launchpad.net/~openstack
>> >> >> >> More help   : https://help.launchpad.net/ListHelp
>> >> >> >
>> >> >> >--
>> >> >> >Mark Nottingham   http://www.mnot.net/
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> This email may include confidential information. If you received
>> it
>> >> in
>> >> >> error, please delete it.
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Mailing list: https://launchpad.net/~openstack
>> >> >> Post to     : openstack at lists.launchpad.net
>> >> >> Unsubscribe : https://launchpad.net/~openstack
>> >> >> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >> This email may include confidential information. If you received it
>> in
>> >> error, please delete it.
>> >
>> 
>> This email may include confidential information. If you received it in
>> error, please delete it.
>

This email may include confidential information. If you received it in error, please delete it.