| fnordahl | mnasiadka: Thank you for reaching out. Starting with wallaby we included ovn in | 08:04 |
|---|---|---|
| fnordahl | UCA. As soon as Impish is refreshed with a new OVN package we should be able to | 08:05 |
| fnordahl | provide that to the xena UCA. | 08:05 |
| BraveheartBSD | Anyone have a guide for setting up hardware raid? | 08:14 |
| webchat7 | Hi. Can someone help me out with Ubuntu 20 cloud-init based unattended server installation? | 11:33 |
| webchat7 | Unattended installation works ... It's just that cloud-init doesn't do anything afterwards, even if I reset it and remove the file that disables network configuration. | 11:33 |
| rbasak | webchat7: what are you expecting cloud-init to do? | 11:37 |
| === masACC is now known as maswan | ||
| webchat7 | I expect cloud-init to initiate again when I attach a coud-init image/drive - some block device with label cidata containing user-data network configuration etc | 11:40 |
| rbasak | I don't think it's designed to do that, sorry. | 11:40 |
| rbasak | The "installer" is designed to install Ubuntu on a machine permanently. It isn't for making cloneable images. | 11:41 |
| rbasak | You might be able to hack something together, though. | 11:42 |
| webchat7 | on other distibutions it does exactly that. Attach an iso with another configuration, reboot or clean and init and it's doing just fine | 11:42 |
| webchat7 | So it's not a hack, when I get it to work | 11:42 |
| rbasak | cloud-init is designed to do that, yes. | 11:43 |
| rbasak | The installer is not. | 11:44 |
| webchat7 | Sure, I'm talking about after the installation | 11:44 |
| rbasak | You'll see that behaviour work with Ubuntu cloud images. Why are you using the intsaller instead of using cloud images? | 11:44 |
| webchat7 | The only way, I figured, was messing around with /etc/cloud/cloud.cfg | 11:44 |
| rbasak | I'd look into what datasource the installer sets up, if you want to hack something together. See https://cloudinit.readthedocs.io/en/latest/topics/datasources.html | 11:45 |
| rbasak | Probably cloud-init is being configured to use a different datasource to your "config drive". | 11:45 |
| rbasak | However, I'm still pretty sure that using the installer to achieve this will be a hack. The intended way to get what you want is to use Ubuntu cloud images. | 11:46 |
| webchat7 | I'm using the server installer, because I don't always have network access | 11:46 |
| rbasak | You can boot Ubuntu cloud images without network access. | 11:46 |
| rbasak | You might need to configure cloud-init not to time out though. | 11:47 |
| webchat7 | I need to do a full installation on bare metal as well as VMs completely offline. Some packages I need are not in the cloud images. | 11:48 |
| rbasak | For the VMs, boot a cloud image somewhere else online, install the packages you want, shut down, and then clone that image. | 11:49 |
| rbasak | I can't help with the bare metal though, sorry. I don't think we currently provide any general mechanism to roll an installer image with additional packages embedded in it. You can hack that together using the same method we use to roll our installer images, of course. | 11:49 |
| rbasak | clone that image> as long as cloud-init sees a different instance-id (eg. you're providing a config drive) then it'll do the right thing there. | 11:50 |
| webchat7 | Already added packages to the Ubuntu 18 installer - but since I use d-i preseed there, it works quite well | 11:51 |
| webchat7 | I think I'd rather want to reset cloud-init and delete the configuration after Ubuntu 20 setup. Will require some hack, but it'll do the trick | 11:52 |
| webchat7 | thanks | 11:52 |
| rbasak | webchat7: I've been looking for this link. Just found it: https://discourse.ubuntu.com/t/a-tool-to-modify-live-server-isos/22195 | 11:57 |
| rbasak | You might find that useful. | 11:58 |
| webchat7 | I'm alredy doing that. The cloud-init config for the unattended installer and the grub config is being added to the ISO in a similar way. | 12:00 |
| mgedmin | you mentioned d-i preseeds, which implies you used the alternative installer | 12:01 |
| webchat7 | for Ubuntu 18 I do - and that works | 12:01 |
| webchat7 | For Ubuntu 20 I don't | 12:01 |
| mgedmin | ubuntu 20.04 lts will not have it, and livefs-editor is a tool for customizing the new subiquity installer | 12:01 |
| webchat7 | The installation isn't the problem. It's just that cloud-init doesn't do anything after the installation when I attach a cloud-init config | 12:03 |
| webchat7 | I already figured the rest of it out, which was quite a bad experience btw. At that time, the Autoinstall Reference said at some points "The snap mentioned above doesn't exist yet" | 12:07 |
| rbasak | webchat7: specific feedback on improvements welcome please. Fundamentally I think the issue is that your use case isn't currently supported though? | 12:18 |
| webchat7 | I'll find my way ;) | 12:19 |
| webchat7 | just thanks for confirming, what I already thought | 12:19 |
| === marlinc_ is now known as marlinc | ||
| shubjero | coreycb: Re: cloud-archive and version control. Any reason why Ubuntu repositories dont keep previous versions for users to target / roll back to? Any idea on how I can obtain Neutron 16.3.0 for bionic from CA? | 14:58 |
| ogra | shubjero, deb packages are not really designed for rollback ... if you'd go back to a former one, that might use other dependencies ... these dependencies would have to roll back as well ... other apps depending on them would then have to be rolled back etc etc | 15:02 |
| ogra | that would create a giant mess in the end | 15:02 |
| ogra | if you want seamless rollback, this is what snap packages were designed for ... they can go back and forth at will | 15:03 |
| shubjero | ogra: OK but when a package contains a show-stopping bug (like bringing an entire cloud offline).. you need to roll back to a version that previously worked. | 15:03 |
| shubjero | And the dependency chains are usually well respected from my experience | 15:03 |
| ogra | no, as a packager you still go forward (you might change the contents of the package to the former ones but you still release a higher version) | 15:04 |
| shubjero | ogra: But if the repository has pruned the previously working version, its a quick way for your users to drop your product long term | 15:04 |
| ogra | the main archive never prunes anything ... are you sure you are not talking about a PPA ? | 15:04 |
| shubjero | As a packager yes, you always move forward. As an operator, you use what works and avoid what doesnt. | 15:04 |
| tomreyn | ogra: i disagree on "the main archive never prunes anything" | 15:05 |
| ogra | tomreyn, well, it is true 🙂 | 15:05 |
| tomreyn | you're saying all old package versions are kept? | 15:06 |
| shubjero | I just did an apt-cache policy openssl-client and I have 1 version available (latest) from the Ubuntu repositories | 15:06 |
| ogra | tomreyn, yes | 15:06 |
| tomreyn | ogra: i'm convinced that's not so. | 15:06 |
| shubjero | If i do the same on a 3rd party repository, like zabbix, elastic, mariadb, I have dozens of versions I can target for use/installation. This is how all repositories should be. | 15:06 |
| ogra | tomreyn, here is an example https://launchpad.net/ubuntu/+source/htop/+publishinghistory | 15:07 |
| tomreyn | ogra: but i see how it's now up to me to proove that, and i don't want to subvert the ongoing discussion, will get bakc to it later. | 15:07 |
| tomreyn | ogra: oh oyu mean on launchpad, not on archive.u.c | 15:07 |
| ogra | launchpad *is* archive.u.c 😉 just a different representation of it | 15:08 |
| tomreyn | there was recently a glibc problem where a newer, boroken package, got published, then pulled a while later, because it introduced new problems. so some ended up with the newer more broken versionn , others with the older, less broken version | 15:09 |
| ogra | yeah | 15:10 |
| shubjero | ogra: https://pastebin.ubuntu.com/p/hZXgybGzkg/ | 15:10 |
| * ogra remembers ... there was also some bad timing involved with the Packages.* file generation | 15:11 | |
| tomreyn | and when those with the newer version tried to install debug packages, they could not, because depednencies could not be resolved. | 15:11 |
| tomreyn | at least one of those package version were no longer available on launchpad either | 15:11 |
| tomreyn | shubjero: looks like 3rd party packages | 15:12 |
| ogra | that only happens if someone actually manually removed something ... normally LP does not lose any revision of any packages ever uploaded to the archive | 15:12 |
| ogra | the libc bug might have been severe enough to do this though | 15:13 |
| tomreyn | ogra: that may be so. but you originally ruled it out happening at all | 15:13 |
| ogra | normally it does not happen ... if there would be i.e. a bitcoin miner in a libc upload it would definitely be removed to not cause harm though | 15:13 |
| tomreyn | we were just talking about bug 1926918 | 15:14 |
| ubottu | Bug 1926918 in glibc (Ubuntu) "cannot install libc6-dev, requires old libc6 version" [Undecided, In Progress] https://launchpad.net/bugs/1926918 | 15:14 |
| tomreyn | https://askubuntu.com/questions/1315906/unmet-dependencies-libc6-the-package-system-is-broken | 15:14 |
| shubjero | tomreyn: Yes, I am trying to convey that many 3rd party repositories keep several versions around, protecting operators by allowing a rollback to a previous version if something bad is discovered in the new package version. It seems like any of the Ubuntu repositories (including cloud-archive).. that's just not possible and from an operator perspective its terrible | 15:14 |
| ogra | tomreyn, right, our system assumes that things having been tested in -proposed actually have been tested before moving to -updates 🙂 ... | 15:15 |
| ogra | people sometimes make mistakes and automation sometimes fails ... but these are corner cases | 15:16 |
| tomreyn | shubjero: okay, i tend to agree to the "everything should be preserved", as debian does it. but if a 'fixed version' (higher version number, previous package) would become instantly available after reggressions are detected, i'd be fine with this, too. | 15:16 |
| shubjero | Agree with you both. Also, I always test my OpenStack upgrades in our lab with the packages available at that time. If by the time I've scheduled the production roll out, newer packages are available (and untested), I'd still like to be able to install the packages I tested in the lab.. but now I can't because those versions are gone | 15:17 |
| tomreyn | ogra: IMO that'd be fine if (non packaging-aware) users were able to resolve the sitation on their own. but i don't want you to waste your time on this debate now. ;-) | 15:18 |
| ogra | if you preserve everything in archive.u.c it means that (at most voluntary) mirrors will need a lot more resources ... | 15:18 |
| shubjero | Turns out that what I tested in my lab was Neutron 16.3.0 and worked great but by the time I rolled out to production only Neutron 16.3.1 was available and contained a show stopping bug that took our entire cloud offline and I had to try and scramble to find an old version of Neutron to install. I managed to find 16.0.0 from Focal which seemed to work but now I'm having many other issues | 15:19 |
| tomreyn | you'd just need one central mirror for that | 15:19 |
| shubjero | which could be because I'm having to run an unexpected version of Neutron | 15:19 |
| shubjero | Anyways, these are operational war stories | 15:19 |
| tomreyn | snapshot.debian.org is actually two mirrror (or maybe 4, 2x ipv4, 2x ipv6) | 15:20 |
| tomreyn | i'd assume canonical has more resources at their disposal than a volunteer run project, but then debian has snaphshot.debian.org but ubuntu has not. :-/ | 15:22 |
| tomreyn | see also deb.debian.org, https mirrors etc. | 15:23 |
| * tomreyn quits whining for now | 15:23 | |
| ogra | well, Lp is our snapshot.d.net 🙂 | 15:24 |
| tomreyn | not if it doesn't preserve everything | 15:27 |
| tomreyn | i'd say Lp is Ubuntus tracker.debian.org and buildd.debian.org | 15:27 |
| tomreyn | + salsa | 15:28 |
| ilpianista | anyone else is using the latest 20.04 AMI on EKS? I cannot make it work because it's missing the heptio-authenticator-aws binary apparently. The previous AMI works fine | 15:55 |
| tomreyn | ilpianista: aws seems to no longer recommend heptio's by default, but their own (fork?): https://github.com/kubernetes-sigs/aws-iam-authenticator#aws-iam-authenticator-for-kubernetes | 16:01 |
| ilpianista | yep, but the AMI has neither | 16:02 |
| tomreyn | see also (outdated) https://aws.amazon.com/blogs/opensource/deploying-heptio-authenticator-kops/ vs (current) https://aws.amazon.com/blogs/opensource/deploying-aws-iam-authenticator-kubernetes-kops/ | 16:02 |
| tomreyn | oh ok | 16:02 |
| === halves_ is now known as halves | ||
| mwhudson | https://discourse.ubuntu.com/t/please-test-wifi-support-in-the-server-installer/22732 | 23:12 |
| sarnold | oo cool | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!