Notes/Minutes from the Flock Meeting
Hi All, At Flock I was asked to take notes during the meeting. The following represents my attempt to follow the conversation and provide some logical flow. I did not record names of speakers, partially out of not knowing everyone, and partially because I didn't think of it. I strongly encourage replies with questions (to suss out details I may have glossed over) and to continue these conversations, where not already started. Please see/edit the notes here: https://fedoraproject.org/wiki/Cloud_SIG_Meeting_-_Flock_2015_-_14_August_2015_-_Rochester Thank you. regards, bex ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [DISCUSS] Making Atomic the cloud edition
I'm well past the 72 hours, so this is probably able to be ignored, but ... On 08/21/2015 06:15 PM, Joe Brockmeier wrote: But I'd also disagree we need to spin up a new SIG around this when the mapping of the Cloud SIG and Atomic interest is close to (if not exactly) 1:1. It sounds like we are talking about creating sub-working groups of fedora-cloud for base, atomic, and docker image. That does start to smell a bit like SIGs to me ... regards, bex ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Local DNSSEC resolver & Containers
On Tue, Jul 14, 2015, at 09:57 AM, P J P wrote: > Hello, > > > -> https://lists.fedoraproject.org/pipermail/cloud/2015-January/004867.html > > > As per the previous discussion above, I was able to use iptables(8) DNAT rule > to divert DNS traffic from Docker containers to a DNSSEC resolver on the host > at 127.0.0.1:53. Thanks for posting this! It's quite useful to have any progress in this area. One problem with this is you're capturing *all* traffic to port 53, but I can imagine valid use cases for skipping the local resolver. We're already seen one with the hotspot detection. Another more complex problem is that while your solution will work for the docker defaults, it's quite common to use something other than the defaults for clustered networking for e.g. Kubernetes. At a practical level, this means all tools that interact with Docker networking configuration like flannel and openshift-sdn will have to understand how to configure this. I'd still personally like to see unbound support a Unix domain socket or kdbus. It'd require NSS configuration in the container, but it avoids all sorts of hacks around container networking for local communication. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Fedocal] Reminder meeting : Fedora Cloud Workgroup
Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2015-08-26 from 17:00:00 to 18:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://apps.fedoraproject.org/calendar/meeting/1999/ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Local DNSSEC resolver & Containers
Hello Colin, all > On Monday, 24 August 2015 8:34 PM, Colin Walters wrote: > One problem with this is you're capturing *all* traffic to port 53, > but I can imagine valid use cases for skipping the local resolver. > We're already seen one with the hotspot detection. Yes, true. We realised that, but it's only a PoC for diverting container DNS traffic to the local resolver on the host. We could tweak the DNAT rule to divert specific DNS traffic, like say requests addressed to docker0(172.17.42.1) bridge interface, provided 'resolv.conf' inside Docker container holds '172.17.42.1' as the name server, instead of the Google public DNS servers. > Another more complex problem is that while your solution will work for the > docker defaults, it's quite common to use something other than the defaults > for clustered networking for e.g. Kubernetes. I see. I'm still experimenting with it, so not quite sure how different parts fit together and work together. About unbound(8) supporting Unix domain sockets, see -> https://github.com/docker/docker/issues/14627#issuecomment-122968821 The upstream 'docker/libnetwork' folks have proposed a similar solution of having a DNS proxy service on the host which will route DNS traffic between Docker containers and the host resolver. --- Regards -P J P http://feedmug.com ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
