; From: Hongbin Lu
> Sent: June-01-16 11:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [magnum] Discuss the idea of manually
> managing the bay nodes
>
> Hi team,
>
> A blueprint was created for tracking this idea:
>
num node-create —bay …
> $ magnum node-list —bay
> $ magnum node-delete $NODE_UUID
>
> Anyway, if magnum want to manage a lifecycle of container
> infrastructure.
> This feature is necessary.
>
> Thanks
> -yuanying
>
>
> 2016年5月16日(月) 7:50 Hongbin Lu
> mailt
Hi lbaas team,
I wonder if there is an operator-facing installation guide for neutron-lbaas. I
asked that because Magnum is working on an installation guide [1] and
neutron-lbaas is a dependency of Magnum. We want to link to an official lbaas
guide so that our users will have a completed instru
Sheel,
Thanks for taking the responsibility. Assigned the BP to you. As discussed,
please submit a spec for the API design. Feel free to let us know if you need
any help.
Best regards,
Hongbin
From: Sheel Rana Insaan [mailto:ranasheel2...@gmail.com]
Sent: May-31-16 9:23 PM
To: Hongbin Lu
Cc
Shu,
According to the feedback from the last team meeting, Gatling doesn't seem to
be a suitable name. Are you able to find an alternative name?
Best regards,
Hongbin
> -Original Message-
> From: Shuu Mutou [mailto:shu-mu...@rf.jp.nec.com]
> Sent: May-24-16 4:30 AM
> To: openstack-dev@l
Hi team,
As discussed in the last team meeting, we agreed to define core use cases for
the API design. I have created a blueprint for that. We need an owner of the
blueprint and it requires a spec to clarify the API design. Please let me know
if you interest in this work (it might require a sig
Hi team,
I wrote this email to propose Eli Qiao (taget-9) to be a Higgins core.
Normally, the requirement to join the core team is to consistently contribute
to the project for a certain period of time. However, given the fact that the
project is new and the initial core team was formed based o
I don’t think it is a good to re-invent docker-compose in Higgins. Instead, we
should leverage existing libraries/tools if we can.
Frankly, I don’t think Higgins should interpret any docker-compose like DSL in
server, but maybe it is a good idea to have a CLI extension to interpret
specific DSL
s: Heat as a
> k8s orchestrator
>
> Quick question below.
>
> On 5/28/16, 1:16 PM, "Hongbin Lu" wrote:
>
> >
> >
> >> -Original Message-
> >> From: Zane Bitter [mailto:zbit...@redhat.com]
> >> Sent: May-27-16 6:31 PM
> >
> -Original Message-
> From: Zane Bitter [mailto:zbit...@redhat.com]
> Sent: May-27-16 6:31 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [TripleO][Kolla][Heat][Higgins][Magnum][Kuryr]
> Gap analysis: Heat as a k8s orchestrator
>
> I spent a bit of time exploring
nced vision vs
> one that has 'just do the basics' but thats just my 2 cents...
>
> Hongbin Lu wrote:
> > I agree with you and Qiming. The Higgins project should start with
> > basic functionalities and revisit advanced features later.
> >
> > Best regard
container
hosts(baremetal and VM) automatically, but manual intervention could be
necessary in many pratical use cases. But I suggest to hide these API
interfaces from endusers since it's not their responsibility to manage those
hosts.
Thanks.
2016-05-25 4:55 GMT+08:00 Hongb
utron and keystone running in one node, and then
have N nodes with docker engine, kuryr/libnetwork and the neutron agents of
the vendor of your choice.
[Hongbin Lu] Yes, Magnum is optional if you prefer to install swarm/k8s/mesos
manually or by other tools. What Magnum offers is basically an automat
ssues)
and we are just waiting to start the work (and solve any issues as they come)
Thanks
Gal.
On Mon, May 23, 2016 at 6:35 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Hi Kuryr team,
I want to start this ML to sync up the latest status of the nested container
networking imp
Hi all,
One of the most important feature that Magnum team wants to deliver in Newton
is the full baremetal support. There is a blueprint [1] created for that and
the blueprint was marked as "essential" (that is the highest priority). Spyros
is the owner of the blueprint and he is looking for h
Hi all,
At the last team meeting, we tried to define the scope of the Higgins project.
In general, we agreed to focus on the following features as an initial start:
* Build a container abstraction and use docker as the first
implementation.
* Focus on basic container operations
Hi Kuryr team,
I want to start this ML to sync up the latest status of the nested container
networking implementation. Could I know who is implementing this feature in
Kuryr side and how Magnum team could help in this efforts? In addition, I
wonder if it makes sense to establish cross-project l
FYI,
If you interest to be a mentor for containers or other areas, check below...
Best regards,
Hongbin
From: Emily K Hugenbruch [mailto:ekhugenbr...@us.ibm.com]
Sent: May-23-16 10:25 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [PTLs][all][mentoring] Mentors needed in speci
Hi all,
This is a reminder that we are going to have the second Higgins team meeting at
tomorrow. Hope to see you all there.
https://wiki.openstack.org/wiki/Higgins#Agenda_for_2016-05-24_0300_UTC
Best regards,
Hongbin
__
Op
uot;
>> mailto:openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually
>> managing the bay nodes
>>
>> Hi,
>>
>> I think, user also want to specify the deleting node.
>> So we should manage “node” ind
Hi all,
This is a continued discussion from the design summit. For recap, Magnum
manages bay nodes by using ResourceGroup from Heat. This approach works but it
is infeasible to manage the heterogeneity across bay nodes, which is a
frequently demanded feature. As an example, there is a request t
Hi all,
As discussed, we are going to hold weekly team meetings. I would like to invite
you to the Doodle poll "Higgins team weekly meeting", in which you can choose
your preferred meeting time.
Please follow the link in order to participate in the poll:
http://doodle.com/poll/36mrihhkpxhnf6rf
currently do, and IMO it's our job as a team to
> ensure our docs are up-to-date. Any kind of input which touches the API
> should also live in the API docs, because that's in line with every other
> OpenStack service.
>
> I don't think I've seen documentation
bject: Re: [openstack-dev] [magnum] How to document 'labels'
> >
> >
> >
> >
> >
> >
> > +1 for 1 and 3.
> >
> > I'm not sure maintainability should discourage us from exposing
> information
> > to the user t
rstand a bit better the “chaos” option 3 would cause.
Tom
From: Hongbin Lu [mailto:hongbin...@huawei.com<mailto:hongbin...@huawei.com>]
Sent: 12 May 2016 16:35
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Jinja2 for Heat template
We discussed the management of Heat templates several times. It seems the
consensus is to leverage the *conditionals*feature from Heat (option #1). From
the past discussion, it sounds like option #2 or #3 will significantly
complicate our Heat templates, thus incurring burden on maintenance.
Ho
Hi all,
This is a continued discussion from the last team meeting. For recap, 'labels'
is a property in baymodel and is used by users to input additional key-pair
pairs to configure the bay. In the last team meeting, we discussed what is the
best way to document 'labels'. In general, I heard th
> -Original Message-
> From: Emilien Macchi [mailto:emil...@redhat.com]
> Sent: May-11-16 9:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [puppet] magnum module -
> fixes/improvements for Mitaka release
>
> On Wed, May 11, 2016 at
l.com>> wrote:
HongBin,
What is the skill requirement or credential for this documentation liaison
role? I am interested in doing this
Anthony.
On Tue, May 10, 2016 at 3:24 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Hi team,
We need a volunteer as liaison for documentation
drive consensus on the
project roadmap. Everyone is welcome to join. I hope to see you all there.
[1] https://review.openstack.org/#/c/313935/
[2] https://wiki.openstack.org/wiki/Higgins
[3] https://wiki.openstack.org/wiki/Higgins#Agenda_for_2016-05-13_0300_UTC
Best regards,
Hongbin
From: Hongbin Lu
Hi team,
We need a volunteer as liaison for documentation team. Just let me know if you
interest in this role.
Best regards,
Hongbin
> -Original Message-
> From: Lana Brindley [mailto:openst...@lanabrindley.com]
> Sent: May-10-16 5:47 PM
> To: OpenStack Development Mailing List; enstack
Hi team,
Based on requests, I propose to add support for Keystone authentication for k8s
bay. A blueprint was created for that:
https://blueprints.launchpad.net/magnum/+spec/keystone-for-k8s-bay
A goal is to enable other OpenStack services to access the APIs of k8s bays. So
far, I received a u
eat
> ResourceGroup): It can address the use case of heterogeneity of bay
> nodes (i.e. different availability zones, flavors), but need to
> elaborate the details further.
> >
> > The idea revolves around creating a heat stack for each node in the
> bay. This idea shows a l
there are at least two requested features that will benefit from this idea:
1. The ability to specify different availability zones for bay nodes:
https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones
2. The ability to specify different flavors for bay nodes:
http://lists.openstack
.
--
Adrian
On Apr 23, 2016, at 2:55 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
I am not necessary agree with the viewpoint below, but that is the majority
viewpoints when I was trying to sell Magnum to them. There are people who
interested in adopting Magnum, but they ran away afte
Hi team,
As Adrian mentioned, we decided to narrow the scope of the Magnum project, and
needed to revise Magnum’s mission statement to reflect our mission clearly and
accurately. I would suggest to work on this effort as a team and created an
etherpad for that:
https://etherpad.openstack.org/p
Hi team,
For reference, below is a summary of the discussions/decisions in Austin design
summit. Please feel free to point out if anything is incorrect or incomplete.
Thanks.
1. Bay driver: https://etherpad.openstack.org/p/newton-magnum-bay-driver
- Refactor existing code into bay drivers
- Eac
for a licence issue
Yes, I will contribute to this project.
Thanks
On Sat, Apr 23, 2016 at 8:44 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Jay,
I will discuss the proposal [1] in the design summit. Do you plan to contribute
on this efforts or someone from DCOS community inter
provision minion nodes
>
> Hi Ricardo,
>
> This is really good suggestion. I'd like to see whether we can use
> "foreach"/"repeat" in ResourceGroup in Heat.
>
> Regards,
> Gary Duan
>
> -----Original Message-
> From: Ricardo Rocha [ma
>> we seem to very easily fall into the trap that your assertion
> >> presents. But in almost every one of those cases, having done so
> >> winds up having been a mistake.
> >>
> >> > Both Sahara and Trove have LCD abstractions for very common things.
>
I am not necessary agree with the viewpoint below, but that is the majority
viewpoints when I was trying to sell Magnum to them. There are people who
interested in adopting Magnum, but they ran away after they figured out what
Magnum actually offers is a COE deployment service. My takeaway is CO
Source DCOS.
From Mesosphere
DC/OS software is licensed under the Apache License, so you should feel free to
use it within the terms of that license.
---
Thanks.
On Thu, Apr 21, 2016 at 5:35 AM, Hongbin Lu
Hi team,
Based on a request, I created a link to the latest atomic image that Magnum is
using: https://fedorapeople.org/groups/magnum/fedora-atomic-latest.qcow2 . We
plan to keep this link pointing to the newest atomic image so that we can avoid
updating the name of the image for every image up
gt;
> > Thanks, Kevin From: Monty
> > Taylor [mord...@inaugust.com] Sent: Thursday, April 21, 2016 10:22 AM
> > To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
> > [magnum][app-catalog][all] Build unified abstractio
n use the same key to
> decrypt it upon reading the key back. This might be an acceptable
> middle ground for clouds that will not or can not run Barbican. This
> should work for any OpenStack cloud since Grizzly. The total amount of
> code in Magnum would be small, as the API already exi
> -Original Message-
> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
> Sent: April-21-16 10:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
>
>
> > On Apr 2
gt;
> - Original Message -----
> > From: "Hongbin Lu"
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >
> > > -Original Message-
> > > From: Keith Bray [mailto:keith.b...@rackspace.com]
> > &
> -Original Message-
> From: Keith Bray [mailto:keith.b...@rackspace.com]
> Sent: April-20-16 6:13 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
>
> Magnum doesn¹t h
,
Hongbin
From: Mark Collier [mailto:m...@openstack.org]
Sent: April-19-16 12:36 PM
To: Hongbin Lu
Cc: foundat...@lists.openstack.org; Guang Ya GY Liu
Subject: Re: [OpenStack Foundation] [magnum] Seek advices for a licence issue
Hopefully today’s news that Mesosphere is open major sourcing components of
, at 11:58 AM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Eli,
The approach of pre-pulling docker images has a problem. It only works for
specific docker storage driver. In comparison, the tar file approach is
portable across different storage drivers.
Best regards,
Hongbin
From:
> -Original Message-
> From: Ian Cordasco [mailto:sigmaviru...@gmail.com]
> Sent: April-20-16 1:56 PM
> To: Adrian Otto; OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
>
> -
From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) [mailto:li-gong.d...@hpe.com]
Sent: April-20-16 3:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision
minion nodes
Hi Folks,
We are considering whet
tiated, and you value that, then you likely want to avoid
> the lowest-common-demonitator API because that abstracts you from the
> differentiation that you value.
>
> Kind regards,
> -Keith
>
>
>
> On 4/19/16, 10:18 AM, "Hongbin Lu" wrote:
>
> >Sorr
Eli,
The approach of pre-pulling docker images has a problem. It only works for
specific docker storage driver. In comparison, the tar file approach is
portable across different storage drivers.
Best regards,
Hongbin
From: taget [mailto:qiaoliy...@gmail.com]
Sent: April-19-16 4:26 AM
To: opens
Yes, that is an alternative. The complication is how to secure the
communication between Magnum bays and the standalone docker registry. I assume
we needs some custom logic to setup the communication channel (i.e. install the
TLS credential). One way to support it is to add a configuration hook
7;s for
> Kubernetes/Swarm/Mesos templates and have an api to kick off a workflow
> in Horizon to have Magnum start up a new instance of of the template
> the user selected.
>
> Thanks,
> Kevin
>
> From: Hongbin Lu [hongbin...@huawei.com]
as CC to make sure most can
attend any of these times.
On Wed, Mar 30, 2016 at 5:12 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Gal,
Thursday 4:10 – 4:50 conflicts with a Magnum workroom session, but we can
choose from:
• 11:00 – 11:40
• 11:50 – 12:30
•
Hi all,
Magnum will have a fishbowl session to discuss if it makes sense to build a
common abstraction layer for all COEs (kubernetes, docker swarm and mesos):
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9102
Frankly, this is a controversial topic since I heard agreement
> > references for each cert and key instead of just one barbican
> > reference for both. Also, you would probably have to write the
> > Castellan integration in a way that always uses a context that is
> > generated from the config file which will result in all keys being
> >
0/
I suspect Barbican will forever be a much more mature choice for Magnum.
On Tue, Apr 12, 2016 at 2:43 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Hi all,
In short, some Magnum team members proposed to store TLS certificates in
Keystone credential store. As Magnum PTL, I want to
Hi all,
In short, some Magnum team members proposed to store TLS certificates in
Keystone credential store. As Magnum PTL, I want to get agreements (or
non-disagreement) from OpenStack community in general, Keystone community in
particular, before approving the direction.
In details, Magnum le
st Road, Haidian District Beijing P.R.China 100193
----
Follow your heart. You are miracle!
Hongbin Lu ---11/04/2016 12:06:07 am---My preference is #1, but I don’t feel
strong to exclude #2. I would agree to go with #2 f
-containers
Thanks,
Kevin
____________
From: Hongbin Lu [hongbin...@huawei.com]
Sent: Monday, April 11, 2016 11:10 AM
To: Adrian Otto; OpenStack Development Mailing List (not for usage questions)
Cc: foundat...@lists.openstack.org<mailto:foundat...@lists.openstack.org>
S
age-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: April-11-16 5:28 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [magnum][requirements][release] The
> introduction of package py2-ipaddress
>
> Hongbin Lu wrote:
> > Hi requiremen
Sorry, I disagree.
Magnum team doesn’t have consensus to reject the idea of unifying APIs from
different container technology. In contrast, the idea of unified Container APIs
has been constantly proposed by different people in the past. I will try to
allocate a session in design summit to discu
Hi requirements team,
In short, the recently introduced package py2-ipaddress [1] seems to break
Magnum. In details, Magnum gate recently broke by an error: "'\xac\x18\x05\x07'
does not appear to be an IPv4 or IPv6 address" [2] (the gate breakage has been
temporarily fixed but we are looking fo
Adrian Otto ---04/08/2016 08:49:52 PM---On Apr 8,
2016, at 3:15 PM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote:
From: Adrian Otto mailto:adrian.o...@rackspace.com>>
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>
Hi team,
I would like to give an update for this thread. In the last team, we discussed
several options to introduce Chronos to our mesos bay:
1. Add Chronos to the mesos bay. With this option, the mesos bay will
have two mesos frameworks by default (Marathon and Chronos).
2. Add a
gt; Ihar
>
> Hirofumi Ichihara wrote:
>
> >
> >
> > On 2016/04/08 12:10, Kevin Benton wrote:
> >> Try depending on I2a10a8f15cdd5a144b172ee44fc3efd9b95d5b7e
> > I tried. Let's wait for the result.
> >
> >
> >> On Thu
t has no attribute 'strftime'
>
> Hongbin Lu wrote:
>
> > Hi all,
> > Magnum gate recently broke with error: “AttributeError: 'str' object
> > has no attribute 'strftime'” (here is a full log [1]). I would like
> to
> > confirm if ther
rict Beijing P.R.China 100193
Follow your heart. You are miracle!
[Inactive hide details for Hongbin Lu ---01/04/2016 02:20:17 am---Hi all, Eli
Qiao has been consistently contributed to Magnum f]Hongbin Lu ---01/04/20
Hi all,
Magnum gate recently broke with error: "AttributeError: 'str' object has no
attribute 'strftime'" (here is a full log [1]). I would like to confirm if
there is a recent commit in Neutron that causes the breakage. If yes, a quick
fix is greatly appreciated.
[1]
http://logs.openstack.org
> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: April-06-16 12:16 PM
> To: Hongbin Lu
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum] Containers lifecycle management
>
>
> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: April-06-16 9:14 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [magnum] Containers lifecycle management
>
>
> Greetings,
>
> I'm fairly new to Magnum and I hope my comments below are
Hi team,
As mentioned in the team meeting, Magnum team is using an etherpad [1] to
collaborate topics for design summit. If you interest to join us in the Newton
design summit, I would request your inputs in the etherpad. In particular, you
can do the followings:
* Propose new topics that you wa
ult (we used to
> have networking selection logic in
> scheduler) .
>
> ---
> Egor
>
> ------
> --
> *From:* Hongbin Lu
> *To:* Guz Egor ; OpenStack Development Mailing
> List (not for usage question
...@yahoo.com]
Sent: March-31-16 12:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Hongbin Lu
Subject: Re: [openstack-dev] [magnum] Are Floating IPs really needed for all
nodes?
Hongbin,
It's correct, I was involved in two big OpenStack private cloud deployments an
Hi all,
Thanks for your inputs. We discussed this proposal in our team meeting [1], and
we all agreed to support an option to remove the need of floating IPs. A
blueprint was created for implementing this feature:
https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips . Please
f
me up with based on your feedback:
https://review.openstack.org/#/c/300729/
Thanks,
Dims
On Fri, Apr 1, 2016 at 6:19 PM, Hongbin Lu wrote:
> Dims,
>
> Thanks for splitting the k8sclient code out. Below is my answer to your
> question.
>
> - Should this be a new openstack/ repo
Dims,
Thanks for splitting the k8sclient code out. Below is my answer to your
question.
- Should this be a new openstack/ repo?
Yes, I think so. We need it in openstack namespace in order to leverage the
openstack infra for testing and packaging.
- Would the Magnum team own the repo and use th
Hi all,
Eli Qiao has been consistently contributed to Magnum for a while. His
contribution started from about 10 months ago. Along the way, he implemented
several important blueprints and fixed a lot of bugs. His contribution covers
various aspects (i.e. APIs, conductor, unit/functional tests,
read-only access everywhere, but it means you need
to always authenticate at least with this account)
https://github.com/docker/docker/issues/17317
- swarm 1.1 and kub8s 1.0 allow authentication to the registry from
the client (which was good news, and it works fine), handy if you want
to push/pull
Egor,
I agree with what you said, but I think we need to address the problem that
some clouds are lack of public IP addresses. It is not uncommon that a private
cloud is running without public IP addresses, and they already figured out how
to route traffics in and out. In such case, a bay doesn
Hi Thierry,
After discussing with the Kuryr PTL (Gal), we agreed to have a shared fishbowl
session between Magnum and Kuryr. I would like to schedule it at Thursday 11:50
- 12:30 for now (by using the original Magnum fishbowl slot). We might adjust
the time later if needed. Thanks.
Best regard
Hi team,
After a quick check, it seems python-magnumclient and magnum-ui don't use upper
constraints. Magnum (the main repo) uses upper constraints in integration tests
(gate-functional-*), but doesn't use it in others (e.g. py27, py34, pep8, docs,
coverage). The missing of upper constraints co
Another use case I can think of is to cache the required docker images in the
Glance image.
This is an important use case because we have containerized most of the COE
components (e.g. kube-scheduler, swarm-manager, etc.). As a result, each bay
needs to pull docker images over the Internet on p
integration is important enough and i dont mind using this
time for the session as well.
Either way i am also ok with the 11-11:40 and the 11:50-12:30 sessions or the
3:10-3:50
On Tue, Mar 29, 2016 at 11:32 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Hi all,
As discussed befor
Hi team,
This is the item we didn't have time to discuss in our team meeting, so I
started the discussion in here.
Here is the blueprint:
https://blueprints.launchpad.net/magnum/+spec/support-private-registry . Per my
understanding, the goal of the BP is to allow users to specify the url of th
Hi all,
As discussed before, our team members want to establish a shared session
between Magnum and Kuryr. We expected a lot of attendees in the session so we
need a large room (fishbowl). Currently, Kuryr has only 1 fishbowl session, and
they possibly need it for other purposes. A solution is
Hi team,
Please review the agenda for our team meeting tomorrow:
https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-03-29_1600_UTC
. Please feel free to add items to the agenda if you like.
Best regards,
Hongbin
__
Gal,
Thanks for clarifying the initiative. I added “[Magnum]” to the title so that
Magnum team members can cast their inputs to this thread (if any).
Best regards,
Hongbin
From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: March-19-16 6:04 AM
To: Fox, Kevin M
Cc: OpenStack Development Mailing L
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: March-24-16 9:24 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 -
> are weready?
>
> On Thu, Mar 24, 2016 at 1:48 AM,
for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability
From: Hongbin Lu mailto:hongbin...@huawei.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday 19 March 201
this [2]
> > and this [3]
> >
> > An overall solution is highly available *only* if all of the parts it
> > relies are also highly available as well.
> >
> >
> > [1]
> >
> http://docs.openstack.org/developer/barbican/contribute/architecture.h
> > tml
plexity of doing secure
storage correctly. It gives operators production grade secure storage options,
while giving devs easier options.
--Dave McCowan
[1] https://github.com/openstack/nova/tree/master/nova/keymgr
[2] https://github.com/openstack/cinder/tree/master/cinder/keymgr
From:
Hi,
I would like to announce my candidacy for the PTL position of Magnum.
To introduce myself, my involvement in Magnum began in December 2014, in which
the project was at a very early stage. Since then, I have been working with the
team to explore the roadmap, implement and refine individual c
will put some remarks on the
whiteboard. Duplicating Barbican sounds like a mistake to me.
--
Adrian
> On Mar 17, 2016, at 12:01 PM, Hongbin Lu wrote:
>
> The problem of missing Barbican alternative implementation has been raised
> several times by different people. IMO, this is a very
The problem of missing Barbican alternative implementation has been raised
several times by different people. IMO, this is a very serious issue that will
hurt Magnum adoption. I created a blueprint for that [1] and set the PTL as
approver. It will be picked up by a contributor once it is approve
ongbin,
On Mar 17, 2016, at 2:25 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Adrian,
I think we need a boarder set of inputs in this matter, so I moved the
discussion from whiteboard back to here. Please check my replies inline.
I would like to get a clear problem statement wr
uare peg in
a round hole.
- Doug
On 3/17/16 8:45 PM, Hongbin Lu wrote:
> Thanks Adrian,
>
>
>
> I think the Keystone approach will work. For others, please speak up
> if it doesn't work for you.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
201 - 300 of 409 matches
Mail list logo
