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.

Sign up for GitHub

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

Jump to bottom

repositories: fix keys and archs #548

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

repositories: fix keys and archs #548

wants to merge 2 commits into from

Conversation

SMillerDev
Copy link

PR progress checklist (to be filled in by reviewers)

  • Changes to documentation are appropriate (or tick if not required)
  • Changes to tests are appropriate (or tick if not required)
  • Reviews completed

What type of PR is this?

Primary type

  • [build] Changes related to the build system
  • [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
  • [ci] Changes to the continuous integration configuration
  • [feat] A new feature
  • [fix] A bug fix
  • [perf] A code change that improves performance
  • [refactor] A code change that neither fixes a bug nor adds a feature
  • [revert] A change used to revert a previous commit
  • [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

  • [docs] Documentation changes
  • [test] Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.

Related issues and/or pull requests

#545
#539

Describe the changes you're proposing

Move to onedir packages by default
Set the OS architecture in debian based repos

Pillar / config required to test the proposed changes

Debug log showing how the proposed changes work

Documentation checklist

  • Updated the README (e.g. Available states).
  • Updated pillar.example.

Testing checklist

  • Included in Kitchen (i.e. under state_top).
  • Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
  • Updated the relevant test pillar.

Additional context

@SMillerDev SMillerDev requested a review from a team as a code owner May 19, 2023 09:59
@lmf-mx
Copy link

lmf-mx commented Jun 12, 2023

@SMillerDev This does actually break existing deployments and should be noted.

That said, I don't think it's the wrong direction, but there's some things still amiss.

  • IMO, everything should go to onedir or better yet, default to it with a pillar override, before new versions that don't support the classic packages are released.
  • Specifically in the Ubuntu mapping, key_url points to a place that doesn't exist for 22.04, since it doesn't include the onedir "salt/" dir in the path.

@jeff350
Copy link

jeff350 commented Jun 14, 2023

@SMillerDev It was clarified in a salt issue that the -2023 on the key is the year the key was generated. So this PR should go to 2023 being hard coded instead of the jinja to get the current year.

saltstack/salt#64144 (comment)

@SMillerDev
Copy link
Author

Thanks for the heads up, I'll fix that.

SMillerDev
SMillerDev commented Jun 14, 2023
View reviewed changes
salt/osfamilymap.yaml Outdated Show resolved Hide resolved
salt/osfingermap.yaml Outdated Show resolved Hide resolved
salt/osmap.yaml Outdated Show resolved Hide resolved
salt/osmap.yaml Outdated Show resolved Hide resolved
salt/osmap.yaml Outdated Show resolved Hide resolved
jeff350
jeff350 requested changes Jun 16, 2023
View reviewed changes
Copy link

@jeff350 jeff350 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are a few more small changes to fix the urls of repos.

Could you please look at this and modify your commit messages to follow the format that will pass the commitlint in CI. you can see this here https://gitlab.com/saltstack-formulas/salt-formula/-/jobs/4471523712#L125

salt/osmap.yaml Show resolved Hide resolved
salt/osmap.yaml Show resolved Hide resolved
salt/osmap.yaml Show resolved Hide resolved
salt/osmap.yaml
pkgrepo: 'deb [signed-by=/usr/share/keyrings/salt-archive-keyring.gpg arch=amd64] {{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }} {{ oscodename }} main'
pkgrepo_keyring: '{{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }}/salt-archive-keyring.gpg'
pkgrepo: 'deb [signed-by=/usr/share/keyrings/SALT-PROJECT-GPG-PUBKEY-2023.gpg arch={{ repoarch }}] {{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/{{ repoarch }}/{{ salt_release }} {{ oscodename }} main'
pkgrepo_keyring: '{{ salt_repo }}/{% if oscodename == "jammy" %}salt/{% endif %}{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }}/SALT-PROJECT-GPG-PUBKEY-2023.gpg'
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this can be modified to support more versions. This would limit 3006 not being installed on 18.04 and 20.04. Would we want an if loop here based off of salt version being installed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep logic of oscodenames + salt versions, it adds a lot of uneeded temporary complexity because we need to apply this logic also for key naming.
I think that poeople relying on old repository can pin version of this formula to 1.x.x while waiting to update their salt ecosystem.
Proposed a PR here -> #561

salt/osmap.yaml Show resolved Hide resolved
@lmf-mx lmf-mx mentioned this pull request Jun 16, 2023
Closed
19 tasks
@lmf-mx
Copy link

lmf-mx commented Jun 21, 2023

I think there are a few more small changes to fix the urls of repos.

Could you please look at this and modify your commit messages to follow the format that will pass the commitlint in CI. you can see this here https://gitlab.com/saltstack-formulas/salt-formula/-/jobs/4471523712#L125

@SMillerDev Can you update the commit messages to pass the linter?

@SMillerDev
Copy link
Author

I will once I actually get it to work

@lmf-mx
Copy link

lmf-mx commented Jun 21, 2023

I will once I actually get it to work

If you mean the formula, I believe I've covered all the cases in the update based on your PR, #550
If you mean the messages, you can interactive rebase and force push, https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message

@lmf-mx lmf-mx mentioned this pull request Jul 26, 2023
Open
19 tasks
@techhat
Copy link
Member

techhat commented Sep 27, 2023

FYI, SALTSTACK-GPG-KEY.pub no longer exists in the repo, so without some of these changes I'm finding that the most recent release of this formula is now unusable in multiple OSs. @Ch3LL

@sticky-note sticky-note mentioned this pull request Feb 1, 2024
Open
19 tasks
sticky-note
sticky-note reviewed Feb 1, 2024
View reviewed changes
Copy link
Member

@sticky-note sticky-note left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please @jeff350, can you take a look here pls #561

salt/osmap.yaml Show resolved Hide resolved
salt/osmap.yaml Show resolved Hide resolved
salt/osmap.yaml Show resolved Hide resolved
salt/osmap.yaml
pkgrepo: 'deb [signed-by=/usr/share/keyrings/salt-archive-keyring.gpg arch=amd64] {{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }} {{ oscodename }} main'
pkgrepo_keyring: '{{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }}/salt-archive-keyring.gpg'
pkgrepo: 'deb [signed-by=/usr/share/keyrings/SALT-PROJECT-GPG-PUBKEY-2023.gpg arch={{ repoarch }}] {{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/{{ repoarch }}/{{ salt_release }} {{ oscodename }} main'
pkgrepo_keyring: '{{ salt_repo }}/{% if oscodename == "jammy" %}salt/{% endif %}{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }}/SALT-PROJECT-GPG-PUBKEY-2023.gpg'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep logic of oscodenames + salt versions, it adds a lot of uneeded temporary complexity because we need to apply this logic also for key naming.
I think that poeople relying on old repository can pin version of this formula to 1.x.x while waiting to update their salt ecosystem.
Proposed a PR here -> #561

salt/osmap.yaml Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sticky-note sticky-note sticky-note left review comments

@jeff350 jeff350 Awaiting requested review from jeff350

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@SMillerDev @lmf-mx @jeff350 @techhat @sticky-note