Thanks alot, actually they are using Heat with update network function, so I guess Heat has to do the work :)
On Thu, Jul 6, 2017 at 10:50 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On 07/06/2017 10:39 AM, Matt Riedemann wrote: > >> On 7/6/2017 6:39 AM, Gary Kotton wrote: >> >>> Hi, >>> >>> When you attach an interface there are a number of options: >>> >>> 1. Pass a existing port >>> >>> 2. Pass a network >>> >>> In the second case a new port will be created and by default that will >>> have the default security group. >>> >>> You could try the first option by attaching the security group to the >>> port >>> >>> Thanks >>> >>> Gary >>> >>> *From: *Zhenyu Zheng <zhengzhenyul...@gmail.com> >>> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org> >>> *Date: *Thursday, July 6, 2017 at 12:45 PM >>> *To: *OpenStack List <openstack-dev@lists.openstack.org> >>> *Subject: *[openstack-dev] [Nova][Neutron] Allow passing security groups >>> when attaching interfaces? >>> >>> Hi, >>> >>> Our product has meet this kind of problem, when we boot instances, we >>> are allowed to pass security groups, and if we provided network id, ports >>> with the sg we passed will be created and when we show instances, we can >>> see security groups field of instance is the sg we provided. But when we >>> attach again some new interfaces(using network_id), the newly added >>> interfaces will be in the default security group. >>> >>> We are wondering, will it be better to allow passing security groups >>> when attaching interfaces? or it is considered to be a proxy-api which we >>> do not like? >>> >> >> I don't think we want this, it's more proxy orchestration that would have >> to live in Nova. As Gary pointed out, if you want a non-default security >> group, create the port in neutron ahead of time, associate the non-default >> security group(s) and then attach that port to the server instance in nova. >> > > This +100. > > Best, > -jay > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
