Merge "Advancing the protocal of the website to HTTPS in rolling-upgrade.rst."
This commit is contained in:
commit
aaf301ff30
|
@ -21,7 +21,7 @@ The Entity Models in ``barbicanclient`` should be refactored to provide a
|
|||
more Pythonic api. This refactor will make the existing Entities consistent
|
||||
with the recently approved Containers blueprint. [1]_
|
||||
|
||||
.. [1] http://specs.openstack.org/openstack/barbican-specs/specs/juno/client-add-containers.html
|
||||
.. [1] https://specs.openstack.org/openstack/barbican-specs/specs/juno/client-add-containers.html
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
@ -110,7 +110,7 @@ We could continue to use the objects as they currently exist.
|
|||
Also note that the Orders functionality will need to be revisited once
|
||||
the Typed Orders implementation lands. [2]_
|
||||
|
||||
.. [2] http://specs.openstack.org/openstack/barbican-specs/specs/juno/api-orders-add-more-types.html
|
||||
.. [2] https://specs.openstack.org/openstack/barbican-specs/specs/juno/api-orders-add-more-types.html
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
@ -188,4 +188,4 @@ References
|
|||
==========
|
||||
|
||||
Containers in the Client etherpad: https://etherpad.openstack.org/p/python-barbicanclient-containers
|
||||
Containers Blueprint: http://specs.openstack.org/openstack/barbican-specs/specs/juno/client-add-containers.html
|
||||
Containers Blueprint: https://specs.openstack.org/openstack/barbican-specs/specs/juno/client-add-containers.html
|
||||
|
|
|
@ -256,8 +256,8 @@ https://github.com/cloudkeep/barbican/wiki/Barbican-Options:-authentication-with
|
|||
References
|
||||
==========
|
||||
|
||||
* http://docs.openstack.org/developer/oslo.messaging/notification_listener.html
|
||||
* https://docs.openstack.org/developer/oslo.messaging/notification_listener.html
|
||||
|
||||
* http://docs.openstack.org/developer/oslo.messaging/index.html
|
||||
* https://docs.openstack.org/developer/oslo.messaging/index.html
|
||||
|
||||
* http://docs.openstack.org/developer/oslo.messaging/notification_listener.html#oslo.messaging.MessageHandlingServer
|
||||
* https://docs.openstack.org/developer/oslo.messaging/notification_listener.html#oslo.messaging.MessageHandlingServer
|
||||
|
|
|
@ -126,7 +126,7 @@ Each API method which is either added or changed should have the following
|
|||
think about when defining their policy.
|
||||
|
||||
Example JSON schema definitions can be found in the Nova tree
|
||||
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3
|
||||
https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3
|
||||
|
||||
Note that the schema should be defined as restrictively as
|
||||
possible. Parameters which are required should be marked as such and
|
||||
|
|
|
@ -105,7 +105,7 @@ attempt.
|
|||
To implement this scheduling process, this blueprint proposes using the Oslo
|
||||
periodic task feature, described here:
|
||||
|
||||
http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.periodic_task.html
|
||||
https://docs.openstack.org/developer/oslo-incubator/api/openstack.common.periodic_task.html
|
||||
|
||||
A working example implementation with an older code base is shown here:
|
||||
|
||||
|
|
|
@ -245,10 +245,10 @@ References
|
|||
http://www.dmtf.org/sites/default/files/standards/documents/DSP2038_1.0.0.pdf
|
||||
|
||||
* Audit Middleware
|
||||
http://docs.openstack.org/developer/keystonemiddleware/audit.html
|
||||
https://docs.openstack.org/developer/keystonemiddleware/audit.html
|
||||
|
||||
* PyCADF developer docs
|
||||
http://docs.openstack.org/developer/pycadf/
|
||||
https://docs.openstack.org/developer/pycadf/
|
||||
|
||||
* CADF event model and taxonomies
|
||||
https://wiki.openstack.org/w/images/e/e1/Introduction_to_Cloud_Auditing_using_CADF_Event_Model_and_Taxonomy_2013-10-22.pdf
|
||||
|
|
|
@ -32,7 +32,7 @@ Keystone and Barbican
|
|||
The following is an example of implementing a json-home type of response from
|
||||
Keystone
|
||||
(documented here:
|
||||
http://docs.openstack.org/api/openstack-identity-service/2.0/content/\
|
||||
https://docs.openstack.org/api/openstack-identity-service/2.0/content/\
|
||||
Versions-d1e472.html)::
|
||||
|
||||
{
|
||||
|
@ -43,7 +43,7 @@ Versions-d1e472.html)::
|
|||
"links": [
|
||||
{
|
||||
"rel": "self",
|
||||
"href": "http://identity.api.openstack.org/v1.0"
|
||||
"href": "https://identity.api.openstack.org/v1.0"
|
||||
}
|
||||
],
|
||||
"media-types": {
|
||||
|
@ -65,7 +65,7 @@ Versions-d1e472.html)::
|
|||
"links": [
|
||||
{
|
||||
"rel": "self",
|
||||
"href": "http://identity.api.openstack.org/v1.1"
|
||||
"href": "https://identity.api.openstack.org/v1.1"
|
||||
}
|
||||
],
|
||||
"media-types": {
|
||||
|
@ -87,7 +87,7 @@ Versions-d1e472.html)::
|
|||
"links": [
|
||||
{
|
||||
"rel": "self",
|
||||
"href": "http://identity.api.openstack.org/v2.0"
|
||||
"href": "https://identity.api.openstack.org/v2.0"
|
||||
}
|
||||
],
|
||||
"media-types": {
|
||||
|
@ -131,12 +131,12 @@ provided in response such as per this Keystone example::
|
|||
"rel": "self"
|
||||
},
|
||||
{
|
||||
"href": "http://docs.openstack.org/api/openstack-identity-service/2.0/content/",
|
||||
"href": "https://docs.openstack.org/api/openstack-identity-service/2.0/content/",
|
||||
"type": "text/html",
|
||||
"rel": "describedby"
|
||||
},
|
||||
{
|
||||
"href": "http://docs.openstack.org/api/openstack-identity-service/2.0/identity-dev-guide-2.0.pdf",
|
||||
"href": "https://docs.openstack.org/api/openstack-identity-service/2.0/identity-dev-guide-2.0.pdf",
|
||||
"type": "application/pdf",
|
||||
"rel": "describedby"
|
||||
}
|
||||
|
|
|
@ -198,12 +198,12 @@ Documentation Impact
|
|||
A new barbican-manage command user guide will be added, which should include
|
||||
new user guide for database migration subcommands and user guide of
|
||||
pkcs11-related subcommands modified from existing
|
||||
http://docs.openstack.org/developer/barbican/api/userguide/pkcs11keygeneration.html
|
||||
https://docs.openstack.org/developer/barbican/api/userguide/pkcs11keygeneration.html
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#] http://docs.openstack.org/developer/keystone/man/keystone-manage.html
|
||||
.. [#] http://docs.openstack.org/developer/nova/man/nova-manage.html
|
||||
.. [#] https://docs.openstack.org/developer/keystone/man/keystone-manage.html
|
||||
.. [#] https://docs.openstack.org/developer/nova/man/nova-manage.html
|
||||
.. [#] https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
|
||||
|
|
|
@ -52,7 +52,7 @@ not include the zone designation will result in an error response with status
|
|||
code 400. Values that specify a time offset from UTC will also result in a 400
|
||||
error response even if the offset is zero to specify UTC.
|
||||
|
||||
.. _Pagination, Filtering, and Sorting: http://git.openstack.org/cgit/openstack/api-wg/tree/guidelines/pagination_filter_sort.rst
|
||||
.. _Pagination, Filtering, and Sorting: https://git.openstack.org/cgit/openstack/api-wg/tree/guidelines/pagination_filter_sort.rst
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
@ -178,7 +178,7 @@ References
|
|||
|
||||
API Working Group's Guideline for Pagination, Filtering and Sorting:
|
||||
|
||||
http://git.openstack.org/cgit/openstack/api-wg/tree/guidelines/pagination_filter_sort.rst
|
||||
https://git.openstack.org/cgit/openstack/api-wg/tree/guidelines/pagination_filter_sort.rst
|
||||
|
||||
ISO 8601 in Wikipedia:
|
||||
|
||||
|
|
|
@ -139,7 +139,7 @@ Each API method which is either added or changed should have the following
|
|||
think about when defining their policy.
|
||||
|
||||
Example JSON schema definitions can be found in the Nova tree
|
||||
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3
|
||||
https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3
|
||||
|
||||
Note that the schema should be defined as restrictively as
|
||||
possible. Parameters which are required should be marked as such and
|
||||
|
|
|
@ -139,7 +139,7 @@ Each API method which is either added or changed should have the following
|
|||
think about when defining their policy.
|
||||
|
||||
Example JSON schema definitions can be found in the Nova tree
|
||||
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3
|
||||
https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3
|
||||
|
||||
Note that the schema should be defined as restrictively as
|
||||
possible. Parameters which are required should be marked as such and
|
||||
|
|
Loading…
Reference in New Issue