mirroring for alternative content

Hi, We have several forms of non-Koji internal builds: 1) COPR (the most visible) 2) http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/ (this could be a COPR) 3) rpm-ostree: http://rpm-ostree.cloud.fedoraproject.org/#/ Now, I recently was allocated a new atomic01.qa.fedoraproject.org

Re: mirroring for alternative content

On Sat, Jun 21, 2014, at 10:35 AM, Kevin Fenzi wrote: Yeah, we can actually map an external IP into it if required, but I agree it isn't great to have the build host also serving external content. Though, separate from the actual content, it would be nice if it had a webserver to output live

Following up on Atomic in Fedora infrastructure

For https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image I was talking with Dennis Gilmore about some of what we would need to do in order to have Atomic be more closely integrated into the mainline infrastructure. From memory, some action items: * Define repodata.xml or similar to enable

Re: Following up on Atomic in Fedora infrastructure

Hi, I've now finished my action item for moving fedora-atomic into fedora hosted: [1]https://fedorahosted.org/fedora-atomic/ I cleaned up the repository too; we now no longer need to pull from my COPR, and also I dropped the rawhide-kernel-nodebug (for now). Should be ready to try

Re: mirroring for alternative content

On Thu, Jun 26, 2014, at 12:52 PM, Kevin Fenzi wrote: Yeah, my only worry here is that we have too much churn, but it sounds like there's some mitigation there and you have already been working on reducing that ;) I'm getting complaints about the download speed from the one-off

Re: Atomic status

Hi Stephen, Thanks for the response. On Fri, Jul 18, 2014, at 10:43 AM, Stephen John Smoogen wrote: Most of the above are also in grumpy areas of infrastructure where adding a person to fix it means they will need to learn a lot of other things before it works well or doesn't snag up

Re: Atomic status

On Fri, Jul 18, 2014, at 11:07 AM, Colin Walters wrote: Let's look at an example of another project: [1]http://www.ovirt.org/Home Other references: [2]http://openstack.redhat.com It has its own yum repositories on Fedorapeople, though it appears to also have RPMs regularly going

Re: Atomic status

On Fri, Jul 18, 2014, at 11:30 AM, Joe Brockmeier wrote: Yes and no. I think we should probably work as a Remix for the F21 timeframe while still trying to get as much in for the Cloud Product as possible - and then try to be well-integrated with Fedora infra within the F22 timeframe. But

Re: Atomic status

On Fri, Jul 18, 2014, at 01:01 PM, Kevin Fenzi wrote: I think the plan here was to get a koji plugin? I think Dennis was thinking it would be run as part of the compose script, like pungi? Although we didn't take minutes which was a mistake, that was my understanding. I'm not sure there's a

Re: Atomic status

On Fri, Jul 18, 2014, at 04:48 PM, Matthew Miller wrote: From when we last talked, I thought you were going to bring up this last one as a policy question on the Fedora Cloud list? But also from our discussion, it doesn't look like keeping even full history would be hugely significant --

Re: Atomic status

One of the issue we will have is that Fedora infrastructure is used in production for Fedora, so i think we will not have as much agility if we start to target it right from the start. Right. But on the other hand if we do it, then it is actually integrated in a way that's potentially

Followup on Atomic composes

From: 15:36:25 dgilmore walters: i have it working for the TC/RC process. I need to change up a few things. not yet looked at doing it for rawhide/branched yet Are there any blockers to setting up the rawhide/branched parts? Anything I can help with? In particular, will these composes write

Re: Followup on Atomic composes

On Tue, Jul 22, 2014, at 05:40 PM, Matthew Miller wrote: On Tue, Jul 22, 2014 at 08:07:39AM -0400, Colin Walters wrote: In the meantime though, Atomic still needs a mechanism to *try* code that's in development. So I may look at having the internal compose server be a pull from COPR type

Re: Good time to sync Thursday or Friday morning?

On Tue, Jul 29, 2014, at 04:51 PM, Joe Brockmeier wrote: Colin, Dennis - can you do Friday 9 a.m. Eastern? Works for me. ___ infrastructure mailing list infrastructure@lists.fedoraproject.org

Re: Good time to sync Thursday or Friday morning?

