| *** chmouel has quit IRC | 00:02 | |
| tristanC | pabelanger: what complications do you suspect? | 02:36 |
|---|---|---|
| *** chmouel has joined #softwarefactory | 07:54 | |
| *** chmouel has quit IRC | 08:05 | |
| *** chmouel has joined #softwarefactory | 08:12 | |
| *** chmouel has quit IRC | 08:25 | |
| *** chmouel has joined #softwarefactory | 08:43 | |
| *** chmouel has quit IRC | 09:14 | |
| *** chmouel has joined #softwarefactory | 09:44 | |
| *** chmouel has quit IRC | 10:55 | |
| *** chmouel has joined #softwarefactory | 11:01 | |
| *** chmouel has quit IRC | 11:32 | |
| *** chmouel has joined #softwarefactory | 11:48 | |
| *** chmouel has quit IRC | 11:52 | |
| *** chmouel has joined #softwarefactory | 12:31 | |
| *** chmouel has quit IRC | 12:52 | |
| pabelanger | tristanC: the idea to start is the keep the tenant separate, since they are 2 different teams. Right now, we don't want changes to ansible-network, to affect ansible, so I think the best place to start is to have 2 tenants. And maybe in the future, see if they will colapse. | 14:50 |
| *** chmouel has joined #softwarefactory | 14:59 | |
| *** chmouel has quit IRC | 15:37 | |
| *** chmouel_ has joined #softwarefactory | 15:37 | |
| tristanC | pabelanger: hum, it started as 2 tenants, and as they were not conflicting, they got merged like 4 sprints ago... | 15:51 |
| tristanC | the config project in ansible-network should only be used for some jobs with secret | 15:53 |
| tristanC | isn't it better to have all the ansible thing in the same project for collaboration? | 15:53 |
| tristanC | pabelanger: what is the need for an ansible-network tenant? | 15:55 |
| pabelanger | tristanC: talking with ricky, there might be reasons to keep them separate, for example, ansible-networking will have a faster release cycles (then ansible) | 15:55 |
| pabelanger | this could mean different branches and so on | 15:55 |
| tristanC | can't a tenant handle different release cycles? | 15:56 |
| pabelanger | that that ansible-network and ansible are separate orgs, I think it make sense to start out as 2 tenants. But see how we can reduce overlap | 15:56 |
| pabelanger | tristanC: basically ansible won't depend on ansible-network jobs and same for other way. | 15:56 |
| pabelanger | with that in mind, having 2 tenant seems the better approach to help stop that | 15:57 |
| pabelanger | and given that no other project so far has 2 config projects, I fear it will confuse people | 15:57 |
| pabelanger | since inheritance is complicated | 15:57 |
| pabelanger | as for what is needed in ansible-network tenant, I'd say everything in github.com/ansible-network. Which means having zuul-config / ansible-network-zuul-jobs | 15:58 |
| tristanC | pabelanger: we did forget to publish documentation, please see: https://tree.taiga.io/project/morucci-software-factory/us/1484 | 16:01 |
| tristanC | pabelanger: dci and sf also have 2 config projects in a single tenant, and it worked fine so far | 16:03 |
| pabelanger | tristanC: sure, I am not saying it won't work. Just saying there are 2 different orgs, and I don't believe lumping them into a single shared zuul configuration to start is going to be helpful. The ansible-network org is very fast moving, we can also say, testing of jobs and such before moving them into ansible tenant. i also fear, that changes to ansible-network, maybe break ansible, simply because | 16:05 |
| pabelanger | something didn't get tested properly | 16:05 |
| pabelanger | With that in mind, I think it is far to move them into separate tenants, since we are only talking about zuul configuration | 16:06 |
| pabelanger | I've also discussed with ricky about starting to upload logs into swift for vexxhost, since they have credits for the cloud | 16:06 |
| tristanC | pabelanger: it's also rewrite rules for the ansible.sf.io deployment | 16:06 |
| pabelanger | tristanC: for apache? | 16:07 |
| tristanC | pabelanger: yes, and also for the logstash and collaborative tools | 16:07 |
| pabelanger | given there isn't really and jobs running for ansible-network yet, don't really seeing may people using them right now. But agree, eventually want them | 16:08 |
| pabelanger | Talking with ricky, I think the first main goal I want to help with, is get ansible-network gating | 16:09 |
| pabelanger | even if just on ansible-zuul-jobs | 16:09 |
| pabelanger | because still people are using the github merge butting | 16:09 |
| pabelanger | button* | 16:09 |
| tristanC | isn't the ansible-network org going to use the same gating rules as the ansible org? | 16:10 |
| pabelanger | unsure | 16:11 |
| pabelanger | but it won't be same people | 16:11 |
| pabelanger | but will have different release schedules | 16:11 |
| tristanC | anyway, if you discovered concern about that story, please comment on it and we can re-evaluate it for a next sprint: https://tree.taiga.io/project/morucci-software-factory/us/1484 | 16:11 |
| tristanC | last time we talked about it, it sounded like it would be better to have a shared ansible check/gate pipelines with shared jobs | 16:13 |
| tristanC | for every ansible things | 16:13 |
| pabelanger | yes for ansible namespace, sure. it think we'll still get that | 16:14 |
| tristanC | i mean, including the ansible-network org | 16:14 |
| pabelanger | but, with ansible-network they are more roles now, which will depend only on ansible | 16:14 |
| pabelanger | ansible namespace won't depend on anything in ansible-network I think | 16:14 |
| pabelanger | I'll make a comment on taiga, but hoping we could start work on the tenant split early this coming week. | 16:15 |
| tristanC | pabelanger: shouldn't we plan this more since we already spent some time doing the oposite work? | 16:20 |
| pabelanger | tristanC: there are some notes already in https://etherpad.openstack.org/p/gundalow I've had with rcarrillocruz / gundalow | 16:24 |
| pabelanger | tristanC: step 1 on ansible-network side, is to start gating, on zuul configuration | 16:25 |
| pabelanger | but having it split across ansible / ansible-network is already confusing. | 16:26 |
| pabelanger | on thursday we found an issue with network vendor appliance and fact gathering | 16:27 |
| pabelanger | means making changes to base jobs | 16:27 |
| pabelanger | but, before that, we wanted to do the base-minimal / base change we discussed upstream and made in RDO | 16:27 |
| pabelanger | but that exposed the base-minimal in ansible/zuul-config and base in ansible-network/ansible-zuul-jobs | 16:28 |
| pabelanger | which raise the discussion that there doesn't want to be cross configuration between the orgs like that | 16:28 |
| pabelanger | since, both are really 2 different orgs | 16:28 |
| pabelanger | so talking with rcarrillocruz, we figure having 2 tenants in zuul would be a good place to start | 16:29 |
| pabelanger | and if there is some shared infra to start, that is also okay | 16:29 |
| tristanC | pabelanger: perhaps fixing the current base job to work for network applicance should be good enough to move on? | 16:33 |
| tristanC | pabelanger: also we might want to test on a isolated zuul how a single project (ansible/ansible) shared by 2 tenants work. iirc, last time i tried, changes got enqueued on both tenant and one pipelie got deadlock | 16:34 |
| pabelanger | tristanC: fixing the base job isn't problem, already something in place. It is more the fact ansible-network base jobs now live in ansible namespace. The cross namespace for configuration isn't something we want to start off with | 16:38 |
| pabelanger | tristanC: sounds like a zuul bug we need to fix, but we can not add ansible/ansible for now to ansible-network tenant | 16:38 |
| pabelanger | I expect ansible-network to be using the released version from pypi | 16:38 |
| tristanC | pabelanger: shouldn't the base job just to upload logs? i don't understand why this can't be shared | 16:39 |
| tristanC | pabelanger: it's the ansible-test job that gundalow wanted to use from the ansible/ansible project for ansible-network org | 16:39 |
| pabelanger | tristanC: okay, then lets fix zuul and test again with shared ansible/ansible | 16:41 |
| gundalow | tristanC: +1 to capturing requirements and understanding what we are trying to achieve, feel free to use the bottom of my Etherpad | 16:41 |
| gundalow | I'm back working on Wednesdays | 16:42 |
| pabelanger | tristanC: with base-mininal (trusted) the discussion is where base would live | 16:45 |
| pabelanger | right now, that was going to be ansible-network/ansible-zuul-jobs | 16:45 |
| pabelanger | however, the issue was pointed out, nothing in ansible should depend on ansible-network for zuul configuration | 16:45 |
| pabelanger | we could have ansible/ansible-zuul-jobs for the bae | 16:46 |
| pabelanger | base( | 16:46 |
| pabelanger | however, some discussion with gundalow were that zuul configuraiton would be in ansible/ansible | 16:46 |
| pabelanger | due to branching | 16:46 |
| pabelanger | and since ansible-network could have different release candence, it gets complicated fast for zuul configuration | 16:47 |
| pabelanger | with ansible and ansible-network projects are okay with shared configuration, then we could do a shared tenant | 16:47 |
| tristanC | it's getting late here, i have to go now, let's talk about this next week | 16:48 |
| pabelanger | sure | 16:48 |
| *** chmouel_ has quit IRC | 17:20 | |
| *** chmouel has joined #softwarefactory | 17:21 | |
| *** chmouel has quit IRC | 17:23 | |
| *** chmouel_ has joined #softwarefactory | 17:24 | |
| *** chmouel_ has quit IRC | 17:27 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!