Hey,
+1 on releasing this!
Checklist for reference:
- [✓] Download links are valid.
- [✓] Checksums and PGP signatures are valid.
- [✓] Source code artifacts have correct names matching the current release.
- [✓] LICENSE and NOTICE files are correct for each OpenWhisk repo.
- [✓] All files have l
Hi,
On Thu, Jun 28, 2018 at 9:22 AM Markus Thoemmes
wrote:
...
> - [✓] No compiled archives bundled in source archive. (Other than gradlew.jar)
> Is there a procedure to verify the last point? I quickly did a find for jar
> files and a find for executable files...
I also use find + file to
+1 on this release.
Checklist for reference:
[X] Download links are valid.
[0] Checksums and PGP signatures are valid. (did not verify on this point
iteration)
[X] Source code artifacts have correct names matching the current release.
[X ] LICENSE and NOTICE files are correct for each OpenWhisk re
I vote +1 for Release as Apache OpenWhisk 0.9.0-incubating.
Checklist:
[X] Download links are valid.
[X] Source code artifacts have correct names matching the current release.
[X] LICENSE and NOTICE files are correct for each OpenWhisk repo.
[X] All files have license headers if necessary.
[X] N
+1 on the release.
I verified that sources built on MacOS and checked the following items:
[ X ] Download links are valid.
[ X ] Checksums and PGP signatures are valid.
[ X ] Source code artifacts have correct names matching the current
release.
[ X ] LICENSE and NOTICE files are correct for each
Andy,
I just opened the pull request for the entitlement SPI
(Please see: https://github.com/apache/incubator-openwhisk/pull/3822)
As you can see it implements the existing EntitlementProvider interface as SPI
without changing it. I think it would be still easy to adapt it according to
your
pr
After doing some preliminary poking at this, I believe we'll want to
use either a tool like https://github.com/google/oatts to generate a
test suite from our Swagger spec OR use swagger-codegen to generate a
Scala client from our Swagger spec and try to plug that into the
existing WskRest tests.
U
I've just submitted a PR [1] to remove the "old style" non-Helm deployment
from the deploy-kube project.
The Helm-based deployment is (a) much simpler for users to deploy and (b)
supports strictly more configuration options than the code being removed.
We've been heading this direction for a cou
+1
On Wed, Jun 27, 2018 at 11:43 AM Rodric Rabbah wrote:
> In general I think this is a good change - but minor nit that "latest" in
> docker doesn't mean pull the latest tag.
>
> -r
>
>
>
> On Wed, Jun 27, 2018 at 7:35 AM, Markus Thoemmes <
> markus.thoem...@de.ibm.com
> > wrote:
>
> > Dear Op
+100 this is great
Related to the topic but something can be done afterwards we have the base
Deprecate the docker sdk, and instead have more clear docs on how to build
an image runtime from scratch or use the base one dockerskeleton or use
one of the existing ones for a language by extending th
+1 to Helm !
Having one way to deploy kube makes it more simple to maintain, maintaining
both is a lot of duplication waisted effort
--cs
On Thu, Jun 28, 2018 at 6:07 PM David P Grove wrote:
>
> I've just submitted a PR [1] to remove the "old style" non-Helm deployment
> from the deploy-kube
Thanks Ben for the quick update on this task
-cs
On Thu, Jun 28, 2018 at 5:15 PM Ben Browning wrote:
> After doing some preliminary poking at this, I believe we'll want to
> use either a tool like https://github.com/google/oatts to generate a
> test suite from our Swagger spec OR use swagger-co
12 matches
Mail list logo