Yep. - Original Message - Colin, Dennis - can you do Friday 9 a.m. Eastern? Best, jzb - Original Message - From: Dennis Gilmore dgilm...@redhat.com To: Joe Brockmeier j...@redhat.com Cc: Colin Walters walt...@redhat.com, infrastructure@lists.fedoraproject.org

Re: rhel6 - rhel7 migrations status

On Fri, Oct 10, 2014, at 01:51 PM, Kevin Fenzi wrote: impossible:· These are ones where it's not really possible to move the current thing to 7, and we are waiting for the next major version. bodhi* (bodhi1) collab* (mailman2) hosted-lists* (mailman2) mirrorlists (mirrormanager)

Re: rhel6 - rhel7 migrations status

On Thu, Oct 16, 2014, at 10:08 PM, Toshio Kuratomi wrote: I've recently taken a look at socket as part of working at ansible. Socket? It should definitely be possible to do this (and even to use ansible playbooks to partially provision/configure the containers. However you would need to

Re: users belonging to tenant in FedoraCloud

On Thu, Mar 12, 2015, at 10:30 AM, Miroslav Suchý wrote: In new OpenStack instances users belong to this tenants: ... - { name: cockpit, email: 'walt...@redhat.com', tenant: scratch, password: {{cockpit_password}} } The login here doesn't actually work for me in the new cloud; is it

Re: users belonging to tenant in FedoraCloud

On Thu, Mar 12, 2015, at 10:30 AM, Miroslav Suchý wrote: In new OpenStack instances users belong to this tenants: ... - { name: cockpit, email: 'walt...@redhat.com', tenant: scratch, password: {{cockpit_password}} } The login here doesn't actually work for me in the new cloud; is it

Re: users belonging to tenant in FedoraCloud

On Tue, Mar 24, 2015, at 09:40 PM, Kevin Fenzi wrote: Thats great, but the new cloud is not yet done. It's not open for business. ;) We are going to reinstall it at least one more time before we put it in service. So, I can send you info, but you should realize any instances you make can and

Re: users belonging to tenant in FedoraCloud

On Wed, Mar 25, 2015, at 05:14 AM, Miroslav Suchý wrote: On 03/24/2015 11:29 PM, Colin Walters wrote: - { name: cockpit, email: 'walt...@redhat.com', tenant: scratch, password: {{cockpit_password}} } Colin, to which FAS account this maps? walters I have walt...@redhat.com set

Re: firewall blocking atomic01.qa access to RHN/registry.access.redhat.com

On Fri, Apr 24, 2015, at 12:14 PM, Kevin Fenzi wrote: So, can you try and get those things via external? ie, instead of using an internal ip and trying to cross that great firewall, use external IPs and access like any other customer? Ah I see, the DNS is shared right now. I think I found

firewall blocking atomic01.qa access to RHN/registry.access.redhat.com

Hi, I'm trying to set up a Docker/Kubernetes/Atomic cluster in VMs on atomic01.qa to prototype out some alt.fp.org rel-eng work - using RHEL7 Atomic, but not being able to access subscription.rhn.redhat.com or registry.access.redhat.com is a pain. Is there a reason this is being blocked? In

[PATCH] Send SIGHUP to libvirt in notify on all hosts, not just buildhw

