This is a defect with Github and should not affect our ability to fix
defects and correct/refactor our code. git is a CLI tool not a GUI tool
and should be treated as such. We should not be imposing restrictions on
our developers because a 3rd party GUI does not fit our workflows.
Tom
On
This has been my thinking in the last couple of months to completely
deprecate the COE specific APIs such as pod/service/rc and container.
As we now support Mesos, Kubernetes and Docker Swarm its going to be
very difficult and probably a wasted effort trying to consolidate their
separate APIs
Hi Team,
Wanted to let you know why we are having consistent functional test
failures in the gate.
This is being caused by Nova returning No valid host to heat:
2015-08-13 08:26:16.303 31543 INFO heat.engine.resource [-] CREATE:
Server kube_minion [12ab45ef-0177-4118-9ba0-3fffbc3c1d1a]
Hello,
After a discussion in our weekly meeting[1] and in a ML thread[2] we have
decided to retire the heat-coe-templates[3] repository and move it to
openstack-attic[4].
Initially this repository was intended to replace heat-kubernetes[5] and the
templates in the Magnum repo. However the
...@rackspace.com wrote:
Team,
Tom Cammann (tcammann) has become a valued Magnum contributor, and
consistent reviewer helping us to shape the direction and quality of our new
contributions. I nominate Tom to join the magnum-core team as our newest
core reviewer. Please respond with a +1 vote
Hello team,
I've been doing work in Magnum recently to align our templates with the
upstream templates from larsks/heat-kubernetes[1]. I've also been porting
these changes to the stackforge/heat-coe-templates[2] repo.
I'm currently not convinced that maintaining a separate repo for Magnum
Hello team,
I’ve submitted a blueprint[1] for adding python 3 compatibility to Magnum. Many
of the other integrate release OpenStack projects have started on this[2]
journey and it would be great to add ourselves to that list.
This will entail refactoring a fairly small amount of code throughout
My main issue with having the user generate the keys/certs for the kube
nodes
is that the keys have to be insecurely moved onto the kube nodes.
Barbican can
talk to heat but heat must still copy them across to the nodes, exposing the
keys on the wire. Perhaps there are ways of moving secrets
:21 AM, Davanum Srinivas dava...@gmail.com wrote:
+1 from me Tom.
On Mon, Jun 15, 2015 at 1:15 PM, Tom Cammann tom.camm...@hp.com wrote:
Hello,
I haven't seen any false positives in a few weeks from the functional
tests, but I have seen a couple reviewers missing the -1 from the non-voting
job
Hello,
I haven't seen any false positives in a few weeks from the functional
tests, but I have seen a couple reviewers missing the -1 from the
non-voting job
when there has been a legitimate failures.
I think now would be a good time to turn 'check-functional-dsvm-magnum' to
voting.
Thanks,
Hello,
I'm addressing https://bugs.launchpad.net/oslo/+bug/1326020 which is
dealing with periodic tasks.
There is currently a code block that checks if a task is 0.2 seconds
away from being run and if so it run now instead. Essentially
coalescing nearby tasks together.
From
11 matches
Mail list logo
