Re: Taskotron and Cloud Image tests
On Thu, 17 Apr 2014 17:35:13 +0200 Vitaly Kuznetsov vkuzn...@redhat.com wrote: snip Another possible snag is that I want to start locking down network access on most if not all of the test clients so that it's less possible for user-submitted tasks to go awry and do things they shouldn't. This hasn't been done yet, though and it's something that we can discuss going forward. For valid we'll require two things: 1) Access to Cloud's (AWS, Openstack, ...) endpoint 2) SSH to running VM Interfacing with EC2 wasn't a use-case that I was thinking of for network isolation of the taskotron clients, so those plans may change somewhat. The clients aren't isolated yet, so this won't be a problem immediately. Can we have special dedicated test client for valid? That would make sense from securitty pov as we need to store cloud access credentials there. I suppose that we could but I'd really prefer to avoid that if at all possible. Having one special client isn't an issue but it does open the door to other task authors asking for the same thing and that will get unmanageable pretty quick. That being said, I'm not sure how to go about managing credentials like that in a secure fashion. This'll require some more thought but suggestions are certainly welcome :) Tim signature.asc Description: PGP signature ___ 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: [cloud] #14: Investigate systemd-networkd
#14: Investigate systemd-networkd --+ Reporter: mattdm| Owner: janeznemanic Type: task | Status: new Priority: normal| Milestone: Fedora 21 (Alpha) Component: Cloud Base Image | Resolution: Keywords:| --+ Comment (by mattdm): Replying to [comment:17 janeznemanic]: So what's the plan here? How do we proceed? What shall I do? It might be useful to put together a variant of the kickstart file used to produce the current cloud image which uses systemd-networkd for eth0 instead of initscripts. See https://git.fedorahosted.org/cgit/spin- kickstarts.git/tree/fedora-cloud-base.ks and basically search for network for parts that might need to be changed. Then, you should be able to feed that kickstart file into ImageFactory (or appliance-creator) and get a qcow2 image we can test. I suppose that someone should file an RFE for systemd to have a generator (that's a typical systemd construct) for handling legacy ifcfg files (as above), and to create the ifup/ifdown compatibility scripts. Most ideally, someone will contribute that as patches to systemd upstream, because code always speaks louder than wishes :) but, just explaining what we need is a good start. -- Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:18 cloud https://fedorahosted.org/cloud Fedora Cloud Working Group Ticketing System ___ 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: [cloud] #46: Project Atomic and Fedora Docker Host Image
#46: Project Atomic and Fedora Docker Host Image ---+- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Fedora 21 (Branch) Component: Docker Host Image | Resolution: Keywords: meeting| ---+- Comment (by hguemar): Tough choice, though the Atomic Host way is awesome, it's still in early stages and might even scare the majority/laggards. At least for F21, we should provide both ways if possible. If we had to chose only one, it seems logical that we focus on the Atomic Host considering our mission statement: Atomic is TEH future ! -- Ticket URL: https://fedorahosted.org/cloud/ticket/46#comment:2 cloud https://fedorahosted.org/cloud Fedora Cloud Working Group Ticketing System ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
