openstack-resource-controller icon indicating copy to clipboard operation
openstack-resource-controller copied to clipboard

Update on allocationPools in subnet doesn't update the actual resource in openstack.

Open anpolychrono opened this issue 10 months ago • 3 comments

I have created a subnet with success:

apiVersion: openstack.k-orc.cloud/v1alpha1
kind: Subnet
metadata:
  annotations:
    argocd.argoproj.io/tracking-id: 'data-subnet:openstack.k-orc.cloud/Subnet:orc/data-subnet'
  creationTimestamp: '2025-02-24T20:04:54Z'
  finalizers:
    - openstack.k-orc.cloud/subnet
  generation: 2
  name: data-subnet
  namespace: orc
  resourceVersion: '4068444'
  uid: a16fd15c-d114-44b7-9379-d90d4c485dac
spec:
  cloudCredentialsRef:
    cloudName: openstack
    secretName: staging
  managementPolicy: managed
  networkRef: data-network
  resource:
    allocationPools:
      - end: 192.168.1.20
        start: 192.168.1.1
    cidr: 192.168.1.0/24
    description: This subnet will be used for data plan traffic
    gateway:
      type: None
    ipVersion: 4
    tags:
      - gettingstarted
status:
  conditions:
    - lastTransitionTime: '2025-02-24T20:04:54Z'
      message: OpenStack resource is available
      observedGeneration: 2
      reason: Success
      status: 'True'
      type: Available
    - lastTransitionTime: '2025-02-24T20:04:54Z'
      message: OpenStack resource is up to date
      observedGeneration: 2
      reason: Success
      status: 'False'
      type: Progressing
  id: ba93ab08-4335-442c-9f85-c5cc6bb63edb
  resource:
    allocationPools:
      - end: 192.168.1.10
        start: 192.168.1.1
    cidr: 192.168.1.0/24
    description: This subnet will be used for data plan traffic
    dnsPublishFixedIP: false
    enableDHCP: true
    gatewayIP: ''
    ipVersion: 4
    ipv6AddressMode: ''
    ipv6RAMode: ''
    name: data-subnet
    projectID: d0062568026244e69e3400e511a59a9e
    revisionNumber: 1
    tags:
      - gettingstarted

but after updating the allocationPools end address , the update populates to the Subnet CR but the allocationPool in openstack subnet didn't change. You can see that in the above yaml when I changed the end address from 192.168.1.10 to 192.168.1.20 the update in the Subnet CR was made but the Subnet in Openstack didn't change:

Image

anpolychrono avatar Feb 24 '25 20:02 anpolychrono

This is a valid issue, but simply because mutability for Subnet isn't implemented yet. We haven't implemented much mutability at all yet, tbh, only really enough to get a good feel for the required coding patterns.

The usage you describe is correct, and exactly how we intend it to work. He hope it will work that way soon. To avoid confusion we should probably make the spec immutable until we have actually implemented mutability. That way at least you'll get an API error.

How can we communicate this better while we're still working on it? @mandre, you implemented the handy Supported Resources table in README. I wonder if we should expand further on what 'partially implemented' means. E.g. could we separate it into 'import', 'create', 'update', perhaps with linked footnotes? I might noodle an attempt at that while I'm already working on docs.

@anpolychrono if you would like to try adding mutability for this resource yourself we will gladly help you through the process. We are just getting to the stage where we think we're at a good point for others to come in and help, which is why I'm currently working on developer documentation.

mdbooth avatar Feb 25 '25 10:02 mdbooth

Thanks for the clear update @mdbooth , this period I do not have too much time to help but I would like to do so. I will let you know once I find a slot, till then I will use the project to create Openstack resources since I found it more k8s native than running terraform with a k8s tf-controller.

anpolychrono avatar Mar 01 '25 21:03 anpolychrono

This is confusing indeed, and I had the same reaction when I first tried ORC myself. Users will legitimately expect ORC to manage the full life cycle of the resources, including update.

IMO we should both add a prominent disclaimer in the README clarifying the development status of the project (let's be honest, the current version being 1.0 adds to the confusion), and make the specs immutable for each resource until it implements mutability.

Anyway, this issue is up for grab if you, or anyone else, is willing to give it a try.

mandre avatar Mar 02 '25 09:03 mandre