14:01:47 <bstinson> #startmeeting CBS/Infra 14:01:47 <centbot> Meeting started Mon Oct 23 14:01:47 2017 UTC. The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:47 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:01:54 <bstinson> #topic Agenda 14:02:03 <bstinson> #info Topic: Status Updates 14:02:10 <bstinson> #info Topic: Account Requests 14:02:16 <bstinson> #info Topic: CI - Multiarch 14:02:24 <bstinson> #info Topic: CI - Open Floor 14:02:31 <bstinson> #info Topic: Open Floor 14:02:35 <bstinson> #topic Status Updates 14:03:22 <bstinson> so this sort of fits in with the multiarch section, but i have power and network to the aarch64 machines. i'll be finishing up the configs in the next couple of days 14:03:38 <Arrfab> bstinson++ 14:03:57 <sbonazzo> bstinson: ++ 14:04:18 <bstinson> all the rest of our shiny new kit in CI is in the queue to be configured as well. keep an eye out for announcements 14:04:55 <bstinson> other status updates? 14:05:29 <bstinson> Arrfab: i wasn't able to get to trying a migration to the new cloud last week, hoping to get that scheduled soon 14:05:38 <Arrfab> bstinson: I guess you read the pre-dojo meeting from last week ? unsure if we want to discuss this in status updates or open floor 14:05:44 <Arrfab> bstinson: sure 14:06:30 <bstinson> Arrfab: i read through it, can take us through a couple of topics? 14:06:36 <bstinson> #chair alphacc Arrfab kbsingh 14:06:36 <centbot> Current chairs: Arrfab alphacc bstinson kbsingh 14:07:24 <Arrfab> bstinson: well, multiple topics indeed, but one that is tied to cbs is the build-bot proposal 14:07:54 <sbonazzo> bstinson: while getting the list, can you please add to the todo list: add fc27 builds to your copr repo centos-packager ? 14:07:56 <Arrfab> what's the official status for this (couldn't find anything documented) as depending to whom I'm speaking to, I have different answers 14:08:19 <bstinson> sbonazzo: got it 14:08:27 <sbonazzo> bstinson: tnx 14:08:45 <bstinson> Arrfab: there is no official status. if we can support the email aliases that's the main thing 14:08:58 <bstinson> if we can get that, then they're more or less 'regular' accounts 14:09:47 <Arrfab> bstinson: yes, but it seems kbsingh had concerns about where the x509 key/cert would be stored, etc, and was mentioning to me something like a proper creds store in jenkins ? (so hidden to users, but used only there) 14:10:27 <Arrfab> but that would break workflow at least for RDO people, as number80 said that it's all driven from their infra (and so they'd like to keep it there) 14:10:54 <bstinson> there are 2 'bot' accounts currently out there. and what we do now, is just put the cert in their workspace (which noone else has access to) 14:11:45 <Arrfab> bstinson: yes, so actually there is no way to prevent someone using its own key/cert wherever he wants to anyway :-) 14:12:14 <Arrfab> and that's what rdo people do : it's number80's creds that are used to automate builds/tags on cbs 14:12:18 <bstinson> well, right. unless we set the password for the bots, and don't give it to them 14:13:37 <Arrfab> I'd have liked kbsingh to be here for the meeting and/or comment all the mails with his points though 14:14:46 <bstinson> i'd say let's work on the email aliases. and continue putting the certs in the jenkins workspaces 14:15:07 <bstinson> a more featureful credential store in jenkins is on the roadmap, but not soon 14:15:39 <Arrfab> ok .. worth noting that even with the alias solution, they can still use it outside of ci though, but that's already the case now anyway 14:16:21 <bstinson> yeah, there's most likely always be a way to get read access to that cert if they really try hard 14:17:07 <Arrfab> bstinson: and the fact that in the proposal here the alias would go to sig-chair (at least) they'd use centos-cert to get it themselves without us 14:18:33 <Arrfab> next topic maybe ? 14:19:30 <bstinson> well, what if we set the password, and have the bot renewal happen automatically as part of our regular cert notification/disabling process 14:20:21 <Arrfab> bstinson: what do you mean by "set the password" ? 14:20:34 <bstinson> we create the account in ACO 14:21:07 <Github-Bot> [sig-cloud-instance-build] soul9 opened pull request #110: docker: change dependencies to anaconda-tui (master...patch-1) https://git.io/vdx01 14:21:17 <Arrfab> hmm, so we'd become owner then, and not sig-chair ? 14:21:52 <mrunge> sbonazzo: for opstools, there is nothing else other than x86_64 on mirror.centos.org. Should there be more? 14:22:45 <bstinson> Arrfab: if we can do the account automatically as part of the 'new SIG' process, that's even better. we don't want people squatting on those names in ACO 14:23:35 <Arrfab> reason why the proposal was email alias, so that it can switched to different people[s] if needed 14:23:47 <sbonazzo> mrunge: rest should be on http://mirror.centos.org/altarch/7/ :-) 14:24:02 <sbonazzo> mrunge: aarch64 / ppc64le 14:24:03 <Arrfab> but we can take ownership of that .. but still, they'll ask for those creds somehow 14:24:18 <mrunge> sbonazzo: aha. I must admit, I didn't knew about that 14:24:51 <mrunge> and currently we do not support it 14:25:37 <mrunge> sbonazzo: ok, there is nothing on http://mirror.centos.org/altarch/7/ 14:25:49 <mrunge> at least, I did not miss anything :) 14:25:51 <bstinson> Arrfab: right, so we do the email alias, and point the email address for the ACO account to the alias 14:26:06 <Arrfab> bstinson: yes 14:26:51 <mrunge> sbonazzo: why should content land under /altarch at all? 14:28:12 <mrunge> rather than under mirror.c.o/centos/7/opstools 14:28:15 <bstinson> Arrfab: and we'll automatically know when a SIG cert is about to expire during your notification runs. we can just regenerate the cert then 14:32:09 <bstinson> do we want to take this back to centos-devel and come back next week? 14:32:18 <Arrfab> bstinson: yes 14:32:55 <bstinson> ok, Arrfab: did you want to write something, or should I? 14:32:57 <Arrfab> bstinson: my plan was also to start a separate thread for all points from that pre-dojo meeting , so that it would be easier to track and participate 14:33:14 <Arrfab> I'll do 14:33:24 <bstinson> ok cool 14:33:58 <bstinson> are there other topics we should touch on from the Dojo today? 14:34:32 <Arrfab> bstinson: probably, but without involved people in this meeting, it doesn't make sense to only discuss that you and me alone :-) 14:35:21 <bstinson> ok 14:35:30 <bstinson> #topic Account Requests 14:35:41 <bstinson> #info CI: Up to date 14:36:12 <bstinson> kbsingh: any update on ACO? 14:40:18 <bstinson> if not 14:40:22 <bstinson> #topic CI - Multiarch 14:40:56 <bstinson> jdetiber reported some trouble with VMs getting stuck in the Deprovision state. Hoping to track that down this week 14:40:58 <bstinson> and 14:41:12 <bstinson> (as said in the status updates section) We have some live aarch64 hardware! 14:41:16 <bstinson> VMs will come shortly 14:41:31 <Arrfab> bstinson: nice 14:41:39 <jdetiber> bstinson: yay! 14:42:02 * jdetiber is looking forward to flipping the switch for multi-arch openshift testing to include aarch64 14:42:19 <Arrfab> bstinson: btw, it seems the PR was merge for python-cico client, but nothing was released/built yet ? 14:42:25 <Arrfab> s/merge/merged/ 14:43:17 <bstinson> jdetiber: i'm going to start a thread about the distribution of the flavors we have. please comment there with your thoughts (since as of right now you're the only user of CI multiarch stuff that i can tell :) 14:43:31 <bstinson> Arrfab: yes, that's been on my list for a while 14:43:59 <Arrfab> bstinson: expect rdo people, as it was discussed at CERN last week and they're ready to jump in the train for multiarch CI 14:44:04 <jdetiber> bstinson: sure thing 14:44:17 <bstinson> Arrfab: great 14:44:45 <Arrfab> bstinson: reason why they'd ask about python-cico status btw ;-) 14:45:13 <bstinson> yep, i do know it's becoming a blocker 14:46:56 <bstinson> #topic CI - Open Floor 14:47:03 <bstinson> anyone have other topics for CI today? 14:48:14 <jdetiber> bstinson: I'm hoping to make some changes to my CI jobs to leverage the artifacts host and avoid consuming all the disk space on the slave host :) 14:49:20 <jdetiber> bstinson: is there a process for automatically purging old data on the artifact host? I want to avoid blowing up disk space there as well :) 14:49:34 <Arrfab> jdetiber: I'll discuss with bstinson but maybe we can start using more the new pike cloud to spread the load amongst multiple slaves 14:50:02 <bstinson> jdetiber: we can set a job for you, just let me know what schedule you'd like 14:50:05 <bstinson> Arrfab: already in the works 14:50:18 <jdetiber> nice! 14:50:26 <jdetiber> bstinson: sure thing, once I know more, I'll reach out 14:51:53 <bstinson> awesome 14:51:58 <bstinson> #topic Open Floor 14:52:29 <bstinson> what else do we have today? 14:53:06 <bstinson> mrunge, sbonazzo: i saw you talking through the altarch things, anything you need there? 14:53:46 <Arrfab> sbonazzo: waiting for your input in that bug report and the we can commit to git so that it should appear on mirror.c.o :) 14:54:21 <sbonazzo> Arrfab: I think I commented on the bug 14:54:59 <sbonazzo> bstinson: mrunge: it would be nice to get parity with x86_64 for opstools tags there too 14:55:23 <Arrfab> sbonazzo: ah, ok .. strangely bstinson said that 4.2 isn't released but you say the reverse so I guess that as sig chair, you know what you want to see signed and released :) 14:55:46 <sbonazzo> Arrfab: 4.2 isn't released yet upstream 14:55:47 <Arrfab> mrunge: don't forget to ask if you want to use altarch opstools pkgs landing on mirror.c.o too 14:56:14 <sbonazzo> Arrfab: so bstinson is right, but if the publish chain is set, once we tag for release everything should flow seamlesssly right? 14:56:15 <Arrfab> sbonazzo: so why would you want to see that released already on mirror.c.o ? I'd say let's wait ? 14:56:24 <sbonazzo> Arrfab: ok for waiting 14:56:27 <Arrfab> ok 14:56:32 <bstinson> sbonazzo: we can't do the publish chain until we have RPMs ready to release 14:56:43 <sbonazzo> bstinson: oh, ok 14:59:26 <mrunge> bstinson: Arrfab it would be great to set opstools up in a comparable way to virt-sig. i.e. get alt arch bits be published via /altarch ... in the same way 15:00:27 <Arrfab> mrunge: sure, so as for the usual process, can you create bug report for that ? the bug id is what we use to track in git (for link to who asked what) 15:00:47 <mrunge> Arrfab: there is already one; https://bugs.centos.org/view.php?id=13283 15:01:03 <Arrfab> yes, for ovirt :-) 15:01:10 <mrunge> not sure what is missing from my side here 15:01:17 <bstinson> mrunge: we need a separate bug for opstools 15:01:29 <bstinson> with a list of the tags you'd like synced 15:01:43 <mrunge> aha, ok. now I get you 15:01:45 <Arrfab> that, with cbs repos, and where they'll land on mirror.c.o (take that bug report opened by sbonazzo as an example) 15:02:36 <sbonazzo> need to go, see you tomorrow 15:02:37 <mrunge> would it be possible to extend, what we already have on mirror.c.o to alternative arches? 15:02:57 <bstinson> mrunge: we need you to tell us what you want 15:03:07 <mrunge> currently there's only x86_64, but that leaves much space for aarch64, ppc etc. 15:03:11 <Arrfab> http://mirror.centos.org/altarch/7/ 15:03:32 <mrunge> bstinson: -E_too_much_freedom 15:04:16 <mrunge> :P 15:05:22 <bstinson> we're over time 15:05:38 <bstinson> mrunge: if you can do a bug with details we'll get that out 15:05:54 <mrunge> bstinson: yes, thank you. will do 15:06:16 <bstinson> ok, any final pressing topics? 15:06:16 <bstinson> going once 15:06:31 <bstinson> twice 15:06:54 <bstinson> thanks all! 15:07:01 <bstinson> #endmeeting