Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract a .net6/.netstandard2.1 core library #362

Closed
buehler opened this issue Jan 14, 2022 · 1 comment
Closed

Extract a .net6/.netstandard2.1 core library #362

buehler opened this issue Jan 14, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@buehler
Copy link
Owner

buehler commented Jan 14, 2022

Some parts of KubeOps shall be extracted into a .netstandard2.0 "core library" such that other users of KubeObs may extend the core functionality. This is based on the discussion of #355.

@buehler buehler added the enhancement New feature or request label Jan 14, 2022
@buehler buehler changed the title Extract a .netstandard2.0 core library Extract a .net6 core library Jan 25, 2022
@buehler buehler changed the title Extract a .net6 core library Extract a .net6/.netstandard2.1 core library Jan 27, 2022
@jefflill
Copy link

jefflill commented May 31, 2022

Hi guys, glad to see you're still at it! I've been using your old 6.2.4 release but am looking forward to upgrading this week.

I see that this issue is still open and I wanted to mention that I implemented a pretty easy workaround that your users could try in them meantime if these changes require too much surgery. Perhaps you could address this issue with some documentation/guidance with the pattern described below (and then close this issue):

I just created two library projects to hold my resources, one called ResourceDefinitions and the other called Resources, where:

  • My ResourceDefinitions library project is .NET 6 and references the KubeOps packages and defines the CRDs via your attributes, etc.
  • My Resources library project is .NETStandard and it just references (shares) the resource source files from the ResourceDefinitions project.
  • The ResourceDefinitions project defines the KUBEOPS variable but the Resources project does not. I use conditional compilation to comment out the KubeOps attributes, etc. so the Resources project can build as .NETStandard and without referencing the KubeOps package.
  • My operators reference the ResourceDefinitions library and your CRD generators work just fine against that.
  • My client (non-operator apps) reference the .NETStandard Resources project and these resources can be managed just fine with KubernetesClient.

Here's an example of what one of my resource files look like:

using System;
using System.Collections.Generic;
using System.Text;

using k8s;
using k8s.Models;

#if KUBEOPS
using DotnetKubernetesClient.Entities;
using KubeOps.Operator.Entities;
using KubeOps.Operator.Entities.Annotations;
#endif

#if KUBEOPS
namespace Neon.Kube.ResourceDefinitions
#else
namespace Neon.Kube.Resources
#endif
{
#if KUBEOPS
    [KubernetesEntityShortNames]
    [EntityScope(EntityScope.Cluster)]
    [Description("Describes a neonKUBE cluster upstream container registry.")]
#endif
    public class V1ContainerRegistry : CustomKubernetesEntity<V1ContainerRegistry.V1ContainerRegistrySpec>
    {
        public V1ContainerRegistry()
        {
        }

        public class V1ContainerRegistrySpec
        {
            private const string prefixRegex = @"^(\*\.)?([a-zA-Z0-9-_]+\.)*([a-zA-Z0-9-_]+)(/[a-zA-Z0-9-\._~\[\]@\!&'\(\)\*+,;%=\$]+)*$";

#if KUBEOPS
            [Required]
            [Pattern(@"^(\*.)?" + prefixRegex)]
#endif
            public string Prefix { get; set; } = null;

            public int SearchOrder { get; set; } = -1;

            public bool Insecure { get; set; } = false;

            public bool Blocked { get; set; } = false;

#if KUBEOPS
            [Pattern(prefixRegex)]
#endif
            public string Location { get; set; } = null;

            public string Username { get; set; } = null;

            public string Password { get; set; } = null;
        }
    }
}

@buehler buehler closed this as completed Oct 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants