Open Stack

I've got a PS in progress for kolla-kubernetes to do keystone fernet token rolling too. Having a cluster aware cron job like function is really nice.
________________________________________
From: Taryma, Joanna [joanna.taryma at intel.com]
Sent: Friday, March 17, 2017 11:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][ironic] Kubernetes-based long running processes

Thank you for this explanation, Clint.
Kuberentes gets more and more popular and it would be great if we could also take advantage of it. There are already projects in Openstack that have a mission that aligns with task scheduling, like Mistral, that could possibly support Kubernetes as a backend and this solution could be adopted by other projects. I’d rather think about enriching an existing common project with k8s support, than starting from scratch.
I think it’s a good idea to gather cross-project use cases and expectation to come up with a solution that will be adoptable by all the projects that desire to use while still being generic.

WRT Swift use case – I don’t see what was listed there as excluded from Kubernetes usage, as K8S supports also 1 time jobs [0].

Joanna

[0] https://kubernetes.io/docs/concepts/jobs/run-to-completion-finite-workloads/

On 3/16/17, 11:15 AM, "Clint Byrum" <clint at fewbar.com> wrote:

    Excerpts from Dean Troyer's message of 2017-03-16 12:19:36 -0500:
    > On Wed, Mar 15, 2017 at 5:28 PM, Taryma, Joanna <joanna.taryma at intel.com> wrote:
    > > I’m reaching out to you to ask if you’re aware of any other use cases that
    > > could leverage such solution. If there’s a need for it in other project, it
    > > may be a good idea to implement this in some sort of a common place.
    >
    > Before implementing something new it would be a good exercise to have
    > a look at the other existing ways to run VMs and containers already in
    > the OpenStack ecosystem.  Service VMs are a thing, and projects like
    > Octavia are built around running inside the existing infrastructure.
    > There are a bunch of deployment projects that are also designed
    > specifically to run services with minimal base requirements.

    The console access bit Joanna mentioned is special in that it needs to be
    able to reach things like IPMI controllers. So that's not going to really
    be able to run on a service VM easily. It's totally doable (I think we
    could have achieved it with VTEP switches and OVN when I was playing
    with that), but I can understand why a container solution running on
    the same host as the conductor might be more desirable than service VMs.

    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev