openstack team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx]
> Sent: 23 August 2011 20:24
> To: Ewan Mellor; Mark Nottingham; <ksankar@xxxxxxxxxxxxxx>
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx]
> >> Sent: 23 August 2011 19:37
> >> To: Ewan Mellor; Mark Nottingham; <ksankar@xxxxxxxxxxxxxx>
> >> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >> >> [mailto:openstack-
> >> bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx]
> >> >> On Behalf Of Ziad Sawalha
> >> >> Sent: 16 August 2011 22:17
> >> >> To: Mark Nottingham; <ksankar@xxxxxxxxxxxxxx>
> >> >> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> >> >> 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@xxxxxxxx> wrote:
> >> >>
> >> >> >On 24/06/2011, at 3:31 PM, <ksankar@xxxxxxxxxxxxxx>
> >> >> ><ksankar@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
> >> >> >> Date: Wed, June 22, 2011 9:52 pm
> >> >> >> To: "openstack@xxxxxxxxxxxxxxxxxxx"
> >> <openstack@xxxxxxxxxxxxxxxxxxx>
> >> >> >>
> >> >> >> 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@xxxxxxxxxxxxxxxxxxx
> >> >> >> Unsubscribe : https://launchpad.net/~openstack
> >> >> >> More help : https://help.launchpad.net/ListHelp
> >> >> >> _______________________________________________
> >> >> >> Mailing list: https://launchpad.net/~openstack
> >> >> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> >> >> 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@xxxxxxxxxxxxxxxxxxx
> >> >> 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.