.) This patch (not tested as I'm not aware of an easy way to do so) should hopefully help me use libvirt on atomic01.qa. From 3d08ba991ebdd3f5c50e36354b6275587b17adcd Mon Sep 17 00:00:00 2001 From: Colin Walters walt...@verbum.org Date: Mon, 27 Apr 2015 21:24:17 -0400 Subject: [PATCH] Send SIGHUP

Re: [PATCH] Send SIGHUP to libvirt in notify on all hosts, not just buildhw

On Tue, Apr 28, 2015, at 01:18 PM, Kevin Fenzi wrote: ok, but it's not complete. When you change an handler name, it needs to be changed where it's called too. Ah right, thanks for catching that. So, I commited the following, can you see if it meets your needs and if not we can adjust it

Re: Proposal to mirror Docker images

On Tue, Aug 16, 2016, at 11:33 AM, Randy Barlow wrote: > In summary, the proposal is to write a patch for the docker client that > > will give it the capability

Re: Cert penning, Certs and related

On Mon, Oct 10, 2016, at 01:04 PM, Kevin Fenzi wrote: > On Mon, 10 Oct 2016 16:57:25 + > Patrick Uiterwijk wrote: > > ...snip... > > > As far as I know, yum/dnf supports setting a cafile for repos, so we > > can just update fedora-repos. > > That doesn't help. If

Re: Cert penning, Certs and related

On Wed, Oct 12, 2016, at 03:17 PM, Kevin Fenzi wrote: > Sure, but they won't. They will complain that we have an invalid cert > and we will need to explain to them whats going on. ;) I still think this would be mostly covered if the yum repo files and the ostree remote config had a comment

Re: Proposal to mirror Docker images

On Thu, Sep 1, 2016, at 10:49 AM, Colin Walters wrote: > Related to this, I think it'd be useful to target public IaaS (AWS, GCE, etc.) > for inside-infra mirrors. Basically we want Fedora images to hit a S3 bucket > in > the region or equivalent by default for content. This i

Re: Cert penning, Certs and related

On Wed, Nov 23, 2016, at 12:10 PM, Kevin Fenzi wrote: > I suppose thats workable if all the stakeholders agree. To confirm, are you agreeing with: > So I'd propose pinning to a 3 set of CAs: > > - Digicert > - Some other well-regarded CA vendor > - A Fedora-infra custom CA (doesn't have to

Re: Cert penning, Certs and related

On Mon, Nov 28, 2016, at 11:20 AM, Kevin Fenzi wrote: > > Yeah. I am not sure the process we will need to use to get some other > CA vendor. RH has a relationship with digicert, so we get our certs via > that. When using another vendor we may have to go through some > red-tape. So, I can't

Re: Cert penning, Certs and related

On Fri, Oct 14, 2016, at 08:42 AM, Colin Walters wrote: > > Anyways, there's a higher level question here - you're arguing > for pinning to Digicert rather than a custom CA. That seems good > enough, but I think we need a recovery mechanism in case Digicert > explodes. > > S

Re: Cert penning, Certs and related

On Mon, Oct 10, 2016, at 01:58 PM, Kevin Fenzi wrote: > > But does that not mean anyone going to the same place with a browser or > command line downloading specific packages will get a "sorry, this cert > is not trusted" ? Thats not such a big deal for ostree's, but for rpms, > people do this

src.fedoraproject.org vs pkgs.fedoraproject.org and TLS

Did we lose TLS-authenticated access to the pkg git? I see on the cgit webpage: https://src.fedoraproject.org/cgit/rpms/golang-googlecode-go-crypto.git/ It only offers anonymous transports without integrity (http://, git://). Specifically for the CentOS Atomic Host SIG builds we go out of our

Re: Cert penning, Certs and related

On Tue, Dec 13, 2016, at 01:49 PM, Stephen John Smoogen wrote: > So the parts I think I am seeing different answers are: > 1. What are we trying to accomplish and where? > 2. What infrastructure is needed to accomplish this? I think this stuff is pretty well covered in the thread and should be

Re: src.fedoraproject.org vs pkgs.fedoraproject.org and TLS

On Tue, Dec 13, 2016, at 11:23 PM, Kevin Fenzi wrote: > > We missed fixing this when we made changes sunday night. > Oops. Thanks for pointing it out. > > I have now done so, and it should only offer https:// It works now, thanks! https://github.com/CentOS/sig-atomic-buildscripts/pull/202

Re: Cert penning, Certs and related

On Fri, Dec 9, 2016, at 05:38 PM, Stephen John Smoogen wrote: > I don't think anyone is understanding each other.. because that isn't > what I was getting from this thread until now. The thread has been 95% just me and Kevin on and off over the last 6 months. I asked him for clarification.

Re: Cert penning, Certs and related

On Tue, Nov 29, 2016, at 02:00 PM, Kevin Fenzi wrote: > The various browsers already have our digicert cert hard coded. > So, if we ever had problems with that cert and had to switch to the > secondary or tertiary certs, all browser access would be broken. ;( > > So, perhaps we should be more