Create Standardized Local Development En...

https://github.com/ublue-os/main/issues/378

GitHub

Create Standardized Local Development Environment · Issue #378 · ub...

I was talking with Jorge in the discord and getting a standardized local development environment set up would make it much easier to onboard folks. The biggest hurdle I found working with this proj...

41 Replies

bsherman•9mo ago

I made some comments, but happy have a more in depth chat here if interested.

Noel•9mo ago

Yeah, the thought here is an easy way for folks to get a custom built version of ublue built on a VM in an approachable way. Like, you still build the container and push to a registry, but you can make your changes and iterate quickly.

bsherman•9mo ago

do you envision more than an easy to install local registry?

Noel•9mo ago

My thought is to have it spin up a whole VM that is configured and set up for you to test changes against. I'm not sure if I'm not explaining my thought process behind this well or if this is truly an esoteric thing I am wanting to do.

bsherman•9mo ago

Ohhhh! I think i see now... 1) ansible spins up a local registry (in VM or in container?) 2) ansible spins up a VM and auto-rebases to your custom image? or just makes it available for rebasing?

Noel•9mo ago

Right, ansible spins up a local registry container, then ansible spins up a VM and auto rebases to the custom image! I've got it partially working already minus the ansible. I'm running into some pretty weird issues with trying to rebase off of coreos. Ideally it would be: 1. Fork the git repo 2. Have ansible build the container, create the registry, push the container, and then create the VM. 3. The VM rebases off your local registry.

bsherman•9mo ago

I do think it's quirky to rebase from CoreOS... yes it works... and probably is fine for most things, but probably at the least you'll want to disable zincati in your ignition file... i'm not sure if there many other concerns with it... mostly just the CoreOS is not installed like a desktop... so... it's going to be different, XFS by default, ignition services, etc... I appreciate you being patient with me trying to understand your vision. 🙂

Noel•9mo ago

I appreciate you wanting to understand my vision in the first place, so no worries here! 😄

bsherman•9mo ago

I will say, I'm still missing how this is a "standardized development environment" but i may just be a bit to pedantic in general. I do see it as an "image testing accelerator" 😄

Noel•9mo ago

lol I'm open to calling it whatever we want 😄 that is probably a more accurate term for it.

bsherman•9mo ago

when i first read the title, I was epxecting like a VScode install with templated configs or something 😄

Noel•9mo ago

I'm not a developer. I'm a SysAdmin, so I probably say things that sound weird to traditional devs 😄

bsherman•9mo ago

i'm both 🙂

Noel•9mo ago

So you're the mythical DevOps that everyone has been talking about 😉

bsherman•9mo ago

and i was both before "devops" was a thing pretty much

Noel•9mo ago

Yeah, if we want to call it an "Image Testing Accelerator", I'm open to that. It's mostly I want to see what is happening in the GUI when I make a change. Or if there is something user facing, it would be nice to test that quickly.

bsherman•9mo ago

yeah, i see what you mean, you are talking about a faster feedback loop on changes and how they actually look

Noel•9mo ago

yes. And ultimately getting a VM set up more quickly.

bsherman•9mo ago

Well, there's always going to be room for questions and interpretation, but I'll tell you one thing I've learned on this Ublue project, especially seems true since it's my first significant open source contribution... If you care enough to build it for yourself, do it, and show it off... and if you can demonstrate it, you'll get more interest and feedback. If you only want to do it based ON others feedback, probably not the right motivations. 😉 so, i say, build it, make it useful for you, keep in mind you want to share with others (eg, don't hardcode your username, etc 😉 ) and then it's a success no matter what

Noel•9mo ago

Yeah, for sure! I'm learning things about ignition files through this process which is nice as well. I've wanted to dig more into CoreOS. so far it's working in a very manual way, but I ran into a quirky thing with rebasing on the coreos image. I'm wondering if it has to do with zincatti doing something.

bsherman•9mo ago

zincati tries to update pretty quick after a first boot, so that can block other rpm-ostree operations, like a rebase

Noel•9mo ago

This is what my butane file looks like:

