I did not get a chance to answer all the questions during the deep dive so
here is my follow up.
>
> * 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:
- 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)
- Openshift could have a host path mounted for development and allow
source code to be edited directly to use it as a dev environment
- 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
···
On Mon, Jul 3, 2017 at 8:20 AM, Ohad Levy wrote:
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.sutcliffe@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: gwmngilfen@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+unsubscribe@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+unsubscribe@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+unsubscribe@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
