To quickly summarize the discussion on IRC, should we decide to go for improving paddles, it would probably make sense to: * Implement a mirror feature in paddles. A new paddle could query an existing paddle and update its database with what it finds there. The issue / comment fields would only be allowed on completed runs which are immutable in the existing paddles and do not cause problems with syncrhonization. * A centralized paddles read/write to the public would mirror information from the paddles that are used by http://pulpito.ceph.com/ and http://pulpito.ovh.sepia.ceph.com:8081/ * A pulpito would run from this centralized paddles and implement new features, with no risk to disrupt the existing paddles/pulpito, which would be a good testbed to demonstrate pull requests implementing these new features can be accepted * teuthology-openstack ( or ceph-workbench ceph-qa-suite ) would have a new --paddles options to use this centralized paddles server instead of creating a new one, so that results are archived in a permanent place (that would be the default). On 29/02/2016 14:53, Loic Dachary wrote: > Hi, > > This week-end I updated http://ceph-workbench.dachary.org/root/ceph-workbench and got the integration tests to pass again (a few minor issues broke it in the past two months http://ceph-workbench.dachary.org/root/ceph-workbench/activity). I suppose the most important item in the backlog is to have a convenient way to record the teuthology runs and associate them with known issues. I updated http://ceph-workbench.dachary.org/root/ceph-workbench/issues/26 with a short description of what it would look like if we used the redmine wiki for that purpose. But it feels fragile and redundant with paddles (the database that records the tests). > > I think we have three options to automate the use case we want (i.e. what we've been doing at http://tracker.ceph.com/issues/14692 & al). > > * Automate the redmine update using issue comments & wiki pages (http://ceph-workbench.dachary.org/root/ceph-workbench/issues/26). > * Create a git-notes database with links to issues / pr / test results (http://ceph-workbench.dachary.org/root/ceph-workbench/issues/5) > * Improve paddles / pulpito > > We've discussed the first two options extensively over the past year but not so much the idea of improving paddles / pulpito. Maybe because pulpito is too much web and not enough plain text for my taste, at least that's one of the things that comes to mind. But this can probably be improved as well. It could go > like this: > > * Add an "issue" and "comment" field in paddles for each test. > * Add a query to show all jobs that ran against a given SHA1 to paddles (that's the focus we have in the stable release issues) > * Add a query to show all run of a given job (based on the description) to paddles > * Add a redmine friendly text output to pulpito so that it can be copy/pasted to a comment (instead of doing what we do with the fail.py script and maybe more) > * Add the input fields in pulpito to fill the "issue" field and the "comment" field to the pulpito UI (which is what we do when analyzing failures). > > What do you think ? > > Cheers > > On 26/02/2016 15:12, Abhishek Varshney wrote: >> Hi Loic, >> >> On Fri, Feb 26, 2016 at 1:11 PM, Loic Dachary <loic@xxxxxxxxxxx> wrote: >>> Hi, >>> >>> It's a quiet time in the small world of the stable release team, ideal for mentoring the new members who generously answered our call for participation. Welcome to Chen Xiaoxi, Gaurav Bafna, Wei-Chung Cheng, Martin Palma and Chris Jones :-) >>> >>> I propose that we take advantage of the next few weeks to expand our scope in two ways: >>> >>> * test Ceph development versions as well as stable versions >>> * publish packages for Ceph development versions >>> >>> Testing Ceph development versions is actually less work than with stable versions because the developers run a lot of tests already and fix problems on a daily basis. Our help would likely be needed with a few teuthology suite runs right before the development release is published, once a month. But the development versions tend to be more frequent, therefore it will probably be as much work as for a stable release, overall. The workflow would be revisited: there is no cherry-picking. Instead, bug fixes must be against the jewel branch or whatever branch will be the upcoming stable. And this branch is merged back into master on a regular basis (i.e. more frequently than the development releases). >>> >>> As you may have noticed, no packages were published for the 10.0.3 development release and that's where we could make a real difference. This would be an entirely new part of our workflow, but also an exciting one because it's the last missing piece of the puzzle. Once we are able to publish usable packages for development releases, nothing is stopping us to do the same for stable releases. It's a lot easier than it seems since the packages are already built for the teuthology jobs. All we need is a public space to archive them and sign them. This is not mutually exclusive with the current package publication workflow, it would be a community driven alternative that is much needed in some cases. >>> >>> Of course, this is easier said than done :-) What do you think ? Are there other important work that we should try to accomplish instead ? Things that would benefit Ceph users and developers more ? >> >> Would it be a good idea to give some focus to ceph-workbench[1] too >> and formalise backport workflows, since we have a bigger Stable >> Releases Team now? >> >> [1] https://pypi.python.org/pypi/ceph-workbench >> >>> >>> Cheers >>> >>> -- >>> Loïc Dachary, Artisan Logiciel Libre >> >> Thanks >> Abhishek >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- Loïc Dachary, Artisan Logiciel Libre -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
