openstack team mailing list archive

[Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx>]

Yes, but I'd also like to give the sysadmin's the choice at least in case they are dealing with deployment constraints that are imposed on them.


From: Yuriy Taraday <yorik.sar@xxxxxxxxx<mailto:yorik.sar@xxxxxxxxx>>
Date: Tue, 23 Aug 2011 20:05:26 +0400
To: Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx<mailto:ziad.sawalha@xxxxxxxxxxxxx>>
Cc: Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx<mailto:Ewan.Mellor@xxxxxxxxxxxxx>>, Mark Nottingham <mnot@xxxxxxxx<mailto:mnot@xxxxxxxx>>, "<ksankar@xxxxxxxxxxxxxx<mailto:ksankar@xxxxxxxxxxxxxx>>" <ksankar@xxxxxxxxxxxxxx<mailto:ksankar@xxxxxxxxxxxxxx>>, "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] Default ports for services

Shouldn't it be a sysadmin's headache?
I think, it should be secure enough to run both APIs on one port and let sysadmin decide to allow or deny access to them on some conditions.

Kind regards, Yuriy.



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

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<mailto: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.