Source: I run a few production backend services in Python. Mostly to Debian boxes.
No matter what your product anticipates, it doesn't anticipate all the things I do, in fairly boring applications. I compile my own Python. I install postfix for some applications. I install a kernel module that increases the Linux entropy pool. You have not anticipated my set of problems.
What this means is that no matter how much great stuff your product brings to the table, I bring just as much, if not more, configuring your product and designing a deployment solution around it for my application.
If your product isn't open-source, that's a non-starter for me. Because now I'm worried that I could spend a lot of time configuring the product, and not being able to add that one feature that I need. I'm not sure if you can run a business with an open-source deployment product, but I know that I won't ever use a closed-source one.
Do a better job of explaining how these apps run. I took a look at your sample manifest files, and it wasn't clear to me if you are installing nginx or something? Or if you intend the apps to be daemon-like? So create a page that explains, in words, how to deploy a daemon-like app and how to deploy a webapp, and who is responsible for installing the web server and editing its configuration file(s) (do you clobber them?) and what web server it is supposed to be.
Finally, add a docker.io example. It's not production ready, but it looks like it's designed for people like me who have deployments involving heterogeneous payloads. I'm going to move to it eventually, so if I was to switch deployment stacks I would want good support for it.
All your points are really great! I do need to work on writing additional docs / examples of how specific use cases would be handled.
Also you are correct that I have not anticipated your set of problems and I would love to get some time with you (phone / email or chat) and learn what your problems and pain points are around deployments and figure out if distelli is a good fit.
Distelli can be used to automate compiling a new python on the server (eg. I already have an example where NodeJS is built from source) as well as installing postfix or a kernel mod.
Lastly having an example that integrated with docker.io is a great idea. I'll add that to the list.
Thanks for your feedback and please contact me if you're available to share details of your pain points around deployments and help me improve my product for you.
>If your product isn't open-source, that's a non-starter for me. Because now I'm worried that I could spend a lot of time configuring the product, and not being able to add that one feature that I need. I'm not sure if you can run a business with an open-source deployment product, but I know that I won't ever use a closed-source one.
One can certainly provide an open source software which is not free software and illegal to redistribute. I can't see how that's detrimental to business. E.g. you can download the source code but you can share it to anyone.
Not really. Well, you can of course do that but you can't really call that "open source". "open source" has a set meaning that a lot of people spent a lot of time building the reputation of. http://opensource.org/osd-annotated
I'm not just being pedantic; this matters because if Distelli advertised itself as "open source" and I invested time into it then I found out that they didn't allow me to redistribute my amazing changes or to see my friends brilliant changes I'd be really pissed off. It would mean there was no scope for building up an alternative ecosystem that wasn't under the control of Distelli and thus I'd have no real freedom.
For what it's worth (ie. not much, I'm probably not your target market), I agree with drewcrawford - If I'm looking at this kind of tool freedom is important to me and I'll check the open source options before checking the closed source ones.
I actually thought of that when I wrote my comment, but I wasn't sure if open source only meant the open source definition by the open source initiative. Apparently there's no "access to the source code" meaning if we are to believe Wikipedia.
Therefore there's three possible cateogories: closed source, open source and 'access to the source code but no free license'.
> open source only meant the open source definition by the open source initiative
Some people will argue about that point and say it ain't so, but you've seen what I think about that :-)
> 'access to the source code but no free license'.
I've never seen a good term for that but some big names do it - Atlassian used to do it with JIRA and Confluence (don't know if they still do). It's not a bad thing to do - it's just not Open Source.
Never heard of one. That sounds a bit unworkable to me tho - where would you draw the line? "I fixed your indention. In every file.". And if the parent company could control who got the original source, they could still shutdown alternative uses and thus maintain control.
Part of the central definition of open source is the users freedom; which means the producers have to give up some control.
You either go full Open Source and accept the potential loss of control or you don't (in which case be honest and don't call it that).
We don't have any custom python build. The distelli manifest just runs virtualenv and then pip to install dependencies from the requirements.txt file. Here is an example:
No matter what your product anticipates, it doesn't anticipate all the things I do, in fairly boring applications. I compile my own Python. I install postfix for some applications. I install a kernel module that increases the Linux entropy pool. You have not anticipated my set of problems.
What this means is that no matter how much great stuff your product brings to the table, I bring just as much, if not more, configuring your product and designing a deployment solution around it for my application.
If your product isn't open-source, that's a non-starter for me. Because now I'm worried that I could spend a lot of time configuring the product, and not being able to add that one feature that I need. I'm not sure if you can run a business with an open-source deployment product, but I know that I won't ever use a closed-source one.
Do a better job of explaining how these apps run. I took a look at your sample manifest files, and it wasn't clear to me if you are installing nginx or something? Or if you intend the apps to be daemon-like? So create a page that explains, in words, how to deploy a daemon-like app and how to deploy a webapp, and who is responsible for installing the web server and editing its configuration file(s) (do you clobber them?) and what web server it is supposed to be.
Finally, add a docker.io example. It's not production ready, but it looks like it's designed for people like me who have deployments involving heterogeneous payloads. I'm going to move to it eventually, so if I was to switch deployment stacks I would want good support for it.