[openstack-dev] [Magnum] Discuss configurable-coe-api-port Blueprint
Kai Qiang Wu
wkqwu at cn.ibm.com
Tue Jun 16 01:09:10 UTC 2015
Hi Adrian,
If I summarize your option, it would be,
1) Have a function like this,
magnum bay-create --name swarmbay --baymodel swarmbaymodel
--baymodel-property-override apiserver_port=8766
And then magnum pass that property to override baymodel default properties,
and create the bay.
2) You talked another BP, about adjust bay api_address to be a URL, For bay
attribute api_address should be return format like following
tcp://192.168.45.12:7622 or http://192.168.45.12:8234
Is it ?
Thanks
Best Wishes,
--------------------------------------------------------------------------------
Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing
E-mail: wkqwu at cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193
--------------------------------------------------------------------------------
Follow your heart. You are miracle!
From: Adrian Otto <adrian.otto at rackspace.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: 06/13/2015 02:04 PM
Subject: Re: [openstack-dev] [Magnum] Discuss
configurable-coe-api-port Blueprint
Hongbin,
Good use case. I suggest that we add a parameter to magnum bay-create that
will allow the user to override the baymodel.apiserver_port attribute with
a new value that will end up in the bay.api_address attribute as part of
the URL. This approach assumes implementation of the magnum-api-address-url
blueprint. This way we solve for the use case, and don't need a new
attribute on the bay resource that requires users to concatenate multiple
attribute values in order to get a native client tool working.
Adrian
On Jun 12, 2015, at 6:32 PM, Hongbin Lu <hongbin.lu at huawei.com> wrote:
A use case could be the cloud is behind a proxy and the API port is
filtered. In this case, users have to start the service in an
alternative port.
Best regards,
Hongbin
From: Adrian Otto [mailto:adrian.otto at rackspace.com]
Sent: June-12-15 2:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Discuss
configurable-coe-api-port Blueprint
Thanks for raising this for discussion. Although I do think that the
API port humber should be expressed in a URL that the local client
can immediately use for connecting a native client to the API, I am
not convinced that this needs to be a separate attribute on the Bay
resource.
In general, I think it’s a reasonable assumption that nova instances
will have unique IP addresses assigned to them (public or private is
not an issue here) so unique port numbers for running the API
services on alternate ports seems like it may not be needed. I’d like
to have input from at least one Magnum user explaining an actual use
case for this feature before accepting this blueprint.
One possible workaround for this would be to instruct those who want
to run nonstandard ports to copy the heat template, and specify a new
heat template as an alternate when creating the BayModel, which can
implement the port number as a parameter. If we learn that this
happens a lot, we should revisit this as a feature in Magnum rather
than allowing it through an external workaround.
I’d like to have a generic feature that allows for arbitrary
key/value pairs for parameters and values to be passed to the heat
stack create call so that this, and other values can be passed in
using the standard magnum client and API without further
modification. I’m going to look to see if we have a BP for this, and
if not, I will make one.
Adrian
On Jun 11, 2015, at 6:05 PM, Kai Qiang Wu(Kennan) <
wkqwu at cn.ibm.com> wrote:
If I understand the bp correctly,
the apiserver_port is for public access or API call service
endpoint. If it is that case, user would use that info
htttp(s)://<ip>:<port>
so port is good information for users.
If we believe above assumption is right. Then
1) Some user not needed to change port, since the heat have
default hard code port in that
2) If some users want to change port, (through heat, we can do
that) We need add such flexibility for users.
That's bp
https://blueprints.launchpad.net/magnum/+spec/configurable-coe-api-port
try to solve.
It depends on how end-users use with magnum.
Welcome to more inputs about this, If many of us think it is
not necessary to customize the ports. we can drop the bp.
Thanks
Best Wishes,
--------------------------------------------------------------------------------
Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing
E-mail: wkqwu at cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software
Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing
P.R.China 100193
--------------------------------------------------------------------------------
Follow your heart. You are miracle!
<graycol.gif>Jay Lau ---06/11/2015 01:17:42 PM---I think that
we have a similar bp before:
https://blueprints.launchpad.net/magnum/+spec/override-nat
From: Jay Lau <jay.lau.513 at gmail.com>
To: "OpenStack Development Mailing List (not for usage
questions)" <openstack-dev at lists.openstack.org>
Date: 06/11/2015 01:17 PM
Subject: Re: [openstack-dev] [Magnum] Discuss
configurable-coe-api-port Blueprint
I think that we have a similar bp before:
https://blueprints.launchpad.net/magnum/+spec/override-native-rest-port
I have some discussion before with Larsks, it seems that it
does not make much sense to customize this port as the
kubernetes/swarm/mesos cluster will be created by heat and end
user do not need to care the ports,different
kubernetes/swarm/mesos cluster will have different IP addresses
so there will be no port conflict.
2015-06-11 9:35 GMT+08:00 Kai Qiang Wu <wkqwu at cn.ibm.com>:
I’m moving this whiteboard to the ML so we can have some
discussion to refine it, and then go back and update the
whiteboard.
Source:
https://blueprints.launchpad.net/magnum/+spec/configurable-coe-api-port
@Sdake and I have some discussion now, but may need more
input from your side.
1. keep apserver_port in baymodel, it may only allow
admin to have (if we involved policy) create that
baymodel, have less flexiblity for other users.
2. apiserver_port was designed in baymodel, if moved from
baymodel to bay, it is big change, and if we have other
better ways. (it also may apply for
other configuration fileds, like dns-nameserver etc.)
Thanks
Best Wishes,
--------------------------------------------------------------------------------
Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing
E-mail: wkqwu at cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun
Software Park,
No.8 Dong Bei Wang West Road, Haidian District
Beijing P.R.China 100193
--------------------------------------------------------------------------------
Follow your heart. You are miracle!
__________________________________________________________________________
OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Jay Lau (Guangya Liu)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150616/21c69034/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150616/21c69034/attachment.gif>
More information about the OpenStack-dev
mailing list
