*** cheng1 has quit IRC | 02:13 | |
*** sgw has quit IRC | 02:33 | |
*** cheng1 has joined #starlingx | 03:26 | |
*** adrianreza has joined #starlingx | 04:45 | |
*** iamweswilson_ has joined #starlingx | 06:07 | |
*** ildikov_ has joined #starlingx | 06:07 | |
*** evgenyl_ has joined #starlingx | 06:08 | |
*** evgenyl has quit IRC | 06:15 | |
*** iamweswilson has quit IRC | 06:15 | |
*** ildikov has quit IRC | 06:15 | |
*** iamweswilson_ is now known as iamweswilson | 06:15 | |
*** ildikov_ is now known as ildikov | 06:15 | |
*** evgenyl_ is now known as evgenyl | 06:15 | |
*** irclogbot_2 has quit IRC | 06:18 | |
*** irclogbot_3 has joined #starlingx | 06:20 | |
*** ijolliffe has joined #starlingx | 12:41 | |
*** mriedem has joined #starlingx | 13:29 | |
*** rcw has joined #starlingx | 15:21 | |
*** sgw has joined #starlingx | 15:23 | |
sgw | Morning folks | 15:24 |
---|---|---|
sgw | Hi Dirk, I was looking at the rpm-packaging CI for SUSE and openSUSE last week and see that it uses Jenkins, I started playing with a jenkins container, can you share the config files? Since I don't have a login, I can't see the Jenkins setup. I did find the automation repo, but that seems to have the backend playbooks, but not the actual jenkins config. | 15:26 |
*** sgw has quit IRC | 15:53 | |
*** sgw has joined #starlingx | 16:05 | |
*** mriedem has left #starlingx | 16:19 | |
*** mriedem has joined #starlingx | 16:19 | |
*** mriedem has left #starlingx | 16:19 | |
dirk | sgw: there are a few Jenkins job builder files under the Jenkins/ci.opensuse.org/ subdirectory in automation repo, did you find that already? | 17:11 |
dirk | sgw: my idea was so far to integrate it in the existing instance, what do you think about this? | 17:12 |
dirk | Please note that expects the jinja2 /renderspec layer. What I've seen so far didn't use that yet? | 17:14 |
sgw | dirk: yes, that's what I found, but I don't think it had enough information for me to re-create the jenkins job itself, it had the info about what the jobs can do. | 17:30 |
sgw | dirk what I want to do initially is setup something up locally to test with building for openSUSE and the few debian packages we created meta-data for, Then I can demo that to the community build sub-team. | 17:32 |
dirk | sgw: it should have all the information except for plugins etc | 18:01 |
dirk | Unfortunately this part is a bit in a sad state, we use still zuulv2 | 18:01 |
dirk | Are you tracking the spec files etc in git? | 18:03 |
dirk | As that's the main functionality of the ci so far - to translate build service errors into votes on Gerrit reviews | 18:04 |
sgw | Yes, we will be, I have made the first review for the fault repo that was merged today \o/ https://review.opendev.org/#/c/666147/ | 18:05 |
sgw | dirk: I will admit they are functional, but not pretty yet! | 18:05 |
sgw | dirk, maybe I am missting some thing about jenkins then (/me is learning to many different tools [Jenkins, zuul, tox, ansible, ...] ) | 18:07 |
dirk | sgw: so the main thing I think you need is a Jenkins install with a gearman plugin | 18:31 |
dirk | The rest is then in git | 18:31 |
dirk | sgw: ok, looks good | 18:32 |
dirk | Which part is the one you're stuck on right now? | 18:33 |
dirk | sgw: basically the flow is .. Gerrit review -> Gerrit event stream -> zuul v2/v3 instance (in our case v2) -> gearman -> Jenkins job | 18:53 |
*** rcw has quit IRC | 19:05 | |
*** jsun3 has joined #starlingx | 19:25 | |
*** rcw has joined #starlingx | 19:31 | |
*** rcw has quit IRC | 19:41 | |
*** rcw has joined #starlingx | 19:42 | |
sgw | dirk: was off running & lunch, I will look at gearman also | 20:08 |
*** rcw has quit IRC | 20:31 | |
*** rcw has joined #starlingx | 20:31 | |
sgw | dpenney: reagarding your comment about upper constraints, I don't think it masters in this case | 20:32 |
dpenney | probably not, no. just noticed it when I went back and looked again | 20:32 |
sgw | I can change it if you want | 20:34 |
sgw | I pulled that from the openstack/rpm-packaging repo | 20:34 |
dpenney | it looks like we've got a mix of them in various tox.ini files. Might be good to use stable/stein and we can set about updating all of them | 20:36 |
dpenney | some are master, some are actually stable/pike! | 20:37 |
sgw | dpenney: we still use pike for the downloads scripts! | 20:39 |
*** ijolliffe has quit IRC | 20:39 | |
sgw | I thnk an LP is in order for that to change it to something else | 20:39 |
dpenney | should we go with stable/stein? seems like it would make sense to align with runtime | 20:41 |
dpenney | I can create an LP and post reviews for the existing ones if you want | 20:42 |
sgw | dpenney: I was thinking about what the name should be, what do we go with during the development of stx-3.0? master or train? | 20:45 |
dpenney | moving to train would mean updates to repo and image directives files, so we could update the tox.ini constraints then as well | 20:47 |
sgw | what's the history of calling it after the openstack name? Would it make more sense to be starlingx-2.0 or stx-3.0? | 20:48 |
*** rcw has quit IRC | 20:50 | |
dpenney | calling what after the openstack name? | 20:52 |
dpenney | I was just thinking about the path to the upper-constraints file used | 20:52 |
sgw | dpenney: sorry got side tracked here, Dean is in town | 21:27 |
sgw | dpenney: the downloads area called pike | 21:28 |
dpenney | ahhh, gotcha. I'd lean towards just using "master" for that, probably | 21:29 |
sgw | dpenney: just to review in the stx-tools mirror code, we have stx-r1/Centos/pike, should we just make this stx-2.0/Centos/[Binary, downloads, Source] get ride of openstack name completely | 21:34 |
sgw | We also seem to have a double Centos in the mirror itself, but I think that's for the stx-installer files, something to look at cleaning in up stx-3.0 | 21:36 |
dpenney | sure, I agree with dropping the openstack name | 21:37 |
dpenney | slittle1 would need to comment on the impact of that... maybe Jenkins script changes, etc | 21:38 |
sgw | possibly, so back the the requirements, do you have a perfernce there stein vs master? | 21:46 |
dpenney | I think we should be using stein for them. I've found one case so far where moving from stable/pike to stable/stein exposes a pylint error (albeit in controllerconfig code that should be going away), presumably because of an upversioned dependency in stein vs pike... so maybe we'd get false-postives by using master vs stein | 21:49 |
sgw | Ok, will fix that to stein and resubmit | 21:49 |
dpenney | I'll keep going through with the others... I've updated them all, and just going through manually running tox | 21:50 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!