Uploaded image for project: 'jclouds'
  1. jclouds
  2. JCLOUDS-1205

Setting a custom pool name with floatingIpPoolNames() in NovaTemplateOptions seems to have no effect

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not A Bug
    • Affects Version/s: 2.0.0
    • Fix Version/s: None
    • Component/s: jclouds-compute
    • Labels:
    • Environment:
      CentOS 6.8, OpenJDK 1.8.0.111-0.b15.el6_8

      Description

      I'm trying to spawn an instance in the FUGA cloud (https://fuga.io/) with jclouds 2.0 and auto-associate a floating IP but this fails with:

      JavaException: org.jclouds.rest.ResourceNotFoundException: {"itemNotFound": {"message": "Floating IP pool not found.", "code": 404}}

      FUGA has a custom namespace for the FloatingIP extension and it uses a custom name for the Floating IP Pool. Because of the former, I already ran into https://issues.apache.org/jira/browse/JCLOUDS-1013 and had to update to jclouds 2.0. With jclouds 2.0 this issue is solved and jclouds now finds the Floating IP extension but now the problem seems to be that jclouds does not use the right pool (with FUGA's custom pool name "external").

      I'm using the generic compute service and my code to spawn a new instance looks somewhat like this:

          ComputeService compute = this.contextBuilder.buildView(ComputeServiceContext.class).getComputeService();
      
          try {
              TemplateBuilder templateBuilder = compute.templateBuilder();
              Template template = templateBuilder
                                                  .locationId(region)
                                                  .imageId(imageId)
                                                  .hardwareId(instanceType)
                                                  .build();
              template.getOptions().as(NovaTemplateOptions.class).autoAssignFloatingIp(true);
              template.getOptions().as(NovaTemplateOptions.class).floatingIpPoolNames("external");
              template.getOptions().as(NovaTemplateOptions.class).userData(userData.getBytes());
      
              NodeMetadata node = getOnlyElement(compute.createNodesInGroup(groupName, 1, template));
              return node;
      
          } catch (RunNodesException e) {
              System.err.println("error adding node to group " + groupName + ": " + e.getMessage());
              return null;
          }
      

      So I'm using the "floatingIpPoolNames" method in NovaTemplateOptions to specify FUGA's custom floating IP pool name "external". But still, trying to create an instance fails with the aforementioned exception:

      JavaException: org.jclouds.rest.ResourceNotFoundException: {"itemNotFound": {"message": "Floating IP pool not found.", "code": 404}}

      I believe the way I'm setting the custom pool name property via "floatingIpPoolNames" in NovaTemplateOptions must be basically correct. At least the "userData" I also set on NovaTemplateOptions just one line later is picked up correctly (verified when "autoAssignFloatingIp" is set to false, because then the instance is started successfully - just without a public IP, obviously).

      I can successfully allocate and associate floating IPs to instances in the FUGA cloud when using horizon. And also with nova client I can successfully interact with the FUGA API to list the Floating IP Pools and to create/delete floating IPs:

      [xvid@devweb02 java]$ nova floating-ip-pool-list
      WARNING: Command floating-ip-pool-list is deprecated and will be removed after Nova 15.0.0 is released. Use python-neutronclient or python-openstackclient instead.
      ----------

      name

      ----------

      external

      ----------
      [xvid@devweb02 java]$ nova floating-ip-create external
      WARNING: Command floating-ip-create is deprecated and will be removed after Nova 15.0.0 is released. Use python-neutronclient or python-openstackclient instead.
      -----------------------------------------------------------------------------

      Id IP Server Id Fixed IP Pool

      -----------------------------------------------------------------------------

      5a4a318e-1672-425d-9522-d900e34efa98 185.54.114.154
      external

      -----------------------------------------------------------------------------
      [xvid@devweb02 java]$ nova floating-ip-list
      WARNING: Command floating-ip-list is deprecated and will be removed after Nova 15.0.0 is released. Use python-neutronclient or python-openstackclient instead.
      -----------------------------------------------------------------------------

      Id IP Server Id Fixed IP Pool

      -----------------------------------------------------------------------------

      5a4a318e-1672-425d-9522-d900e34efa98 185.54.114.154
      external

      -----------------------------------------------------------------------------

      So I believe there's no issue with FUGA. I tried my jclouds code also with another public cloud (Cloudwatt) that uses the default name ("public") for the floating IP pool and my code runs successfully there and brings up an instance with auto-associated public IP from the pool.

      What I then also tried is to intentionally set "floatingIpPoolNames" to a bogus name and then my code still worked in the Cloudwatt cloud! So this indicates to me that whatever is set on "floatingIpPoolNames" seems to be ignored internally and jclouds is just always trying to allocate from the default pool name (and therefore with Cloudwatt, where the pool name is the default "public", it always works no matter what is specified as "floatingIpPoolNames" while with the FUGA cloud it never works).

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mmilitzer Michael Militzer
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: