search

Telecominfraproject / ols-ucentral-schema

OpenLAN/Shasta contribution repo
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

[OLS-390] Move uplink_interface definition to state.yml, add version … #26

Closed mikehansen1970 closed 2 weeks ago

mikehansen1970 commented 2 weeks ago

The attribute uplink_interface should be under state/state.yml instead of state/interface.ipv4.yml. This is already being reported in this manner by the Asterfusion and EdgeCore switches Add uplink_interface to state/state.yml

  uplink_interface:
    type: string
    description:
      Current interface that serves as the Uplink. Example Ethernet2.

Schema version should be tracked in the ols-ucentral-schema repo so that it can be reported when the device connects:

Add schema.json to ols-ucentral-client, aligns with wlan-ucentral-schema

{
    "major": 3,
    "minor": 2,
    "patch": 0
}

capabilities/connect.capabilities.yml, matches the schema.json file definition

  version:
    type: object
    description:
      The ols schema version to be used with this Switch
    properties:
      major:
        type: integer
      minor:
        type: integer
      patch:
        type: integer
Cahb commented 2 weeks ago

Hey Mike; Is there a guideline for bumping version? Generic MAJOR / MIN / PATCH version bumping rule of thumb in SW is essentially: Major breaks all compatibility; Min slightly changes API (added params for example) Patch should be fully compatible, and mostly fixes something non-compat-breaking;

The question is do we change this versioning on every change? How do we deduce what version num would be changed?

Also, just out of curiosity: how this versioning is even used in the AP-world? I remember you said how it's being generated, that it makes it into the connect message and stuff; But what's the actual use of it? Does the GW check this in any way or something like that?

P.S. changes are fine by me, +1;

mikehansen1970 commented 2 weeks ago

Hi Oleksandr,

This is a very good question. In this case, we are not really doing strict ‘semantic’ versioning, in fact this ‘version’ is to my understanding just reflecting the OLS/Tip version that the schema is compatible with. During the development stages of a release, we should leave the version as is, because that is the release that is being worked on. Any changes being made are applied to that version, and it doesn’t need to be updated because it is not released yet. i.e. the 3.2.0 aligns to OLS 3.2.0.

I recommend, upon ‘release’ milestone being achieved, we should make a release branch, i.e. release-3.2.0 or something to that effect. If we had to patch something in the release, and it required schema changes, then a branch release-3.2.x would be created with those changes.

When 3.2.0 is released and it’s release branch is created, then we move the version on main to align with the next OLS/TIP version this schema would be for, i.e. 4.0.0. While this is in development, that version would not change.

Example in practice ols-ucentral-schema version is 3.2.0 on branch main, we are still producing dev images, version does not change for submissions to main upon release availability (i.e. 3.2.0 is ‘done’) create a branch, release-3.2,

Please let me know if this makes sense?

The version is actually the OLS version, the version in the schema reflects what OLS version this schema is for.

Thanks, Mike

On 2024-10-05, 6:17 AM, "Olexandr, Mazur" @.***> wrote:

Hey Mike; Is there a guideline for bumping version? Generic MAJOR / MIN / PATCH version bumping rule of thumb in SW is essentially: Major breaks all compatibility; Min slightly changes API (added params for example) Patch should be fully compatible, and mostly fixes something non-compat-breaking;

The question is do we change this versioning on every change? How do we deduce what version num would be changed?

Also, just out of curiosity: how this versioning is even used in the AP-world? I remember you said how it's being generated, that it makes it into the connect message and stuff; But what's the actual use of it? Does the GW check this in any way or something like that?

P.S. changes are fine by me, +1;

— Reply to this email directly, view it on GitHubhttps://github.com/Telecominfraproject/ols-ucentral-schema/pull/26#issuecomment-2395008004, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APDDQCHKCH75K3TBAHQFVYTZZ64EXAVCNFSM6AAAAABPMFSIGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGAYDQMBQGQ. You are receiving this because you authored the thread.Message ID: @.***>

Cahb commented 2 weeks ago

@mikehansen1970 totally makes sense; Just wanted to make sure i understand the use of this; Thanks!