Show HN: VirtKick – Self-hosted Digital Ocean | Hacker News Reader

Show HN: VirtKick – Self-hosted Digital Ocean

virtkick.io

216 pointsNowaker92 comments

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.

Sorry for that. The hypervisor died, which results in errors like this. We use Bugsnag so we've got all the stacktraces - we'll handle distasters. :)

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

>The best way would be to contribute. :)

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.

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/u1LKwi http://goo.gl/j1j80f

> I want my contributions to the free software community to remain free.

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"?

If you have a contributor assignment, the assignee can choose to release the changes under a proprietary license.

It's not our intention though, see https://news.ycombinator.com/item?id=8527999

> 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.

It doesn't ensure they remain free - a copyright assignment allows the contributions to be used as part of a proprietary release.

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 are assigning them copyright, and they can sell proprietary licensed versions, then it's a pretty valid request...

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.

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).

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.

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...

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.

As someone who has

  * 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.

[0] https://github.com/pradels/vagrant-libvirt

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.

Thanks for your comment.

> 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?

Excactly right - plus on remote hypervisors too.

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!

It just sounded too good to be true. I'll definitely contribute.

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.

Exactly right, we value existing tools - that's what makes DO so strong. :)

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?

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

So, as your link mentions...why not just use GPL?

It's good enough for Linux.

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.

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.

All infra code needs to carry the MIT license or similar, IMHO. It's infrastructure.

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!

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.

What's wrong with that? Don't we want to encourage proprietary companies to host using open software?

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.

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.

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)

The AGPL prevents no such thing, they are free to do so provided they follow the license the creators published the code with.

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.

It seems we have HN'ed the service; after creating a Debian image: "internal error: pool 'HDD' has asynchronous jobs running."

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/

another thing: all the add-on links redirect to the same DNS add-on

Oh, forgot to actually add something there. To give you a better understanding, it'll work the same way as on Heroku.

thanks, I'll be checking the project out for sure

So what is this? A project based off of openstack, a complete re-working of an openstack-like environment or something different?

A complete re-working - as OpenStack is too big if you're not a corporation with a very big infrastructure.

I disagree - OpenStack scales down perfectly to two-machine or even (one-machine) deployments (if you don't want HA).

It is a pain to configure, but that's the price you pay for flexibility, future-proofing (scalability) and its' true community development model.

"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.

That's really not true. I run it on small deployments all the time: http://www.stackgeek.com/guides/gettingstarted.html

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!

It would be nice to see an architecture diagram, or just a list of the planned components and their responsibilities.

Just made something that can answer few questions: https://www.virtkick.io/dia.svg

seems the backend is python, and the web app is ruby. Curious as to why you decided to use 2 different languages.

(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.

I would not consider nor call this "Self-hosted DigitalOcean" - Interesting project never the less.

So excited to see this! Great job guys!

I've been following this for a while, and it looks like an awesome way to roll your own cloud!

I actually wanted to create something like this. Does it do ssh key injection when VMS are created?

Not at this point (we mount an ISO as CD), but we've got it planned: https://github.com/virtkick/virtkick/issues/6

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?

Looking forward to it, you'll see my contribution!

Thanks, can't wait!

How does this compare to something like Cloud Foundry?

Cloud Foundry is a self-hosted Heroku. Both are PaaS (but it's you who provide the "P" with the former).

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?

Yes. Quite clear actually too.

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?

Without any judgement over the project and its quality, I would not call it "Self-hosted DO".

Because DigitalOcean, basically, is a way to get VMs without self-hosting them!

(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.

Got downvoted for this...

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.

Website offline, github page - https://github.com/virtkick/virtkick

Demo - https://demo.virtkick.io/

https://www.virtkick.io/ works OK, but it seems you killed https://alpha.virtkick.io/ (our 128 GB hypervisor wasn't enough to handle load). https://demo.virtkick.io/ is a static HTML prototype to get familiar with planned features.

Its getting like the early 2000s on /. around here. What happened to modern elastic hosting stuff?

No LXC on the map? :(

Docker works with LXC

used to. Now-a-days it uses libcontainer.

Docker moved out of lxc long time ago

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

actually it only does two, lxc and libcontainer (aka native) https://github.com/docker/docker/blob/master/daemon/execdriv...

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. :)

some documentation...?

Not at this point. We're focusing on features now. However, installing an alpha is a matter of 4 commands, give it a try: https://github.com/virtkick/virtkick-starter#virtkick-take-c...

Reply on news.ycombinator.com