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