[all][qa] grenade zuulv3 native job available now and its migration plan
Hello Everyone, Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch. Thanks to tosky for keep working on this and finish it!! New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'. * Start using this new base job for your projects specific grenade jobs. * Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri). Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also. [1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/ -gmann
Great accomplishment. -----Original Message----- From: Ghanshyam Mann <gmann@ghanshyammann.com> Sent: Friday, May 1, 2020 7:39 PM To: openstack-discuss Subject: [all][qa] grenade zuulv3 native job available now and its migration plan [EXTERNAL EMAIL] Hello Everyone, Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch. Thanks to tosky for keep working on this and finish it!! New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'. * Start using this new base job for your projects specific grenade jobs. * Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri). Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also. [1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/ -gmann
Hi, Thx a lot. Great job. I already pushed some patch to neutron to switch our legacy jobs to be zuulv3. It's https://review.opendev.org/725073 - lets see what we will need to change/fix there :) On Fri, May 01, 2020 at 07:39:21PM -0500, Ghanshyam Mann wrote:
Hello Everyone,
Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch.
Thanks to tosky for keep working on this and finish it!!
New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'.
* Start using this new base job for your projects specific grenade jobs.
* Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri).
Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d
It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also.
[1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/
-gmann
-- Slawek Kaplonski Senior software engineer Red Hat
Hey Ghanshyam, This is pretty good news! Congratulations to the whole team! I posted a patch to migrate the Octavia grenade job to native Zuul v3 [1]. It was really easy and simple to do it, so thanks again. One question. The job runs Tempest some tests (Nova, Neutron, ...) right after Grenade. From an Octavia perspective, it is not something we really don't care about but rather would prefer running (a subset of) Octavia tests or none. Is this possible? In patch set 6 [2], I tried to disable Tempest completely. I did so by disabling "tempest" in devstack_services and set ENABLE_TEMPEST=False in the Grenade plugin settings file. Yet, Tempest tests still ran. Looking at the grenade job definition, it includes the tempest role -- is this correct? I would expect Tempest to run only if ENABLE_TEMPEST=True. Thanks, Carlos [1] https://review.opendev.org/#/c/725098/ [2] https://review.opendev.org/#/c/725098/6/ On Sat, May 2, 2020 at 2:40 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
Hello Everyone,
Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch.
Thanks to tosky for keep working on this and finish it!!
New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'.
* Start using this new base job for your projects specific grenade jobs.
* Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri).
Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d
It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also.
[1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/
-gmann
On Monday, 4 May 2020 09:26:12 CEST Carlos Goncalves wrote:
Hey Ghanshyam,
This is pretty good news! Congratulations to the whole team!
I posted a patch to migrate the Octavia grenade job to native Zuul v3 [1]. It was really easy and simple to do it, so thanks again.
One question. The job runs Tempest some tests (Nova, Neutron, ...) right after Grenade. From an Octavia perspective, it is not something we really don't care about but rather would prefer running (a subset of) Octavia tests or none. Is this possible?
Yes, you can definitely check the subset of tests. That behavior is driven by the same variable as in devstack-tempest jobs, which is tempest_test_regex. You can check an example here: https://review.opendev.org/#/c/638390/41/.zuul.yaml
In patch set 6 [2], I tried to disable Tempest completely. I did so by disabling "tempest" in devstack_services and set ENABLE_TEMPEST=False in the Grenade plugin settings file. Yet, Tempest tests still ran. Looking at the grenade job definition, it includes the tempest role -- is this correct? I would expect Tempest to run only if ENABLE_TEMPEST=True.
That variable only contronls the smoke tests executed post-upgrade (currently disabled), not the job-specific tempest tests. I realized now I have a long standing note to fix that, but it's not critical anyway in order to implement your requirement. Please remember to use the "native-zuulv3-migration" topic for those kind of changes (they are part of the more general "removal of legacy jobs" goal for Victoria). Ciao -- Luigi
---- On Mon, 04 May 2020 03:03:22 -0500 Luigi Toscano <ltoscano@redhat.com> wrote ----
On Monday, 4 May 2020 09:26:12 CEST Carlos Goncalves wrote:
Hey Ghanshyam,
This is pretty good news! Congratulations to the whole team!
I posted a patch to migrate the Octavia grenade job to native Zuul v3 [1]. It was really easy and simple to do it, so thanks again.
One question. The job runs Tempest some tests (Nova, Neutron, ...) right after Grenade. From an Octavia perspective, it is not something we really don't care about but rather would prefer running (a subset of) Octavia tests or none. Is this possible?
Yes, you can definitely check the subset of tests. That behavior is driven by the same variable as in devstack-tempest jobs, which is tempest_test_regex. You can check an example here: https://review.opendev.org/#/c/638390/41/.zuul.yaml
There are two run of Tempest in grenade job: 1. smoke test run on old node before upgrade. Those are just to verify the installation and optional to run. You can disable those by BASE_RUN_SMOKE=False in your job. I will say if that takes time then disable it like we discussed for Ironic case. 2. upgrade tests. These tests run after the upgrade. The default set of test run are smoke tests (tempest + installed plugins) and can be overridden by tox_envlist and tempest_test_regex (example shown by tosky ) the same way devstack job does. -gmann
In patch set 6 [2], I tried to disable Tempest completely. I did so by disabling "tempest" in devstack_services and set ENABLE_TEMPEST=False in the Grenade plugin settings file. Yet, Tempest tests still ran. Looking at the grenade job definition, it includes the tempest role -- is this correct? I would expect Tempest to run only if ENABLE_TEMPEST=True.
That variable only contronls the smoke tests executed post-upgrade (currently disabled), not the job-specific tempest tests. I realized now I have a long standing note to fix that, but it's not critical anyway in order to implement your requirement.
Please remember to use the "native-zuulv3-migration" topic for those kind of changes (they are part of the more general "removal of legacy jobs" goal for Victoria).
Ciao -- Luigi
On Mon, May 4, 2020 at 5:24 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
---- On Mon, 04 May 2020 03:03:22 -0500 Luigi Toscano < ltoscano@redhat.com> wrote ----
On Monday, 4 May 2020 09:26:12 CEST Carlos Goncalves wrote:
Hey Ghanshyam,
This is pretty good news! Congratulations to the whole team!
I posted a patch to migrate the Octavia grenade job to native Zuul v3 [1]. It was really easy and simple to do it, so thanks again.
One question. The job runs Tempest some tests (Nova, Neutron, ...) right after Grenade. From an Octavia perspective, it is not something we really don't care about but rather would prefer running (a subset of) Octavia tests or none. Is this possible?
Yes, you can definitely check the subset of tests. That behavior is driven by the same variable as in devstack-tempest jobs, which is tempest_test_regex. You can check an example here: https://review.opendev.org/#/c/638390/41/.zuul.yaml
There are two run of Tempest in grenade job: 1. smoke test run on old node before upgrade. Those are just to verify the installation and optional to run. You can disable those by BASE_RUN_SMOKE=False in your job. I will say if that takes time then disable it like we discussed for Ironic case.
2. upgrade tests. These tests run after the upgrade. The default set of test run are smoke tests (tempest + installed plugins) and can be overridden by tox_envlist and tempest_test_regex (example shown by tosky ) the same way devstack job does.
Luigi helped me out on #openstack-qa earlier today and reviewed https://review.opendev.org/#/c/725098/ -- thanks!
-gmann
In patch set 6 [2], I tried to disable Tempest completely. I did so by disabling "tempest" in devstack_services and set ENABLE_TEMPEST=False
in
the Grenade plugin settings file. Yet, Tempest tests still ran. Looking at the grenade job definition, it includes the tempest role -- is this correct? I would expect Tempest to run only if ENABLE_TEMPEST=True.
That variable only contronls the smoke tests executed post-upgrade (currently disabled), not the job-specific tempest tests. I realized now I have a long standing note to fix that, but it's not critical anyway in order to implement your requirement.
Please remember to use the "native-zuulv3-migration" topic for those kind of changes (they are part of the more general "removal of legacy jobs" goal for Victoria).
Ciao -- Luigi
Hi, Somewhat related: do the new jobs finally allow choosing which tests are run rather than blindly run all smoke tests available? It has been a huge problem for ironic since the introduction of upgrade testing, and we're discussing migrating away from grenade because of that. Dmitry On Sat, May 2, 2020 at 2:41 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
Hello Everyone,
Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch.
Thanks to tosky for keep working on this and finish it!!
New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'.
* Start using this new base job for your projects specific grenade jobs.
* Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri).
Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d
It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also.
[1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/
-gmann
---- On Mon, 04 May 2020 09:36:47 -0500 Dmitry Tantsur <dtantsur@redhat.com> wrote ----
Hi, Somewhat related: do the new jobs finally allow choosing which tests are run rather than blindly run all smoke tests available? It has been a huge problem for ironic since the introduction of upgrade testing, and we're discussing migrating away from grenade because of that.
It does for upgrade tests in the same way you do for devstack job. You can use the tox_envlist and tempest_test_regex. But the pre-upgrade tests, tests are not configurable. We discussed those but then left those as it is because of they are just to verify the installation and not really needed to run by project-specific job. I think we can disable pre-upgrade tests by default and let projects enabled on a need basis via BASE_RUN_SMOKE. Will that help? -gmann
Dmitry
On Sat, May 2, 2020 at 2:41 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote: Hello Everyone,
Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch.
Thanks to tosky for keep working on this and finish it!!
New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'.
* Start using this new base job for your projects specific grenade jobs.
* Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri).
Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d
It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also.
[1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/
-gmann
On Monday, 4 May 2020 16:36:47 CEST Dmitry Tantsur wrote:
Hi,
Somewhat related: do the new jobs finally allow choosing which tests are run rather than blindly run all smoke tests available? It has been a huge problem for ironic since the introduction of upgrade testing, and we're discussing migrating away from grenade because of that.
The set of smoke tests is unchanged, mirroring the old behavior (tox -esmoke). It was not part of the migration which, apart from using a more Zuul-like workflow, tried to not change everything else. You can change the set of jobs executed after the end of grenade, the non- smoke ones. If tuning the set of smoke tests could be useful, it could be discussed and planned for later. Ciao -- Luigi
On 02.05.20 02:39, Ghanshyam Mann wrote:
Hello Everyone,
Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch.
Thanks to tosky for keep working on this and finish it!!
New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'.
* Start using this new base job for your projects specific grenade jobs.
* Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri).
Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d
It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also.
The template integrated-gate-py3 has been introduced in stein cycle as far as I can see, so we do need to update the extra grenade-py3 lines to grenade where they exist in stein and train as well to avoid the duplicated runs, don't we? Andreas
[1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/
-gmann
-- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
---- On Tue, 05 May 2020 02:35:58 -0500 Andreas Jaeger <aj@suse.com> wrote ----
On 02.05.20 02:39, Ghanshyam Mann wrote:
Hello Everyone,
Finally, after so many cycles, grenade base job has been migrated to zuulv3 native[1]. This is merged in the Ussuri branch.
Thanks to tosky for keep working on this and finish it!!
New jobs 'grenade', 'grenade-multinode', 'grenade-postgresql' and 'grenade-forward' are zuulv3 native now and we kept old job name 'grenade-py3' as an alias to 'grenade' so that it would not break the gate using 'grenade-py3'.
* Start using this new base job for your projects specific grenade jobs.
* Migration to new job name: The integrated template and projects are using old job name 'grenade-py3' need to move to a new job name. Job is defined in the integrated template and also in the project's zuul.yaml for irrelevant-files. So we need to switch both places at the same time otherwise you will be seeing the two jobs running on your gate (master as well as on Ussuri).
Integrated service specific template has switched to new job[2] which means you might see two jobs running 'grenade' & 'grenade-py3' running on your gate until you change .zuul.yaml. Example: Nova did for master as well as Ussuri gate - https://review.opendev.org/#/q/I212692905a1d645cd911c2a161c13c794c0e0f4d
It needs to be done in Ussuri also as Tempest where integrated templates are present is branchless and apply the change for Ussuri job also.
The template integrated-gate-py3 has been introduced in stein cycle as far as I can see, so we do need to update the extra grenade-py3 lines to grenade where they exist in stein and train as well to avoid the duplicated runs, don't we?
We do not need until we backport the grenade new job to stable/train. For stable/train gate, only old job is running because new job from a template is not found ?(if I am not wrong). I tested it on nova stable/train and only single job run. -gmann
Andreas
[1] https://review.opendev.org/#/c/548936/ [2] https://review.opendev.org/#/c/722551/
-gmann
-- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
On 05.05.20 17:43, Ghanshyam Mann wrote:
[...] Andreas Jaeger wrote:
The template integrated-gate-py3 has been introduced in stein cycle as far as I can see, so we do need to update the extra grenade-py3 lines to grenade where they exist in stein and train as well to avoid the duplicated runs, don't we?
We do not need until we backport the grenade new job to stable/train. For stable/train gate, only old job is running because new job from a template is not found ?(if I am not wrong).
nova uses integrated-gate-compute which is defined in tempest on a branch, so the train version of the template is used in train. But integrated-gate-py3 is used on *all* branches (openstack-zuul-jobs is branch less). Let me test on glance with https://review.opendev.org/725640 , Andreas -- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
---- On Tue, 05 May 2020 11:01:17 -0500 Andreas Jaeger <aj@suse.com> wrote ----
On 05.05.20 17:43, Ghanshyam Mann wrote:
[...] Andreas Jaeger wrote:
The template integrated-gate-py3 has been introduced in stein cycle as far as I can see, so we do need to update the extra grenade-py3 lines to grenade where they exist in stein and train as well to avoid the duplicated runs, don't we?
We do not need until we backport the grenade new job to stable/train. For stable/train gate, only old job is running because new job from a template is not found ?(if I am not wrong).
nova uses integrated-gate-compute which is defined in tempest on a branch, so the train version of the template is used in train.
But integrated-gate-py3 is used on *all* branches (openstack-zuul-jobs is branch less).
Let me test on glance with https://review.opendev.org/725640 ,
Tempest is also branchless too so template is there for all branches. glance also use tempest-integrated-storage not integrated-gate-py3. 'grenade' job is available on branch-specific only as grenade is branched so new job even added in the template is not present in train so it is not run. If we plan to backport grenade new job to train then new job will start running on train too. We talked about it in qa office hour today and if that is easy to backport then it is fine otherwise no urgency on this. -gmann
Andreas -- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
On 05.05.20 18:08, Ghanshyam Mann wrote:
---- On Tue, 05 May 2020 11:01:17 -0500 Andreas Jaeger <aj@suse.com> wrote ----
On 05.05.20 17:43, Ghanshyam Mann wrote:
[...] Andreas Jaeger wrote:
The template integrated-gate-py3 has been introduced in stein cycle as far as I can see, so we do need to update the extra grenade-py3 lines to grenade where they exist in stein and train as well to avoid the duplicated runs, don't we?
We do not need until we backport the grenade new job to stable/train. For stable/train gate, only old job is running because new job from a template is not found ?(if I am not wrong).
nova uses integrated-gate-compute which is defined in tempest on a branch, so the train version of the template is used in train.
But integrated-gate-py3 is used on *all* branches (openstack-zuul-jobs is branch less).
Let me test on glance with https://review.opendev.org/725640 ,
Tempest is also branchless too so template is there for all branches. glance also use tempest-integrated-storage not integrated-gate-py3.
On train it uses integrated-gate-py3.
'grenade' job is available on branch-specific only as grenade is branched so new job even added in the template is not present in train so it is not run.
Yes, indeed.
If we plan to backport grenade new job to train then new job will start running on train too. We talked about it in qa office hour today and if that is easy to backport then it is fine otherwise no urgency on this.
and once you backport, both grenade and grenade-py3 will run. So, for now all is working since the projects list grenade-py3 explicitely, Andreas
-gmann
Andreas -- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
-- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
participants (7)
-
Andreas Jaeger
-
Arkady.Kanevsky＠dell.com
-
Carlos Goncalves
-
Dmitry Tantsur
-
Ghanshyam Mann
-
Luigi Toscano
-
Slawek Kaplonski