-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: deps: Add lorax #113
WIP: deps: Add lorax #113
Conversation
We aren't using it today, but we might use it in the future - or we may at least share code. Since this container is enormous anyways, there's no real downside to adding the dep now. For more information, see discussion in: coreos#91
Hmm, we won't actually start using/sharing code with it anytime super soon though, right? Let's just leave this open until that changes? |
(Also I got confused, So...one angle we could take would be to replace our existing |
Using lorax in builds requires either a lorax PR to enable local repos through a local mount or a migration away from how virt-install.py disables the network interface to pull a local ostree repo. Looking at the class lorax uses to launch the VM (https://github.com/weldr/lorax/blob/master/src/pylorax/installer.py#L134) it shouldn't be too hard to pass in extra opts. Something on this line might work:
I'm not super familiar with virt mounts but the |
Yep! The only downside to this is that 9p isn't in the RHEL kernel. An alternative might be something like HTTP-over-virtio. |
That would be more universal... if the container already ships with python, just throw up a simpleHTTPServer on 127.0.0.1 before virt-install and change the script to allow networking. Atomic style. |
Doesn't seem like we're going to do this. |
We aren't using it today, but we might use it in the future - or
we may at least share code.
Since this container is enormous anyways, there's no real downside
to adding the dep now.
For more information, see discussion in:
#91