I did not get a chance to answer all the questions during the deep dive so here is my follow up.
On Mon, Jul 3, 2017 at 8:20 AM, Ohad Levy <ohadl...@gmail.com> wrote: > > * Current state and future Roadmap >> > > I would be happy if you could also cover: > - Smart proxy features (and how it works - e.g. a container per feature > with base container etc). > I have not touched more of the core smart proxy feature management such as DHCP and DNS yet. > - Dev vs Production (whats in scope vs not) > I mentioned this in the video, but I'll recap. I have mostly targeted production setups but there are known strategies for development. There are a few ways we could consider and try to do development with this: 1) ansible-container run is local docker and has a section for dev_overrides [1]. With this you should point and mount source code directly in when using 'run' (however, run does not entirely work currently due to size of the setup) 2) Openshift could have a host path mounted for development and allow source code to be edited directly to use it as a dev environment 3) Openshift has an rsync strategy to rsync a directory to a container for development work [1] https://docs.ansible.com/ansible-container/container_yml/reference.html#dev-overrides > - Installer - do we still need it in a context of a Kubernetes > application? > I would say no given the current state of the installer. The installer is designed around a single machine deployment currently. The puppet modules themselves are not currently usable as they would each need to be tweaked to allow for deploying no runtime configuration. We could then explore trying to puppet apply them to build the containers. You could argue it is bad on me to try to not re-use them due to all the work that has gone into them. I just found starting from scratch and working with Ansible to be easier and quicker than attempting to dissect them so far. I do believe we still need an "installer" or "deployer" to orchestrate everything being configured and setup for users. Our stack can get complex, and between all the customization pieces, passwords, certificates, having a tool to manage that would be useful for user interaction and ease. > - SCL ? can we move away from it? > I think that's a big question. You are essentially asking can we move away from RPM packaging (since Deb uses gems directly if I recall). There is a valid argument for using gems directly. That would reduce build overhead, allow for development and production to be closer to together and reduce build time. We'd still want the SCL for runtime on enterprise Linux to allow for upgrading the version of Ruby as I think that is better than relying on RVM. > - reuse? for example, https://github.com/manageiq?q=container have some > basic ruby / rails containers etc > Sure, any container could be used as a base and built on top of. This would come down to how much customization do we need or is there in an existing container. Right now I build the entire stack, so every application gets a container built except for using thirdparty Postgres and Mongodb. > - application scaling ? (e.g. more dynflow workers etc). > I touched on this briefly, by default I am attempting to set services as scaled by default to enforce getting used to and dealing with those behaviors for scaling. For example, having 2 Foreman applications, 4 Pulp workers by default. I have not yet tried a 2 or more foreman-tasks replica yet. But I'll put it on my list to bump next spin up. Eric > > sorry for the long list :) > > thanks, > Ohad > >> >> >> Thanks, >> Eric >> >> >> [1] https://github.com/theforeman/forklift/pull/424 >> >> On Thu, Jun 29, 2017 at 10:15 AM, Greg Sutcliffe < >> greg.sutcli...@gmail.com> wrote: >> >>> Hi all, >>> >>> Running Foreman in a container is a question that comes up from time to >>> time in the Foreman community. Eric Helms has been experimenting with >>> running the whole Foreman stack (core, proxies, plugins) inside >>> Kubernetes, and wants to show you how it looks. We'll be holding a deep >>> dive into this on Monday 10th July, at 2pm (GMT +1). You can tune in >>> here: >>> >>> https://www.youtube.com/watch?v=mPjUvNAYp1c >>> >>> As always, we welcome your contributions to the video - do join us live >>> on YouTube Live chat or in our IRC channel to put your questions to >>> Eric! >>> >>> Cheers, >>> Greg >>> -- >>> IRC / Twitter: @gwmngilfen >>> Diaspora: gwmngil...@joindiaspora.com >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "foreman-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to foreman-dev+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Eric D. Helms >> Red Hat Engineering >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-users+unsubscr...@googlegroups.com. >> To post to this group, send email to foreman-users@googlegroups.com. >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-users+unsubscr...@googlegroups.com. > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at https://groups.google.com/group/foreman-users. > > For more options, visit https://groups.google.com/d/optout. > -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscr...@googlegroups.com. To post to this group, send email to foreman-users@googlegroups.com. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
