Roadmap #139
Comments
|
While abstracting out the container management, it would be nice if we also considered Amazon ECS as a potential runner. |
|
+10 you're right for Amazon ECS |
|
I haven't actually dug into the DNS controllers yet, but it would be nice to support Route53 instead of just bind. Check these out: I would be happy to make one for Bind9 - should be pretty simple. |
|
Hum.. +1, I'm in favor to use closed service for ensuring proper quality if the embedded open-source application is not enough. According to me we shall deploy a dummy "Route53" container (which is of course not a real one) and make it so it can be selected in the place of the bind container in the base. I'll try to make a POC asap, without the code for route53. Also, I think it's time to revive the master branch, most change which will be done starting from now will break existing infrastructure. |
|
Sweet I look forward to the PoC. Also agree on the need for an incubator branch, what if we consider it as a v10 incubator? Major version increments are the best time to make these sorts of changes IMO |
|
Yes it's going to be the incubator of 0.10.0 (remember we don't follow the Odoo version anymore. |
|
Maybe the completion of the incubator is the right time for the OCA migration too? Starting with a fresh production in a fresh repo will make it even more clear that the products are incompatible. |
|
Yep, well we can migrate there anytime we want anyway. Any news on this side ? |
|
We have incredible buy-in (3-4 delegates), so I'm certain it's happening. We won't be able to move it in before we fix things like the #141 & some other OCA things like naming standards for columns and ReadMes, so it makes sense to migrate over after the incubator. My team knows these OCA standards pretty well, so we can handle that for the most part. It's a lot of grunt work, so I'll have some juniors handle it for us most likely. I also have a set of migration regexes that help out quite a bit. It seems a lot of devs have been working towards similar goals on their own, and all agree that what you have here wins. Most recent message in the thread - https://odoo-community.org/groups/contributors-15/contributors-46578?mode=thread&date_begin=&date_end= |
|
Wow ok I wasn't aware that this thread was gotten so big o_o, will read it later. I'm already working on #141, as I said I think it's not as big as it seems. |
|
For DNS management, I would suggest you to consider the CloudFlare DNS services, as they are free and available over APIs. Also, it would be valuable to have an SSO/Identity Management, which could be Gluu. They are working on a Docker version, which can be adopted. Security Standards Compliance and Hardening belongs in a different issue, IMO. |
|
Hmmm so maybe an implementation using LibCloud, then a simple selection to determine the driver for the intended service |
|
Wow LibCloud looks like a golden mine to me, that's exactly what I hoped to find. I think we are going to have more and more demand for using external service so here is my position :
Finally, to me SSO/Identity Management/Portal are really important and will be a core feature of Clouder. We don't have a template for them yet but know that's a component which I think about since a really long time, it will be the core of Clouder for the user, where they log into, where they will be redirected to the applications hosted in the Clouder infrastructure (not just odoo, but gitlab, owncloud, rainloop, mattermost and so on). I am aiming for the same user experience we have when we use google applications, nothing less and SSO/Portal are key for this. |
|
Regarding external services, I think the way to manage them is via the Connector libraries. We can be naive of the external service itself, simply providing a dummy model like you did. That dummy model can then be inherited by a module to glue a connector into it. The best part is, it doesn't even need to be glued by service type because the connectors themselves are abstract. For example - given the connector_dns repo, the glue module would create a polymorphic _inherits between the Clouder Domain with the Connector's DNS Record. Add a bit of logic to map the two records, then the DNS synchronization is handled via the external connector library instead. This allows us to maintain a service-agnostic approach to the whole situation - all we do is write to a dummy model. |
|
The research I did on IDP/SSO solutions shows Gluu as the better open source SSO/IDP, compared with OpenAM and Shibboleth among others. This seems to be good addition: And was wondering what would be your choice for centralised logs collection solution: |
|
I believe we all agree, a service-agnostic approach was all I was looking for (same way we do for postfix template with external smtp providers), way to go. @KaloyanNaumov All good names, we'll make sure to check them out when we'll work on theses features. (On side note regarding the discussion on the OCA, I had to reply through the Odoo interface since I hadn't the mail in my mailbox, it lost the subject... grrr Odoo...) |
|
Oh, good news it seems that Salt Cloud use libcloud https://docs.saltstack.com/en/latest/topics/cloud/install/index.html, it seems we have some luck here. Since Clouder already use Stack we just have to go in that direction. |
|
Damn I love it when things are convenient! Rare case right here so let us take the time to revel in it 😆 🎉 🌮 cc @t3ddftw |
|
@YannickB - Might I suggest we make this an "Incubator Roadmap" (or similar) in Github projects instead? I'd like to continue conversations on some of these, but I think this ticket is going to get a bit hefty. |
|
I'm not used to Github projects, you're right it seems to be the way to go |
|
They're new. Turns out they're useless though - I requested this in another repo, and it's actually not possible to create cards without write access to the repo. Pretty much nullifies that possibility for everything open source - sorry to waste your time @YannickB 😦 |
|
Hum you're right... No worries. |
|
Just added a new item regarding the base image used by Clouder |
|
I haven't messed around with Alpine much, will do that this week. Docker is moving their default image to that though, so it can't be all bad. IMO most anything is better than Ubuntu though. I'm a CentOS fan personally, but that's mainly just because yum is amazing and SELinux > AppArmor. The former point is not really that important, and the latter is only relevant on the host system AFAIK. |
|
You can't run separate SELinux / AppArmor policies inside of Docker anyways; the host policies trickle down to the container by default 😉 |
|
FYI I'm in the process of ironing out a plan for the sales/billing/monitoring side of things. Will create an RFC once I have something meaningful. |
|
Oh also another feature that would be worth looking into would be automatic spin-downs/ups for idle instances, similar to Heroku. Here's an implementation that explains it better http://spin-docker.readthedocs.io/en/latest/activity_monitoring.html#stopping-idle-containers-example-workflow |
|
Updated the roadmap with libcloud, download backup, monitoring and documentation items. |
|
Updated the roadmap with self installation item. |
|
in you roadmap you missed something that I had place at the first place if I were you:
the true is that if you develop every things but you do not write the doc in the same time, and it s not an option or the thing you do when you take time to, your app will be unusable. And so, in my work to do a docker image which works to install Odoo 10 + Clouder master, I found an clouder which is so different than the doc that I can't use it. We don't know were to begin, there is no pop up help, no doc, no explaination on how to to use which option to do anything. I had understand how to work with clouder when it was in 8.0 version, but know, I do not understand anything. Please, stop develop new things, make a doc for each things which exists know, in writing that, you will understand what is not really clear or understandable, take the place of the user. |
|
About libcloud Seems to make the jod needed to create a completly automatic platform |
|
Hello @pasgou, Well I couldn't agree more. Please note that the order of item are not the order or priority. In fact at this point I should be finding a solution for the documentation, it's critical now. My own tasks were mainly swarm/alpine/libcloud and I took care of them in November. Problem is, because of that the standard installation are not working anymore. Before I start focus my own work on the documentation, I need to :
So to put it frankly : right now, the master/incubation branch is broken, until we fix it there is no point updating the documentation. About my personal situation : Honestly, I could fix thoses two points in a week, but in December/January I met financial issues and since I have to concentrate on project non-relative to Clouder this is holding me back until probably the end of January. I am more confident for February though. That's all for the update. I heard your point about the documentation, it shall be done as soon as possible now, getting more people involved and ease the pain for newcomers is the priority now. |
|
I understand completly
See your Gmail
Le ven. 6 janv. 2017 à 13:55, Yannick Buron <notifications@github.com> a
écrit :
Hello @pasgou <https://github.com/pasgou>,
Well I couldn't agree more. Please note that the order of item are not the
order or priority.
In fact at this point I should be finding a solution for the
documentation, it's critical now. My own tasks were mainly
swarm/alpine/libcloud and I took care of them in November. Problem is,
because of that the standard installation are not working anymore.
Before I start focus my own work on the documentation, I need to :
- Make the docker-compose so beginner can have an instance right away
- Finish debug with the oneclick installation, so the standard
infrastructure allow to at least deploy a working Odoo instance. The main
struggle are the DNS, as discussed in #176
<https://github.com/clouder-community/clouder/issues/176> we need to
replace bind by powerdns so we have a least the level of features we had
during Odoo Experience. Alpine broke bind unfortunately, that's why we want
to move on powerdns.
So to put it frankly : right now, the master/incubation branch is broken,
until we fix it there is no point updating the documentation.
About my personal situation : Honestly, I could fix thoses two points in a
week, but in December/January I met financial issues and since I have to
concentrate on project non-relative to Clouder this is holding me back
until probably the end of January. I am more confident for February though.
That's why all I am doing right now is answering tickets, I just don't
have the strength to throw myself into the code right now, too much
projects in mind. Still I take the opportunity to find people here in Paris
to help in the next month, I think we can create a strong community here
and since it's difficult for me to code right now I am focussed on that.
That's all for the update. I heard your point about the documentation, it
shall be done as soon as possible now, getting more people involved and
ease the pain for newcomers is the priority now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/clouder-community/clouder/issues/139#issuecomment-270898462>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIue8fPm44nQqf2hOk0SXysx4GEYY1yjks5rPjnLgaJpZM4KW7O_>
.
--
Cordialement
Pascal GOUHIER
COPAGEX
Société d'expertise comptable
Membre de la Communauté des Experts en Gestion
8 Boulevard Albert Einstein
Parc de la Rivière
44300 NANTES
T : 02 40 58 56 49
F : 02 40 95 11 81
http://www.copagex.fr
|
|
Concernant docker compose i made the Job with master and it is almost ready
for branch 0.9.0
See my github
Le ven. 6 janv. 2017 à 23:06, Pascal GOUHIER <pascal.gouhier@copagex.fr> a
écrit :
I understand completly
See your Gmail
Le ven. 6 janv. 2017 à 13:55, Yannick Buron ***@***.***> a
écrit :
Hello @pasgou <https://github.com/pasgou>,
Well I couldn't agree more. Please note that the order of item are not the
order or priority.
In fact at this point I should be finding a solution for the
documentation, it's critical now. My own tasks were mainly
swarm/alpine/libcloud and I took care of them in November. Problem is,
because of that the standard installation are not working anymore.
Before I start focus my own work on the documentation, I need to :
- Make the docker-compose so beginner can have an instance right away
- Finish debug with the oneclick installation, so the standard
infrastructure allow to at least deploy a working Odoo instance. The main
struggle are the DNS, as discussed in #176
<https://github.com/clouder-community/clouder/issues/176> we need to
replace bind by powerdns so we have a least the level of features we had
during Odoo Experience. Alpine broke bind unfortunately, that's why we want
to move on powerdns.
So to put it frankly : right now, the master/incubation branch is broken,
until we fix it there is no point updating the documentation.
About my personal situation : Honestly, I could fix thoses two points in a
week, but in December/January I met financial issues and since I have to
concentrate on project non-relative to Clouder this is holding me back
until probably the end of January. I am more confident for February though.
That's why all I am doing right now is answering tickets, I just don't
have the strength to throw myself into the code right now, too much
projects in mind. Still I take the opportunity to find people here in Paris
to help in the next month, I think we can create a strong community here
and since it's difficult for me to code right now I am focussed on that.
That's all for the update. I heard your point about the documentation, it
shall be done as soon as possible now, getting more people involved and
ease the pain for newcomers is the priority now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/clouder-community/clouder/issues/139#issuecomment-270898462>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIue8fPm44nQqf2hOk0SXysx4GEYY1yjks5rPjnLgaJpZM4KW7O_>
.
--
Cordialement
Pascal GOUHIER
COPAGEX
Société d'expertise comptable
Membre de la Communauté des Experts en Gestion
8 Boulevard Albert Einstein
Parc de la Rivière
44300 NANTES
T : 02 40 58 56 49
F : 02 40 95 11 81
http://www.copagex.fr
--
Cordialement
Pascal GOUHIER
COPAGEX
Société d'expertise comptable
Membre de la Communauté des Experts en Gestion
8 Boulevard Albert Einstein
Parc de la Rivière
44300 NANTES
T : 02 40 58 56 49
F : 02 40 95 11 81
http://www.copagex.fr
|
Hello everyone,
Ok so after Odoo Experience I have a bigger idea of what still need to be done in order to create an awesome service, here are the features planned in the next months, by order or priority :
Also note that a partner want to use OpenShift instead, we're gonna make it so you can have different runner for Clouder, regular Docker Engine, Docker Swarm, Amazon ECS or OpenShift.
We will integrate the libcloud library in Clouder so we can provision instances/containers/dns/other stuffs directly from Clouder. The link logic will be the same, but for example when you deploy a new base it'll not be linked to a DNS bind container but to a dummy container which on deploy will create a DNS record in Route53 or another provider.
Also, the visitor shoud be able to specify or buy his domain from the front.
And the design need to be greatly improved.
Salt log need to be improved (we want to see each result in clouder.job object) and the deployment log should also be visible from gitlab-ci (right now we just call a webhook)
I think it's really important to use a light base image like Alpine (recommanded by Docker), we probably can lessen the Clouder installation to around 5Go thanks to it, if not less. Remember that Dockerfile of Clouder images are here : https://github.com/clouder-images
Having an import feature would be also really interesting for migration from existing infrastructure, so we don't have to do the operation manually in the terminal. We'd just need to import the backup in the backup container and, provided the files are in the correct format, the Clouder restore feature will take care of the rest.
The text was updated successfully, but these errors were encountered: