Hi all,
I am used to report the os-ken related progress in the neutron team meeting.
After switching to winter time, I am not able to attend the meeting at Tuesday
1400 UTC. I sent out the report in the ML instead. Below is the progress in
last week.
* The os-ken 0.2.0 is released: https://rev
Hi Rania,
The config option 'driver' was recently renamed, so I guess the problem is
the version of kuryr-lib is not right. The Pike release of Zun is matched
to kuryr-lib 0.6.0 so you might want to confirm the version of kuryr-lib.
$ sudo pip freeze | grep kuryr
If the version is not right, uni
nov. 2018 à 02:34, Rania Adouni a
> écrit :
>
>> Hi Hongbin,
>> Yes the version of kuryr-lib is :0.8.0 , So I think I should remove it !
>> I should remove only the kuryr-lib ! if you have some command they can
>> help me to unisntall it , it will be nice to provide it
Hi Rania,
See if this helps:
http://lists.openstack.org/pipermail/openstack-dev/2018-November/136547.html
Best regards,
Hongbin
On Wed, Nov 21, 2018 at 7:27 AM Rania Adouni wrote:
> Hi everyone,
>
> I was trying to create container but I just ended up by this error :
> *Docker internal error:
Hi all,
I am writing tests for the Magnum dbapi. I have several questions about its
implementation and appreciate if someone could comment on them.
* Exceptions: The exceptions below were ported from Ironic but don't seem
to make sense in Magnum. I think we should purge them from the code except
Hi Heat team,
I am looking for a solution to bridge between OpenStack and EC2. According
to documents, it seems that Heat has multicloud support but the remote
cloud(s) must be OpenStack. I wonder if Heat supports multicloud in the
context of supporting remote EC2 cloud. For example, does Heat sup
Hi Steve,
Thanks for your contributions. Personally, I would like to think for your
mentorship and guidance when I was new to Magnum. It helps me a lot to pick up
everything. Best wish for your adventure in Kolla.
Best regards,
Hongbin
From: Steven Dake (stdake) [mailto:std...@cisco.com]
Sent:
I am going to share something that might be off the topic a bit.
Yesterday, I was pulled to the #openstack-infra channel to participant a
discussion, which is related to the atomic image download in Magnum. It looks
the infra team is not satisfied with the large image size. In particular, they
Hi team,
I would like to start this ML to discuss the git rename issue. Here is the
problem. In Git, it is handy to retrieve commit history of a file/folder. There
are several ways to do that. In CLI, you can run "git log ..." to show the
history. In Github, you can click "History" bottom on to
Hi Bharath,
I agree the "container" part. We can implement "magnum container-create .." for
mesos bay in the way you mentioned. Personally, I don't like to introduce
"apps" and "appgroups" resources to Magnum, because they are already provided
by native tool [1]. I couldn't see the benefits to
Here is a bit more context.
Currently, at k8s and swarm bay, some required binaries (i.e. etcd and flannel)
are built into image and run at host. We are exploring the possibility to
containerize some of these system components. The rationales are (i) it is
infeasible to build custom packages in
Jay,
Agree and disagree. Containerize some COE daemons will facilitate the version
upgrade and maintenance. However, I don’t think it is correct to blindly
containerize everything unless there is an investigation performed to
understand the benefits and costs of doing that. Quoted from Egor, th
t going to be a
nuisance to keep up with the various upstreams until they become completely
stable from an API perspective, and no additional changes are likely. All of
our COE’s still have plenty of maturation ahead of them, so this is the wrong
time to wrap them.
If someone really wants apps a
As Bharath mentioned, I am +1 to extend the "container" object to Mesos bay. In
addition, I propose to extend "container" to k8s as well (the details are
described in this BP [1]). The goal is to promote this API resource to be
technology-agnostic and make it portable across all COEs. I am going
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
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
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
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
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
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 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
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 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
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 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
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
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
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
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
> -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
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
> >
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
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
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
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
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
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
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
; 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:
>
ng Magnum
> again from its roadmap. Whereas we should leverage Heat(or may be
> Senlin) APIs for the same.
>
> I vote +1 for this feature.
>
> Regards,
> Madhuri
>
> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Thursday,
multiple
> homogeneous bays, not a single heterogeneous one. That way you end up
> with a composition of simple systems rather than a larger complex one.
>
> Adrian
>
>
> > On Jun 1, 2016, at 3:02 PM, Hongbin Lu wrote:
> >
> > Personally, I think this is a good
Hi all,
We would like to introduce you a new container project for OpenStack called
Higgins (might be renamed later [1]).
Higgins is a Container Management service for OpenStack. The key objective of
the Higgins project is to enable tight integration between OpenStack and
container technologie
Hi all,
Please find the Doodle pool below for selecting the Magnum midcycle date.
Presumably, it will be a 2 days event. The location is undecided for now. The
previous midcycles were hosted in bay area so I guess we will stay there at
this time.
http://doodle.com/poll/5tbcyc37yb7ckiec
In add
Hi Heat team,
A question inline.
Best regards,
Hongbin
> -Original Message-
> From: Steven Hardy [mailto:sha...@redhat.com]
> Sent: March-03-16 3:57 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][heat] spawn a group of nodes
Insaan
> Cc: Hongbin Lu; adit...@nectechnologies.in;
> vivek.jain.openst...@gmail.com; Shuu Mutou; Davanum Srinivas; hai-
> x...@xr.jp.nec.com; Yuanying; Kumari, Madhuri; yanya...@cn.ibm.com;
> flw...@catalyst.net.nz; OpenStack Development Mailing List (not for
> usage questions);
wikipedia.org/wiki/Twistlock
>>
>> These words are not used by other project on PYPI and Launchpad.
>>
>> ex.)
>> https://pypi.python.org/pypi/straddle
>> https://launchpad.net/straddle
>>
>>
>> However the chance of renaming in N cycle will be
gt; Subject: Re: [openstack-dev] [Magnum] The Magnum Midcycle
>
> Hi Hongbin.
>
> Not sure how this fits everyone, but we would be happy to host it at
> CERN. How do people feel about it? We can add a nice tour of the place
> as a bonus :)
>
> Let us know.
>
> Ricardo
>
rg>>
Subject: Re: [openstack-dev] [Magnum] The Magnum Midcycle
Hi Hongbin.
CERN's location: https://goo.gl/maps/DWbDVjnAvJJ2
Cheers,
Spyros
On 8 June 2016 at 16:01, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Ricardo,
Thanks for the offer. Would I know wh
+1
> -Original Message-
> From: Shuu Mutou [mailto:shu-mu...@rf.jp.nec.com]
> Sent: June-10-16 5:33 AM
> To: openstack-dev@lists.openstack.org
> Cc: Haruhiko Katou
> Subject: [openstack-dev] [magnum-ui][magnum] Proposed Core addition,
> and removal notice
>
> Hi team,
>
> I propose the f
://etherpad.openstack.org/p/containers-service-api
* https://etherpad.openstack.org/p/openstack-containers-service-api
2016年6月1日(水) 12:09 Hongbin Lu
mailto:hongbin...@huawei.com>>:
Sheel,
Thanks for taking the responsibility. Assigned the BP to you. As discussed,
please submit a spec for the API design
Hi,
It looks Spyros already answered your question:
http://lists.openstack.org/pipermail/openstack-dev/2016-June/097083.html . Is
anything else we can help, or you have further questions?
Best regards,
Hongbin
From: zhihao wang [mailto:wangzhihao...@hotmail.com]
Sent: June-11-16 1:03 PM
To: op
Hi team,
During the team meetings these weeks, we collaborated the initial project
roadmap. I summarized it as below. Please review.
* Implement a common container abstraction for different container runtimes.
The initial implementation will focus on supporting basic container operations
(i.e.
creating a heat stack for each node in the bay. This
idea shows a lot of promise but needs more investigation and isn’t a current
priority.
Tom
From: Hongbin Lu mailto:hongbin...@huawei.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:opens
Rana
Insaan; Yuanying
Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap
On Mon, Jun 13, 2016 at 12:10 AM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Hi team,
During the team meetings these weeks, we collaborated the initial project
roadmap. I summarized it as below.
Percoco wrote:
> > On 12/06/16 22:10 +, Hongbin Lu wrote:
> >> Hi team,
> >>
> >> During the team meetings these weeks, we collaborated the initial
> >> project roadmap. I summarized it as below. Please review.
> >>
> >> * Impl
> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: June-14-16 3:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap
>
> On 13/06/16 18:46 +0
ck Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Magnum] The Magnum Midcycle
Hi Hongbin.
CERN's location: https://goo.gl/maps/DWbDVjnAvJJ2
Cheers,
Spyros
On 8 June 2016 at 16:01, Hongbin Lu
mailto:hong
, CA.
--
Adrian
On Jun 7, 2016, at 1:35 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Hi all,
Please find the Doodle pool below for selecting the Magnum midcycle date.
Presumably, it will be a 2 days event. The location is undecided for now. The
previous midcycles were hosted
x27;m surprised at neutron-lbaas being a
> > dependency of magnum. Why is this? Sorry if it has been asked
> before
> > and I've just missed that answer?
> >
> > Thanks,
> > Brandon
> > On Wed, 2016-06-01 at 14:39 +, Hongbin Lu wrote:
> >>
2016 at 3:54 PM, Hongbin Lu
mailto:hongbin...@huawei.com>> wrote:
Hi neutron-lbaas team,
Could anyone confirm if there is an operator-facing install guide for
neutron-lbaas. So far, the closest one we could find is:
https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun , which doesn'
.
---
Pengfei Ni
Software Engineer @Hyper
2016-06-13 6:10 GMT+08:00 Hongbin Lu
mailto:hongbin...@huawei.com>>:
Hi team,
During the team meetings these weeks, we collaborated the initial project
roadmap. I summarized it as below. Please review.
* Implement a common container abstracti
Ricardo,
Thanks for sharing. It is good to hear that Magnum works well with a 200 nodes
cluster.
Best regards,
Hongbin
> -Original Message-
> From: Ricardo Rocha [mailto:rocha.po...@gmail.com]
> Sent: June-17-16 11:14 AM
> To: OpenStack Development Mailing List (not for usage questions)
Hi all,
This is a reminder that there are doodle pools for midcycle participants to
select the location and time:
Location: http://doodle.com/poll/2x9utspir7vk8ter
Date: http://doodle.com/poll/5tbcyc37yb7ckiec
If you are able to attend the midcycle, I encourage you to vote for your
preferred l
uster.
> >
> > Summary:
> >
> > Heterogeneous:
> > - Complex
> > - Prone to imbalance upon node failure
> > - Less reliable
> >
> > Heterogeneous:
> > - Simple
> > - Don’t get imbalanced when a min_members concept is suppo
: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: June-21-16 2:14 AM
To: OpenStack Development Mailing List (not for usage questions); Vikas
Choudhary; Antoni Segura Puimedon; Irena Berezovsky; Fawad Khaliq; Omer Anson;
Hongbin Lu
Subject: [Kuryr][Magnum] - Kuryr nested containers and Magnum Integration
um has deleted all wrapper API for container creation and pod-create
Oh, I was referring to older design then. In that case, What would be
corresponding alternative now?
Is this related to Zun somehow?
[Hongbin Lu] The alternative is native CLI tool (i.e. kubectl, docker). This is
unrelated to Zu
Hi all,
The Magnum midcycle will be held in Aug 4 - 5 at Austin. Below is the link to
register. Hope to see you all there.
https://www.eventbrite.com/e/magnum-midcycle-tickets-26245489967
Best regards,
Hongbin
__
OpenStack
Hi all,
FYI. The Magnum team is collecting a list of Magnum users. If you are using
Magnum, we would like to have your name and organization recorded in our wiki
[1]. Please note that this is totally optional, but we hope you will let us
know if you are our users.
[1] https://wiki.openstack.or
Hi all,
Here is a notice that we have moved our IRC channel from #openstack-higgins to
#openstack-zun . Right now, all the bots have been moved to the new channel
[1]. The old channel is no longer used anymore.
[1] https://review.openstack.org/#/c/330017/
Best regards,
Hongbin
Hi all,
At the last team meeting, we made an important decision about the design. I
would like to summarize it in this email so that everyone will be on the same
page.
Short version:
* Zun aims to build an unified API layers to interface with various Container
Orchestration Engines (COEs).
* Z
Hi all,
FYI. I won't be able to chair the next team meeting because I will be on the
flight at that time. Madhuri will chair the next meeting on behalf. Thanks.
Best regards,
Hongbin
__
OpenStack Development Mailing List (no
Johannes,
Magnum generates Keystone trust for each bay:
https://blueprints.launchpad.net/magnum/+spec/create-trustee-user-for-each-bay
. Possibly, you can reuse the trust stored in the bay for this purpose.
Best regards,
Hongbin
> -Original Message-
> From: Johannes Grassler [mailto:jg
Hi all,
Because I cannot attend the team meeting next week, I would leave a message
here: I am working on a spec to define the high-level design of the Zun service.
https://etherpad.openstack.org/p/zun-containers-service-design-spec
I would encourage everyone to participant on this efforts to s
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
__
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,
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
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
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
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
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
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
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
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,
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
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
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
...@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
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
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
> -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
> -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
>
>
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
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
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
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
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
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 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
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
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
1 - 100 of 409 matches
Mail list logo