variant: fcos
version: 1.5.0
passwd:
  users: 
    - name: developer
      password_hash: $6$g6iNSNOOBxq13RXx$6rNDyi9NUyfbGIn4GFTi.fcBrtYVOKSu/qLHMlLKilbTe95JK8KVs5TnSUsOSW0cFQjwEZp/eWUUG/rmXS9mk.
      ssh_authorized_keys: ['ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDB5OeiBUihcLAmfrRsaJMT/vfJVJ2uEf2mtxlWK8KTvfapNJhP973NSL7xInvu7L8/K5HimTZZs0mrZvcPQVD/Jo5p7091LvmZl29S63TO/RGT+xgH2+BurZsDE5BumZUB3iO7De7e2wMc9VEQjXcIIJ66JEjNSDuw4F7wSIifm8nhIU2WSJOYSQzs0A5SGwJ6xo9aIWvB0IChLNZSTiRAYp9VAnucGB5NPxpiPuDUsA/gW8lyo6rq6CWTisaId2E7gcVsSIXIISg4LPXIV792jo7ckUj6OqMUZz+NkvcYa7yuRXyIlSTrBTWGgBrZSrYT1cofY3BOVHuhtx06GetqRjtsUCCW/ju4VuuOAt91CHt8jsHXCdjF72UyrSB9dYX9C2yUVwQ0Tw5rSc5C6yF26Yxi3sZW95u5Hb0WDztjxuSSg+2tK08CynYgfDYasIz/yoWoxRQEr4ErvxeZWM3Me1rGSjW7p5ptu/pug4qjp4N15qY86TqiSHdR7LGio0k= noel@desktop.henrymillerfrazier.lan']
      groups:
        - wheel
      shell: /bin/bash

storage:
  files:
    - path: /etc/containers/registries.conf.d/local.conf
      contents:
        local: local.conf

systemd:
  units:
    # Installing qemu-guest-agent as a layered package with rpm-ostree
    - name: rpm-ostree-rebase.service
      enabled: true
      contents: |
        [Unit]
        Description=Rebase with rpm-ostree
        Wants=network-online.target
        After=network-online.target
        # We run before `zincati.service` to avoid conflicting rpm-ostree
        # transactions.
        Before=zincati.service
        ConditionPathExists=!/var/lib/%N.stamp

        [Service]
        Type=oneshot
        RemainAfterExit=yes
        # `--allow-inactive` ensures that rpm-ostree does not return an error
        # if the package is already installed. This is useful if the package is
        # added to the root image in a future Fedora CoreOS release as it will
        # prevent the service from failing
        ExecStart=/usr/bin/rpm-ostree rebase --reboot ostree-unverified-registry:10.42.0.2:5000/bazzite:latest

        ExecStart=/bin/touch /var/lib/%N.stamp

        [Install]
        WantedBy=multi-user.target

variant: fcos
version: 1.5.0
passwd:
  users: 
    - name: developer
      password_hash: $6$g6iNSNOOBxq13RXx$6rNDyi9NUyfbGIn4GFTi.fcBrtYVOKSu/qLHMlLKilbTe95JK8KVs5TnSUsOSW0cFQjwEZp/eWUUG/rmXS9mk.
      ssh_authorized_keys: ['ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDB5OeiBUihcLAmfrRsaJMT/vfJVJ2uEf2mtxlWK8KTvfapNJhP973NSL7xInvu7L8/K5HimTZZs0mrZvcPQVD/Jo5p7091LvmZl29S63TO/RGT+xgH2+BurZsDE5BumZUB3iO7De7e2wMc9VEQjXcIIJ66JEjNSDuw4F7wSIifm8nhIU2WSJOYSQzs0A5SGwJ6xo9aIWvB0IChLNZSTiRAYp9VAnucGB5NPxpiPuDUsA/gW8lyo6rq6CWTisaId2E7gcVsSIXIISg4LPXIV792jo7ckUj6OqMUZz+NkvcYa7yuRXyIlSTrBTWGgBrZSrYT1cofY3BOVHuhtx06GetqRjtsUCCW/ju4VuuOAt91CHt8jsHXCdjF72UyrSB9dYX9C2yUVwQ0Tw5rSc5C6yF26Yxi3sZW95u5Hb0WDztjxuSSg+2tK08CynYgfDYasIz/yoWoxRQEr4ErvxeZWM3Me1rGSjW7p5ptu/pug4qjp4N15qY86TqiSHdR7LGio0k= noel@desktop.henrymillerfrazier.lan']
      groups:
        - wheel
      shell: /bin/bash

storage:
  files:
    - path: /etc/containers/registries.conf.d/local.conf
      contents:
        local: local.conf

