| rbasak | @pilot in | 10:54 |
|---|---|---|
| === ChanServ changed the topic of #ubuntu-devel to: Archive: Final Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: rbasak | ||
| danilogondolfo | Hi rbasak, may I ask you to take a look at this https://bugs.launchpad.net/netplan/+bug/2084444 | 11:13 |
| -ubottu:#ubuntu-devel- Launchpad bug 2084444 in netplan.io (Ubuntu Jammy) "juju can not parse new 50-cloud-init.yaml properly after netplan 0.107 under 22.04" [Undecided, New] | 11:13 | |
| danilogondolfo | It's an SRU regression | 11:13 |
| danilogondolfo | we believe that netplan.io 0.107.1-3ubuntu0.22.04.1 on Jammy should be moved to -proposed while we look for a fix | 11:13 |
| danilogondolfo | the new package triggered a problem on Juju | 11:13 |
| danilogondolfo | CCing slyon | 11:14 |
| rbasak | danilogondolfo: already seen it - thanks! | 11:16 |
| rbasak | danilogondolfo: I think I misunderstood your comment, sorry. | 11:16 |
| rbasak | "In my opinion it should be addressed in Juju" -> did you mean it should *not* be addressed in Juju? | 11:17 |
| rbasak | slyon: please could you urgently prepare a revert for this package? Now that it's published, moving it back to proposed won't work unfortunately. | 11:17 |
| danilogondolfo | No, I mean it should. Juju is parsing Netplan YAML wrongly. | 11:17 |
| rbasak | danilogondolfo: we can't justify not reverting a regression because that would change the new broken behaviour. As a general principle that's illogical. If there's a better reason I'd love to hear it. | 11:18 |
| rbasak | danilogondolfo: what I think we need is an immediate revert of netplan.io, so we can have some breathing space to fix this properly. | 11:18 |
| rbasak | danilogondolfo: and with that breathing room, we need to ensure that we add Juju to the QA process for future netplan releases, as clearly there's a gap in QA here. | 11:19 |
| danilogondolfo | rbasak, I agree. Now, I do believe we should revert netplan.io, that's why I reached out :) So, that's the first time I have to handle it, the previous version is in -security, would moving the new one back to -proposed work in this case? | 11:22 |
| rbasak | danilogondolfo: I don't think so because apt won't downgrade to a lower version. That might work for Juju for new instances, but I don't think it's a good idea to cause a divergence where some users are reverted but others are not. | 11:23 |
| rbasak | danilogondolfo: the usual way is to provide a new upload that has an identical source tree as the good version, but with a higher package version string than the bad version. | 11:23 |
| danilogondolfo | I see. This new version introduces new packages (netplan.io was split in to more specific packages), reverting to the old version could lead to issue here? For example, the old netplan.io installs files that will conflict with the new package netplan-generator... | 11:27 |
| rbasak | Indeed, this seems very painful. That's the cost of making these major changes in stable releases :-( | 11:27 |
| danilogondolfo | as this is causing issues with Juju only, it might be OK to just stop the update | 11:27 |
| danilogondolfo | oh, and phasing is stuck anyway due to something else | 11:28 |
| danilogondolfo | it stopped at 10% | 11:28 |
| rbasak | We only know that it's affecting Juju. It might affect others, too. It doesn't seem OK to break the YAML format like that in a stable release to me :-( | 11:28 |
| danilogondolfo | we haven't broken the YAML, netplan always emitted YAML that way | 11:29 |
| danilogondolfo | but cloud-init was emitting a different format, that very sadly was also accepted by the netplan parser | 11:29 |
| danilogondolfo | but Juju has its own netplan YAML parser and it expects a very specific data format | 11:30 |
| danilogondolfo | now cloud-init will use netplan to emit YAML, and netplan will emit it in the format it always used | 11:32 |
| danilogondolfo | changing cloud-init so it will not use libnetplan even if it's not available would "resolve" the problem, but Juju would still not accept the same YAML accept by netplan | 11:33 |
| danilogondolfo | so that's the whole story | 11:33 |
| danilogondolfo | s/even if it's not available/even if it's available/ | 11:35 |
| danilogondolfo | I guess MAAS was generating the YAML that way, cloud-init was just passing it through without changing it | 11:39 |
| danilogondolfo | but with python3-netplan installed it will use libnetplan to parse and save the YAML to /etc/netplan/ and it will be in the format used by libnetplan since ever | 11:41 |
| rbasak | Nevertheless, unless I misunderstand, it is the netplan change that caused the regression? That's something that we must avoid in stable releases, even if it is due to a more complex interaction. | 11:44 |
| danilogondolfo | Netplan was the trigger, nothing changed on netplan regarding YAML generation. What caused the problem was the Juju custom netplan YAML parser that can't ingest YAML generated by libnetplan (which, again, hasn't changed) | 12:07 |
| danilogondolfo | If anything changed in Jammy, it was the fact that cloud-init started to use libnetplan iff it's available. | 12:08 |
| rbasak | Sounds like the issue was that you introduced libnetplan into Jammy, causing other things to change behaviour? | 12:40 |
| rbasak | This is an example of how adding things can cause regressions! | 12:40 |
| rbasak | danilogondolfo: how's the preparation of the revert going? | 12:40 |
| slyon | rbasak: looking into it. I will try removing of the new python3-netplan & netplan-generator packages via Breaks/Replaces | 12:44 |
| rbasak | Thanks! | 12:50 |
| slyon | rbasak: So, I have a netplan revert prepared in a PPA and did some testing around it: | 14:49 |
| slyon | https://launchpad.net/~slyon/+archive/ubuntu/testing/+packages?field.name_filter=&field.status_filter=published&field.series_filter=jammy | 14:49 |
| slyon | Unfortunately, it won't work as expected, as "apt upgrade" will not remove the | 14:49 |
| slyon | new python3-netplan & netplan-generator packages on upgrade (needs "dist-upgrade"). | 14:49 |
| slyon | Therefore, the rollback won't reach our users. | 14:49 |
| slyon | Furthermore, people that already started using 0.107 functionality (veth,dummy,wpa3,...) would be left stranded with broken network configuration on revert to 0.106. | 14:49 |
| slyon | So I don't think a revert is the correct approach. People using 0.107 from -updates currently should stay on that version. | 14:49 |
| slyon | rbasak: see my suggestion in https://bugs.launchpad.net/netplan/+bug/2084444/comments/6 | 14:54 |
| -ubottu:#ubuntu-devel- Launchpad bug 2084444 in netplan.io (Ubuntu Jammy) "juju can not parse new 50-cloud-init.yaml properly after netplan 0.107 under 22.04" [Critical, New] | 14:54 | |
| === cpaelzer_ is now known as cpaelzer | ||
| rbasak | !dmb-ping | 16:02 |
| ubottu | bdmurray, bdrung, rbasak, schopin, teward, tsimonq2, utkarsh2102: DMB ping | 16:02 |
| sudip | rbasak: teward: just a suggestion, why dont you do a DMB day at the Ubuntu Summit.. I can then apply for core-dev :) | 16:16 |
| teward | sudip: requires DMB OKing it for that. cant run a solo day | 16:17 |
| teward | and theres nothing stopping you from a 2025 application | 16:17 |
| teward | i also have a few Community Council items I have to handle @ the summit so | 16:18 |
| teward | that adds a wrench to my schedule | 16:18 |
| schopin | sudip: mind bringing that up on the devel-permissions ML? | 16:20 |
| sudip | schopin: the DMB day suggestion? | 16:21 |
| schopin | yes. | 16:21 |
| sudip | sure | 16:21 |
| rbasak | @pilot out | 17:30 |
| === ChanServ changed the topic of #ubuntu-devel to: Archive: Final Freeze | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: N/A | ||
| === pushkarnk1 is now known as pushkarnk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!