On Fri, 2017-06-23 at 09:54 -0400, Colin Walters wrote: > On Wed, Jun 21, 2017, at 08:07 PM, Adam Williamson wrote: > > > > Look for the Workstation dvd-ostree 'Flavor'. As you can see, for now I > > just have it running a subset of the regular Workstation tests, with > > the update-related tests - which assume an RPM-based system - > > rpm-ostree is also an RPM-based system; it's even literally in the name of > the project! It's *also* an ostree-based system. Just like hybrid cars > are both gasoline and electric. Well, yes, but I'm usually talking from the *user* perspective. So far as the user is concerned, it's not an RPM-based system: we can't test updates by fiddling around with dnf, is the pertinent point here. > That said of course, things are different since again it's a hybrid and > one needs to consider the base tree vs layered packages. > > The most realistic test is to test updates from "previous stable image/installer". > to "latest tree". > > (As well of course to test layered package updates, but > that runs into > https://github.com/projectatomic/rpm-ostree/issues/391 ) > > There's a variety of rpm-ostree tests that are used for Atomic Host here: > https://github.com/projectatomic/atomic-host-tests/tree/master/roles > > That all said I'm still not sure about doing these types of tests in AutoQA > versus something more like Ansible as we already use for a-h-t. openQA, not AutoQA. If we have another system where we can test the update experience exactly as it works for a real end user - starting from deploying ostree Workstation in the way we actually expect a user to do so, starting from our actual nightly / candidate images - then that's great, let's do that. But if we don't, openQA is probably a practical way to do it. What I'm really kinda looking for is more specific details on the level of "here is approximately what you could do to reliably put a Workstation ostree system into a state where an update for it would be available through the usual mechanism". > Though testing gnome-software's forthcoming rpm-ostree backend would > be back in the realm of GUI testing. So, updating via GNOME Software is not yet possible? That's useful information, thanks. Still, thinking about it, for ostree Workstation we really need to test two *separate* things, yes? Updating the base system, and then deploying and updating software on top of the base system. Again, more details on how that process is expected to work would be useful; are Flatpaks the only expected deployment method for apps on ostree Workstation, for instance? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
