This is an awesome project! Thanks for choosing the AGPLv3!
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.
Frankly, there are two mutually exclusive camps: free software and open source. I myself sympathize with free software (GPL) whereas RushPL with open source (MIT). Selling proprietary versions has never been the reason for CLA, though! We want to be able to re-release VirtKick under MIT (and automatically get rid of CLA) if we get funded, so businesses have no problems with it. (See https://news.ycombinator.com/item?id=8527999)
Selling proprietary versions has never been the reason for CLA, though! We want to be able to re-release VirtKick under MIT (and automatically get rid of CLA) if we get funded, so businesses have no problems with it.
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.
I didn't spot your question. The best way would be to contribute. :) We currently have virtkick-starter, a bunch of scripts that set everything up. You could try it out on Guix and improve if needed. https://github.com/virtkick/virtkick-starter
Oh, that's relatively easy at the moment. Put your distro in these two files. ISO will be autodownloaded by `virtkick-starter` script, and the distro will appear on VM create screen. It'll be configurable in the settings in a month, of course. http://goo.gl/u1LKwihttp://goo.gl/j1j80f
With a copyright assignment, the authors could take the entire project closed-source for future versions. You'd still be able to use older, AGPL-licensed versions, but perhaps not newer versions.
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.
> If you have a contributor assignment, the assignee can choose to release the changes under a proprietary license.
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.
This looks cool, but I can't see why contributors should assign you copyright so you can sell proprietary versions of VirtKick. Very few free software projects have copyright assignment requirements (GNU being a notable exception).
CLA's are both good and bad. The good thing is that the software project has more flexibility when it comes to licenses, but the bad is that they have more flexibility when it comes to licenses...
We don't intend to sell modified proprietary versions. In fact, we planned to re-release it under MIT. Just see on the bottom: "Get excited: (...), MIT..." http://goo.gl/w64Ic5 from https://www.indiegogo.com/projects/virtkick-take-cloud-back We'd just want to get funded, so we can work on it without worrying about other things.
So what exactly is the advantage of using this layer over the existing libvirt ecosystem? If this is supposed to manage your VMs for you instead of you using the existing libvirt tools, I can see a number of disadvantages.
* 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 [0]
I feel that libvirt is a useful (albeit quirky) building block but not something you want to interact with directly. Those tools you mentioned aren't ones I'd generally recommend using. You want to have tools with a higher-level of abstraction that can bring in more functionality that is available in just libvirt and provide better interfaces on top of that combination. There's a reason the OpenStack project created Nova, Glance, Neutron, etc.
What one regards as a feature, other regard as misfeatures. If you like virt-manager, then VirtKick isn't really for you. We value a simple UI more than virt-manager, and REST API more than virsh. We don't say your way is wrong. It's just more difficult.
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.
> so even now we're not "just" a frontend for libvirt.
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.
So just for clarity. I'll be able to download your source/package, install, go to the web interface and start spinning up VM instances on the same machine?
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
> Excactly right - plus on remote hypervisors too.
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.
(co-founder here) we try to not get ahead of ourselves, working on the basics first but it's sometimes nice to think big as well and you have some interesting ideas sir, thanks!
This looks interesting: I've often wanted something with more features than just kvm+libvirt but less complexity than OpenStack or other "private cloud" projects. The one thing that worries me about the pitch is the emphasis on the management panel. I don't want to create a VM in 5 clicks, I want to create it in one API call.
Thanks for your comment. UI comes first as every user will hit it. API comes next. We planned DigitalOcean-compatible API altogether with a CLI. Looks like we removed this from our website by mistake (will get it back real quick), but it's listed in our IGG campaign: https://www.indiegogo.com/projects/virtkick-take-cloud-back
That sounds like a good approach; reimplementing an existing API like EC2 or DO makes it easier to integrate your software with tools like Vagrant and Terraform.
I feel as though this is one step above just a web page with an email box. Aside from listing a suite of popular OSS, you haven't explained what this app does. Is it similar to Panamax in that it offers you a UI, but only for one box / Flynn or Deis which is trying to create an open source Heroku / something completely different?
Flynn, Deis, Heroku are PaaS - they are focused on applications.
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.
This is a great project. However, given the nature of the project and the license, would this then require any software hosted with it to be AGPLv3? Could I run software that is a mix of Apache, MIT, and Erlang Public License in a VirtKick container without violating AGPLv3?
Virtkick has a web application component, which makes the AGPL a great choice. Without the 'Affero' component, anyone could host a version of VirtKick with proprietary modifications.
The point would be to enforce the openness of changes to the source. If you go in and add some things, change the design etc. and pass it off as your own, someone can take the changes you've made and do the same. Not only that, but you're required, not just encouraged, to make public any changes, which may or may not be improvements.
So if I'm trying to use this in my proprietary product, I can either a) use it and open up all my code, or b) use a better-licensed, MIT/BSD/APSL2-compatible code.
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)
Adding and changing things does not necessarily precipitate passing off the work as one's own. I could be wrong, but I don't think there's a big problem with that with the truly free licenses like MIT...so I'm wondering - what's the point?
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.
I am sure any ambiguous licensing can be covered by some explicit statements, like what it applies to exactly and to what it doesn't. Good point though!
Our intention is that you share code back to the project if you modified it and added some new great features. :) If I'm not wrong, it only applies to the modified source code, and not the data/machines that you work with. http://stackoverflow.com/a/18406382/504845
AGPL means that if you modify VirtKick itself, you have to contribute these modifications back to the project. GPL does not enforce this for software run on a back end.
likely because it could be a hosted application. If he were to choose the GPL then someone could make modifications and host them as a competitive advantage without sharing the modifications to their users.
Trying this, seeing a LOT of '[virtm] libvirt: XML-RPC error : Cannot recv data: ssh: connect to host localhost port 22: Connection refused: Connection reset by peer'
This is because I don't use port 22 for SSH.
Can I fix this easily?
I'm sorry but we missed your comment. Just created an issue to track this problem: https://github.com/virtkick/virtkick/issues/65 Please subscribe to the issue so you'll get the updates.
Yep. Our 128 GB hypervisor wasn't enough. We redirected traffic to a static HTML prototype, so - at least - you guys have a chance to see the design and planned features. https://demo.virtkick.io/
"Pain to configure" is a blocker here, though. That's why we sacrifice flexibility for simplicity. OpenStack is great for environments that need it - VirtKick won't fit them.
I have used your scripts and I'm quite grateful for the time they have saved me. However, the end result is not a fully functional OpenStack installation. I have no idea how much longer that will take, I'm still working on getting public and private networks configured properly, getting floating IPs to work at all, etc.
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.
Feel free to jump in the Gitter or email me about them. The networking stuff is usually the last mile in OpenStack and is hard to script for a variety of systems. Happy to add to them if I can make it easier for you!
(co-founder here) The backend will be ruby as well, we used webvirtmgr only as a means to kickstart the project and have something usable quickly. :) On a general note though we aren't afraid to mix languages. For example node.js is used to handle web sockets for the VNC console as well as for the starter application.
Perfect! I wanted to host my own DO type thing for personal projects and I tried "webvirtmgr" which has a nice control panel for libvirt, but the creator insists that ssh key injection is out of the scope of his project. I'm glad to see this happening!
You may be surprised that VirtKick wraps WebVirtMgr and uses it as a JSON API for libvirt. :-) This is a temporary solution but does the job - it allowed us to start real quick with features that users care about, instead of harnessing libvirt. (Of course, SSH key injection is in a scope of our project! https://github.com/virtkick/virtkick/issues/6)
Ah, I didn't see that before. So without SSH key injection, what's the current primary method of gaining access to VMS created from cloud images that have no password & ssh key? I'm eager to start using it to host a throwaway jenkins server locally. Do you manually edit in ssh key/password or is there some tool to use?
(co-founder here) Of course your perspective on DigigalOcean is valid but we think of it simply as a good philosophy to deliver a VM to a user in a seamless, straightforward way - that's the part that we want achieve and let users to self-host. Essentially, you could build your own DigitalOcean using VirtKick. Does it make sense for you? Doesn't mean you should rush and start your own business .. you can run it privately for your own needs or for your company's needs.
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.
LXC is not on immediate roadmap but is very much doable since it is supported by libvirt which we already use. You can open an issue on our Github to track its progress, no promises though. :)
Docker by default uses their own libcontainer now but you can change that. In fact last time I checked it supported quite a few via execution drivers like OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones, chroot
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.