duate.
Best regards.
Chaoyi Huang ( joehuang )
发件人: Maru Newby [ma...@redhat.com]
发送时间: 2014年9月1日 17:53
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging
perspective
O
4, 9:05 AM, joehuang wrote:
> Hello,
>
> Not all features which had already been shipped in Neutron supported by
> Horizon. For example, multi provider network.
>
> This is not the special case only happened in Neutron. For example, Glance
> delivered V2 api in IceHouse or ev
Hello,
Sorry I don't know what happened in the history of Neutron DB design.
It's very strange that there is no timestamp for Neutron objects, especially
for Port. Nova/Cinder has timestamp field for almost all objects.
Port status will be changed timely, it's very useful to record the timesta
+1
There are lots of concurrent requests to the quota management service if it's
shared for projects, especially if it's shared for multi-regions (KeyStone can
be global service for multi-regions), also latency will affect the end user
experience. POC is good idea to verify the concept.
Best R
Hello,
if an ordinary user sent a get-token request to KeyStone, internalURL and
adminURL of endpoints will also be returned. It'll expose the internal high
privilege access address and some internal network topology information to the
ordinary user, and leads to the risk for malicious user to
tc-Multi-clouds-integration-by-OpenStack-cascading-td54115.html
Best Regards
Chaoyi Huang (joehuang)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-td54115.html
Best Regards
Chaoyi Huang (joehuang)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
for the
> multi-site cloud, but it's prosperity API in the north bound interface. The
> cloud operators want the ecosystem friendly global open API for the
> mutli-site cloud for global access.
Best Regards
Chaoyi Huang ( joehuang )
F
Hi,
If time is available, how about adding one agenda to guide the direction for
cascading to move forward? Thanks in advance.
The topic is : " Need cross-program decision to run cascading as an incubated
project mode or register BP separately in each involved project. CI for
cascading is qui
Hello, Thierry,
That sounds great.
Best Regards
Chaoyi Huang ( joehuang )
From: Thierry Carrez [thie...@openstack.org]
Sent: 09 December 2014 18:32
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Cross-Project meeting, Tue December
recap and move forward
>> On Fri, Dec 5, 2014 at 8:23 AM, joehuang wrote:
>>> Dear all & TC & PTL,
>>>
>>> In the 40 minutes cross-project summit session “Approaches for
>>> scaling out”[1], almost 100 peoples attended the meeting, and the
vs. Cells – summit
recap and move forward
On 12/11/2014 04:02 AM, joehuang wrote:
>> [joehuang] The major challenge for VDF use case is cross OpenStack
>> networking for tenants. The tenant's VM/Volume may be allocated in
>> different data centers geographically, but vi
. Cells – summit
recap and move forward
On 12/11/2014 04:02 AM, joehuang wrote:
> Hello, Russell,
>
> Many thanks for your reply. See inline comments.
>
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Thursday, December 11, 2014 5:22 A
egards
Chaoyi Huang ( joehuang )
From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: Friday, December 12, 2014 8:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells - summit
recap and move forward
On Thu, Dec
Hello, Joshua,
Sorry, my fault. You are right. I owe you two dollars.
Best regards
Chaoyi Huang ( joehuang )
-Original Message-
From: Joshua Harlow [mailto:harlo...@outlook.com]
Sent: Friday, December 12, 2014 9:47 AM
To: OpenStack Development Mailing List (not for usage questions
ta disks up to ~80,000 4K random
> read IOPS and ~70,000 4K random write IOPS.*
> How would cascading support something like this?
[joehuang] Just reminder you that the cascading works like a normal OpenStack,
if it can be solved by one OpenStack instance, it should be feasible too in
c
tion. My doubt is what's the "private APIs", which
commponents included " communication between the components ".
Best Regards
Chaoyi Huang ( joehuang )
-Original Message-
From: Dan Smith [mailto:d...@danplanet.com]
Sent: Friday, December 12, 2014 11:41 AM
To: O
s would address these challenges, these
questions are only part of them. It would be the best if cells can address all
challenges, then of course no need an adtional solution.
Best regards
Chaoyi Huang ( joehuang )
From: Andrew Laski [andrew.la...@rackspace.com]
S
short or medium term ( for example, Kilo and L release )? Or we need
more discussion to include it in the roadmap, then I would like to know how to
do that.
Best Regards
Chaoyi Huang ( joehuang )
From: Russell Bryant [rbry...@redhat.com]
Sent: 12 December 2
.
Using global KeyStone makes the project ID/user/role/domain/group have
consistentent view in the cloud. The token used in the request to cascading
Nova/Cinder/Neutron will be transfered in the request to the cascaded
Nova/Cinder/Neutron too.
Best regards
Chaoyi Huang ( joehuang
k-dev] Cross-Project meeting, Tue December 16th, 21:00 UTC
Dear PTLs, cross-project liaisons and anyone else interested,
We'll have a cross-project meeting Tuesday at 21:00 UTC, with the following
agenda:
* Next steps for cascading (joehuang)
* Providing an alternative to shipping default config
Hi, Swami,
I would like to know whether the FIP under DVR could be configured to
distributed mode or central mode in Kilo, not find relevant information from
http://specs.openstack.org/openstack/neutron-specs/.
For example, it will be helpful for following FIP use cases: 1) FIP will be
address
To: joehuang; OpenStack Development Mailing List (not for usage questions); 龚永生
Subject: RE: [openstack-dev] About DVR limit
Hi Joehuang,
FIP today as of Juno can be both in centralized node (dvr_snat) and distributed
“dvr” compute nodes.
Thanks
Swami
From: joehuang [mailto:joehu...@huawei.com
I also recommend approach #2.
For, approach #1,
1) You have to maintain a state machine if you want to synchronize the image to
3 or more backend.
2) Not always 3 or more backend will be synchronized successfully, unless you
make it like a transaction, it's hard to process the synchronization
Roseville)
Cc: joehuang; OpenStack Development Mailing List (not for usage questions)
Subject: Re:RE: [openstack-dev] About DVR limit
Hi, Swami, Joehuang,
in dvr compute nodes, it is 1:1 NAT FIP, means the floatingip for VM, and it
is in the namespace of qrouter-.
but in dvr_snat node, it is 1
routing will be implemented before that, 2 ) Full
distributed SNAT or only provide multi-SNAT network nodes
Best Regards
Chaoyi Huang ( Joe Huang )
From: Vasudevan, Swaminathan (PNB Roseville)
[mailto:swaminathan.vasude...@hp.com]
Sent: Friday, January 16, 2015 12:56 AM
To: joehuang; 龚永生
Cc
(Replace the word "synchronization" to "replication" to reduce misunderstanding)
I also recommend approach #2.
For, approach #1,
1) You have to maintain a state machine if you want to replicate the image to 3
or more backend.
2) Not always 3 or more backend will be replicated successfully, unl
Hi All,
Totally agree with Allamaraju. Only hierarchical administrative boundary is not
enough, the definition of internal network architecture within one domain is
very important. The networking among projects in one domain could be isolated
or not, the access to external network may be not o
+1.
Or at least provide a way to specify an external UUID for the instance, and can
retrieve the instance through the external UUID which may be linked to external
system's object.
Chaoyi Huang ( joehuang )
发件人: Pasquale Porreca [pasquale
or this? We should be thorough when making API changes like
this.
On Wed, Sep 24, 2014 at 6:56 AM, joehuang
mailto:joehu...@huawei.com>> wrote:
+1.
Or at least provide a way to specify an external UUID for the instance, and can
retrieve the instance through the external UUID which may be l
Hello, Dear TC and all,
Large cloud operators prefer to deploy multiple OpenStack instances(as
different zones), rather than a single monolithic OpenStack instance because of
these reasons:
1) Multiple data centers distributed geographically;
2) Multi-vendor business policy;
3) Server nodes s
OpenStack API exposed.
Cells: a single OpenStack instance scale up methodology
Therefore, no conflict between Cells and OpenStack cascading. They can be used
for different scenario, and Cells can also be used as the cascaded OpenStack
(the child OpenStack).
Best Regards
Chaoyi Huang ( joehuang
en for the integration of software /
hardware .
Best Regards
Chaoyi Huang ( joehuang)
From: John Griffith [john.griff...@solidfire.com]
Sent: 01 October 2014 0:10
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all]
session.
Best Regards
Chaoyi Hunag ( joehuang )
From: Joe Gordon [joe.gord...@gmail.com]
Sent: 01 October 2014 2:06
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
e less scalable distributed system we have", no
conflict, no matter OpenStack cascading introduced or not, we need a solid,
stable and scalable OpenStack.
6. "How I imagine this working out (in my view)", all these things are good, I
also like it.
Best Re
nStack cascading solution from
architecure point of view.
Best Regards
Chaoyi Huang ( joehuang )
From: Andrew Laski [andrew.la...@rackspace.com]
Sent: 01 October 2014 3:49
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [tc] Multi-c
( joehuang )
From: Adam Young [ayo...@redhat.com]
Sent: 01 October 2014 4:25
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
cascading
On 09/30/2014 12:10 PM, John Griffith wrote:
On Tue, Sep
ll scale up methodology.
Best Regards
Chaoyi Huang ( joehuang )
From: Tom Fifield [t...@openstack.org]
Sent: 01 October 2014 15:19
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
cascadi
OpenStack itself
support
multiple API version compatibility co-exist. For sure DB/messagebus/backend
drivers/controller
node configuration can be different for different cascaded OpenStack.
Best regards
Chaoyi Huang ( joehuang )
From: loy wol
Huang ( joehuang )
From: Alex Glikson [glik...@il.ibm.com]
Sent: 01 October 2014 12:51
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
cascading
This sounds related to
shop before the formal Paris design summit, so that we
can exchange ideas completely. 40 minutes design summit session is not enough
for deep diving. PoC team will stay at Paris from Oct.29 to Nov.8.
Best Regards
Chaoyi Huang ( joehuang )
From: Tiwari, Arv
op for deep diving in the OpenStack cascading?
Best Regards
Chaoyi Huang ( joehuang )
From: Duncan Thomas [duncan.tho...@gmail.com]
Sent: 02 October 2014 18:59
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev
ad for the venue and date-time.
Best Regards
Chaoyi Huang ( joehuang )
From: Duncan Thomas [duncan.tho...@gmail.com]
Sent: 02 October 2014 22:33
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-c
ibuted way.
Could you come to Paris a little early, I am afraid we have to prepare live
demo on Nov.2, and Nov.3 is a very busy day. The f2f deep diving would be
better to have before Nov.2.
Please follow this thread for the venue and date-time.
Best Regards.
Chaoyi Huang
solve
the inconsistency issue.
Best Regards
Chaoyi Huang ( joehuang )
From: Joshua Harlow [harlo...@outlook.com]
Sent: 07 October 2014 12:21
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [t
, OS-API is preferred. If we developed
totally new API for Node-pool, it takes long time to grow API-ecosystem or 3rd
party APP for it.
Best Regards
Chaoyi Huang ( joehuang )
-Original Message-
From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: Tuesday, October 07, 20
re that I haven't thought of yet.
On 7 October 2014 14:24, joehuang wrote:
> Hello, Joshua,
>
> Thank you for your concerns on OpenStack cascading. I am afraid that I am not
> proper person to give comment on cells, but I would like to speak a little
> about cascading for y
Hello, Duncan,
You are right. It's not simple multiplier game.
The performance or scalability bottleneck is mainly impacted from two aspect:
request concurrency to the cloud, and the volume of the objects (including
VM,Volume,Port,etc).
We can discuss that in a scenario: there are 1 million V
Hi,
Many thanks to Steve to link these topics together.
+1
Consider that there are lots of production installation of cells solution, the
improvement on cells are definitely necessary.
And also hope to add the following demand for the large cloud operator (
especially cloud for NFV ) in the
se.
3) the unified cloud need to expose open and standard api. If shared Nova /
Cinder with federated Neutron, this point can be arhieved.
Best Regards
Chaoyi Huang ( joehuang )
-Original Message-
From: henry hly [mailto:henry4...@gmail.com]
Sent: Thursday, October 23, 2014 3:13 PM
To
linkedin.com/today/author/23841540
Best Regards
Chaoyi Huang
From: Day, Phil [philip@hp.com]
Sent: 23 October 2014 19:24
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
native in the nova cells session.
[1] http://kilodesignsummit.sched.org/type/cross-project+workshops
[2] https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
Best Regards
Chaoyi Huang ( joehuang )
From: Russell Bryant [rbry...@redhat.co
Thanks for your confirmation.
Best Regards
Chaoyi Huang ( joehuang )
From: Thierry Carrez [thie...@openstack.org]
Sent: 29 October 2014 16:55
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [All] Finalizing cross-project design summit
st Regards
Chaoyi Hunag ( joehuang )
From: Wuhongning [wuhongn...@huawei.com]
Sent: 30 October 2014 10:25
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
cascading
( joehuang )
From: A, Keshava [keshav...@hp.com]
Sent: 30 October 2014 17:45
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
cascading
Hi,
Can the VM migration
Hi,
Why not use already defined multi-segements (or multi-provider-network) API
interface, and hide the L2GW explicit manipulation?
Best Regards
Chaoyi Huang ( joehuang )
From: Sukhdev Kapur [sukhdevka...@gmail.com]
Sent: 06 November 2014 19:27
To
Interesting idea to optimize the performance.
Not only security group rule will leads to fanout message load, we need to
review and check to see if all fanout usegae in Neutron could be optimized.
For example, L2 population:
self.fanout_cast(context,
self.make_msg(method, fdb_entr
From real solution scenario, we usually have to integrate hardware to provide
tenant north-south traffic. So the DVR should work not only for distributed
FWaaS, but also for central FWaaS/SNAT/FIP for north-south traffic.
Best Regards
Chaoyi Huang ( Joe Huang )
发件人: Richard Woo [mailto:richard
Hello,
It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into
two parts: one part is for east-west FWaaS, this part could be done on DVR
side, and make it become distributed manner. The other part is for north-south
part, this part could be done on Network Node side, that
Hello,
My personal view is that not to put all configuration options being accessed by
RESTFUL API, but for these configurations which will leads to restart the
controller nodes should be able to be configured dynamically through RESTFUL
api.
There are lots of configuration change only become
Hello, Phillip.
Currently, Neutron did not pass the token to the context. But Nova/Cinder did
that. It's easy to do that, just 'copy' from Nova/Cinder.
1. How Nova/Cinder did that
class NovaKeystoneContext(wsgi.Middleware)
///or CinderKeystoneContext for cinder
auth_token = req.
t least be passed to context and
because its not could be deemed a bug?
Thank you
On 7/18/14 2:03 AM, "joehuang"
mailto:joehu...@huawei.com>> wrote:
>Hello, Phillip.
>
>Currently, Neutron did not pass the token to the context. But Nova/Cinder
>did that. It's ea
Hi,
Good job!
I would like to know how to submit cross project spec? Is there a repository
for cross project cross project spec.
Best Regards
Chaoyi Huang ( Joe Huang )
-邮件原件-
发件人: Andreas Jaeger [mailto:a...@suse.com]
发送时间: 2014年8月3日 1:17
收件人: openstack-dev@lists.openstack.org
主题: [
Regards
Chaoyi Huang ( Joe Huang )
From: Zhipeng Huang [mailto:zhipengh...@gmail.com]
Sent: Wednesday, November 25, 2015 5:44 PM
To: OpenStack Development Mailing List (not for usage questions); joehuang;
caizhiyuan (A); Irena Berezovsky; Orran Krieger; Mohammad Badruzzaman; 홍석찬
Subject: Re
Best Regards
Chaoyi Huang ( Joe Huang )
From: joehuang
Sent: Wednesday, December 02, 2015 2:37 PM
To: 'Zhipeng Huang'; OpenStack Development Mailing List (not for usage
questions); caizhiyuan (A); Irena Berezovsky; Orran Krieger; Mohammad
Badruzzaman; 홍석찬
Subject: [openstack-dev][tricircl
Hi,
Let’s have regular meeting today starting UTC1300 at #openstack-meeting
Agenda:
Progress of To-do list: https://etherpad.openstack.org/p/TricircleToDo
Discussion of stateless design.
Best Regards
Chaoyi Huang ( Joe Huang )
From: joehuang [mailto:joehu...@huawei.com]
Sent: Tuesday, December
Hi, Shinobu,
You found a bug, yeah. The design has been moved to the master branch, so the
description:
'Note: Stateless proposal is working on the “experiment” branch:'
'https://github.com/openstack/tricircle/tree/experiment'
Just been removed from the design blueprint as you mentione
rve as the PTL of Tricircle in Newton release, thanks for
your support, let's move Tricircle forward together.
Best Regards
Chaoyi Huang ( Joe Huang )
-Original Message-
From: joehuang
Sent: Monday, May 09, 2016 10:08 AM
To: 'OpenStack Development Mailing List (not for us
discussed in the weekly meeting, please reply
the mail.
Best Regards
Chaoyi Huang ( Joe Huang )
From: joehuang
Sent: Wednesday, May 11, 2016 3:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev][tricircle]weekly meeting of May. 11
Hi,
IRC meeting: htt
8, 2016 at 5:31 PM, joehuang wrote:
> Hello, Team,
>
> From last Monday to today, only single candidate (myself, if I missed
> someone's nomination, please point out) for the PTL election of Tricircle for
> Newton release, according to the guideline from the community, no el
Hello, L2GW team,
Congratulation on L2GW Mitaka Release! Would you team please help to move
“Border Gateway support” [1] forward? There is one key feature (cross-OpenStack
L2 Networking automation) in Tricircle has dependency on L2GW’s Border Gateway
in Newton release.
And one session[3] in A
-
From: Sean M. Collins [mailto:s...@coreitpro.com]
Sent: Thursday, May 19, 2016 11:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L2GW][Tricircle]Border Gateway support
joehuang wrote:
> And one session[3] in Austin summit called
Hello, Shinobu,
We have gate test for pep8 in the CI pipeline, for import orders, if it's
incorrect, pep8 gate check will give -1 in the result.
I checked the core.py in the repository, the import order is ok, first import
system level, then OSLO, then projects level with blank line between dif
Hi, Shinobu,
Agree with you that we need to complete
the spec ASAP but without compromising
on quality.
Sent from HUAWEI AnyOffice
发件人：shinobu.kj
收件人：openstack-dev,
时间：2016-05-20 14:40:54
主题:[openstack-dev] [tricircle] Cross OpenStac L2 Networking Specification
Hi Team,
Probably we would not
Hi,
IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every
Wednesday starting from UTC 13:00.
Let's continue the working items:
# implementation discussion of 'cross pod L2 networking' and 'dynamic pod
binding'
# bugs review
If you have other topics to be discussed in
Hello,
This spec[1] was to expose quiesce/unquiesce API, which had been approved in
Mitaka, but code not merged in time.
The major consideration for this spec is to enable application level
consistency snapshot, so that the backup of the snapshot in the remote site
could be recovered correct
Hi,
IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every
Wednesday starting from UTC 13:00.
Let's continue the working items:
# tempest plugin and test cases
# implementation discussion of 'cross pod L2 networking' and 'dynamic pod
binding'
# bugs review
If you have
Hello,
There is one quite strange issue in Tricircle stable/mitaka branch
(https://github.com/openstack/tricircle/tree/stable/mitaka) . Even the patch (
https://review.openstack.org/#/c/324209/ ) were given Code-Review +2 and
Workflow +1, the gating job not started, and the patch was not merged
Hello,
There are several articles will be helpful both to reviewers and code
contributors: [1],[2],[3]
[1]: http://docs.openstack.org/infra/manual/developers.html#code-review
[2]: http://docs.openstack.org/infra/manual/developers.html#peer-review
[3]: https://krotscheck.net/2015/07/13/code-re
Hello,
As the job "publish to PyPI" has been added to the infra pipeline, I suggest to
cherry pick the following patches(which has been merged to the master branch)
to stable/mitaka branch, then we can make an initial release in stable/mitaka
branch, and also to test the release publish procedu
Hi,
IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every
Wednesday starting from UTC 13:00.
Today's agenda:
# spec review and status of 'cross pod L2 networking' and 'dynamic pod binding'
# policy enforcement for API access
# tempest test integration
If you have othe
Hello,
This spec is not approved yet: https://review.openstack.org/#/c/295595/
But the BP is approved:
https://blueprints.launchpad.net/nova/+spec/expose-quiesce-unquiesce-api
Don't know how to deal with the spec now. Is this spec killed? Should Nova
support application level consistency snaps
you have an approved spec
but unapproved blueprint
On 6/12/2016 7:48 PM, joehuang wrote:
> Hello,
>
> This spec is not approved yet:
> https://review.openstack.org/#/c/295595/
>
> But the BP is approved:
> https://blueprints.launchpad.net/nova/+spec/expose-quiesce-unquiesce-
Hello,
A tempest plugin was written for the Kingbird
https://review.openstack.org/#/c/328683/, the plugin and test cases could be
discovered by tempest, and the configuration is working if we add the
configuration items into the tempest.conf manfully, but if we run tox
-egenconfig in the temp
Hi,
IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every
Wednesday starting from UTC 13:00.
Today's agenda:
# spec review and status of 'cross pod L2 networking' and 'dynamic pod binding'
# integration test in the CI pipeline
# policy enforcement for API access
If you
eader from the message) There is more
details on this here:
https://wiki.openstack.org/wiki/MailingListEtiquette#Threading
I almost missed this because it was part of a different thread.
On Wed, Jun 15, 2016 at 05:14:26AM +0000, joehuang wrote:
> Hello,
>
> A tempest plugin was w
Hello,
The publish-to-pypi job is configured for Tricircle[1], and already gave
"openstackci" the role to "Owner"[3][2].
After push a new tag v2.0.1 in stable/mitaka branch of :
https://github.com/openstack/tricircle, the tagging is successfully applied to
the repository, but the publish-to-py
ony Breeds [mailto:t...@bakeyournoodle.com]
Sent: Friday, June 17, 2016 10:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Infra] publish-to-pypi not working in Tricircle
stable/mitaka branch
On Fri, Jun 17, 2016 at 01:15:13AM +, joehuang wrot
still suggest you to play
2.0.1 through DevStack installation according to the README.md. For
configuration guide through pip installlation is not provided yet.
Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development
Hello,
I am on the trip to attend the OPNFV Berlin summit, would like to know if
someone can chair the weekly meeting of Tricircle. If no volunteer before Jun.
22, we may have to skip this weekly meeting.
Best Regards
Chaoyi Huang ( joehuang
Hello,
In last week OPNFV summit in Berlin, a presentation was given about "Overlay L2
networking across OpenStack", the slides is for your reference:
https://docs.google.com/presentation/d/1Cv23dLAmSB57IpD-nt-TH5lrCehcoeiml7HpvgUWauo/edit#slide=id.g1478638225_0_0
Best Regards
Chaoyi Huang ( J
when loading the plugin, you may find error information
the show command.
Best Regards
Chaoyi Huang ( joehuang )
From: Yipei Niu [newy...@gmail.com]
Sent: 27 June 2016 21:44
To: OpenStack Development Mailing List (not for usage questions)
Cc: joehuang; Zhiyuan
for plugin discovery,
and no config option you have registered in oslo_config.cfg, so " no such
option in group DEFAULT:".
Best Regards
Chaoyi Huang ( joehuang )
From: Yipei Niu [newy...@gmail.com]
Sent: 28 June 2016 22:05
To: OpenStack Development Mailing
‘cross pod L2 networking’ and ‘dynamic pod binding’
# todo list review
# integration test for new features
If you have other topics to be discussed in the weekly meeting, please reply
the mail.
Best Regards
Chaoyi Huang (joehuang
Hello, team,
The wiki page of Tricircle was updated in
the architecture and value section, other
sections also with minor update
Please review and comment, and update
accordingly for obvious error.
If you have any question and topic to discuss, also let's discussion in the
m-l. Thanks
Sent
aoyi Huang (joehuang)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Chaoyi Huang (joehuang)
From: Jainesh Patel [jainesh...@gmail.com]
Sent: 08 July 2016 2:08
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Opportunity to contribute in OpenStack
Hello,
We are a group of students that are currently pursuing our
Hi, Thierry,
One question about this ' The transition to the "big tent" governance model is
now finished, with all the expected projects now officially part of the
OpenStack community. The big tent is all about community: answering the "are
you one of us" question.'.
Does it mean that no mor
ricircle.
>>
>> [1] http://docs.openstack.org/developer/nova/sample_config.html
>>
>> Best regards,
>> Yipei
>>
>> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo
>> wrote:
>>>
>>> FYI:
>>> This is the reason is that there
Hi,
IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every
Wednesday starting from UTC 13:00.
Agenda:
# Cross OpenStack L2 networking
# pod scheduling
# Reliable aync. Job
# Link: https://etherpad.openstack.org/p/TricircleToDo
If you have other topics to be discussed in
1 - 100 of 488 matches
Mail list logo
