Hi, Thanks for that mail Tristan.
Le 07/07/2016 à 16:47, Tristan Cacqueray a écrit : > Greeting folks, > > I'd like to schedule a backlog grooming next Monday after the daily > standup. Please reply to this thread with the story you'd like to be > implemented for the next sprint. > > Here is my list: > > * Release of 2.2.3 and upgrade of sf-project.io[0] > -> The goal is to get systemd daemon-reload fixes, as well as > -> Deploy storyboard (tech preview) to start playing with it Here are some previously discussed stories we should re-discuss or (because already groomed) plan for the next sprint : - The so famous "login page" refactoring http://softwarefactory-project.io/redmine/issues/1437 - Schedule of the SF/RDO followup meeting http://softwarefactory-project.io/redmine/issues/1479 - Add smtp notifications for POST config job http://softwarefactory-project.io/redmine/issues/1432 - Clean admin_mail_forward notifications http://softwarefactory-project.io/redmine/issues/1445 > I'd like to reduce the scope of this story to sf-project.io only. > > > * Integrate ELK to index CI logs[1] > -> At the end of current sprint, we'll have the backend in place > and before moving on to adding a front-end, I'd like we focus on > implementing integration tests > -> Moreover i'd like us to be able to query elastic search database > directly. It seems very important that we are able to understand > and operate that first (critical) stack. > > > Probably not for next sprint, I'd like to present/discuss an improvement > to our LXC usage... How about we switch to runc ? > Based on my previous experiment[2] it seems like a fine container > technology that plays nicely with systemd. > > I've demonstrated how it can be used to test zuul[3] and indeed in 2 > minutes it's able to build, configure, start and test zuul-server, 2 > zuul-merger and a bunch of zuul-launcher. > > Basically, here is the (early) proposed plan: > * Adds a new deploy/runc/deploy.py script to replace in-place LXC. > * Adapt the current ansible configuration tooling to support out of > the instance usage (to be run from directly from the host). > * Dissociate service data from the rootfs, so that backup, migration > and upgrade are less critical. > > The goal is to avoid problem we encounter frequently when doing upgrade. > Note that much like the dyn-arch effort, this could be implemented in > parallel without breaking the current workflow. > > Regards, > -Tristan > > [0] http://softwarefactory-project.io/redmine/issues/1480 > [1] http://softwarefactory-project.io/redmine/issues/1442 > [2] http://softwarefactory-project.io/r/gitweb?p=sf-runc.git;a=summary > [3] > http://softwarefactory-project.io/jenkins/job/sf-runc-functional-tests/11/console > > > > _______________________________________________ > Softwarefactory-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/softwarefactory-dev > _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
