When a Bay is created, we use Heat to bring up resources to use for the Bay.
We would like to see the related status in the Bay resource that tracks what's
happening. We use the new status attribute to show what is happening with Heat
behind the scenes.
Partially-Implements: blueprint magnum-bay-status
Change-Id: I7b841f2afbe575b039ebbde0e19d8fc464246608
Oslo team is recommending everyone to use the direct imports and
not use the Oslo namespaces. So switch all our code to use oslo_*
instead of "from oslo." or "import oslo" or "from oslo"
NOTE: some of the tests still have mocks referring to oslo.utils
@mock.patch('oslo.utils.timeutils.utcnow')
as the tests break otherwise. We should do this later.
Closes-bug: #1419385
Change-Id: I8e3fbeb833cddc3f55674a0e781ffe69d5033ad4
newer hacking has rules for the following:
H105 Don't use author tags
H238 old style class declaration, use new style (inherit from `object`)
W292 no newline at end of file
So we need to clean them up and stop ignoring them
Change-Id: I12b995cf87d6bc0938298f397b41a4693627bb4b
The get() API was not used by the following objects, just remove it.
1) node
2) pod
3) replication controller
4) service
5) container
Change-Id: I2f578f8d072d772bf34e676b115eccf6c08bac8a
The updated API include the following:
1) get_bay_by_id
2) get_baymodel_by_id
3) get_node_by_id
4) get_container_by_id
Implements part of bp multi-tenant
Change-Id: I7d2f8b7ea361b38d6f0110772c10f93037c7aefb
The updated API include the following:
1) get_node_list
2) get_baymodel_list
3) get_bay_list
4) get_container_list
Implements part of bp multi-tenant
Change-Id: Iabc81288cf58d0a7da4f4fec90a1be561d41d9f3
The updated API include the following:
1) get_bay_by_uuid
2) get_baymodel_by_uuid
3) get_node_by_uuid
4) get_container_by_uuid
Implements part of bp multi-tenant
Change-Id: I6cff457e585b4dd11f485eb63e477b8de0e96bea
project_id and user_id were added to the following tables:
1) container
2) node
3) bay
4) baymodel
Implements part of bp multi-tenant
Change-Id: Ied9a855251246bb087bc8bca70809a81594f26c7
Pod, Service and ReplicationController have data and definition_url attribute,
but it's name is needlessly long.
This fixes it to more appropriate attribute name.
Change-Id: I64e8922ef8f6fc0dc4a7fda02aa0913ca15177e4
Only replication controller manifest knows about rc name, so
this patch retrieve rc name from rc manifest.
Change-Id: I8193c2066ea1f0a40761f304f784fbb3b2d16796
Only service manifest knows about service name, so this patch retrieve service
name from service manifest.
Change-Id: I1eb0f7dd7227875e1d10e5bd1d22f7e989e15f86
Did the following fix/modification to make the tests pass:
* Raise an exception on deleting non-existent pod or service.
* Rename the following methods:
get_service_by_bay_uuid -> get_services_by_bay_uuid (db)
get_by_bay_uuid -> list_by_bay_uuid (objects)
Change-Id: I7cbeb119550acecdbf0697df19172a8285eabca8
This is the backend change for patch Iaae8486
The k8s service create only has one parameter as filename, this
patch is updating magnum backend api can use filename as parameter
when creating service.
Change-Id: I67f0cea72b00f1ce35bf3e8c49153daf1d2fff68
This is the backend change for patch I254a20a
The k8s pod create only has one parameter as filename, this patch
is updating magnum backend api can use filename as parameter when
creating pod.
Change-Id: Ibdc05415ce2cb4e30f1d5687b03f2c0761047dec
First cut of Docker container creation and start should be working now
Tested using the REST API:
curl -i -X POST -H 'X-Auth-Token: 1b238d90cd0645a39a626581cf0c9f19' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{"image_id": "cirros", "name": "mycontainer"}' \
http://127.0.0.1:9511/v1/v1/containers
curl -i -X PUT -H 'X-Auth-Token: 1b238d90cd0645a39a626581cf0c9f19' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'User-Agent: python-magnumclient' \
http://127.0.0.1:9511/v1/containers/4e19a981-057f-4d55-9aaf-d12c06e6430a/start
And the magnum CLI:
echo '{"name":"mycontainer", "image_id":"cirros"}' | magnum --debug container-create
magnum --debug container-start --id c6d6c759-9875-4dd4-aaa3-619799015c1d
Change-Id: Ib7a46d95d2d89cd8479bb0a318a3c9efaf23f187
The baymodel_id represents the bay model used to generate this
particular Bay. This is essentially a split of Bay into multiple
objects - one for template storage - one for instantation.
Change-Id: Ie6b7220bfecfd61af0ecf9114a791dfed61b415e
The baymodel object and ReST object is used to control bay properties
for different bay models. It is then possible to launch bay models
using this functionality.
Change-Id: I317bda292719ca3f4649283f7e27674c813cc3b0
The node object represents either a bare metal or virtual machine node
that is provisioned with an OS to run the containers, or alternatively,
run kubernetes.
Change-Id: I9eba14232c193688347b7ec2674c83f230404ae1
The idea of bay-create is that you create a grouping of machines that run
container software. In order to do this, an image_id stored in glance is
necessary to pull the base image to modify for launching by either heat or
Ironic. A node_count is needed as well, to identify how many ironic nodes
you want to launch.
Change-Id: I5689d024f4ece93369498bd7f64cde0b8a59e292
Jenkins