On July 20, 2018 2:45 pm, Paul Belanger wrote:
On Fri, Jul 20, 2018 at 06:21:48AM +0200, Matthieu Huin wrote:Here's another reason to apply the Tech Preview model that I painfully became aware of while working on my upstream patches: a lot of my work in SF itself depends on my upstream patches being included in Zuul. The tenant-scoped web API in Zuul implies work on cauth and sf-config to support the JWT auth. If I wait for upstream to merge my patch, I cannot start implementing these changes in cauth and sf-config since our version of zuul won't have the needed feature.Is there any way to circumvent that, or should we accept that a lot of our dev will be slowed down by upstream?Yup, can see how that is a blocker. I guess my question would be, if SF decided to work to land features in upstream zuul master first, then wait to make changes to sf-config / cauth only after a tagged release, what would that looking?
That would be ideal, but without a release schedule and some sort of blueprints/expected features, it's not realistic. For example, the /tenant/job REST api[0] (to enable simple things like exposing the location of a job) has been submitted 8 months ago already... Similarly, I proposed an implementation[1] of the container build resource right after we agreed on the design at Vancouver, more than 2 months ago. We don't know what will be in the next version of Zuul or when it will be released. SF developments are blocked without tech-previews.
Actually, as long as we are not releasing SF before a tagged version of upstream zuul, depends-on here should work. And shouldn't block any development of sf-config / cauth patches right?
Note that we are already waiting for tagged version upstream to release SF and we often work on the upstream blockers to make the releases happen.
I think the key thing here, is we won't be able to land the new RPM on sf.io (rdoproject / ansible tenants) due to upstream not releasing a tag, but nothing saying we cannot do the testing in a staging environment first.
Technically, I do not think the tech previews need a staging environment as they are fairly isolated from the zuul/nodepool logic. For example, the extra nodepool drivers are optional. Regards, -Tristan [0] https://review.openstack.org/527579 [1] https://review.openstack.org/570667
pgpwK28XLgCoZ.pgp
Description: PGP signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
