| *** sfbender has joined #softwarefactory | 05:33 | |
| sfbender | Tristan de Cacqueray created software-factory/python-log2gearman-distgit master: Add missing paho-mqtt worker requirement https://softwarefactory-project.io/r/13487 | 05:33 |
|---|---|---|
| *** nchakrab has joined #softwarefactory | 06:23 | |
| nchakrab | Hey folks, I am trying to add https://github.com/ansible-network/vyos/ repo to https://softwarefactory-project.io/r/#/c/13403/1/resources/tenant-ansible.yaml. Can anyone please point me to the repo that I need to clone and raise a PR for adding `-ansible-network/vyos`? | 06:30 |
| tristanC | nchakrab: on that click, you can click the "gear" next to the project name to get clone command | 07:15 |
| tristanC | nchakrab: it's "git clone https://softwarefactory-project.io/r/config" | 07:16 |
| tristanC | nchakrab: https://softwarefactory-project.io/docs/user/contribute.html | 07:16 |
| nchakrab | tristanC: Thanks! Cloned the repo. | 07:22 |
| *** jpena|off is now known as jpena | 07:36 | |
| nchakrab | tristanC: Successfully pushed the changes using git review | 07:48 |
| nchakrab | Requesting you to have a look at it. Thanks! | 07:48 |
| tristanC | nchakrab: nice, thanks! i've approved it | 08:02 |
| nchakrab | Thank you! | 08:02 |
| tristanC | once it's merged, a config-update job will run to apply the configuration, the new project should be registered in few minutes in https://ansible.softwarefactory-project.io/zuul/projects.html | 08:02 |
| nchakrab | Do I need to merge it? | 08:06 |
| nchakrab | tristanC: ^ | 08:06 |
| tristanC | nhicher: zuul merge the change when it's approved, it actually just merged | 08:06 |
| nchakrab | Ok. Great! | 08:10 |
| *** jpena is now known as jpena|lunch | 11:03 | |
| ganeshrn | https://github.com/ansible-network/yang/pull/7 <-- need help with this PR | 11:27 |
| ganeshrn | i want hold the junos node so that i can ssh and try to figure out the root cause of failure | 11:27 |
| tristanC | ganeshrn: i'll add an autohold for the yang_fetch-vqfx-devel-py2 job | 12:00 |
| nhicher | /names | 12:03 |
| *** jpena|lunch is now known as jpena | 12:09 | |
| ganeshrn | tristanC: thanks | 12:19 |
| tristanC | ganeshrn: how to add your key on such nodes? the shell is admin@test> ... | 12:28 |
| *** nchakrab has quit IRC | 12:29 | |
| tristanC | oh, sftp works, let me copy your key | 12:29 |
| tristanC | ganeshrn: you should be able to ssh admin@38.145.35.108 using your github ssh key | 12:31 |
| ganeshrn | tristanC: yes i can login | 12:32 |
| ganeshrn | thanks for the help | 12:32 |
| gundalow | tristanC: pabelanger rcarrillocruz How do you you think we can proceed with tenant configuration (end of) https://etherpad.openstack.org/p/gundalow | 14:25 |
| tristanC | gundalow: not sure if rcarrillocruz documented what he would like to have. we could proceed with any choosen proposal | 14:27 |
| gundalow | ah, good spot | 14:28 |
| tristanC | i would prefer proposal C as it only need better documentation, but don't mind any other proposals | 14:29 |
| rcarrillocruz | i prefer different tenants prroposal | 14:36 |
| rcarrillocruz | if it can be done within SF, let's be it | 14:36 |
| rcarrillocruz | we don't have a common CI team across all Ansible | 14:36 |
| rcarrillocruz | different teams have different needs | 14:37 |
| rcarrillocruz | different secrets, different cloud providers needs | 14:37 |
| rcarrillocruz | etc | 14:37 |
| rcarrillocruz | having two trusted projects is confusing, regardless of documentation, and can wedge things | 14:37 |
| * rcarrillocruz goes away for other call | 14:37 | |
| pabelanger | would agree with 2 tenants too, even to start. Merging back to a single tenant down the road could be a long term goal too. | 14:44 |
| tristanC | rcarrillocruz: having a common CI across all Ansible is why i think we should try to make a single tenant work as needed | 14:44 |
| pabelanger | we'll be making pipeline changes for ansible-network to be gating, and since ansible/ansible isn't up to speed yet for CI configuraiton, we don't want to confuse their pipelines too | 14:45 |
| tristanC | pabelanger: why would it confuse the pipelines? | 14:46 |
| pabelanger | could see confusion if SF bot started leaving comments on a check job in ansible/ansible if configured | 14:47 |
| pabelanger | today, it is not reporting IIRC. | 14:47 |
| pabelanger | we'll need zuul to start dropping label to start gating | 14:47 |
| gundalow | Just for clarification, one of the business goals of the Galaxy roles under gh/ansible-network was so the Network Team can release Ansible Roles independently from Ansible. ie Roles can be release every two weeks, where as Ansible releases only 2-3 times a year | 14:47 |
| gundalow | pabelanger: Could you please expand on `we'll need zuul to start dropping label to start gating`? | 14:48 |
| rcarrillocruz | tristanC: that's the thing, organization wise, we don't have a common CI team. It would make sense to have one tenant if we have one, but we don't | 14:48 |
| pabelanger | basically, I think ansible-network is ready to gate on zuul and start experimenting on the faster release cycle that gundalow just mentioned. I think ansible/ansible needs more planing and dicussing with the larger community | 14:48 |
| rcarrillocruz | therefore, it makes sense to setup the tenants to mimic our orgs | 14:48 |
| rcarrillocruz | there's no word on whether core is going to adopt zuul | 14:48 |
| tristanC | gundalow: i don't understand why you can't have 2 project with 2 different releases system not share the same tenant and pipelines | 14:48 |
| rcarrillocruz | or galaxy | 14:48 |
| rcarrillocruz | or tower | 14:48 |
| rcarrillocruz | they may | 14:48 |
| rcarrillocruz | may be not | 14:49 |
| rcarrillocruz | there's no schedule | 14:49 |
| rcarrillocruz | please let's not confuse branching and releases with tenants | 14:49 |
| rcarrillocruz | let's talk about the tenants | 14:49 |
| pabelanger | gundalow: we need to configure the zuul github app to vote on a PR, I believe this is done with label in github | 14:49 |
| pabelanger | gundalow: so, then zuul will first look to that, to ensure all tests passed, before adding the PR into gate pipeline and trying to merge | 14:49 |
| gundalow | TristanC I was just giving background, I currently have no preference on single vs multi tenant | 14:50 |
| tristanC | pabelanger: you can do with 'status', and the gate pipeline is already configured to required a check success status | 14:50 |
| pabelanger | ah, okay. Getting term mixed up | 14:50 |
| rcarrillocruz | here's my vote: | 14:51 |
| rcarrillocruz | 1 prefer two tenants | 14:51 |
| rcarrillocruz | now, if two tenants are not possible due to SF resources or limitations | 14:52 |
| rcarrillocruz | we rename ansible tenant to ansible-network tenant | 14:52 |
| rcarrillocruz | and ew consolidate all jobs in ansible-network zuul-config | 14:52 |
| rcarrillocruz | having two trusted projects is a no go to me | 14:52 |
| pabelanger | yah, that would work too | 14:52 |
| pabelanger | until ansible/ansible as a community has the zuul discussion | 14:53 |
| rcarrillocruz | in the end, what we are going to test in ansible/ansible are *just* network things, i.e. things my team takes care | 14:53 |
| rcarrillocruz | so it makes sense to have it on our namespace | 14:53 |
| rcarrillocruz | otherwise contributors may look around ansible namespace, which obviously has more eyes than ansible-network, and will just 'assume' 'oh, this is the new zuul ci thing, let me PR against it' | 14:53 |
| pabelanger | tristanC: how does ^ sound? | 14:54 |
| tristanC | that sounds like what we had before we migrated stuff to a/z-c :) | 14:55 |
| tristanC | i thought the goal with the merge was to aim for a common ci accross ansible things | 14:56 |
| rcarrillocruz | well, i never said to have a zuul-config on ansible/ansible AND ansible-network, i wasn't part of that conversation | 14:56 |
| rcarrillocruz | tristanC: we use the tools to serve our processes, the thing is we don't have a common CI team, therefore we said to have two tenants | 14:56 |
| rcarrillocruz | now you pushed back, cos you said it was hard for SF | 14:56 |
| rcarrillocruz | to support multitenant | 14:56 |
| rcarrillocruz | the vhosts on ansible.sf.io etc | 14:57 |
| tristanC | rcarrillocruz: it's not particular hard for SF, i just want to get this story right and not have to revert changes in a few weeks | 14:57 |
| pabelanger | I don't know if it is hard, but maybe not something supported right now on a single SF install | 14:57 |
| pabelanger | at least that is what I understand from ticket | 14:58 |
| rcarrillocruz | ok tristanC | 14:58 |
| rcarrillocruz | i thikn it's better for you | 14:58 |
| rcarrillocruz | to have one tenant | 14:58 |
| rcarrillocruz | right? | 14:58 |
| rcarrillocruz | it's more appealing than two ? | 14:58 |
| rcarrillocruz | cos frankly, what i'm -2 is two trusted projects | 14:58 |
| rcarrillocruz | i think tenants to isolate is good, but not a blocker for me | 14:58 |
| gundalow | Yup, is "Do we have to use two trusted projects" the real question here? | 14:59 |
| rcarrillocruz | in the end , dev moving forward is going to be largely in ansible-network for us, not ansible/ansible | 14:59 |
| rcarrillocruz | ansible/ansible will stay mostly frozen | 14:59 |
| pabelanger | gundalow: I think it was the comment about ansible/ansible not depending on ansible-network namespace for jobs | 14:59 |
| gundalow | for gh/ansible/ trusted config shouldn't change much | 14:59 |
| pabelanger | which, if 2 tenants, makes that easy to protect | 14:59 |
| tristanC | i don't mind either way, but as you say, if a/a is frozen, then why bother with having a tenant for a/a/ ? | 14:59 |
| pabelanger | in a single tenant, it is up to users to try and pervent that | 15:00 |
| rcarrillocruz | tristanC: ok, then i think we have a winner | 15:00 |
| rcarrillocruz | single tenant | 15:00 |
| rcarrillocruz | rename to ansible-network | 15:00 |
| rcarrillocruz | ditch ansible/zuul-config | 15:00 |
| rcarrillocruz | keep ansible-network/zuul-config as single trusted project | 15:00 |
| rcarrillocruz | as for branching, which is what gundalow was concerned about, that doesn't matter where it lives, the branches are a repo thing | 15:00 |
| rcarrillocruz | meaning | 15:00 |
| rcarrillocruz | we can have devel/stable-2.6, etc jobs | 15:00 |
| rcarrillocruz | in ansible-zuul-jobs | 15:01 |
| tristanC | so that's new proposal, would you mind recording it in the etherpad please? | 15:01 |
| rcarrillocruz | and even ansible-network/zuul-config | 15:01 |
| gundalow | I don't want branches in anything apart from ansible/ansible. Need to have all of of what changes in the ansible/ansible repo | 15:02 |
| tristanC | i mean we'll propose a story with action item, and add it to the next sprint | 15:02 |
| rcarrillocruz | done | 15:02 |
| rcarrillocruz | gundalow: that's not an issue, if you want to have all job definitions for ansible/ansible and not depend anywhere, then you put zuul.d within it with the job definitions | 15:03 |
| pabelanger | gundalow: I think that will work, the part we might need to dive into is branching zuul config project, etc zuul-config. It possible to branch that, but so far zero projects are doing it. I think my suggestion would be to keep that branchless for easy of use | 15:03 |
| pabelanger | and keep backwards support of jobs until stable branches are retired | 15:04 |
| gundalow | Though a/a is not trusted, so we can test the PRs | 15:04 |
| gundalow | Currently I think it's only the base jobs that are outside of a/a | 15:04 |
| pabelanger | yah, I don't think ansible/ansible would be trusted, because just for that reason no pre-merge testing | 15:05 |
| pabelanger | gundalow: right | 15:05 |
| rcarrillocruz | it can't be ... ansible/ansible is not a trusted project | 15:05 |
| rcarrillocruz | it's a repo that contains software that we want to test | 15:05 |
| tristanC | pabelanger: https://git.zuul-ci.org/cgit/zuul/tree/zuul/configloader.py#n1934 seems to indicate only the master branch is loaded from config-projects | 15:05 |
| rcarrillocruz | a trusted project is roughly a zuul specific repo | 15:05 |
| rcarrillocruz | to host | 15:05 |
| rcarrillocruz | base jobs | 15:05 |
| rcarrillocruz | secrets | 15:05 |
| rcarrillocruz | and that about it | 15:05 |
| pabelanger | tristanC: yah, I don't think we've every discussed multi branch for config project | 15:06 |
| pabelanger | I think zuul would get very complicated fast in that case | 15:06 |
| gundalow | adding more branches in sounds like it's making it more complex, and moving away from your existing established workflowa | 15:07 |
| gundalow | workflows* | 15:08 |
| rcarrillocruz | i'm confused gundalow , you said jobs needed to be versioned... i.e. jobs for ansible devel, devel branch on ansible-zuul-jobs | 15:13 |
| rcarrillocruz | stable-2.5, stable-2.5 jobs branch | 15:13 |
| rcarrillocruz | etc | 15:13 |
| rcarrillocruz | i mean, we need to have the jobs in branches accordingly...it's part of how zuul works, it implictly checks out the branch being tested | 15:13 |
| gundalow | I thought you meant branched zuul-config | 15:16 |
| gundalow | As well as branched a/a | 15:17 |
| rcarrillocruz | upstream openstack does not have branched zuul-config, i think some have it hacked it up, but is not the common case | 15:18 |
| rcarrillocruz | the branches are in the untrusted repos | 15:18 |
| gundalow | OK | 15:18 |
| pabelanger | gundalow: right, I think from ansible POV and workflow, you can keep your current branching strategies but for zuul base jobs and some zuul config, I would think it will be easier to manage if branchless. | 15:19 |
| pabelanger | zuul jobs have setting for branch selection and overrides | 15:20 |
| pabelanger | so we can have 2 jobs in a single branch, but will work differently on branch A and B | 15:20 |
| pabelanger | so far with openstack and rdoproject, a master branch for zuul config has worked well | 15:20 |
| pabelanger | while projects themself branch at will | 15:20 |
| rcarrillocruz | yeah, and if three's really a need for a base job that is only needed in a branch, is not the end of the world to create a new one with a different name | 15:23 |
| gundalow | +1 | 15:24 |
| rcarrillocruz | gah, other call | 15:25 |
| rcarrillocruz | what a day | 15:25 |
| rcarrillocruz | ttyl | 15:25 |
| pabelanger | gundalow: rcarrillocruz: https://zuul-ci.org/docs/zuul/user/config.html#attr-job.branches would be the job setting | 15:26 |
| pabelanger | even has an example | 15:26 |
| pabelanger | you'd likely do that for per branch base jobs | 15:26 |
| pabelanger | however, I've yet to see an example where that is needed | 15:27 |
| gundalow | As most configuration for a/a will be in the branch, including job definitions which specify modest. I agree I doubt we'd need that | 15:28 |
| gundalow | The reason I keep on going on about a/a is we need to support testing n-3 major releases and things will change dramatically over time | 15:29 |
| gundalow | As long as that requirement is met I don't care much | 15:30 |
| gundalow | If we have separate tenants does that mean we have separate VM resource pools? | 15:31 |
| pabelanger | no, VM pools can be shared across tenants right now | 15:35 |
| pabelanger | gundalow: is there a list of nodesets that ansible/ansible needs today? | 15:36 |
| rcarrillocruz | none unfortunately | 15:37 |
| pabelanger | gundalow: again, in openstack-infra, we had openstack-zuul-jobs which contained things like default nodesets and job templates, which projects would use | 15:37 |
| rcarrillocruz | pabelanger: let me link what i worked on since last week | 15:37 |
| pabelanger | then, more specific testing needs would be contained in openstack-dev/devstack, since that is the default testing platform | 15:37 |
| rcarrillocruz | https://github.com/ansible-network/yang/pull/7 | 15:37 |
| rcarrillocruz | check the depends on | 15:37 |
| rcarrillocruz | the idea is | 15:38 |
| rcarrillocruz | a n integration job will be made of two nodes | 15:38 |
| rcarrillocruz | a controller (fedora for example) | 15:38 |
| gundalow | pabelanger: today just `ansible-network-vyos-1.1.8` for a/a | 15:38 |
| pabelanger | so far, I've found keeping nodesets out of branches to be a good practice, but means nodesets need to live as long as the oldest branches | 15:38 |
| rcarrillocruz | and an appliance | 15:38 |
| rcarrillocruz | vyos | 15:38 |
| rcarrillocruz | vqfx | 15:38 |
| rcarrillocruz | nxos | 15:38 |
| pabelanger | but, the majority of testing in openstack is on LTS platforms, so ubuntu / centos | 15:38 |
| rcarrillocruz | right now we just have vqfx, the ansible-network-vyos is somethingi pulled up with the nested VM idea | 15:38 |
| rcarrillocruz | but since we are going to vexxhost for nodepool, we don't share a sec group | 15:39 |
| pabelanger | with the appliances you listed, I think they could be in a branchless project for all branches to use | 15:39 |
| rcarrillocruz | so we can have appliances running witout opening ports that may not be relevant to other node types for other tenants/projects | 15:39 |
| pabelanger | then only removed, once all jobs have been retired | 15:39 |
| pabelanger | and the cool thing about zuul | 15:39 |
| rcarrillocruz | ( i know now nodepool you can specify a sec group, ,but months ago it was just 'default' secgroup) | 15:39 |
| pabelanger | you cannot just remove a nodeset if still in use by a job in a branch | 15:39 |
| pabelanger | so there shouldn't be a way to break job config | 15:40 |
| pabelanger | rcarrillocruz: is there any redistubtion issues with some of the images? | 15:41 |
| rcarrillocruz | with these, we don't | 15:41 |
| rcarrillocruz | there are some we are using in DCI that we shouldn't be using in CI, but... | 15:41 |
| rcarrillocruz | i want get rid of them | 15:41 |
| pabelanger | okay | 15:41 |
| pabelanger | rcarrillocruz: and some are using nested virt? | 15:42 |
| rcarrillocruz | with the nested approach, i was | 15:42 |
| rcarrillocruz | i.e. the ansible-network-vyos it's a fedora, that on boot launches with qemu and nested virt enabled a vyos appliance | 15:42 |
| rcarrillocruz | but the vqffx thing i pasted, it's not a nested image | 15:42 |
| rcarrillocruz | is THE vqfx | 15:42 |
| rcarrillocruz | that's why i need a controller, two nodes nodeset | 15:43 |
| rcarrillocruz | so i can checkout the PR, and do 'ansible-playbook tests/test.yml' kind of thing | 15:43 |
| pabelanger | yah | 15:43 |
| pabelanger | rcarrillocruz: is there any plans for ubuntu testing? | 15:43 |
| pabelanger | right now I think you are using fedora | 15:43 |
| rcarrillocruz | we don't care | 15:44 |
| rcarrillocruz | the roles and modules we write interact with network appliances | 15:44 |
| rcarrillocruz | the only thing we do care from testing perspective is py2 and py3 | 15:44 |
| pabelanger | I've found, since fedora is fast moving, it is a little disruptive for jobs. And maybe consider some LTS for that | 15:44 |
| rcarrillocruz | and branches, e.g. devel, 2.6 | 15:44 |
| pabelanger | hopefully centos-8 in coming months | 15:44 |
| rcarrillocruz | pabelanger: i don't care, providing we can have py2 and py3, we can use ansible with pip | 15:44 |
| pabelanger | okay, so maybe ubuntu-bionic | 15:45 |
| pabelanger | gives you 2 years | 15:45 |
| pabelanger | before moving again | 15:45 |
| pabelanger | python3 on centos-7 is a non starter sadly | 15:45 |
| pabelanger | unless you pull in a bunch of external repos | 15:45 |
| rcarrillocruz | pabelanger: i think from 'politics' perspective, maybe better centos with external repos | 15:46 |
| rcarrillocruz | like, i got asked 'why you test ovs against ubuntu, you should use centos/fedora' :P | 15:46 |
| pabelanger | yah | 15:47 |
| pabelanger | there is just some issues with dual python stack right now | 15:47 |
| pabelanger | openstack is having a hard time with that from redhat POV too | 15:47 |
| *** jpena is now known as jpena|off | 16:25 | |
| *** sshnaidm is now known as sshnaidm|off | 17:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!