Thanks Adrian. Sounds good. Best regards, Hongbin
From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: June-13-15 2:00 AM To: OpenStack Development Mailing List (not for usage questions) 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...@huawei.com<mailto:hongbin...@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.o...@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) <wk...@cn.ibm.com<mailto:wk...@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: wk...@cn.ibm.com<mailto:wk...@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....@gmail.com<mailto:jay.lau....@gmail.com>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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 <wk...@cn.ibm.com<mailto:wk...@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: wk...@cn.ibm.com<mailto:wk...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
