g List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under
/bays
I don't see why the existent of /containers endpoint blocks your workflow.
However, with /containers gone, the alternate workflows are blocked.
As a counterexample, some users want to
-To: OpenStack List
Date: Saturday, 16 January 2016 02:24
To: OpenStack List
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays
The requirements that running a fully containerized application optimally &
effectively requires the usage of a dedicated COE tool such as S
ssage-
> From: Kyle Kelley [mailto:kyle.kel...@rackspace.com]
> Sent: January-19-16 2:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays
>
> With /containers gone
.
From: Hongbin Lu <hongbin...@huawei.com>
Sent: Tuesday, January 19, 2016 9:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays
Assume your logic is applied. Shoul
bin...@huawei.com>
Sent: Tuesday, January 19, 2016 9:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays
Assume your logic is applied. Should Nova remove the endpoint of managing VMs?
Should
]
Sent: January-19-16 5:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays
+1
Doing this, and doing this well, provides critical functionality to OpenStack
while keeping said functionality reasonably
02 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays
A reason is the container abstraction brings containers to OpenStack: Keystone
for authentication, Heat for orchestration, Horizon f
Product Architect – Private Cloud R - Rackspace
From: Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>>
Sent: Thursday, January 14, 2016 1:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Ne
ards,
>
> Hongbin
>
>
>
> *From:* Mike Metral [mailto:mike.met...@rackspace.com]
> *Sent:* January-15-16 6:24 PM
> *To:* openstack-dev@lists.openstack.org
>
> *Subject:* Re: [openstack-dev] [magnum] Nesting /containers resource
> under /bays
>
>
>
> I too believe
vate Cloud R - Rackspace
From: Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>>
Sent: Thursday, January 14, 2016 1:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /contain
- Rackspace
From: Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>>
Sent: Thursday, January 14, 2016 1:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resour
nstack-dev] [magnum] Nesting /containers resource under
/bays
On 01/13/2016 04:42 AM, Jamie Hannaford wrote:
> I've recently been gathering feedback about the Magnum API and one of
> the things that people commented on was the global /containers
> endpoints. One person highlig
area until these are put into further use.
From: Hongbin Lu <hongbin...@huawei.com>
Sent: Wednesday, January 13, 2016 5:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource u
through
Magnum’s endpoints.
Hope it is clear.
Best regards,
Hongbin
From: Kyle Kelley [mailto:kyle.kel...@rackspace.com]
Sent: January-14-16 11:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays
On 01/13/2016 04:42 AM, Jamie Hannaford wrote:
I've recently been gathering feedback about the Magnum API and one of
the things that people commented on was the global /containers
endpoints. One person highlighted the danger of UUID collisions:
"""
It takes a container ID which is intended
Hi Jamie,
I would like to clarify several things.
First, a container uuid is intended to be unique globally (not within
individual cluster). If you create a container with duplicated uuid, the
creation will fail regardless of its bay. Second, you are in control of the
uuid of the container
16 matches
Mail list logo
