Re: OSTree updates/pulls from LAN and pendrive



On Tue, Apr 19, 2016 at 9:11 PM, Colin Walters <walters verbum org> wrote:
On Mon, Apr 18, 2016, at 10:59 AM, Krzesimir Nowak wrote:
 
Sure, but ostree_repo_pull_with_options does use the remote_name_or_baseurl also to get some options (like URL, metalink, GPG verification, branches) and we want to temporarily override only the URL.
 
True.  An "override-url" option does seem pretty simple and useful.  Then expose via the commandline like `ostree pull --url="" href="http://mirror.example.com" target="_blank">http://mycorp.com/mirrors/osvendor/repo osvendor` ?

Cool, this is in https://github.com/ostreedev/ostree/pull/271
 
 
I'm not sure how git "alternates" fits into this use case. I never used it, but from what I understand (after quick documentation and code reading), you can use it to point git to other object stores on the same computer. So if it is on the server, client will know about additional locations of objects stores for fetching the objects. If it is on the client, it basically tells git not to copy objects but reuse some other local object store. There's also the http-alternates file with similar function, but that looks like a strictly server-side thing.
In our case the objects stores are on different computers.
 
Hm, true.  I'd be really surprised though if git didn't have some equivalent of this.  Myself I tend to set up alternative remotes, but it is manual.

Ah, dunno. You can pass a URL to "git fetch" instead of a remote name, but then I guess it isn't using any remote config options. But git has accumulated like a bazillion features over time, so maybe?

 
What would be the tradeoffs of using the archive-z2 repository with only the latest commit? From my small experiments we seem to lose the commit history, so I'm not sure if it is possible to roll back/checkout the earlier commits (they are unreachable at that point). Anything else?
 
They'd be reachable via HTTP from upstream, right?  We can get from any commit to any other commit via archive-z2 fetches remember.  Deltas are just a way to optimize that.
 
In rpm-ostree we added `rpm-ostree deploy` to make this nicer from the cmdline: http://blog.verbum.org/2015/12/15/new-atomic-host-verb-rpm-ostree-deploy/
I've been meaning to push down the version-number-based logic into OSTree.

Thanks. I'll have a look and get back to you. I'm still a bit unfamiliar with all those nitty-gritty details of ostree inner workings, but I'm learning.
 
I tried experimenting with doing "ostree --repo=<path/to/pendrive>/repo; ostree --repo=<path/to/pendrive>/repo pull-local --depth=0 --verbose /ostree/repo" as root, but got some strange problems that needs investigating (something like syscall 314 [sys_ioprio_set?] which returned EPERM, didn't have that problem when pulling to repo on harddrive instead).
 
On x86_64 at least 314 is `sys_sched_setattr` which I think GThread tries to do by default but probably isn't available to unprivileged users.  Shouldn't be fatal?
 

Ah, we were testing it on the Endless Mini computer with ARM processor, so I guess the syscalls are numbered differently. Still, haven't looked into it in detail, will get back here when I know more.
 
Anyways, simply storing an archive-z2 repo of the complete commit on the USB drive should be fully sufficient for offline updates.  Things are more challenging if you want to try to go smaller via deltas.
 

The only thing I'm wondering about is if ostree repo uses some filesystem features that are not available in vfat filesystem (which is typically found on pendrives).



--
Kinvolk GmbH | Graunstr. 43, 13355 Berlin
Geschäftsführer/Directors: Alban Crequy, Chris Kühl, Iago López Galeiras
Registergericht/Court of registration: Amtsgericht Charlottenburg
Registernummer/Registration number: HRB 171414 B
Ust-ID-Nummer/VAT ID number: DE302207000


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]