On 30 March 2016 at 13:40, Sean Dague <[email protected]> wrote: > On 03/29/2016 09:55 PM, Matt Riedemann wrote: > <snip> > > > > Yup, HenryG walked me through the cases on IRC today. > > > > The more I think about option (b) above, the less I like that idea given > > how much work goes into the allocate_for_instance code in nova where > > it's already building the list of possible networks that will be used > > for creating/updating ports, we'd essentially have to duplicate that > > logic in a separate method to get an idea of what security groups would > > be applied. > > > > I'd prefer to be lazy and go with option (a) and just say nova doesn't > > return security-groups in the REST API when creating a server and > > neutron is the network API. That would require a microversion probably, > > but it would still be easy to do. I'm not sure if that's the best user > > experience though. > > > > Is there a sane resource on the neutron side we could link to? Today > security_groups are returned with a name from nova, which made sense > when it was an internal structure, but makes way less sense now. > > "security_groups": [ > { > "href": "....", > } > ] > > Where the link is to a neutron resource (and we could do a local link > for the few nova net folks) might be more appropriate. >
Not that I could think of, though the extra level of indirection to solve this issue is kind of a neat idea. > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
