I tried to create a VM on the demo site, and got a nice Ruby error message next to the VM's name on the 'Machines' page: undefined method `+' for nil:NilClass
Still, I'm very excited about this!
If anyone from the project reads this: Where is the appropriate place to request support for an additional GNU/Linux distribution? I would love to get GNU Guix running on this.
Edit: It seems that I have jumped the gun with my enthusiasm for this project. They will be selling proprietary re-licensed versions as a reward and require copyright assignment for contributions.
VirtKick, please reconsider your decision to require copyright assignment. I want my contributions to the free software community to remain free.
So selling proprietary versions isn't your goal, but allowing the code to be used in proprietary versions is?
You're walking a very fine line here. One so thin I wouldn't fault anyone who said it doesn't even exist.
Of course, I was just wondering where a ticket could be created so that it's on the record as a feature request.
>We currently have virtkick-starter, a bunch of scripts that set everything up.
Perfect. I'll have a look. Thanks!
Edit: I think we have a misunderstanding. I would like to use VirtKick to provision Guix VMs, not just install VirtKick on Guix.
And you don't feel that the AGPLv3 ensures that...? Or you mean "I don't want my contributions to be distributed under any other license"?
For programs like this, I see little benefit of AGPL over GPL, since the main use-case will be in-house deployments. I can't see how anyone would deploy something like this on the backend, where if you made an in house-fork with bug fixes to support your proprietary infrastructure, you'd have to publish the patches for the wider community. It seems like a big red flag to me.
Exactly! Hence my request for clarification (see above).
If more explanation is necessary: What davexunit is saying is that he wants his contributions to remain free. The AGPLv3 ensures that, even with copyright assignment. But what I guess davexunit really means is that he wants to be sure that all contributors, present and future, are locked into the AGPLv3 forever. I'm not saying the latter is wrong, I'm just saying you should call a spade a spade.
* No virt-manager with SPICE, networking configuration, and other features
* No virt-install for very easy creation of VMs, even straight from distro repository URLs
* No virsh for command-line management
* In general, no seamless use of any of the vast ecosystem of tools around libvirt
Is the only advantage that it supports Docker? In that case, why not just add support for Docker into libvirt, and Docker images into virt-install?
Is the advantage that it's a web UI for libvirt? There are certainly plenty of those already, but I guess creating another one is fine.
I really don't see the use-case.
* used libvirt and the various tools you mentioned for managing VMs
* used the libvirt API to help write vagrant-libvirt 
Existing libvirt clients, at least those that we know of, aren't super reliable though. libvirt stucks when there's too much happening on the HV, or denies jobs without even trying (e.g. when a pool has async jobs). A backend that schedules tasks for background execution is needed for that (and we have it), so even now we're not "just" a frontend for libvirt.
The use case is a very simple panel with zero virt knowledge needed to start.
Thanks for your comment.
I would certainly prefer that virtkick was 'just a frontend' for libvirt. Then the people who are making use of virtkick can seamlessly rely on the huge amount of existing software that supports libvirt. You can provide a REST API that is translated to the existing libvirt API rather than replacing it.
If you have task-scheduling improvements for libvirt, they should be upstreamed rather than only exist in your software, so everyone can benefit from them.
Are the extras like monitoring 3rd party integrations that I'll have to pay for, or actual features of VirtKick?
External monitoring integration, and off-site status page, will be actual features of VirtKick. Think of VirtKick is a 1-click installable panel that you can use both on your desktop and as a VPS provider. Instead of paid features, we want it to be forever free - instead, we aim to be crowdfunded. https://www.indiegogo.com/projects/virtkick-take-cloud-back
Things get crazy here (in a good way). You could create federation where you allow remote hypervisor management from a central authority (your app). #ArchiveTeam needs their VM running for the latest web property shutdown? Here, have access to my overpowered home router to run a few tiny VMs to help the cause.
Knocked it out of the park here guys (and/or gals)! Awesome job.
VirtKick is like DigitalOcean or Linode - they are focused on machines (and containers, that you think of as machines). You install it on your Linux desktop (for localhost hacking), or home or dedicated server (for something more).
Will try to express it a little bit better. Thanks for your feedback.
I also might point out, as a person working on a proprietary service, it's in our interest to contribute upstream. Who wants to maintain compatibility patches? It's in EVERYONE's best interest to have solid, open infrastructure used by everyone (yes, even evil closed companies like google)
Node.js has been super popular for the past few years and it's built from mostly MIT style licenses. It's so hot that Microsoft has made a big effort to make it usable and provide tools to work with it on Windows. Nobody that I know of has come along and taken this product, re-branded it and then pawned it as their own creation.
I understand that the point of the Affero license is to prevent "Tivoization" of a product, but it seems to come at the cost of not being able to attract a large base of developers to contribute to the project, since everyone would rather be working with more liberal licenses.
It's good enough for Linux.
This is because I don't use port 22 for SSH.
Can I fix this easily?
It is a pain to configure, but that's the price you pay for flexibility, future-proofing (scalability) and its' true community development model.
With Juno imminent, I might just start over and hope the Juno installation isn't so difficult, though that doesn't seem to be a top priority for the developers.
VirtKick is closer to a scale that I have time to manage, I think. Of course there are tradeoffs; with the big players running OpenStack in production, security fixes are available quickly and I love/hate the short release cycle. VirtKick has layers of security risks and (so far) no big-money contributors who need to get fixes out quickly.
VirtKick is a self-hosted DigitalOcean. Both are very simple IaaS (but it's you who provide the "I" with the former)
Does it explain?
My follow-up then would be how would this compare to OpenStack? If they serve the same purpose, where do you want to differentiate from OpenStack?
Because DigitalOcean, basically, is a way to get VMs without self-hosting them!
I honestly value DO for the service of providing VMs, and I don't care to run my private VMs. We also have dedicated servers, which run docker directly.