systemd:
  units:
    # Installing qemu-guest-agent as a layered package with rpm-ostree
    - name: rpm-ostree-rebase.service
      enabled: true
      contents: |
        [Unit]
        Description=Rebase with rpm-ostree
        Wants=network-online.target
        After=network-online.target
        # We run before `zincati.service` to avoid conflicting rpm-ostree
        # transactions.
        Before=zincati.service
        ConditionPathExists=!/var/lib/%N.stamp

        [Service]
        Type=oneshot
        RemainAfterExit=yes
        # `--allow-inactive` ensures that rpm-ostree does not return an error
        # if the package is already installed. This is useful if the package is
        # added to the root image in a future Fedora CoreOS release as it will
        # prevent the service from failing
        ExecStart=/usr/bin/rpm-ostree rebase --reboot ostree-unverified-registry:10.42.0.2:5000/bazzite:latest

        ExecStart=/bin/touch /var/lib/%N.stamp

        [Install]
        WantedBy=multi-user.target

I'm wondering if my oneshot service doesn't execute quickly enough

bsherman•9mo ago

🙂 have you seen this: https://github.com/ublue-os/ucore/blob/main/examples/ucore-autorebase.butane

GitHub

ucore/examples/ucore-autorebase.butane at main · ublue-os/ucore

An OCI base image of Fedora CoreOS with batteries included - ublue-os/ucore

Noel•9mo ago

I have not! this looks very useful!

bsherman•9mo ago

take a look at the ucore repo if curious i haven't had trouble with zincati starting before this but i think you probably don't want to try to rebase all the time

Noel•9mo ago

right. What I'm wondering is could this be repurposed to build something like bazzite? The benefit of Fedora CoreOS is that they already have images created in various formats for deployment. Silverblue they only have an ISO.

bsherman•9mo ago

uh, no hmm oh, i see, you are talking about qemu disk images, etc

Noel•9mo ago

yes also there is the coreos-installer package which allows you to pull one down to utilize.

bsherman•9mo ago

i think it's fine to use coreos for the install if you know it's never going to replicate a user-style install and assuming it works at all 😉 but i'm 99% sure it should

Noel•9mo ago

I'm going to pull some of the code from the autorebase.butane and see if it fixes some of my issues. I have no reason to belive it shouldn't So... I think I found the issue. Fedora CoreOS does not create an /etc/fstab file, so it doesn't mount /boot by default.

Noel•9mo ago

when you run rpm-ostree after rebasing, it gives this nasty error similar to this: https://github.com/coreos/fedora-coreos-tracker/issues/322

GitHub

testing: failed to start rpm-ostree daemon after auto-update to 31....

My canary node updated from 30.20191014.1 to 31.20191127.1 and properly rebooted into it; however it does not seem to be very healthy. rpm-ostree daemon is not available anymore, as it fails to sta...

Noel•9mo ago

The fix interactively is to do this: mount /dev/disk/by-label/boot /boot or add an entry to your fstab

bsherman•9mo ago

wait, what? hmmm you CAN rpm-ostree rebase to another image on coreos... i do it all the time with the ucore images... but are you saying that there's something different about the configuration on silverblue(desktop fedora rpm-ostree) which requires /etc/fstab? after doing that one manual mount command, do things work smoothly?

Noel•9mo ago

Yeah, I'll explain in a second. Just making food right now 😂 @j0rge or @KyleGospo may be able to answer better than me, but what I notice with CoreOS is that it doesn't use btrfs by default. and no /etc/fstab is generated on CoreOS either which maybe silverblue uses for some rpm-ostree related things? I'm a bit out of my depth. for context, I am rebasing a locally built version of bazzite I have on a coreos VM. unless I add a fstab file to mount /dev/disk/by-label/boot to /boot, the rpm-ostree daemon service won't start.

j0rge•9mo ago

I dunno there's some etc merge thing going on isn't there? but also, the whole "image testing accelerator" sounds awesome . o O ( I bet OEMs would love that )

bsherman•9mo ago

one CAN use btrfs on CoreOS, it's just part of the ignition storage config, but yeah, XFS is default... shouldn't actually be a problem for basic testing though

Noel•9mo ago

yeah, that was my thought. I do know on my own bazzite system I do have an /etc/fstab created. CoreOS doesn't seem to create one by default.

bsherman•9mo ago

for the short term, i suggest adding that fstab entry as a file in ignition, ... see how much further you can get

Noel•9mo ago

yup, I did that and it works.

bsherman•9mo ago

yeah, it's not required

Noel•9mo ago

I'm at the point where I may be able to ansibleize it.

Gaming

Programming

Create Standardized Local Development En...