to specify the deleting node.
> So we should manage “node” individually.
>
> For example:
> $ magnum node-create —bay …
> $ magnum node-list —bay
> $ magnum node-delete $NODE_UUID
>
> Anyway, if magnum want to manage a lifecycle of container
> infrastructure.
> This
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
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:
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
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
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
s: Heat as a
> k8s orchestrator
>
> Quick question below.
>
> On 5/28/16, 1:16 PM, "Hongbin Lu" <hongbin...@huawei.com> wrote:
>
> >
> >
> >> -Original Message-
> >> From: Zane Bitter [mailto:zbit...@redhat.com]
> >> Sent:
> -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
n 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 regards,
> >
> &g
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 Hongbin Lu
<hong
one 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 automation of
de
)
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
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:
Hi Kuryr team,
I want to start this ML to sync up the latest status of the nest
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
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
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
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
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
__
nstack.org<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” indi
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
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
ll face the same
> maintenance burden as we 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
t; <openstack-dev@lists.openstack.org>
> > Cc: Qun XK Wang <bjw...@cn.ibm.com>
> > Date: 05/12/2016 07:08 AM
> > Subject: Re: [openstack-dev] [magnum] How to document 'labels'
> >
> >
> >
> >
> >
> >
&
icy.
I would like to understand 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] Jinj
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.
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
> -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
com<mailto:vcloudernb...@gmail.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
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>>
and 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;
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
of being managed by Heat
> 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.
e 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.org/pi
.
--
Adrian
On Apr 23, 2016, at 2:55 PM, Hongbin Lu
<hongbin...@huawei.com<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 ado
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:
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
-
for a licence issue
Yes, I will contribute to this project.
Thanks
On Sat, Apr 23, 2016 at 8:44 PM, Hongbin Lu
<hongbin...@huawei.com<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 someo
o:rocha.po...@gmail.com]
> Sent: Thursday, April 21, 2016 3:49 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to
> provision minion nodes
>
> Hi Hongbi
;>
> >> > Both Sahara and Trove have LCD abstractions for very common things.
> >> > Magnum should too.
> >> >
> >> > You are falsely assuming that if an LCD abstraction is provided,
> >> > then users cant use the raw api directly. This is
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
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
<hong
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
_ 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 abstraction for all COEs
> &g
; certificate and store it in keystone. We would then 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
&g
> -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
gt;
> - Original Message -----
> > From: "Hongbin Lu" <hongbin...@huawei.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > > -Original Message-
>
> -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
,
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
, at 11:58 AM, Hongbin Lu
<hongbin...@huawei.com<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.
> -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
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" <hongbin...@huawei.com&
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:
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
m/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]
> Sent: Monday, April 18,
as CC to make sure most can
attend any of these times.
On Wed, Mar 30, 2016 at 5:12 PM, Hongbin Lu
<hongbin...@huawei.com<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
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
nces 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
> > owned by
rnative to Barbican:
https://review.openstack.org/#/c/284950/
I suspect Barbican will forever be a much more mature choice for Magnum.
On Tue, Apr 12, 2016 at 2:43 PM, Hongbin Lu
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:
Hi all,
In short, some Magnum team memb
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
ilding), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West 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
,
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>
Subject: Re: [opensta
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 requi
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
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
for Adrian Otto ---04/08/2016 08:49:52 PM---On Apr 8,
2016, at 3:15 PM, Hongbin Lu <hongbin...@huawei.com]Adrian Otto ---04/08/2016
08:49:52 PM---On Apr 8, 2016, at 3:15 PM, Hongbin Lu
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:
From: Adrian Otto <adrian.
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
fumi Ichihara <ichihara.hirof...@lab.ntt.co.jp> wrote:
>
> >
> >
> > On 2016/04/08 12:10, Kevin Benton wrote:
> >> Try depending on I2a10a8f15cdd5a144b172ee44fc3efd9b95d5b7e
> > I tried. Let's wait for the result.
> >
> >
> >> On Th
ttribute 'strftime'
>
> Hongbin Lu <hongbin...@huawei.com> 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 there is a recent commi
Bei Wang West Road, Haidian District 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
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]
> -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
tworking selection logic in
> scheduler) .
>
> ---
> Egor
>
> ----------
> --
> *From:* Hongbin Lu <hongbin...@huawei.com>
> *To:* Guz Egor <guz_e...@yahoo.com>; OpenStack Development Mailing
> List
...@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 and
we
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
with based on your feedback:
https://review.openstack.org/#/c/300729/
Thanks,
Dims
On Fri, Apr 1, 2016 at 6:19 PM, Hongbin Lu <hongbin...@huawei.com> wrote:
> Dims,
>
> Thanks for splitting the k8sclient code out. Below is my answer to your
> question.
>
> - Should this
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
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,
- example:
docker.cern.ch/my-fancy-image<http://docker.cern.ch/my-fancy-image>.
Things we found on the way:
- registry v2 doesn't seem to allow anonymous pulls (you can always
add an account with read-only access everywhere, but it means you need
to always authenticate at least with this account
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
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
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
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
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
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> w
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
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
> -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
ist (not for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability
From: Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org<mailto:op
;
> > 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#overall-architecture [2]
> > http
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: Hongbin Lu <hong
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
s on the
whiteboard. Duplicating Barbican sounds like a mistake to me.
--
Adrian
> On Mar 17, 2016, at 12:01 PM, Hongbin Lu <hongbin...@huawei.com> wrote:
>
> The problem of missing Barbican alternative implementation has been raised
> several times by different people. IMO, this
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
.@rackspace.com<mailto:adrian.o...@rackspace.com>> wrote:
Hongbin,
On Mar 17, 2016, at 2:25 PM, Hongbin Lu
<hongbin...@huawei.com<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 b
.
- 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
>
>
>
> *From:*Adrian Otto [mail
OK. If using Keystone is not acceptable, I am going to propose a new approach:
· Store data in Magnum DB
· Encrypt data before writing it to DB
· Decrypt data after loading it from DB
· Have the encryption/decryption key stored in config file
· Use
201 - 300 of 406 matches
Mail list logo
