* Add ability for handling new predicates for requires
component's property
* Refactoring of exist components validation function
* Update release components according to new DSL model
Implements: blueprint component-registry-improvements
Change-Id: I6175e28118dac494d48968e3f8c51e89ab74a34b
Depends-On: Iab03bf5e36800c8aea0e054719d40ca42a542b73
This patch adds a clear message saying that a pre-provisioned
cluster must support LCM feature in order to allow stopping its
deployment.
Change-Id: I99dc93fac7767dcc5d7116fafd412142e4b3b945
Closes-bug: #1543611
Since there are a couple of places where models for
restrictions is initialized, it's moved to cluster object.
Also, comments from previous commit
(Ibba7951968cbafd59fff0d516e74f9dd9e454edc) are fixed
It's refactoring bug is not needed.
Change-Id: Ic499a5deefb12740ebedc630b024dae0b4248ec5
Task based deployment (>=9.0) implements save way to stop
deployment action, so we can enable stop deployment for such
cluster without restrictions. But it is still need to be
disabled for old env < 9.0 which was already deployed once[1]
Add tests
[1]: https://bugs.launchpad.net/fuel/+bug/1529691
Change-Id: I4284f70f00c5c0b2db026df748c1f73fcd941bf1
Closes-Bug: #1571713
Since Nailgun contains attributes restriction
mechanism it's possible to verify attributes
restrictions. This commit applies restrictions
checks into validation for both node attributes
and cluster attributes.
Change-Id: I269da9a7a7df5fea336c07784b37d6ced1641993
Closes-Bug: #1567394
nailgun.errors have a huge set of exceptions but without hierarchy. This
patch remove exception generation from dict and make it explicitly with
python classes and add some exceptions hierarchy. Now all network errors
inherit from NetworkException and same for other exceptions.
Change-Id: I9a2c6b358ea02a16711da74562308664ad7aed97
Closes-bug: #1566195
These handlers now support query string param `graph_type` that defining
what graph to use during command execution:
/clusters/<cluster_id>/deploy/
/clusters/<cluster_id>/deploy_tasks/
Change-Id: I9d675f15402997570f9032e94ced21176a529cf1
Implements: blueprint custom-graph-execution
Before this change if master node had been upgraded to Fuel of
versions >= 8.0, attempt to re/deploy existing clusters would have failed
as attributes of those clusters would have lack 'deployed_before' field.
Since processing of the flag is temporary solution it should not be
coded in data base migration logic. Thus the change introduces creating
of the attribute with given value if it is not already present.
Change-Id: I302ddb340d2ecf14b1fa414fda71aa7f32363bdf
Closes-Bug: #1551339
In Fuel 5.1 we had an experimental feature - 'patching openstack env'.
The idea was to update and to rollback OpenStack environments between
minor releases. However, we have encounter a lot of problems with
restoring OpenStack databases andresolving dependency hell in packages,
so we buried it and never release it.
This patch removes legacy code from the source tree. We can do it
without fear, since it wasn't released in public.
Related-Bug: #1511499
Change-Id: I58b3fedd239eb7fe4226e51c2d6386efab14395d
In order to upgrade deployed cluster that is in operational state
without re-provisioning it, we need a possibility to forcefully
update cluster attributes (aka cluster/environment settings).
Optional flag '--force' is added to the commands below:
fuel settings --env <env_id> --upload --force
fuel env --env <env_id> --attributes --upload --force
This flag is handled by API here:
clusters/<id>/attributes/?force=1
Partial-Bug: 1540434
Change-Id: Ic6541f8e227251ae992a3005d543a8e1e42665f3
When cluster is successfuly deployed, that is, has 'operational' status,
'deployed_before' key is added to generated attributes of the cluster.
This flag then is used to determine whether stop action is allowed for
the cluster.
Change-Id: I8ecfca5819352ac27d7cec91e22f8006d8c3d8de
Closes-Bug: #1529691
Currently there are at least two providers for neutron which works with
vCenter: DVS and NSXv. So nova network can't be only one possible solution.
Change-Id: Ifa485faaa4d3aa1d94298411a088100e3477d68e
Closes-Bug: #1523977
Modifying cluster creation API (POST /api/clusters) for handling
components data and setup proper values of cluster attributes by
components from wizard. Change storage components metadata.
Implements: blueprint component-registry
Change-Id: Ic2b6774881aab47b5a0914518c5f5db9ab28f3b6
- Added attribute 'is_runtime' to plugin. this attribute means
that plugin can be installed to operational env.
- Make attribute 'is_locked' public and remove logic to calculate
the cluster is locked or not from UI.
Change-Id: I372bfb2c502bcd5927533b03aea1557cf49d9afb
Closes-Bug: #1519050
* Set release state for CentOS to 'unavailable'
* Add release's deployability check in cluster validator
Change-Id: Ic48ed10530efab3823018709b1e072bcfc35d891
Closes-bug: #1486559
In tests, by default, we create Releases with 'multinode'
mode allowed for clusters, now it is taken from release fixture and
only in places that require it, specific modes for releases are used.
Change-Id: If0c0d2bf8fc8a6c572d6284304e0615fd951e005
Related-Bug: #1428054
Fuel cannot deploy clusters, if they use vCenter and
Neutron as a network provider. This patch restricts
network provider selection to Nova Network for the
mentioned cases.
Change-Id: I4b4f861058f6b93ec519fa1d655edecb5cee90aa
Closes-bug: #1470488
* Extended db model with field 'hostname'
* Added hostname validation in API node handler
Change-Id: If18d00612140dcaaeec23bea172dcf6490186e5d
Implements: blueprint node-naming
For 7.0 environments user won't able to choose classic provisioning.
* Remove radio button from UI;
* Add check in validator to disallow classic provisioning for 7.0 envs;
Partially implements: blueprint disable-classic-provisioning
Change-Id: I9fa55dd251b5fab04e2e36154714ba67a8b5a54b
The original fix did not work for validation while updating the cluster
only with deployment mode, which is how the deployment mode is set via
python-fuelclient.
Change-Id: Id3dcbfd339db184ffe75ca8d06675195fe9486de
Closes-Bug: #1456540
Field is called `modes`. Cluster validation stops creating the
environment with mode that is not in the `modes` field of cluster
release.
One cluster validation test seemed to have reversed logic
(test_release_non_exists_validation). It is fixed now.
Change-Id: Iafeb988a91f44e29ea0491422b8348997d950bc4
Closes-Bug: #1456540
Added new exception 'NoDeploymentTasks' which is raised when user
is trying to manually deploy cluster whose release has empty
'deployment_tasks' and 'fuel_version' >= 6.1
Added loading of fake deployment tasks in both test Environment class
and 'loaddefault' command - so it also works in fake mode.
Change-Id: Ibaee6912cfbca27dbb35c4f9c09feb74c81b02a1
Closes-Bug: #1448066
Add validation for cluster attributes. Do it so that it doesn't break
compatibility with current tests. Validate regexpes if they are provided.
Change-Id: I9c1fc04dab45aecf3e32615172654d11844df7c3
Closes-Bug: #1447407
Current release's '.state' attribute is obsolete and do not used. It was
introduced a time ago when we had an RHEL support. So it could be
refactored to fit out current goals.
Since now there will be only two states:
* available
* unavailable
There is no way to start provisioning task for unavailable releases.
Change-Id: I8827c710da6e4f77a6397381d51fe25b87149462
Implements: blueprint downloadable-ubuntu-release
We have several requirements for graph storages, that will
satisfy all parties:
- Store graph definition externally to nailgun, in fuel-library,
because fuel-library devs should be able to modify graph configuration,
based on changes in puppet modules
- Validate any data that nailgun will store, and validation should
happen at the time data is received by nailgun
- It should be possible to migrate data to required format, on upgrade,
if we will decide that it is necessary
- It should be possible to modify graph per cluster, and per release,
for flexibility of debugging and development, also it may
help with maintenance tasks
To solve this issues 2 db fields was added:
Cluster.deployment_tasks
Release.deployemtn_tasks
It will be possible to read/modify both of this fields by next api request:
GET/PUT release/<rel_id>/deployment_tasks
GET/PUT cluster/<cluster_id>/deployment_tasks
Also note that deployment configuration for old release will be stored in
nailgun code in orchestrator/graph_configuration.py module
implements blueprint granular-deployment-based-on-tasks
Change-Id: I6f23da3ea7a4f692d02dcb84175540e64f34df89
- errors are now returned as tracebacks, not HTML
- added schema checking based on the handler type and validator
- content_json decorator rewritten completely
- common JSON types
- creation of nodes with non-number ID is now forbidden according to scheme
Implements: blueprint nailgun-api-requests-responses-validation
Change-Id: Icf49bb534ccb19872402b66532ef44418bd66a53
We have to make possible to downgrade openstack release from
later version to earlier version.
Implements blueprint openstack-patching-nailgun-part
Change-Id: I473887ae49f9fa85e2cafcc53cb23cc230e321cc
OpenStack upgrader performs the following tasks:
* add information about new releases to Nailgun
* add notification about new releases to Nailgun
Related to blueprint fuel-upgrade
Change-Id: I962921492e09e06eb0396fae26c4bea1774720df
To improve RESTfulness and make a step to API freezing, we need to make each
handler able to receive back its own JSON without falling to 500 error.
Implements: blueprint nailgun-rest-same-json
Change-Id: I78d910eac3d7b067a9930000aab6f568214bf2eb
Andreas Jaeger