* Cleanup outdated or moved content
* Client conventions has moved to Knative Client
* 2018 roadmaps are expired and out of date
* API Specification (incl errors) has moved to Knative Docs
* diagnose-me.sh is out of date and replacement effort has moved to Knative Operator
* Removed references to Knative Build
* Removed unreferenced images
* Remove dead link
* Use apis.URL for our URL status fields.
Deprecate `status.domain` in favor of `status.url`.
Fixes: https://github.com/knative/serving/issues/1590
* Fix comments, make apis.Url a pointer for omitempty.
* No more dead links in serving md files
* updated test-infra to get the new markdown link checker
* fixed all dead links in the docs
* ran the link checker on all docs
* Fix markdown files
* Update docs/roadmap/scaling-2018.md
Co-Authored-By: adrcunha <35786489+adrcunha@users.noreply.github.com>
* Change normative example from pinned to release mode
* Proofread and expand
* Talk about a safety belt
* consistency in revision names
* correct last route spec
* Respond to some comments; add rollback
* Add the nonce to the revision
* Respond to review comments
* Fix typos and grammar
* Respond to comments
* s/next/candidate/
I'm not sure if `concurrencyModel: SingleThreaded` was ever a
valid value (per spec.md "Single" is a valid option for this
field).
At any rate, using the new containerConcurrency field for this.
* [2222] Add configurationGeneration label to revisions
This commit removes the configurationGeneration annotation on revisions
and replaces it with the configurationGeneration label.
* [2222] remove references to annotation and update tests
* [2222] remove more references to annotation and update docs
This shifts the focus from:
* an inline BuildSpec to a full resource definition (with TypeMeta)
* a `buildRef` instead of a `buildName`.
Related to: https://github.com/knative/serving/issues/1961
* Conditions proposal
Replace LatestRevisionReady condition with:
Configuration.Status.Ready
Service.Status.ConfigurationReady
Updated Service Status to include:
Ready
ConfigurationReady
RouteReady
The overall condition of any resource can be checked by looking at its
Ready condition. This simplifies the logic for clients that need to poll
for Readiness.
For Service, the status of its owned resources can be checked by looking
at its ConfigurationReady and RouteReady conditions. This saves clients
from having to perform an extra hop to determine why a Service is not
Ready. The Ready condition of a Service should reflect a union of the
Ready conditions of its owned Configuration and Route.
Also fix typo: s/meassage/message/
* Pluralize conditions
* Add missing condition to errors example
Other Knative projects use the project name in the CRD group. Now that
the Serving project is no longer called "elafros", the project name
should be included in the CRD group namespace.
This is a breaking change, but aligns well with the other breakages
caused by the rename.
I intentionally did not update name for resource labels or for logging.
In docs there were a few references to CRDs from the build project.
Those CRD groups are now called build.knative.dev.
* elafros/elafros -> knative/service
* replace elafros with knative
* changed ela package to serving
* change elafros/build to knative/build and newer version
* things are running mostly
* address build / test failures
* address integration test failures
* repo has not chnaged
* Some spec docs were using `RolloutComplete` for the condition type,
however as errors.md documents and as discussed in #351, the type
should actually be `Ready`
* The conformance tests were asserting against the condition `Reason`
but as per #351 and errors.md, values in this field are for the
user to consume and should be transpart to client applications.
* errors.md didn't make the latter as clear as mattmoor@'s comment
in #351 so I copied some of his comment into the doc
Also reorganized some of errors.md to make it easier to identify,
by field, what requirements are.
* Initial checkin of Service docs (aka "Steve")
* Partial checkpoint on updating spec
* Add service to images
Adds Service to images
* Update the rest of examples
* Reorder errors to group logically into deployment and routing errors.
Introduce Service error documentation, and structure error blocks to show how Service aggregates errors from Route and Configuration.
* Address small comments from @vaikas-google and @mattmoor. Did not refactor service.pinned behavior.
Initial copy/commit of Elafros API design doc, chunked into sections. Also includes initial definitions of Elafros personas.
Still TODO:
- Appendices A-E, which cover extended use cases.
knative-automation
tayarani
mattmoor-sockpuppet
Dan Gerdesmeier
Matt Moore
Xavier Coulon
Adriano Cunha
mattmoor-sockpuppet
Naomi Seyfer
Ahmet Alp Balkan
John Sanda
Dr Nic Williams
jonjohnsonjr
Scott Andrews
Ville Aikas
Christie Wilson
Evan Anderson