Hi Lonnie,

thank you for pointing out that we don't have this comparison, we'll try to fix that. But this is not about competition anyway. Our focus is a bit different.

To answer your question: first of all, Danube Cloud (DC) is trying to be user friendly and easy to use in the first place. You don't need the dedicated headnode (the management are just few VMs that can be migrated anywhere). On top of that, DC includes full Zabbix install for automated monitoring of all nodes and hosted VMs, full featured VM backups using incremental ZFS snapshots, DNS server, multi-tenant IP address and networks management, etc.

All this stuff is in community edition. Enterprise version is about SLA support, not about features (all our new work goes into the community edition).


On 9. 8. 2017 13:11, Lonnie Cumberland wrote:
Hi Daniel,

I just started looking at the Danube release and it looks like you
have brought things together nicely, but was trying to locate what
major changes, improvements, or modifications the Danube release has
over Triton and could not find a list anywhere to look over.

I am sure that you have made some changes as your post describes to
some degree, but was looking to try and get a feel for why I might be
interested in installing your Danube release over Triton. One thing
that I did immediately see on your site is that you have a Community
release which seems to have less features than your Enterprise release
while also offering the Danube Cloud while Joyent seems to have their
single Triton release while focusing on the Triton Cloud services.

This was just meant to be quick observation and I have not looked
heavily into the Danube software while still very new to the Triton
Data Center as well so I'm not really one to do any type of
evaluations or comparisons at this point, but I am all for making
things easier so that one can setup a solidly functioning private
cloud so as to be able to focus on containers and their uses while
minimizing the concerns about the infrastructure.

Personally, I am setting up a private cloud to learn from and test,
with a major focus on running Docker containers, micro-services and
possibly Kubernetes at some future point.

Cheers and have a good day,

On Wed, Aug 9, 2017 at 3:33 AM, Daniel Kontsek <dan...@kontsek.sk
<mailto:dan...@kontsek.sk>> wrote:

Dear Joyent and SmartOS Community,

we have been successfully using and integrating SmartOS at Danube
Cloud (Erigones) for about 5 years now. At the beginning we've
built an IaaS platform, which we've transformed into a
full-featured software solution - Danube Cloud (former Erigones
SDDC) [1]. During this time, there were occasional moments where
we thought that a Linux hypervisor would maybe be a better
choice... But the strengths of SmartOS / illumos gave ourselves
repeatedly arguments that - YES - it was the right choice (Zones,
ZFS, Crossbow, DTrace... you know the perks...). We would like to
say to all illumos and SmartOS contributors: THANK YOU for the
amazing work.

Although, we would like to use the SmartOS platform as it is, we
have to maintain some changes to the illumos-joyent and
smartos-live repositories. This is mostly because of support for
installation/boot from hard drive (contributed by Juraj Lutter),
installer (prompt-config) script location and other smaller
changes to the installer. As far as my understanding goes, Joyent
would not want to support installation to hard drive but maybe
some other (smaller) features would be beneficial for Joyent and
the SmartOS community. We can create pull requests for that, but
there are a few topics I would like to discuss first:

-  AFAIK we should open merge requests here: https://cr.joyent.us/
and not on GitHub, but we should create an issue on GitHub first,
is this correct, or can we just create CRs in Gerrit?

-  Shell scripts coding style (mainly svc/methods and
prompt_config) is a problem. We are seeing mixing of bash coding
patterns, even in scripts where new bash features are used. (e.g.
$var vs ${var} vs "${var}", `` vs $(), [ vs [[). I assume lots of
these are just Solaris heritage, but some scripts are new and yet
we see these strange inconsistencies. I'm not going to argue about
line length and tabs vs spaces (although please don't mix them).
But as we are saying: at least do it consistently wrong :) We are
happily using shellcheck [2] for most of our bash scripts and it
does solve these kind of problems. Is there a coding style guide
for shell scripts?

-  For example: we would love to rewrite the
smartos_prompt_config.sh script so it does not use global
variables. Would you accept such change?


[1]  https://github.com/erigones/esdc-ce/wiki

*smartos-discuss* | Archives
| Modify <https://www.listbox.com/member/?&;> Your Subscription [Powered by Listbox] <http://www.listbox.com>

Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
Powered by Listbox: http://www.listbox.com

Reply via email to