CRD status subresource is not recognised by meta-controller

[bsctl]

Hello, it looks like the CRD status subresource is not recognised by meta-controller if we struct it. For example, we created following CRD for "websites"

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  # name must match the spec fields below, and be in the form: <plural>.<group>
  name: websites.example.com
spec:
  scope: Namespaced
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
  names:
    kind: Website
    singular: website
    plural: websites
    shortNames:
    - ws
  subresources:
    status:
      current: 0
      updated: 0
      available: 0
      generation: 0
      route:        
    scale:
      specReplicasPath: .spec.replicas
      statusReplicasPath: .status.replicas
...

and this composite controller

apiVersion: metacontroller.k8s.io/v1alpha1
kind: CompositeController
metadata:
  name: website-controller
spec:
  generateSelector: true
  #resyncPeriodSeconds: 10
  parentResource:
    apiVersion: noverit.com/v1
    resource: websites
  childResources:
  - apiVersion: apps/v1
    resource: deployments
    updateStrategy:
      method: InPlace
  - apiVersion: v1
    resource: services
    updateStrategy:
      method: Recreate
  - apiVersion: extensions/v1beta1
    resource: ingresses
    updateStrategy:
      method: Recreate
  hooks:
    sync:
      webhook:
        url: http://192.168.1.103:8060/website

From the meta-controller log, we cannot see the status of parent in the webhook request.

On the other end, it works if we simply leave the status as following in the CRD

...
  subresources:
    status:      
    scale:
      specReplicasPath: .spec.replicas
      statusReplicasPath: .status.replicas
...

Could you please have a look in the code?

Thanks,

Adriano

[enisoc]

Metacontroller doesn't yet support the CRD subresource feature, since it was only alpha and disabled by default as of k8s 1.10. We do plan to support it though. You can follow issue #26 to track it.

[bsctl]

@enisoc That's great. We can close #84 in favour of #26.
Thanks for sharing this awesome project!