Learn about OSB and contribute to `kustomize` and `k9s` packages to add ARM arch
a project by dpock
Updated about 1 year ago. 1 hackers ♥️. 1 follower.

Description

There are already k9s and kustomize packages that exist for openSUSE today. These could be used as the source for these binaries in our rancher projects. By using them we would benefit from CVE fixes included in our distribution of the packages not in cluded upstream. However they are not providing arm package builds which are required.

Goals

  • [ ] Update the kustomize package in OBS to use the newest version and send change request

Resources

  • k9s: https://build.opensuse.org/package/show/openSUSE:Factory/k9s
  • kustomize: https://build.opensuse.org/package/show/openSUSE:Factory/kustomize
  • Learning Docs: https://confluence.suse.com/display/packaging/Training%2C+Talks+and+Videos

Join this project

Looking for hackers with the skills:

obs

This project is part of:

Hack Week 24

Activity

  • about 1 year ago: dpock started this project.
  • about 1 year ago: hennevogel added keyword "obs" to this project.
  • about 1 year ago: hennevogel liked this project.
  • about 1 year ago: dpock originated this project.


    • Comments

    • dpock
      about 1 year ago by dpock | Reply

      The first thing I've learned about OBS revolves around the way packages are maintained and delivered. And unfortunately, that lesson largely causes the rest of the "exciting" parts of this hack week project to fizzle away.

      I assumed that because I couldn't do: zypper in k9s On the BCI images that this would work for all architectures after adding the right repo. This may still be partially possible, however the architecture for packages may cause the source to vary.

      For instance the k9s package for ARM on factor can be found here: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/k9s

    • dpock
      about 1 year ago by dpock | Reply

      In my testing to learn OBS, I enabled my project to have ARM published on 15.6 and 15.7. Then enabled the repo to build for those and it gave me the desired results: https://build.opensuse.org/package/show/home:dpock:branches:devel:kubic/k9s

      However, even this isn't strictly necessary as I once suspected. Since ARM builds/packages exist in a dedicated repo. So for the intent of my downstream project, we just add both repos into the image. The ARM ones will be used on arm and ignored on non-arm.

    • dpock
      about 1 year ago by dpock | Reply

      Ultimately it seems like the k9s package -which was the biggest concern- is ready to use. No notes needed to shift over to use that in our image. However, kustomize binary is very old so needs to be updated.

    • dpock
      about 1 year ago by dpock | Reply

      I've created an initial PR to switch k9s to this source for shell: https://github.com/rancher/shell/pull/294

    • dpock
      about 1 year ago by dpock | Reply

      I must admit - this project is a bit of a bust at this point.

      In hindsight, it was created with a clear assumption that "SLES is missing these packages due to missing repo sources". From my previous comments it should be fairly clear that this assumption was incorrect. There are multiple community-maintained packages that can be sourced for the development package, which in turn can feed into the repo which could be used in SLES (and there by BCI images).

      That said, the difficulties I found accessing these binaries via BCL images are more reflective of openSUSE/SLES packaging practices. To solve for that may still be possible, however it's not going to be a technical focused solution as I assumed I could attempt here.

    Similar Projects

    Try out Neovim Plugins supporting AI Providers by enavarro_suse

    Description

    Experiment with several Neovim plugins that integrate AI model providers such as Gemini and Ollama.

    Goals

    Evaluate how these plugins enhance the development workflow, how they differ in capabilities, and how smoothly they integrate into Neovim for day-to-day coding tasks.

    Resources

    Create a page with all devel:languages:perl packages and their versions by tinita

    Description

    Perl projects now live in git: https://src.opensuse.org/perl

    It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.

    I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta

    But I never had the time to automate this.

    I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).

    Goals

    • Have a script that updates a central repository (e.g. https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run)
    • Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)

    Resources

    Results

    Day 1

    Day 2

    • HTML Page has now links to src.opensuse.org and the date of the last update, plus a short info at the top
    • Code is now 100% covered by tests: https://app.codecov.io/gh/perlpunk/opensuse-devel-languages-perl-meta
    • I used the modern perl class feature, which makes perl classes even nicer and shorter. See example
    • Tests
      • I tried out the mocking feature of the modern Test2::V0 library which provides call tracking. See example
      • I tried out comparing data structures with the new Test2::V0 library. It let's you compare parts of the structure with the like function, which only compares the date that is mentioned in the expected data. example

    Day 3

    • Added various things to the table
      • Dependencies column
      • Show popup with info for cpanspec, patches and dependencies
      • Added last date / commit to the data export.

    Plan: With the added date / commit we can now daily check _ObsPrj for changes and only fetch the data for changed packages.

    Day 4

    I started to implement the update functionality. Now it would be nice to do that in a daily workflow.

    Switch software-o-o to parse repomd data by hennevogel

    Run non-stop in escape road, avoid dangerous traps and test your speed to win spectacularly.

    Improvements to osc (especially with regards to the Git workflow) by mcepl

    Description

    There is plenty of hacking on osc, where we could spent some fun time. I would like to see a solution for https://github.com/openSUSE/osc/issues/2006 (which is sufficiently non-serious, that it could be part of HackWeek project).

    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt (including bootstrapping with bootstrap script) and Salt-ssh clients

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    In progress/done for Hack Week 25

    Guide

    We started writin a Guide: Adding a new client GNU Linux distribution to Uyuni at https://github.com/uyuni-project/uyuni/wiki/Guide:-Adding-a-new-client-GNU-Linux-distribution-to-Uyuni, to make things easier for everyone, specially those not too familiar wht Uyuni or not technical.

    openSUSE Leap 16.0

    The distribution will all love!

    https://en.opensuse.org/openSUSE:Roadmap#DRAFTScheduleforLeap16.0

    Curent Status We started last year, it's complete now for Hack Week 25! :-D

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file) NOTE: Done, client tools for SLMicro6 are using as those for SLE16.0/openSUSE Leap 16.0 are not available yet
    • [W] Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    • [W] Package management (install, remove, update...). Works, even reboot requirement detection