You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Ignasi Barrera (JIRA)" <ji...@apache.org> on 2015/09/28 15:41:04 UTC
[jira] [Comment Edited] (JCLOUDS-1003) IpProtocol.ANY does not work
on OpenStack
[ https://issues.apache.org/jira/browse/JCLOUDS-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933298#comment-14933298 ]
Ignasi Barrera edited comment on JCLOUDS-1003 at 9/28/15 1:40 PM:
------------------------------------------------------------------
Using Neutron from Nova is not as straightforward as it should be, as both are separate APIs.
It could make sense to be able to build the Neutron api from the Nova context, but it is not that trivial. Every API has their own set of modules it needs to run: custom bindings, custom drivers (some APis require a specific http driver, etc). Creating one context that has a mixture of the modules required by N APIs to make it possible to build and use them all together is not something that can be done easily, but definitely something to consider to improve the list of "linked services" of the provider metadata, which is currently just a list of strings IIRC.
I'd suggest to think about an approach that allows us to inject a Supplier<NeutronApi> or similar, so the Nova APi can test its presence. Something like "the user creates the context providing a NeutronSupplierModule that provides a previously built Neutron API.
It is just an idea and a first thought. It would be interesting to come up with a solution to effectively build the APi that consumes a linked service from the current context. Something to bring to the dev@ mailing list?
was (Author: nacx):
Using Neutron from Nova is not as straightforward as it should be, as both are separate APIs.
It could make sense to be able to build the Neutron api from the Nova context, but it is not that trivial. Every API has their own set of modules it needs to run: custom bindings, custom drivers (some APis require a specific http driver, etc). Creating one context that has a mixture of the modules required by N APIs to make it possible to build and use them all together is not something that can be done easily, but definitely something to consider to improve the list of "linked services" of the provider metadata, which is currently just a list of strings IIRC.
I'd suggest to think about an approach that allows us to inject a Supplier<NeutronApi> or similar, so the Nova APi can test its presence. Something like "the user creates the context providing a NeutronSupplierModule" that provides a previously built Neutron API.
It is just an idea and a first thought. It would be interesting to come up with a solution to effectively build the APi that consumes a linked service from the current context. Something to bring to the dev@ mailing list?
> IpProtocol.ANY does not work on OpenStack
> -----------------------------------------
>
> Key: JCLOUDS-1003
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1003
> Project: jclouds
> Issue Type: Bug
> Environment: OpenStack Nova on BlueBox Cloud
> Reporter: Andrew Kennedy
>
> Trying to add IpPermissions.permitAnyProtocol() or any IpPermission using IpProtocol.ANY fails with the following error:
> 2015-09-21 07:03:57,972 DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService [brooklyn-execmanager-L0pLKIH7-132]: Sending request 193768812: POST https://cloudsoft-sjc.openstack.blueboxgrid.com:8777/v2/bba97b44a7dd40b1ad8a0b90510129f7/os-security-group-rules HTTP/1.1
> 2015-09-21 07:03:57,972 DEBUG jclouds.wire [brooklyn-execmanager-L0pLKIH7-132]: >> "{"security_group_rule":{"parent_group_id":"1d958f15-aeef-4ee8-a527-71f7fcae9864","cidr":"0.0.0.0/0","ip_protocol":"-1","from_port":"1","to_port":"65535"}}"
> 2015-09-21 07:03:58,793 DEBUG jclouds.wire [brooklyn-execmanager-L0pLKIH7-132]: << "{"badRequest": {"message": "Invalid IP protocol -1.", "code": 400}}"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)