Rename review.openstack.org to review.opendev.org
There are many references to review.openstack.org, and while the redirect should work, we can also go ahead and fix them. Change-Id: I313fe752c179a367ef22227d7c0037c2c27056d8
This commit is contained in:
OpenDev Sysadmins
melissaml
parent
d0a0accca7
commit
c57b4300cf
|
|
@ -1,4 +1,4 @@
|
|||
[gerrit]
|
||||
host=review.openstack.org
|
||||
host=review.opendev.org
|
||||
port=29418
|
||||
project=openstack/heat-specs.git
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ Milestones
|
|||
Currently moved to backlog due to no community's interest. Workable PoC placed
|
||||
here:
|
||||
|
||||
https://review.openstack.org/#/q/topic:bp/property-group
|
||||
https://review.opendev.org/#/q/topic:bp/property-group
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ For example, consider this workflow:
|
|||
created.
|
||||
|
||||
The topic of this spec is steps 3 and 4 above.
|
||||
https://review.openstack.org/#/c/197199 discusses step 5. The other steps
|
||||
https://review.opendev.org/#/c/197199 discusses step 5. The other steps
|
||||
are already possible.
|
||||
|
||||
The discussion below focuses on the TripleO use case, since that is what is
|
||||
|
|
@ -306,7 +306,7 @@ not the options related to a valid composition.
|
|||
|
||||
.. rubric:: References
|
||||
.. [1] http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csd03/TOSCA-Simple-Profile-YAML-v1.0-csd03.html#_Toc419746122
|
||||
.. [2] https://review.openstack.org/#/c/197199
|
||||
.. [2] https://review.opendev.org/#/c/197199
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -193,7 +193,7 @@ No new dependencies to other libraries will be introduced.
|
|||
This work may disturb several on-going work related to AutoScalingGroups.
|
||||
The following work will have to be rebased on this change.
|
||||
|
||||
#. https://review.openstack.org/110379 Scaling group scale-down plugpoint
|
||||
#. https://review.openstack.org/105644 LaunchConfiguration bdm
|
||||
#. https://review.openstack.org/105907 Balancing ScalingGroup across AZs
|
||||
#. https://review.opendev.org/110379 Scaling group scale-down plugpoint
|
||||
#. https://review.opendev.org/105644 LaunchConfiguration bdm
|
||||
#. https://review.opendev.org/105907 Balancing ScalingGroup across AZs
|
||||
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ Implementation
|
|||
|
||||
|
||||
A patch comprising a full implementation of the blueprint
|
||||
(https://review.openstack.org/#/c/89363/) is already being
|
||||
(https://review.opendev.org/#/c/89363/) is already being
|
||||
reviewed, under the old pre-spec process.
|
||||
|
||||
Assignee(s)
|
||||
|
|
@ -117,7 +117,7 @@ Target Milestone for completion:
|
|||
Work Items
|
||||
----------
|
||||
|
||||
Implementation: https://review.openstack.org/#/c/89363/
|
||||
Implementation: https://review.opendev.org/#/c/89363/
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Target Milestone for completion:
|
|||
Work Items
|
||||
----------
|
||||
|
||||
* modify OS::Neutron::Port https://review.openstack.org/#/c/129353/
|
||||
* modify OS::Neutron::Port https://review.opendev.org/#/c/129353/
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
|
|
|||
|
|
@ -133,4 +133,4 @@ None
|
|||
References
|
||||
----------
|
||||
|
||||
* https://review.openstack.org/#/c/153291/
|
||||
* https://review.opendev.org/#/c/153291/
|
||||
|
|
|
|||
|
|
@ -33,8 +33,8 @@ resource within a heat stack.
|
|||
|
||||
It is out of scope for this spec, but worth noting that cinder scheduler
|
||||
hints are now supported by heat and may need similar treatment. See
|
||||
https://review.openstack.org/#/c/126282/ and
|
||||
https://review.openstack.org/#/c/126298/
|
||||
https://review.opendev.org/#/c/126282/ and
|
||||
https://review.opendev.org/#/c/126298/
|
||||
|
||||
|
||||
Proposed change
|
||||
|
|
@ -78,7 +78,7 @@ Assignee(s)
|
|||
-----------
|
||||
|
||||
A patch comprising a full implementation of the blueprint
|
||||
(https://review.openstack.org/#/c/96889/) is already being
|
||||
(https://review.opendev.org/#/c/96889/) is already being
|
||||
reviewed, under the old pre-spec process.
|
||||
|
||||
Primary assignee:
|
||||
|
|
@ -93,7 +93,7 @@ Target Milestone for completion:
|
|||
Work Items
|
||||
----------
|
||||
|
||||
Implementation: https://review.openstack.org/#/c/96889/
|
||||
Implementation: https://review.opendev.org/#/c/96889/
|
||||
Documentation: Add good documentation to heat in tree docs
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ Work Items
|
|||
|
||||
- Add a "tags" parameter to stack-create (engine and API). Note: Tag
|
||||
names must not contain a comma, as specified in the spec:
|
||||
https://review.openstack.org/#/c/155620/
|
||||
https://review.opendev.org/#/c/155620/
|
||||
|
||||
- Add ability to update stack tags during stack-update (engine and
|
||||
API). It should be possible to remove all tags from a stack.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ We are looking to improve the way we deal with versioning (of all sorts
|
|||
db/rpc/rest/templates/plugins).
|
||||
Nova has come up with the idea of versioned objects, that Ironic has also now
|
||||
used. This has now been proposed as an oslo library:
|
||||
https://review.openstack.org/#/c/127532/
|
||||
https://review.opendev.org/#/c/127532/
|
||||
|
||||
https://etherpad.openstack.org/p/kilo-crossproject-upgrades-and-versioning
|
||||
|
||||
|
|
|
|||
|
|
@ -108,4 +108,4 @@ test-requirements.txt
|
|||
- mox: needs to be replaced by mox3 until we move to mock completely.
|
||||
|
||||
[1] https://bitbucket.org/ianb/pastedeploy/commits/f30a7d518c6a79fcddfbe3f622337f81e41cb6a5
|
||||
[2] https://review.openstack.org/#/c/174738/
|
||||
[2] https://review.opendev.org/#/c/174738/
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ For example, consider this workflow:
|
|||
capabilities/options. These are the first major choices a user will make,
|
||||
to determine the nested stack implementations for each type.
|
||||
4. The user selects a nested stack choice for each one that has more than one
|
||||
choice (note https://review.openstack.org/#/c/196656/ discusses approaches
|
||||
choice (note https://review.opendev.org/#/c/196656/ discusses approaches
|
||||
for this selection to be made programmatically via the choices made in (3))
|
||||
5. Reinspect given those major options for the full set of parameters such that
|
||||
the user may be prompted for mandatory and optional parameters, including
|
||||
|
|
|
|||
|
|
@ -98,4 +98,4 @@ Work Items
|
|||
Dependencies
|
||||
============
|
||||
|
||||
Grenade external plugin mechanism https://review.openstack.org/#/c/185050
|
||||
Grenade external plugin mechanism https://review.opendev.org/#/c/185050
|
||||
|
|
|
|||
|
|
@ -84,4 +84,4 @@ Work Items
|
|||
Dependencies
|
||||
============
|
||||
|
||||
- Event message format: https://review.openstack.org/231382
|
||||
- Event message format: https://review.opendev.org/231382
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ inaccurately, in reviews as "SOAP in ReST clothing"). The main driver behind it
|
|||
seems to be a belief that projects will be unwilling to implement a fully
|
||||
ReSTful interface like that proposed here.
|
||||
|
||||
.. _proposed guidelines: https://review.openstack.org/#/c/234994/
|
||||
.. _proposed guidelines: https://review.opendev.org/#/c/234994/
|
||||
|
||||
We could re-use the existing signal API instead of adding a new endpoint.
|
||||
However, that would mean a mix of responsibility in handling signals between
|
||||
|
|
@ -159,7 +159,7 @@ Instead of defining a particular state transition, we could allow the user to
|
|||
set arbitrary resource states. This is a giant can of worms.
|
||||
|
||||
This proposal is an alternative to the one presented in
|
||||
https://review.openstack.org/#/c/212205/ which involved mechanisms to place the
|
||||
https://review.opendev.org/#/c/212205/ which involved mechanisms to place the
|
||||
member IDs of various types of scaling groups under user control. This proposal
|
||||
is both more generic and more relevant to the future convergence plans than
|
||||
that one.
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ Work Items
|
|||
- add the new command to heat-manage.
|
||||
- add code to stack.py to do the migration.
|
||||
- unit tests.
|
||||
- functional tests: https://review.openstack.org/#/c/230292/
|
||||
- functional tests: https://review.opendev.org/#/c/230292/
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ http://docs.openstack.org/developer/devstack/plugins.html
|
|||
By enabling this plugin, we just need to properly set up devstack
|
||||
local[rc] file to be able to setup heat.
|
||||
A good example is ironic one:
|
||||
https://review.openstack.org/#/q/topic:ironic-devstack-plugin
|
||||
https://review.opendev.org/#/q/topic:ironic-devstack-plugin
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
|
|
|||
|
|
@ -20,12 +20,12 @@ Problem description
|
|||
===================
|
||||
|
||||
Ceilometer has moved all the alarming code and subsystem to the Aodh project:
|
||||
https://review.openstack.org/#/c/196552
|
||||
https://review.openstack.org/#/c/197161
|
||||
https://review.opendev.org/#/c/196552
|
||||
https://review.opendev.org/#/c/197161
|
||||
|
||||
Although now we can use ceilometer-client to redirect to Aodh endpoint when
|
||||
creating alarm resources:
|
||||
https://review.openstack.org/#/c/202938
|
||||
https://review.opendev.org/#/c/202938
|
||||
|
||||
But there are some reasons I believe we should to migrate to use
|
||||
Aodh service directly:
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ the semantics of what happens when a client calls into the API, then
|
|||
you should add the APIImpact flag to the commit message. Specifications with
|
||||
the APIImpact flag can be found with the following query:
|
||||
|
||||
https://review.openstack.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
https://review.opendev.org/#/q/status:open+project:openstack/heat-specs+message:apiimpact,n,z
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
|
|
|||
Loading…
Reference in New Issue