Re: [openstack-dev] [tricircle] Nominate change in tricircle core team

[joehuang]

+1. Baisen has contributed lots of patches in Tricircle.

Best Regards
Chaoyi Huang (joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 12 March 2018 9:04
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] Nominate change in tricircle core team

Hi team, I would like to nominate Baisen Song (songbaisen) for tricircle core 
reviewer. Baisen has actively joined the discussion of feature development and 
has contributed important patches since Queens, like resource deletion 
reliability and openstack-sdk new version adaption. I really think his 
experience will help us substantially improve tricircle.

BR
Zhiyuan
--
BR
Zhiyuan
__
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

Re: [openstack-dev] [sdk][masakari][tricircle] Inclusion of SDK classes in openstacksdk tree

[joehuang]

Hello, Monty,

Tricircle did not develop any extra Neutron network resources, Tricircle 
provide plugins under Neutron, and same support resources as Neutron have. To 
ease the management of multiple Neutron servers, one Tricircle Admin API is 
provided to manage the resource routings between local neutron(s) and central 
neutron, it's one standalone service, and only for cloud administrator, 
therefore python-tricircleclient adn CLI were developed to support these 
administration functions.

do you mean to put  Tricircle Admin API sdk under openstacksdk tree?

Best Regards
Chaoyi Huang (joehuang)


From: Monty Taylor [mord...@inaugust.com]
Sent: 21 January 2018 1:22
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [sdk][masakari][tricircle] Inclusion of SDK classes in 
openstacksdk tree

Hey everybody,

Wanted to send a quick note to let people know that all OpenStack
services are more than welcome to put any openstacksdk proxy and
resource classes they have directly into the openstacksdk tree.

Looking through codesearch.openstack.org, masakariclient and tricircle
each have SDK-related classes in their trees.

You don't HAVE to put the code into openstacksdk. In fact, I wrote a
patch for masakariclient to register the classes with
openstack.connection.Connection:

https://review.openstack.org/#/c/534883/

But I wanted to be clear that the code is **welcome** directly in tree,
and that anyone working on an OpenStack service is welcome to put
support code directly in the openstacksdk tree.

Monty

PS. Joe - you've also got some classes in the tricircle test suite
extending the network service. I haven't followed all the things ... are
the tricircle network extensions done as neutron plugins now? (It looks
like they are) If so, why don't we figure out getting your network
resources in-tree as well.

__
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

__
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

Re: [openstack-dev] [tricircle]Distinguish the direction of requests

[joehuang]

Hello,

As you are talking about how to distinguish the request to local Neutron and 
central Neutron, do you mean how to set the "USER_AGENT" in the request header, 
and how to extract the "USER_AGENT" and stored it in the context? Though it's 
mentioned in 
https://developer.openstack.org/sdks/python/openstacksdk/users/connection.html

This field has not been extracted neither in oslo.context, nor neutron-lib 
context:

https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py
https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py

May be we can add it in oslo.context?

Best Regards
Chaoyi Huang (joehuang)

From: XuZhuang [xu_ly...@163.com]
Sent: 01 November 2017 19:49
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle]Distinguish the direction of requests

Hello,


I have some questions in how to distinguish the direction of requests between 
local neutron and central neutron.


There is the preliminary plan


1. For how to distinguish the requests in central neutron

we can add a filter in neutron/…./etc/api-paste.ini. Using this filter we can 
get some values about the source.

But the question is that the process of loading filter is in Neutron. Without 
changing Neutron how could we add a filter? Could we change Neutron?


2. For how to add a signal in the requests

The module of common.client in Tricircle is responsible for sending requests. 
So we can add a signal in the header of requests. And central plugin will get 
this signal using the filter.


Best Regards

Zhuangzhuang Xu (Lyman Xu)




__
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

Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

[joehuang]

Hello, Kendall,

Tricircle would like to have an on-boarding session too, if there is still time 
slot left and not conflict with other my three sessions:
( Mon 6 , 1:55pm-2:15pm, Tricircle - Project Update; Mon 6 , 1:55pm-2:15pm, 
Move mission critical application to multi-site, what we learned; Wed 8 , 
2:05pm-2:15pm Edge Computing (Platform) as a Service powered by OpenStack. )

Thank you well in advance.

Best Regards
Chaoyi Huang (joehuang)

From: Jeffrey Zhang [zhang.lei@gmail.com]
Sent: 13 October 2017 8:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

Hi Kendall,

Kolla project would like to have a on-boarding session too.

thanks.

On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson 
<kennelso...@gmail.com<mailto:kennelso...@gmail.com>> wrote:
Added Nova to my list with Dan, Melanie, and Ed as speakers.

Thanks Matt,
-Kendall (diablo_rojo)

On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann 
<mriede...@gmail.com<mailto:mriede...@gmail.com>> wrote:
On 10/9/2017 4:24 PM, Kendall Nelson wrote:
> Wanted to keep this thread towards the top of inboxes for those I
> haven't heard from yet.
>
> About a 1/4 of the way booked, so there are still slots available!
>
> -Kendall (diablo_rojo)

I've tricked the following people into running a Nova on-boarding room:

- "Super" Dan Smith <dansm...@redhat.com<mailto:dansm...@redhat.com>>
- Melanie "Structured Settlement" Witt 
<melwi...@gmail.com<mailto:melwi...@gmail.com>>
- Ed "Alternate Hosts" Leafe <e...@leafe.com<mailto:e...@leafe.com>>

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me<http://xcodest.me/>
__
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

Re: [openstack-dev] [tc][election] TC non-candidacy

[joehuang]

Thank you very much, Monty. You always provide great help if needed, friendly.

Best Regards
Chaoyi Huang (joehuang)


From: Monty Taylor [mord...@inaugust.com]
Sent: 11 October 2017 7:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tc][election] TC non-candidacy

Hey everybody!

I have decided not to seek reelection for the TC.

I have had the honor and privilege of serving you on the TC and it's
predecessor the PPB since the fall of 2011 (with one six month absence
that I blame on Jay Pipes)

There are a wealth of amazing people running for the TC this cycle, many
of whom have a different genetic, cultural or geographic background than
I do. I look forward to seeing how they shepherd our amazing community.

I am not going anywhere. We're just getting Zuul v3 rolled out, there's
a pile of work to do to merge and rationalize shade and openstacksdk and
I managed to sign myself up to implement application credentials in
Keystone. I still haven't even managed to convince all of you that
Floating IPs are a bad idea...

Thank you, from the bottom of my heart, for the trust you have placed in
me. I look forward to seeing as many of you as I can in Sydney,
Vancouver, Berlin and who knows where else.

Monty

__
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

__
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

Re: [openstack-dev] [all] Queens Goal for Kingbird

[joehuang]

Cool, looking forward to the dashboard plugin.

Best Regards
Chaoyi Huang (joehuang)

From: Goutham Pratapa [pratapagout...@gmail.com]
Sent: 01 September 2017 21:05
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [all] Queens Goal for Kingbird

Hi all,

For this Queens cycle, we would like to implement Kingbird dashboard so that it 
can be used as a plugin in horizon using which

- Admin can manage quota across multiple-regions and

- Users can manage their respective resources (for now flavor, image, keypairs)
 across multiple regions

through front-end.

We are planning to extend resource_management to glance image-metadefs as well.

--
Thanks!!!
Goutham Pratapa
__
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

[openstack-dev] [tricircle]stable/pike brach has been created.

[joehuang]

Hello, all,

Thank you all for the great contribution, stable/pike has been created on 
Aug.18:

https://git.openstack.org/cgit/openstack/tricircle/log/?h=stable/pike


Release notes could be found here:
https://docs.openstack.org/releasenotes/tricircle/pike.html

Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle-North South Networking via Direct Provider Networks]

[joehuang]

Hello, Meher,

By default, only one nic will come up for the
instance from cirros image.

You can log into the instance, follow this mail thread to bring up
the second nic.

http://lists.openstack.org/pipermail/openstack-dev/2014-October/048574.html

Best Regards
Chaoyi Huang(joehuang)
发件人：meher.h...@orange.com
收件人：openstack-dev
时间：2017-08-18 23:30:01
主题:[openstack-dev] [tricircle-North South Networking via Direct Provider 
Networks]

Hello everyone,

Still in the test phase of the scenarios proposed by the Tricircle 
documentation, I try to do "North South Networking via Direct Provider 
Networks" but I failed to start an instance with 2 NICs, apparently the Cirros 
image does not support this option by default.

So I will add a new image and so I need the horizon service which is disabled 
when installing Tricircle. Thanks in advance for giving me an idea on how to 
add the dashboard without re-deploying!

Best regards,

Meher

[Logo Orange]<http://www.orange.com/>

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371>
Mobile : +33 7 58 38 68 
87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887>
meher.h...@orange.com<mailto:meher.h...@orange.com>



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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

Re: [openstack-dev] [releases]pike release notes missing in Tricircle

[joehuang]

Not an issue.

Just found that the patch needs to be approved by reviewer(s), it's not merged 
automatically.

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 18 August 2017 8:47
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev][releases]pike release notes missing in Tricircle

Hello,

The patch to update the reno( https://review.openstack.org/#/c/494565/ ) has 
been merged after Tricircle stable/pike branch is created, and the 
gate-tricircle-releasenotes<http://docs-draft.openstack.org/65/494565/1/check/gate-tricircle-releasenotes/088a2a1//releasenotes/build/html/>
 also worked fine, but the pike release notes is missing in 
https://docs.openstack.org/releasenotes/tricircle/

I found that pike release notes are visible both in Nova/Cinder project 
(https://docs.openstack.org/releasenotes/cinder/  
https://docs.openstack.org/releasenotes/nova/)

Is there something need to do to make pike release notes appearing in the site?

Best Regards
Chaoyi 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

[openstack-dev] [releases]pike release notes missing in Tricircle

[joehuang]

Hello,

The patch to update the reno( https://review.openstack.org/#/c/494565/ ) has 
been merged after Tricircle stable/pike branch is created, and the 
gate-tricircle-releasenotes<http://docs-draft.openstack.org/65/494565/1/check/gate-tricircle-releasenotes/088a2a1//releasenotes/build/html/>
 also worked fine, but the pike release notes is missing in 
https://docs.openstack.org/releasenotes/tricircle/

I found that pike release notes are visible both in Nova/Cinder project 
(https://docs.openstack.org/releasenotes/cinder/  
https://docs.openstack.org/releasenotes/nova/)

Is there something need to do to make pike release notes appearing in the site?

Best Regards
Chaoyi 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

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[joehuang]

Features for tricircle pike has been freezed, and 
no exception was asked until now, as you
proposed, If neutron can have branch this
week, we can cut branch earlier.

Thank you, TTX.


From: Thierry Carrez [thie...@openstack.org]
Sent: 10 August 2017 20:39
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality 
Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

joehuang wrote:
> Tricircle plans to cut stable/pike branch on August 22nd, it has dependency 
> on Neutron stable/pike creation.

That sounds a bit late to create your release branch. It doesn't give
you a lot of time to react to critical issues discovered in that
release, as August 24 is the final date to submit new releases for
inclusion before Pike is formally declared released.

My advice would be to do a X.Y.0 release as soon as you can freeze
features (neutron should have their branch this week), and have some
time to produce a X.Y.1 bugfix release if you detect critical issues in
testing.

--
Thierry Carrez (ttx)

__
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

__
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

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[joehuang]

Hello,

Tricircle plans to cut stable/pike branch on August 22nd, it has dependency on 
Neutron stable/pike creation.

Best Regards
Chaoyi Huang (joehuang)


From: Tony Breeds [t...@bakeyournoodle.com]
Sent: 10 August 2017 13:46
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality 
Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

Hi All,
In an effort to qualify which projects are likley to be affected if
when we open the requirements repo I generated a list of all repos that:

1. Subscribe to requirements management
2. Do not already have a stable/pike branch
3. Do not follow the cycle-with-milestones, cycle-trailing or
   independent release models
4. Are not a 'branchless' project (tempest or tempest-plugin)

These repos I believe *should* have a stable/pike branch or will see
problems when we open openstack/requirements.  Those issues were
described in [1]

It turns out close to 1/3rd of projects that subscribe to requirements
management are not ready for us to re-open for master.  So we need you
help to get that number down to a much more acceptable number.

The good news is it's pretty easy to fix this with the cool tools and
workflow in the releases repo[2].  I suspect that the 'service' will
take care of themselves, and the horizon-plugins are waiting to horizon
to cut RC1.

Repos with type: horizon-plugin
ironic-ui  ironic
manila-ui  manila
monasca-ui monasca
neutron-fwaas-dashboardneutron
solum-dashboardsolum
tacker-horizon tacker
watcher-dashboard  watcher
zun-ui zun

Repos with type: other
python-openstackclient OpenStackClient
patroleQuality Assurance
heat-agentsheat
ironic-inspector   ironic
ironic-python-agentironic
kuryr-kubernetes   kuryr
monasca-common monasca
monasca-notification   monasca
monasca-persister  monasca
monasca-transform  monasca

Repos with type: service
ironic ironic
monasca-apimonasca
monasca-log-apimonasca
swift  swift
tricircle  tricircle
vitragevitrage
watcherwatcher
zunzun

Those are the easy items.

The following repos don't seem to use the openstack/releases repo so I
have less information there.

i18n   I18n
almanach
blazar
blazar-nova
compute-hyperv
ekko
gce-api
glare
ironic-staging-drivers
kosmos
masakari
masakari-monitors
mixmatch
mogan
nemesis
networking-dpm
networking-fujitsu
networking-generic-switch
networking-l2gw
networking-powervm
neutron-vpnaas
neutron-vpnaas-dashboard
nova-dpm
nova-lxd
nova-powervm
os-xenapi
python-blazarclient
python-cratonclient
python-glareclient
python-kingbirdclient
python-masakariclient
python-moganclient
python-oneviewclient
python-openstacksdk
python-valenceclient
swauth
tap-as-a-service
trio2o
valence
vmware-nsx
vmware-nsxlib
openstackclientOpenStackClient
anchor Security
ceilometer-powervm Telemetry
ec2-apiec2-api
horizon-cisco-ui   horizon
bifrostironic
ironic-python-agent-builderironic
magnum magnum
magnum-ui  magnum
manila-image-elements  manila
murano-agent   murano
octavia-dashboard  octavia
senlin-dashboard   senlin
tacker tacker
networking-hyperv  winstackers

It'd be great to get some of these repos represented in
openstack/releases.  Having a confirmed release-model would go a long
way to clearing up the list. An alternate approach would

Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes

[joehuang]

Except webhook, how about custom module(call keystone API directly from custom 
module) for authorization? ( 
https://kubernetes.io/docs/admin/authorization/#custom-modules )

Webhook:
Pros.: http calling, loose coupling, more flexible configuration.
Cons.: Degraded performance, one more hop
custom module:
Pros.: direct function call, better performance, less process to 
maintain.
Cons.: coupling, built-in module.

Best Regards
Chaoyi Huang (joehuang)


From: Morgan Fainberg [morgan.fainb...@gmail.com]
Sent: 09 August 2017 12:26
To: OpenStack Development Mailing List (not for usage questions)
Cc: kubernetes-sig-openst...@googlegroups.com
Subject: Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
based Authentication and Authorization for Kubernetes

I shall take a look at the webhooks and see if I can help on this front.

--Morgan

On Tue, Aug 8, 2017 at 6:34 PM, joehuang <joehu...@huawei.com> wrote:
> Dims,
>
> Integration of keystone and kubernetes is very cool and in high demand. Thank 
> you very much.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: Davanum Srinivas [dava...@gmail.com]
> Sent: 01 August 2017 18:03
> To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing 
> List (not for usage questions)
> Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
> based Authentication and Authorization for Kubernetes
>
> Team,
>
> Having waded through the last 4 attempts as seen in kubernetes PR(s)
> and Issues and talked to a few people on SIG-OpenStack slack channel,
> the consensus was that we should use the Webhook mechanism to
> integrate Keystone and Kubernetes.
>
> Here's the experiment : https://github.com/dims/k8s-keystone-auth
>
> Anyone interested in working on / helping with this? Do we want to
> create a repo somewhere official?
>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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
>
> __
> 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

__
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

__
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

Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes

[joehuang]

Dims,

Integration of keystone and kubernetes is very cool and in high demand. Thank 
you very much.

Best Regards
Chaoyi Huang (joehuang)


From: Davanum Srinivas [dava...@gmail.com]
Sent: 01 August 2017 18:03
To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing 
List (not for usage questions)
Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based 
Authentication and Authorization for Kubernetes

Team,

Having waded through the last 4 attempts as seen in kubernetes PR(s)
and Issues and talked to a few people on SIG-OpenStack slack channel,
the consensus was that we should use the Webhook mechanism to
integrate Keystone and Kubernetes.

Here's the experiment : https://github.com/dims/k8s-keystone-auth

Anyone interested in working on / helping with this? Do we want to
create a repo somewhere official?

Thanks,
Dims

--
Davanum Srinivas :: https://twitter.com/dims

__
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

__
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

[openstack-dev] [tricircle]pike-3 released

[joehuang]

Hello,

Tricircle 3.4.0 (pike-3) released[1], it's time to do regression test and fix 
bugs, next milestone is pike-rc.

[1]https://review.openstack.org/#/c/488904/

Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle]

[joehuang]

Hello, Meher,

For the second node, the devstack configuration file local.conf should be 
configured carefully, especially for the keystone part(sample file 
https://github.com/openstack/tricircle/blob/master/devstack/local.conf.node_2.sample):

HOST_IP=10.250.201.25
REGION_NAME=RegionTwo
KEYSTONE_REGION_NAME=RegionOne
SERVICE_HOST=$HOST_IP
KEYSTONE_SERVICE_HOST=10.250.201.24
KEYSTONE_AUTH_HOST=10.250.201.24

HOST_IP is the second node's IP, KEYSTONE_SERVICE_HOST/KEYSTONE_AUTH_HOST 
should be configured with the first node's IP.

Best Regards
Chaoyi Huang (joehuang)

From: meher.h...@orange.com [meher.h...@orange.com]
Sent: 31 July 2017 21:31
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle]

Hello everybody,

I just installed Tricirle on a single node. Now I'm trying to install it on two 
nodes (two VMs), everything was fine with the first node, Tricirle is well 
installed, on the second node, at the end of the script install it stops on An 
error "Failed to discover available versions when contacting 
http://192.168.123.129/identity. Attempting to parse version from URL.”

So it seems that there is a connection problem with the keystone service on the 
first machine, as far as the connectivity between the 2 nodes is concerned, it 
is perfect.

I am sending you this mail to find out if anyone can help me on this. I thank 
you in advance!

Regards,

Meher

[Logo Orange]<http://www.orange.com/>

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371>
Mobile : +33 7 58 38 68 
87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887>
meher.h...@orange.com<mailto:meher.h...@orange.com>



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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

Re: [openstack-dev] [release]need help for python-tricircleclient

[joehuang]

Hello,

Very sorry for the deadline missing even if it's few hours, and won't let it 
happen next time.

I was waiting for one patch about pagination support in tricircle ( not 
python-tricircleclient). If pagination
for resource routing and job have not been supported well in tricircle, it's 
not good to publish these features
in python-tricircleclient:

python-tricircleclient will list resource routing and job from Tricircle Admin 
API, if there are huge amount of
resource routing and job records, without pagination support, a query will 
easily lead to the db server keep in busy status: the
list operation will make db server eat too much resources, even make the db 
server stopping response for other request.

Because the patch is almost done, so extra few hours were paid to this patch, 
so that python-tricircleclient can include these
useful features in pike, otherwise only pod management feature can be included 
in python-tricircleclient.

Best Regards
Chaoyi Huang (joehuang)


From: Thierry Carrez [thie...@openstack.org]
Sent: 31 July 2017 21:04
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [release]need help for python-tricircleclient

joehuang wrote:
> The patch [1] is to add a tag for python-tricircleclient after new
> features were added to it since last release. But unfortunately, a
> branch called "stable/pike" was there in Apr., and lead to the patch can
> not pass the gate test.

This release request missed the deadline for client libraries releases
(if only by a few hours), so we already created the stable/pike branch
from the last available Pike release (0.1.1 from April 2017).

Given (1) that the deadline was not missed by much, (2) that the last
available release was quite old, and (3) that no other project depends
on python-tricircleclient, damage would be limited in cutting 0.2.0 now
and recreating stable/pike from it. We'll coordinate with infra to make
it happen.

Next time, please don't miss the deadline and create additional work for
the release team !

--
Thierry Carrez (ttx)

__
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

__
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

[openstack-dev] [release]need help for python-tricircleclient

[joehuang]

Hello,

The patch [1] is to add a tag for python-tricircleclient after new features 
were added to it since last release. But unfortunately, a branch called 
"stable/pike" was there in Apr., and lead to the patch can not pass the gate 
test.

"deliverables/pike/python-tricircleclient.yaml: 
openstack/python-tricircleclient 563f700b62de6b57671ec077293da6fa348c250a not 
present in pike branch"

Shall I cherry pick all latest introduced patches from master to the 
stable/pike branch, or the old branch which was created in Apr. should be 
renamed?

[1] https://review.openstack.org/#/c/488903/

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]PTL non-candidacy

[joehuang]

Hello, all,

Next cycle PTL nomination is approaching, as I announced in the last weekly 
meeting, I am not planning to run for Queen PTL position. It's exciting and 
joyful journey to work in the Tricircle project, not only for the interesting 
features, but also for the excellent team:

1) Basic tenant L2/L3 networking among OpenStack regions can work now, and it's 
quite useful to help applications achieve cloud level high availability: 
https://www.youtube.com/watch?v=tbcc7-eZnkY
2) Tricircle+Neutron can also work with Nova cells V2 to scale single 
OpenStack, it's something more than what we have planned.

I would like to thank everyone who has contributed/is contributing in 
Tricricle, and I'm sure community can continue making it even better.

Nomination period will start soon, whoever the next PTL might be, I'll continue 
serving as core reviewer to help the project.

Thank you very much and best wishes.

Best Regards
Chaoyi 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

Re: [openstack-dev] TR: [tricircle]

[joehuang]

Hi Meher,

Yes, as Victor pointed out, it should be done by the devstack script. But in 
our daily development, I use (maybe most of us) Ubuntu to install Tricircle 
through devstack, so not sure whether there is some bug under RHEL, and I have 
no RHEL distribution.

Best Regards
Chaoyi Huang (joehuang)

From: Morales, Victor [victor.mora...@intel.com]
Sent: 12 July 2017 0:13
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] TR: [tricircle]

Hi Meher,

I don’t think that you need to create those folders or at least that it’s shown 
in the devstack functions[1].

Regards/Saludos
Victor Morales

[1] https://github.com/openstack-dev/devstack/blob/master/lib/apache#L178-L192

From: "meher.h...@orange.com" <meher.h...@orange.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, July 11, 2017 at 7:51 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] TR: [tricircle]



[ogo Orange]<http://www.orange.com/>

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371>
Mobile : +33 7 58 38 68 
87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887>
meher.h...@orange.com<mailto:meher.h...@orange.com>


De : HIHI Meher IMT/OLN
Envoyé : mardi 11 juillet 2017 14:50
À : HIHI Meher IMT/OLN
Objet : RE: [openstack-dev][tricircle]

Hi Zhiyuan,

Thank you for the response! So, in this case, I just need to create two 
"sites-available" and "sites-enabled" folders under /etc/ httpd and put in the 
config files found in /etc/httpd/conf.d/?

Regards,

Meher

[ogo Orange]<http://www.orange.com/>

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371>
Mobile : +33 7 58 38 68 
87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887>
meher.h...@orange.com<mailto:meher.h...@orange.com>


De : HIHI Meher IMT/OLN
Envoyé : lundi 10 juillet 2017 16:10
À : 'openstack-dev@lists.openstack.org'
Objet : RE: [openstack-dev][tricircle]

Hello everybody,

I posted before a problem related to installing the tricircle on a single node, 
the script stopped with a keystone startup. You advised me to see the / etc / 
apache2 / sites-enabled folder to see if the keystone config files are 
included. But, I have not found this folder, yet the httpd service is properly 
installed, the name of this file changes according to the distribution? I use 
RHEL 7, thank you in advance!

Meher

[ogo Orange]<http://www.orange.com/>

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371>
Mobile : +33 7 58 38 68 
87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887>
meher.h...@orange.com<mailto:meher.h...@orange.com>


De : HIHI Meher IMT/OLN
Envoyé : mercredi 28 juin 2017 15:12
À : 'openstack-dev@lists.openstack.org'
Objet : [openstack-dev][tricircle]

Hello everyone,

I introduce myself; Meher Hihi; I am doing my internship at Orange Labs 
Networks Lannion-France for the diploma of computer network and 
telecommunications engineer.

I am working on innovative distribution solutions for the virtualization 
infrastructure of the network functions and more specifically on the Openstack 
Tricircle solution, which is why I join your community to participate in your 
discussions and learn from your advice.

Indeed, I try to install Tricircle on a single node by following this 
documentation 
“https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack”.
I managed to install Devstack without any problems, but when I modify the 
local.conf file by adding the Tricircle plugin integration and the HOST_IP, the 
script does not want to work and stops on an error of Start of the Keystone 
service.

I wanted to know if the problem is with my config file that is attached or I 
lack othe

Re: [openstack-dev] [tricircle]

[joehuang]

Hello, Meher

Except checking the sites-enabled in Apache, because single-node installation 
is mainly for very limited feature development, multi-node installation is 
recommended: 
https://docs.openstack.org/developer/tricircle/installation-guide.html#multi-pod-installation-with-devstack

If you only have one node, you don't need to install the second node even if 
you follow the multi-node guide.

You can also talk to us directly through IRC channel #openstack-tricircle in 
freenode.

Best Regards
Chaoyi Huang (joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 29 June 2017 10:28
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle]

Hi Meher,

Welcome to join Tricircle!

Both Keystone and Tricircle services are running under Apache, so if Keystone 
failed to start after enabling Tricircle, I guess there might be some problems 
of Apache configuration. You can check what services are enabled in Apache by 
listing this folder: /etc/apache2/sites-enabled.

tricircle@zhiyuan-1:~/devstack$ ls /etc/apache2/sites-enabled/
keystone-wsgi-admin.conf  keystone-wsgi-public.conf  nova-placement-api.conf  
tricircle-api.conf

Above is the result from my Ubuntu machine.

Also, could you provide me the log of DevStack after enabling Tricircle so I 
can get more hints.

BR
Zhiyuan

On Wed, 28 Jun 2017 at 21:17 
<meher.h...@orange.com<mailto:meher.h...@orange.com>> wrote:
Hello everyone,

I introduce myself; Meher Hihi; I am doing my internship at Orange Labs 
Networks Lannion-France for the diploma of computer network and 
telecommunications engineer.

I am working on innovative distribution solutions for the virtualization 
infrastructure of the network functions and more specifically on the Openstack 
Tricircle solution, which is why I join your community to participate in your 
discussions and learn from your advice.

Indeed, I try to install Tricircle on a single node by following this 
documentation 
“https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack”.
I managed to install Devstack without any problems, but when I modify the 
local.conf file by adding the Tricircle plugin integration and the HOST_IP, the 
script does not want to work and stops on an error of Start of the Keystone 
service.

I wanted to know if the problem is with my config file that is attached or I 
lack other things to configure. You will also find in the file the IP address 
of the machine.

I thank you in advance for the help you will bring me. Sincerely,

Best regards,

Meher

<http://www.orange.com/>

Meher Hihi
Intern
ORANGE/IMT/OLN/WNI/ODIS/NAVI
Fixe : +33 2 96 07 03 
71<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33296070371>
Mobile : +33 7 58 38 68 
87<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33758386887>
meher.h...@orange.com<mailto:meher.h...@orange.com>



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
BR
Zhiyuan
__
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

Re: [openstack-dev] [tricircle] Tricircle vs Trio2o

[joehuang]

Hello, Silvia,

Thank you for your interest in Tricircle and Trio2o.

See inline comments.

Best Regards
Chaoyi Huang (joehuang)

From: Silvia Fichera [fichera@gmail.com]
Sent: 28 June 2017 5:16
To: OpenStack Development Mailing List (not for usage questions); 
openst...@lists.openstack.org
Subject: [openstack-dev] [tricircle] Tricircle vs Trio2o


Hi all,
I would like to build up a multi-region openstack and I read that both 
tricircle and trio2o are the most suitable solutions.
I have few questions:

- from the wikis I couldn't deeply understand the differences between the two: 
ad far as I understood tricircle deploys a shared neutron module, trio2o 
provides a gateway in the case of a single nova/glance module.Is it right?

[joehuang] Yes, Tricircle is to provide networking capability across multiple 
neutron servers in OpenStack mult-region deployment or Nova cells V2 multi-cell 
deployment, one shared Neutron module providing such cross Neutron server 
functionalities and provide the API entrance.  For trio2o, it's major purpose 
is to gateway, and it's not active after it's moved outside from Tricircle, 
during the Tricricle bightent application, some TCs were worried about the API 
consistency if one gateway layer is there, so it's not accepted into OpenStack. 
Though I know many cloud operators expressed the need for single API entry 
point for multiple OpenStack instances. [/joehuang]

- Could you better explain the architecture? For instance: where is the 
Controller? Are the compute nodes the same of the one site implementation?

[joehuang] for the architecture and work flow, you can refer to the slides and 
video we presented in OPNFV Beijing summit: video 
https://www.youtube.com/watch?v=tbcc7-eZnkY  , slides 
https://docs.google.com/presentation/d/1WBdra-ZaiB-K8_m3Pv76o_jhylEqJXTTxzEZ-cu8u2A/
 , 
https://www.slideshare.net/JoeHuang7/shared-networks-to-support-vnf-high-availability-across-openstack-multiregion-deployment-77283728
I don't know what do you mean for Controller, Tricircle only provides plugins 
to Neutron: Neutron server with different plugin plays different role, for 
central Neutron with Tricicle central plugin, it'll play as the networking 
coordination for multiple local Neutrons which will be installed with Tricircle 
local plugin. Each local Neutron work as usual with ML2 plugin/OVS backend or 
SDN controller backend, just install one slim hook layer of Tricircle local 
Neutron plugin. You can experience it through the guide: 
https://docs.openstack.org/developer/tricircle/installation-guide.html#multi-pod-installation-with-devstack
  [/joehuang]

- Is it possible to connect distributed compute nodes with an SDN network, in 
order to use it as data plane?
[joehuang] Yes, it's possible with an SDN network, currently we use in-tree OVS 
implemetation to connect distributed compute nodes, Tricricle is able to carry 
shadow port/shadow agent information to other Neutron servers, so SDN 
controller can use these information to build cross Neutron network. If SDN 
controller can communicate with each other by themselves, and establish cross 
Neutron network, it's also fine, Tricircle support this mode. During OPNFV 
summit, Vikram and I had one idea to see if OVN can work together with 
Tricircle.  Could you describe your idea for the SDN network in more detail, 
then I can check whether my understanding is correct, and provide my valuable 
comment.  [/joehuang]

- If not, what kind of network is in the middle? I suppose that a network is 
necessary to connect the different pod.

[joehuang]  Please refer to the last comment  [/joehuang]

Could you please clarify these points?
Thanks a lot

--
Silvia Fichera
__
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

[openstack-dev] [tricircle]weekly meeting of Jun.28

[joehuang]

Hello, team,

Agenda of Jun.28 weekly meeting:

  1.  feature implementation review
  2.  Community wide goals, PTG and Sydney summit topics
  3.  Open Discussion

How to join:

#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 1:00.



Best Regards
Chaoyi 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

Re: [openstack-dev] An idea about how to deploy multi Nova cells v2 using devstack

[joehuang]

Hello,

Currently Nova has one patch in review to deploy multi-cells for Cells V2, 
https://review.openstack.org/#/c/436094/

And Tricircle also provide one documentation on how how to deploy nova cells v2 
+ Tricricle: 
https://docs.openstack.org/developer/tricircle/installation-guide.html#work-with-nova-cell-v2-experiment
 . And there are may be some issue will happen, you can refer to the trouble 
shooting section.

Best Regards
Chaoyi Huang (joehuang)

From: David Mckein [davidmck...@gmail.com]
Sent: 23 June 2017 10:24
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] An idea about how to deploy multi Nova cells v2 using 
devstack

Hello,

I would like to experiment multi Nova cells v2. I found some references about 
Nova cells v2.
But It's not about multi cells v2 and how to deploy it.
I really want to know if there is a document or idea about how to deploy multi 
Nova cells v2.
I want to know where I can refer and what is going on, please.


Yours Truly
David Mckein
__
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

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[joehuang]

Hi,

Tricricle is based on core plugin interface, so if you want to refactory the 
interface, let us know
whether it'll break Tricricle. And I don't know whether there other plugins are 
using
this interface.

And there is one conclusion in this 
document(https://github.com/openstack/neutron-specs/blob/master/specs/newton/neutron-stadium.rst):

To provide composable networking solutions: the ML2/Service plugin framework 
was introduced many cycles ago to enable users with freedom of choice. Many 
solutions have switched to using ML2/Service plugins for high level services 
over the years. Although some plugins still use the core plugin interface to 
provide end-to-end solutions, the criterion to enforce the adoption of ML2 and 
service plugins for Neutron Stadium projects does not invalidate, nor does make 
monolithic solutions deprecated. It is simply a reflection of the fact that the 
Neutron team stands behind composability as one of the promise of open 
networking solutions. During code review the Neutron team will continue to 
ensure that changes and design implications do not have a negative impact on 
out of tree code irrespective of whether it is part of the Stadium project or 
not.

Best Regards
Chaoyi Huang (joehuang)


From: Édouard Thuleau [edouard.thul...@gmail.com]
Sent: 21 June 2017 16:45
To: OpenStack Development Mailing List (not for usage questions); 
ke...@benton.pub
Cc: Sachin Bansal
Subject: Re: [openstack-dev] [neutron] Do we still support core plugin not 
based on the ML2 framework?

Ok, we would like to help on that. How we can start?

I think the issue I raise in that thread must be the first point to
address and my second proposition seems to be the correct one. What do
you think?
But it will needs some time and not sure we'll be able to fix all
service plugins loaded by default before the next Pike release.

I like to propose a workaround until all default service plugins will
be compatible with non-DB core plugins. We can continue to load that
default service plugins list but authorizing a core plugin to disable
it completely with a private attribut on the core plugin class like
it's done for bulk/pagination/sorting operations.

Of course, we need to add the ability to report any regression on
that. I think unit tests will help and we can also work on a
functional test based on a fake non-DB core plugin.

Regards,
Édouard.

On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton <ke...@benton.pub> wrote:
> The issue is mainly developer resources. Everyone currently working upstream
> doesn't have the bandwidth to keep adding/reviewing the layers of interfaces
> to make the DB optional that go untested. (None of the projects that would
> use them run a CI system that reports results on Neutron patches.)
>
> I think we can certainly accept patches to do the things you are proposing,
> but there is no guarantee that it won't regress to being DB-dependent until
> there is something reporting results back telling us when it breaks.
>
> So it's not that the community is against non-DB core plugins, it's just
> that the people developing those plugins don't participate in the community
> to ensure they work.
>
> Cheers
>
>
> On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau <edouard.thul...@gmail.com>
> wrote:
>>
>> Oops, sent too fast, sorry. I try again.
>>
>> Hi,
>>
>> Since Mitaka release, a default service plugins list is loaded when
>> Neutron
>> server starts [1]. That list is not editable and was extended with few
>> services
>> [2]. But all of them rely on the Neutron DB model.
>>
>> If a core driver is not based on the ML2 core plugin framework or not
>> based on
>> the 'neutron.db.models_v2' class, all that service plugins will not work.
>>
>> So my first question is Does Neutron still support core plugin not based
>> on ML2
>> or 'neutron.db.models_v2' class?
>>
>> If yes, I would like to propose two solutions:
>> - permits core plugin to overload the service plugin class by it's own
>> implementation and continuing to use the actual Neutron db based services
>> as
>> default.
>> - modifying all default plugin service to use service plugin driver
>> framework [3], and set the actual Neutron db based implementation as
>> default driver for services. That permits to core drivers not based on the
>> Neutron DB to specify a driver. We can see that solution was adopted in
>> the
>> networking-bgpvpn project, where can find two abstract driver classes, one
>> for
>> core driver based on Neutron DB model [4] and one used by core driver not
>> based
>> on the DB [5] as the Contrail driver [6].
>>
>> [1]
>> https://github.com/openstack/neutron/commit/aadf2f30f84dff

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

[joehuang]

Hi,

If we just want to replace "bigtent" concept to another concept which mentioned 
in this thread,
many of them gave me the impression that there are still some projects more
important than others, so that's why I suggest to use flat project list, and 
put stress
"OPEN" stack here.

Best Regards
Chaoyi Huang (joehuang)


From: Flavio Percoco [fla...@redhat.com]
Sent: 21 June 2017 15:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] Moving away from "bigtent"   
terminology

On 21/06/17 06:18 +, joehuang wrote:
>hello, Flavio,

Hi :D

>This thread is to discuss moving away from the "big tent" term, not removing 
>some project.
>Removing a project will make this flavor disappear from the ice-cream counter, 
>but this thread,
>it's to use another concept to describe projects under openstack project 
>governance.
>If we don't want to use "big tent" for those projects staying in the counter,
>I hope all projects could be treated in flat, just like different flavor 
>ice-creams are flat in the
>same counter, kid can make choice by themselves.
>
>Even Nova may be only "core"  to some cloud operators, but not always for all 
>cloud operators,
>for example, those who only run object storage service, hyper.sh also not use 
>Nova,  some day may
>some cloud operators only use Zun or K8S instead for computing, it should not 
>be an issue
>to OpenStack community.

I think you misunderstood my message. I'm not talking about removing projects,
I'm talking about the staging of these projects to join the "Big tent" -
regardless of how we call it. The distinction *is* important and we ought to
find a way to preserve it and communicate it so that there's the least amount of
confusion possible.


>OpenStack should be "OPEN" stack for infrastructure, just like kid can choose 
>how many
>balls of ice-cream, cloud operators can make decision to choose which project 
>to use or
>not to manage his infrastructure.

You keep mentioning "OPEN stack" as if we weren't being open (enough?) and I
think I'm failing to see why you think that. Could you please elaborate more?
What you're describing seems to be the current status.

Flavio

>Best Regards
>Chaoyi Huang (joehuang)
>
>
>From: Flavio Percoco [fla...@redhat.com]
>Sent: 20 June 2017 17:44
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [all][tc] Moving away from "bigtent"   
>terminology
>
>On 20/06/17 00:33 +, joehuang wrote:
>>I think openstack community  provides a flat project market place for 
>>infrastructure is good enough:
>>
>>all projects are just some "goods" in the market place, let the cloud 
>>operators to select projects
>>from the project market place for his own infrastructure.
>>
>>We don't have to mark a project a core project or not, only need to tag 
>>attribute of a project, for
>>example how mature it is, how many "like" they have, what the cloud operator 
>>said for the project. etc.
>>
>>All flat, just let people make decision by themselves, they are not idiot, 
>>they have wisdom
>>on building infrastructure.
>>
>>Not all people need a package: you bought a package of ice-cream, but not all 
>>you will like it,
>>If they want package, distribution provider can help them to define and 
>>customize a package, if
>>you want customization, you will decide which ball of cream you want, isn't 
>>it?
>
>The flavors you see in a ice-creem shop counter are not there by accident. 
>Those
>flavors have gone through a creation process, they have been tested and they
>have also survived over the years. Some flavors are removed with time and some
>others stay there forever.
>
>Unfortunately, tagging those flavors won't cut it, which is why you don't see
>tags in their labels when you go to an ice-cream shop. Some tags are implied,
>other tags are inferred and other tags are subjective.
>
>Experimenting with new flavors doesn't happen overnight in some person's
>bedroom. The new flavors are tested using the *same* infrastructure as the 
>other
>flavors and once they reach a level of maturity, they are exposed in the 
>counter
>so that customers will able to consume them.
>
>Ultimately, experimentation is part of the ice-cream shop's mission and it
>requires time, effort and resources but not all experiments end well. At the
>end, though, what really matters is that all these flavors serve the same
>mission and that's why they a

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

[joehuang]

hello, Flavio,

This thread is to discuss moving away from the "big tent" term, not removing 
some project.
Removing a project will make this flavor disappear from the ice-cream counter, 
but this thread,
it's to use another concept to describe projects under openstack project 
governance. 
If we don't want to use "big tent" for those projects staying in the counter, 
I hope all projects could be treated in flat, just like different flavor 
ice-creams are flat in the
same counter, kid can make choice by themselves. 

Even Nova may be only "core"  to some cloud operators, but not always for all 
cloud operators,
for example, those who only run object storage service, hyper.sh also not use 
Nova,  some day may
some cloud operators only use Zun or K8S instead for computing, it should not 
be an issue
to OpenStack community.

OpenStack should be "OPEN" stack for infrastructure, just like kid can choose 
how many
balls of ice-cream, cloud operators can make decision to choose which project 
to use or
not to manage his infrastructure.

Best Regards
Chaoyi Huang (joehuang)


From: Flavio Percoco [fla...@redhat.com]
Sent: 20 June 2017 17:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] Moving away from "bigtent"   
terminology

On 20/06/17 00:33 +, joehuang wrote:
>I think openstack community  provides a flat project market place for 
>infrastructure is good enough:
>
>all projects are just some "goods" in the market place, let the cloud 
>operators to select projects
>from the project market place for his own infrastructure.
>
>We don't have to mark a project a core project or not, only need to tag 
>attribute of a project, for
>example how mature it is, how many "like" they have, what the cloud operator 
>said for the project. etc.
>
>All flat, just let people make decision by themselves, they are not idiot, 
>they have wisdom
>on building infrastructure.
>
>Not all people need a package: you bought a package of ice-cream, but not all 
>you will like it,
>If they want package, distribution provider can help them to define and 
>customize a package, if
>you want customization, you will decide which ball of cream you want, isn't it?

The flavors you see in a ice-creem shop counter are not there by accident. Those
flavors have gone through a creation process, they have been tested and they
have also survived over the years. Some flavors are removed with time and some
others stay there forever.

Unfortunately, tagging those flavors won't cut it, which is why you don't see
tags in their labels when you go to an ice-cream shop. Some tags are implied,
other tags are inferred and other tags are subjective.

Experimenting with new flavors doesn't happen overnight in some person's
bedroom. The new flavors are tested using the *same* infrastructure as the other
flavors and once they reach a level of maturity, they are exposed in the counter
so that customers will able to consume them.

Ultimately, experimentation is part of the ice-cream shop's mission and it
requires time, effort and resources but not all experiments end well. At the
end, though, what really matters is that all these flavors serve the same
mission and that's why they are sold at the ice-cream shop, that's why they are
exposed in the counter. Customer's of the ice-cream shop know they can trust
what's in the counter. They know the exposed flavors serve their needs at a high
level and they can now focus on their specific needs.

So, do you really think it's just a set of flavors and it doesn't really matter
how those flavors got there?

Flavio

--
@flaper87
Flavio Percoco

__
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

[openstack-dev] [tricircle]weekly meeting of Jun.21

[joehuang]

Hello, team,

Agenda of Jun.21 weekly meeting:

  1.  summary of tricircle demo in OPNFV summit
  3.  feature implementation review
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 1:00.


Best Regards
Chaoyi 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

[openstack-dev] [tricircle]weekly meeting of Jun.21

[joehuang]

Hello, team,

Agenda of Jun.20 weekly meeting:

  1.  summary of tricircle demo in OPNFV summit
  3.  feature implementation review
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 1:00.


Best Regards
Chaoyi 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

Re: [openstack-dev] [nova][tricircle] CellsV2 in Pike?

[joehuang]

Thank you very much, Matt, that's great news.

Best Regards
Chaoyi Huang (joehuang)


From: Matt Riedemann [mriede...@gmail.com]
Sent: 20 June 2017 9:29
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][tricircle] CellsV2 in Pike?

On 6/19/2017 8:02 PM, joehuang wrote:
> Hello,
>
> In May, Tricircle has done some work to make Nova cells V2 + Neutron +
> Tricircle work together[1]: each cell will have corresponding local
> Neutron with Tricricle local plugin installed, and one central Neutron
> server work together with Nova API server, where the Tricricle central
> plugin installed.
>
> Would like to know how far multi-cells will be supported for CellsV2 in
> Pike release, so that Tricircle can do more verification of this
> deployment option.
>
> [1]http://lists.openstack.org/pipermail/openstack-dev/2017-May/117599.html
>
> Best Regards
> Chaoyi 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
>

Hi Joe,

Tempest is passing on this devstack change [1] which enables a
multi-cell environment. We're still finding some random things that need
to be aware of a multi-cell deployment and are working through those,
but at this point we expect to be able to declare support for multiple
cells v2 cells in Pike.

[1] https://review.openstack.org/#/c/436094/

--

Thanks,

Matt

__
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

__
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

[openstack-dev] [nova][tricircle] CellsV2 in Pike?

[joehuang]

Hello,

In May, Tricircle has done some work to make Nova cells V2 + Neutron + 
Tricircle work together[1]: each cell will have corresponding local Neutron 
with Tricricle local plugin installed, and one central Neutron server work 
together with Nova API server, where the Tricricle central plugin installed.

Would like to know how far multi-cells will be supported for CellsV2 in Pike 
release, so that Tricircle can do more verification of this deployment option.

[1]http://lists.openstack.org/pipermail/openstack-dev/2017-May/117599.html

Best Regards
Chaoyi 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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

[joehuang]

I think openstack community  provides a flat project market place for 
infrastructure is good enough:

all projects are just some "goods" in the market place, let the cloud operators 
to select projects
from the project market place for his own infrastructure.

We don't have to mark a project a core project or not, only need to tag 
attribute of a project, for
example how mature it is, how many "like" they have, what the cloud operator 
said for the project. etc.

All flat, just let people make decision by themselves, they are not idiot, they 
have wisdom
on building infrastructure.

Not all people need a package: you bought a package of ice-cream, but not all 
you will like it,
If they want package, distribution provider can help them to define and 
customize a package, if
you want customization, you will decide which ball of cream you want, isn't it?

openstack is "OPEN" stack. 

Best Regards
Chaoyi Huang (joehuang)


From: Matt Riedemann [mriede...@gmail.com]
Sent: 19 June 2017 22:56
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][tc] Moving away from "big tent"  
terminology

On 6/17/2017 10:55 AM, Jay Bryant wrote:
>
> I am responding under Tim's note because I think it gets at what we
> really want to communicate and takes me to what we have presented in
> OUI.  We have Core OpenStack Projects and then a whole community of
> additional projects that support cloud functionality.
>
> So, without it being named, or cutesy, though I liked "Friends of
> Openstack", can we go with "OpenStack Core Projects" and "Peripheral
> OpenStack Projects"?

Because then you have to define what "core" means, and how you get to be
"core", which is like the old system of integrated and incubated
projects. I agree that a "core" set of projects is more understandable
at first, probably most for an outsider. But it gets confusing from a
governance perspective within the community.

And if you want to run just containers with Kubernetes and you want to
use Keystone and Cinder with it, you don't need Nova, so is Nova "core"
or not?

This is probably where the constellations idea comes in [1].

At the end of the day it's all OpenStack to me if it's hosted on
OpenStack infra, but I'm not the guy making budget decisions at a
company determining what to invest in. I think Doug has tried to explain
that perspective a bit elsewhere in this thread, and it sounds like
that's the key issue, the outside perspective from people making budget
decisions.

[1] https://review.openstack.org/#/c/453262/

--

Thanks,

Matt

__
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

__
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

Re: [openstack-dev] [nova][neutron]Nova cells v2+Neutron+Tricircle, it works

[joehuang]

Hello, Matt,

See inline comments with [joehuang]

Best Regards
Chaoyi Huang (joehuang)


From: Matt Riedemann [mriede...@gmail.com]
Sent: 07 June 2017 10:09
To: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org
Subject: Re: [openstack-dev] [nova][neutron]Nova cells v2+Neutron+Tricircle, it 
works

On 5/28/2017 6:58 PM, joehuang wrote:
> Hello,
>
> There is one session in OpenStack Boston summit about Neutron
> multi-site, and discuss how to make Neutron cells-aware[1].
>
> We have done experiment how Nova cells v2 + Neutron + Tricircle can work
> very well:

Thanks for testing this out Joe. It's great to get some feedback about
people experimenting with cells v2, especially this close to master - we
generally seem to have a 12-18 month latency on feedback for big things
like this so it's hard to react quickly to something a year old. :)

>
> Follow the guide[2], you will have one two cells environment: cell1 in
> node1 and cell2 in node2, and Nova-api/scheduler/conductor/placement in
> node1. To simplify the integration, the region for Nova-api is
> registered as CentralRegion in KeyStone.

This sounds sort of like what Dan Smith is doing in devstack for
upstream CI:

https://review.openstack.org/#/c/436094/

That's a 2-node job so we have to turn it into multi-cell with just
those two nodes, and one has to be running the controller services.

>
> At the same time, the tricircle devstack plugin will also install
> RegionOne Neutron in node1 to work with cell1, RegionTwo Neutron in
> node2, i,e, we'll have one local Neutron with one cell, the neutron
> endpoint url in cell's compute node will be configured to local Neutron.
> each local Neutron will be configured with Tricircle local Neutron plugin.
>
> We just mentioned that Nova-API is registered as CentralRegion, the
> tricircle devstack plugin will also start a central Neutron server and
> register it in CentralRegion( same region as Nova-API), the central
> Neutron server will be installed with Tricircle central Neutron plugin.
> In Nova-api's configuration nova.conf, the neutron endpoint url is
> configured to the central Neutron server's url.

If I'm understanding this correctly, nova-api will talk to Tricircle
which is federating the networking API for Neutron across the two
regions for "local" Neutron, right?

[joehuang] nova-api talk to central Neutron server, but not Tricircle. 
The central neutron server is installed with Tricircle central plugin

But what about nova-compute running within the cells? Are those talking
*only* to the Neutron deployed local to the same cell that nova-compute
is in? Or can each nova-compute talk to the central Neutron server?

[joehuang] nova-compute talking *only* to the Neutron deployed local to the
same cell that nova-compute is in


I think most of us in Nova have been considering external services as
global to Nova, so Neutron, Glance, Placement, Keystone and Cinder.

We don't support move operations, e.g. live migration, for server
instances across cells yet, but when we do we'd need to know the Neutron
topology to know which hosts we can send an instance to. This is sort of
touched on in the Neutron routed networks spec for Nova, which involves
using the Placement service for defining aggregate associations between
compute hosts and pools of network resources:

https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html

[joehuang] routed network can address neutron scalability to some extent, but 
it just
leaves the tenant network isolation and management to the outside world. The 
complexity
is still there, but just outside Neutron/Nova, if we don't care about tenant's 
network
isolation, then it's ok. For tricircle support VxLAN, the overlay network can 
be extended to 
the host you want to migrate to. In routed network , You have to know the 
network topology, because
the network connectivity is defined outside Neutron, but not inside
Neutron, some host may be not connected to this network. 
So compared to routed network, Tricircle provides more flexible and tenant 
isolated networking capability
through Neutron.

>
> In both central Neutron server and local Neutron, the nova endpoint url
> configuration will be pointed to central Nova-api url, it's for
> call-back message to Nova-API.

Yup, so either Neutron sends an event to the central nova-api endpoint
which knows which cell an instance is in and can route the message
appropriately. I'm thinking of the os-server-external-events API in this
case.

>
> After the installation, now you have one CentralRegion with one Nova API
> and one Neutron Server, and regard to Nova multi-cells, each cell is
> accompanied with one local Neutron. ( It's not necessary for 1:1 mapping
> between cell and local Neutron, may multi-cells mapped to one

[openstack-dev] [nova][neutron]Nova cells v2+Neutron+Tricircle, it works

[joehuang]

Hello,

There is one session in OpenStack Boston summit about Neutron multi-site, and 
discuss how to make Neutron cells-aware[1].

We have done experiment how Nova cells v2 + Neutron + Tricircle can work very 
well:

Follow the guide[2], you will have one two cells environment: cell1 in node1 
and cell2 in node2, and Nova-api/scheduler/conductor/placement in node1. To 
simplify the integration, the region for Nova-api is registered as 
CentralRegion in KeyStone.

At the same time, the tricircle devstack plugin will also install RegionOne 
Neutron in node1 to work with cell1, RegionTwo Neutron in node2, i,e, we'll 
have one local Neutron with one cell, the neutron endpoint url in cell's 
compute node will be configured to local Neutron. each local Neutron will be 
configured with Tricircle local Neutron plugin.

We just mentioned that Nova-API is registered as CentralRegion, the tricircle 
devstack plugin will also start a central Neutron server and register it in 
CentralRegion( same region as Nova-API), the central Neutron server will be 
installed with Tricircle central Neutron plugin. In Nova-api's configuration 
nova.conf, the neutron endpoint url is configured to the central Neutron 
server's url.

In both central Neutron server and local Neutron, the nova endpoint url 
configuration will be pointed to central Nova-api url, it's for call-back 
message to Nova-API.

After the installation, now you have one CentralRegion with one Nova API and 
one Neutron Server, and regard to Nova multi-cells, each cell is accompanied 
with one local Neutron. ( It's not necessary for 1:1 mapping between cell and 
local Neutron, may multi-cells mapped to one local Neutron).

If you create network/router without availability-zone specified, global 
network/router is applied, all instances from any cell can be attached to. If 
you create network/router with availability-zone specified, you can get scoped 
network/router, i.e, the network/router can only be presented in regarding 
cells.

Note:
1. Because Nova multi-cells is still under development, there will be some 
issue in deployment and experience, some typical trouble shooting has been 
provided in the document[2].
2. For the RegionOne and RegionTwo name which is registered by local Neutron, 
you can change it to other better name if needed, for example 
"cell1-subregion", "cell2-subregion", etc.

Feedback and contribution are welcome to make this mode works.

[1]http://lists.openstack.org/pipermail/openstack-dev/2017-May/116614.html
[2]https://docs.openstack.org/developer/tricircle/installation-guide.html#work-with-nova-cell-v2-experiment

Best Regards
Chaoyi 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

Re: [openstack-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[joehuang]

I think a option 2 is better.

Best Regards
Chaoyi Huang (joehuang)

From: Lance Bragstad [lbrags...@gmail.com]
Sent: 25 May 2017 3:47
To: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [openstack-dev] 
[keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

I'd like to fill in a little more context here. I see three options with the 
current two proposals.

Option 1

Use a special admin project to denote elevated privileges. For those unfamiliar 
with the approach, it would rely on every deployment having an "admin" project 
defined in configuration [0].

How it works:

Role assignments on this project represent global scope which is denoted by a 
boolean attribute in the token response. A user with an 'admin' role assignment 
on this project is equivalent to the global or cloud administrator. Ideally, if 
a user has a 'reader' role assignment on the admin project, they could have 
access to list everything within the deployment, pending all the proper changes 
are made across the various services. The workflow requires a special project 
for any sort of elevated privilege.

Pros:
- Almost all the work is done to make keystone understand the admin project, 
there are already several patches in review to other projects to consume this
- Operators can create roles and assign them to the admin_project as needed 
after the upgrade to give proper global scope to their users

Cons:
- All global assignments are linked back to a single project
- Describing the flow is confusing because in order to give someone global 
access you have to give them a role assignment on a very specific project, 
which seems like an anti-pattern
- We currently don't allow some things to exist in the global sense (i.e. I 
can't launch instances without tenancy), the admin project could own resources
- What happens if the admin project disappears?
- Tooling or scripts will be written around the admin project, instead of 
treating all projects equally

Option 2

Implement global role assignments in keystone.

How it works:

Role assignments in keystone can be scoped to global context. Users can then 
ask for a globally scoped token

Pros:
- This approach represents a more accurate long term vision for role 
assignments (at least how we understand it today)
- Operators can create global roles and assign them as needed after the upgrade 
to give proper global scope to their users
- It's easier to explain global scope using global role assignments instead of 
a special project
- token.is_global = True and token.role = 'reader' is easier to understand than 
token.is_admin_project = True and token.role = 'reader'
- A global token can't be associated to a project, making it harder for 
operations that require a project to consume a global token (i.e. I shouldn't 
be able to launch an instance with a globally scoped token)

Cons:
- We need to start from scratch implementing global scope in keystone, steps 
for this are detailed in the spec

Option 3

We do option one and then follow it up with option two.

How it works:

We implement option one and continue solving the admin-ness issues in Pike by 
helping projects consume and enforce it. We then target the implementation of 
global roles for Queens.

Pros:
- If we make the interface in oslo.context for global roles consistent, then 
consuming projects shouldn't know the difference between using the 
admin_project or a global role assignment

Cons:
- It's more work and we're already strapped for resources
- We've told operators that the admin_project is a thing but after Queens they 
will be able to do real global role assignments, so they should now migrate 
*again*
- We have to support two paths for solving the same problem in keystone, more 
maintenance and more testing to ensure they both behave exactly the same way
  - This can get more complicated for projects dedicated to testing policy and 
RBAC, like Patrole


Looking for feedback here as to which one is preferred given timing and payoff, 
specifically from operators who would be doing the migrations to implement and 
maintain proper scope in their deployments.

Thanks for reading!


[0] 
https://github.com/openstack/keystone/blob/3d033df1c0fdc6cc9d2b02a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342

On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad 
<lbrags...@gmail.com<mailto:lbrags...@gmail.com>> wrote:
Hey all,

To date we have two proposed solutions for tackling the admin-ness issue we 
have across the services. One builds on the existing scope concepts by scoping 
to an admin project [0]. The other introduces global role assignments [1] as a 
way to denote elevated privileges.

I'd like to get some feedback from operators, as well as developers from other 
projects, on each approach. Since work is required in keystone, it would be 
good to get consensus before spec freeze (

[openstack-dev] [tricircle]weekly meeting of May.24

[joehuang]

Hello, team,

Agenda of May.24 weekly meeting:

  1.  feature implementation review
  2.  Pike-2 preparation
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 01:00.

If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi 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

Re: [openstack-dev] [all] Project On-Boarding Info Collection

[joehuang]

Hello,

Not use a training slides in Tricricle on-boarding session, and would like to 
create one for new contributors later. For the summary of the on-boarding 
session, have replied in another thread which collects feedback.

Best Regards
Chaoyi Huang (joehuang)

From: Kendall Nelson [kennelso...@gmail.com]
Sent: 09 May 2017 2:57
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all] Project On-Boarding Info Collection

Hello!

If you are running a project onboarding session and have etherpads/slides/ etc 
you are using to educate new contributors  please send them to me! I am 
collecting all the resources you are sharing into a single place for people 
that weren't able to attend sessions.

Thanks!

Kendall (diablo_rojo)
__
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

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

[joehuang]

Tricircle shared a room with Sahara, and stay there for the first half.

Around 6 persons joined the session. Due to the network issue(on the lab side) 
I am not able to logon to my environment to do the training based on live 
environment. I have to play some recorded clips, during the playing, we 
discussed a lot of topics, from the overall architecture and functionalities, 
and whether it support cross Neutron L2 network, and how to setup the 
environment to experience it. I can't remember all detail information. It seems 
45 minutes is too short for on-boarding session, lots of other topics have not 
been discussed. We leave the room after Sahara began their session, two 
projects in same room will be quite noise, many people will talk at the same 
time. After the session, one guy continue to talk with me about Tricircle for 
around half an hour.

Obviously, on-boarding session is necessary for a project, some may be 
contributors, some may be not, but there are lots of people want to learn a 
project in more detail, it'll help a project to grow contributors and 
(potential) operators.

Best Regards
Chaoyi Huang (joehuang)


From: Sean Dague [s...@dague.net]
Sent: 19 May 2017 21:22
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, 
what worked, lessons learned

This is a thread for anyone that participated in the onboarding rooms,
on either the presenter or audience side. Because we all went into this
creating things from whole cloth, I'm sure there are lots of lessons
learned.

If you ran a room, please post the project, what you did in the room,
what you think worked, what you would have done differently. If you
attended a room you didn't run, please provide feedback about which one
it was, and what you thought worked / didn't work from the other side of
the table.

Hopefully we can consolidate some of that feedback for best practices
going forward.

-Sean

--
Sean Dague
http://dague.net

__
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

__
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

Re: [openstack-dev] [nova] Boston Forum session recap - searchlight integration

[joehuang]

Support sort and pagination together will be the biggest challenge: it's up to 
how many cells will be involved in the query, 3,5 may be OK, you can search 
each cells, and cached data. But how about 20, 50 or more, and how many data 
will be cached?

More over, during the query there are instances operation( create, delete)  in 
parallel during the pagination/sort query, there is situation some cells may 
not provide response in time, or network connection broken, etc, many abnormal 
cases may happen. How to deal with some of cells abnormal query response is 
also one great factor to be considered. 

It's not good idea to support pagination and sort at the same time (may not 
provide exactly the result end user want) if searchlight should not be 
integrated.

In fact in Tricircle, when query ports from neutron where tricircle central 
plugin is installed, the tricircle central plugin do the similar cross local 
Neutron ports query, and not support pagination/sort together.

Best Regards
Chaoyi Huang (joehuang)


From: Matt Riedemann [mriede...@gmail.com]
Sent: 19 May 2017 5:21
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] Boston Forum session recap - searchlight
integration

Hi everyone,

After previous summits where we had vertical tracks for Nova sessions I
would provide a recap for each session.

The Forum in Boston was a bit different, so here I'm only attempting to
recap the Forum sessions that I ran. Dan Smith led a session on Cells
v2, John Garbutt led several sessions on the VM and Baremetal platform
concept, and Sean Dague led sessions on hierarchical quotas and API
microversions, and I'm going to leave recaps for those sessions to them.

I'll do these one at a time in separate emails.


Using Searchlight to list instances across cells in nova-api


The etherpad for this session is here [1]. The goal for this session was
to explain the problem and proposed plan from the spec [2] to the
operators in the room and get feedback.

Polling the room we found that not many people are deploying Searchlight
but most everyone was using ElasticSearch.

An immediate concern that came up was the complexity involved with
integrating Searchlight, especially around issues with latency for state
changes and questioning how this does not redo the top-level cells v1
sync issue. It admittedly does to an extent, but we don't have all of
the weird side code paths with cells v1 and it should be self-healing.
Kris Lindgren noted that the instance.usage.exists periodic notification
from the computes hammers their notification bus; we suggested he report
a bug so we can fix that.

It was also noted that if data is corrupted in ElasticSearch or is out
of sync, you could re-sync that from nova to searchlight, however,
searchlight syncs up with nova via the compute REST API, which if the
compute REST API is using searchlight in the backend, you end up getting
into an infinite loop of broken. This could probably be fixed with
bypass query options in the compute API, but it's not a fun problem.

It was also suggested that we store a minimal set of data about
instances in the top-level nova API database's instance_mappings table,
where all we have today is the uuid. Anything that is set in the API
would probably be OK for this, but operators in the room noted that they
frequently need to filter instances by an IP, which is set in the
compute. So this option turns into a slippery slope, and is potentially
not inter-operable across clouds.

Matt Booth is also skeptical that we can't have a multi-cell query
perform well, and he's proposed a POC here [3]. If that works out, then
it defeats the main purpose for using Searchlight for listing instances
in the compute API.

Since sorting instances across cells is the main issue, it was also
suggested that we allow a config option to disable sorting in the API.
It was stated this would be without a microversion, and filtering/paging
would still be supported. I'm personally skeptical about how this could
be consider inter-operable or discoverable for API users, and would need
more thought and input from users like Monty Taylor and Clark Boylan.

Next steps are going to be fleshing out Matt Booth's POC for efficiently
listing instances across cells. I think we can still continue working on
the versioned notifications changes we're making for searchlight as
those are useful on their own. And we should still work on enabling
searchlight in the nova-next CI job so we can get an idea for how the
versioned notifications are working by a consumer. However, any major
development for actually integrating searchlight into Nova is probably
on hold at the moment until we know how Matt's POC works.

[1]
https://etherpad.openstack.org/p/BOS-forum-using-searchlight-to-list-instances
[2]
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/list-instances

[openstack-dev] [tricircle]cancellation of weekly meeting(May 17) due to bug smash

[joehuang]

Hello, team,

The bug smash will be held May.17~19, the weekly meeting of May. 17 will be 
cancelled.

Best Regards
Chaoyi 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

Re: [openstack-dev] [neutron] multi-site forum discussion

[joehuang]

Hello,

Neutron cells aware is not equal to multi-site. There are lots of multi-site 
deployment options, not limited to nova-cells, whether to use 
Neutron-cells/Nova-cells in multi-site deployments, it's up to cloud operator's 
choice. For the bug[3], it's reasonable to make neutron support cells, but it 
doesn't implicate that multi-site should mandatory adopt neutron-cells.

[3] https://bugs.launchpad.net/neutron/+bug/1690425

Best Regards
Chaoyi Huang (joehuang)

From: Armando M. [arma...@gmail.com]
Sent: 13 May 2017 3:13
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] multi-site forum discussion



On 12 May 2017 at 11:47, Morales, Victor 
<victor.mora...@intel.com<mailto:victor.mora...@intel.com>> wrote:
Armando,

I noticed that Tricircle is mentioned there.  Shouldn’t be better to extend its 
current functionality or what are the things that are missing there?

Tricircle aims at coordinating independent neutron systems that exist in 
separated openstack deployments. Making Neutron cell-aware will work in the 
context of the same openstack deployment.


Regards,
Victor Morales

From: "Armando M." <arma...@gmail.com<mailto:arma...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 12, 2017 at 1:06 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron] multi-site forum discussion

Hi folks,

At the summit we had a discussion on how to deploy a single neutron system 
across multiple geographical sites [1]. You can find notes of the discussion on 
[2].

One key requirement that came from the discussion was to make Neutron more Nova 
cells friendly. I filed an RFE bug [3] so that we can move this forward on 
Lauchpad.

Please, do provide feedback in case I omitted some other key takeaway.

Thanks,
Armando

[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18757/neutron-multi-site
[2] https://etherpad.openstack.org/p/pike-neutron-multi-site
[3] https://bugs.launchpad.net/neutron/+bug/1690425

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
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

[openstack-dev] [Openstack-operators]project Tricricle onboarding in Boston

[joehuang]

Hello,

If you are interested in learning more about Tricircle - networking automation 
across OpenStack clouds, you are welcome to the on-boarding session in Boston, 
Tuesday, May 9, 4:40pm-5:25pm Level One - MR 101.

Please feel free to add topics in the etherpad, 
https://etherpad.openstack.org/p/BOS-forum-tricircle-onboarding , and use +1 to 
prompt your preferred topics.

Best Regards
Chaoyi 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

[openstack-dev] [Openstack-operators] try and feedback on tenant overlay networking across multiple OpenStack clouds

[joehuang]

Hello,

Tricircle is a project to provide tenant level L2/L3 overlay networking 
automation across Neutron in multi-region OpenStack deployments.

The cross OpenStack networking topology can be composed mainly from four 
concepts:

Local Network
  - Local Network is a network which can only reside in one OpenStack cloud.
  - Network type could be VLAN, VxLAN, Flat.
Local Router
  - Local Router is a logical router which can only reside in one OpenStack
cloud.
Cross OpenStack L2 Network
  - Cross OpenStack L2 Network is a network which can be streched into more
than one OpenStack cloud.
  - Also called cross Neutron L2 network, or cross pod L2 network.
  - Network type could be VLAN, VxLAN, Flat.
Non-Local Router
  - Non-Local Router will be able to reside in more than one OpenStack cloud,
and internally inter-connected with bridge network.
  - Bridge network used internally for non-local router is a special cross
OpenStack L2 network.
  - Local networks or cross OpenStack L2 networks can be attached to local
router or non-local routers if the network can be presented to the region
where the router can reside.

With these four concepts, various typologies could be composed:
  - Instances in different OpenStack clouds can be attached to a cross
OpenStack L2 network directly, so that they can communicate with
each other no matter in which OpenStack cloud.
  - Local router can be set gateway with external networks to support
north-south traffic handled locally.
  - Non-local router can work only for cross OpenStack east-west networking
purpose if no external network is set to the router.
  - Non-local router can serve as the centralized north-south traffic gateway
if external network is attached to the router, and support east-west
traffic at the same time.

Several typical cross OpenStack networking topology have been supported in 
Tricircle Pike1.5, just released on May.2:

1. Multiple North-South gateways with East-West Networking enabled
  - 
https://docs.openstack.org/developer/tricircle/networking-guide-multiple-ns-with-ew-enabled.html
2. North South Networking via Single External Network
  - 
https://docs.openstack.org/developer/tricircle/networking-guide-single-external-network.html
3. North South Networking via Multiple External Networks
  - 
https://docs.openstack.org/developer/tricircle/networking-guide-multiple-external-networks.html
4. North South Networking via Direct Provider Networks
  - 
https://docs.openstack.org/developer/tricircle/networking-guide-direct-provider-networks.html

Now you can experience these networking automation capabilities through 
devstack, the installation guide is also available:
 - 
https://docs.openstack.org/developer/tricircle/installation-guide.html#multi-pod-installation-with-devstack

If you want to learn more about the networking automation provided by 
Tricircle, the wiki page of Tricircle is an entrance to the project:
  - https://wiki.openstack.org/wiki/Tricircle

Two sessions in OpenStack Boston Summit are also good start point.
1. When One Cloud is Not Enough: An Overview of Sites, Regions... 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18076/
2. Tricircle - Project Onboarding. 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18701

And in OPNFV Beijing Summit in June, one PoC demo will be done to show how 
Tricircle networking capability can help VNF(telecom application) to achieve 
high availability across OpenStack clouds(or multi-sites): 
https://docs.google.com/presentation/d/16Qfm3D1yhrW31ZEVRYea8mcyKI06fQ3a6Okk4VhFGkQ/
 .

Feel free to ping us in mail-list or IRC if you have any topic to be discussed. 
Very keen to get your feedback on the networking requirements and expectation, 
and discuss in more detail f2f if needed.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]weekly meeting of May.3

[joehuang]

Hello, team,

Please note the new weekly meeting time is UTC 01:00, Wednesday.

Agenda of May.3 weekly meeting:

  1.  feature implementation review
  2.  Pike-1.5 (May.2) review
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 01:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle]poll for new weekly meeting time slot

[joehuang]

Hello,

According to the poll, most of contributors prefer the option "Wed  UTC 01:00, 
Beijing 9:00 AM, PDT(-1 day) 6:00 PM". I'll submit a patch to update the weekly 
meeting time slot.

Best Regards
Chaoyi Huang (joehuang)
____
From: joehuang
Sent: 24 April 2017 16:12
To: openstack-dev
Subject: [openstack-dev][tricircle]poll for new weekly meeting time slot

Hello,

We's like to reschedule our weekly time according to our discussion, there are 
four options after some offline communication:

Wed  UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM
Wed  UTC 13:00, Beijing 9:00 PM, PDT 6:00 AM
Thu  UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM
Fri  UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM


Please vote in the doodle poll: http://doodle.com/poll/ypd2xpqppzaqek5u thanks 
a lot.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]weekly meeting APR.26

[joehuang]

Hello,

According to the plan, we'd like to release pike-1.5 on May.2, the priorities 
of these patches are as follows:

MUST to have(Should be merged before the end of this week):

  *   Release note and doc for multi-gw NS networking, 
https://review.openstack.org/#/c/458786/
  *   Add guide for multiple north-south gateways with east-west enabled, 
https://review.openstack.org/#/c/458315/

NICE to have(To be merged as far as possible):

  *   Include tricircleclient installation, 
https://review.openstack.org/#/c/437719/
  *   Implement asynchronous job Admin API, 
https://review.openstack.org/#/c/446837/
  *   Documentation on asynchronous job management, 
https://review.openstack.org/#/c/456652/
  *   Add VLAN aware VMs support, https://review.openstack.org/#/c/444579/
  *   Basic devstack gate run script: https://review.openstack.org/#/c/455615/
  *   Release notes for asynchronous job management API, 
https://review.openstack.org/#/c/459668/
  *
  *   Networking Qos service spec, https://review.openstack.org/#/c/417947/

For other patches, work on best effort.

If no urgent topic to be discussed before the weekly meeting, the APR.26 weekly 
meeting is to be skipped.

And also please continue to vote in the new weekly meeting time slot polling: 
http://doodle.com/poll/ypd2xpqppzaqek5u

Best Regards
Chaoyi 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

Re: [openstack-dev] project on-board schedule

[joehuang]

Thank you very much, Hongbin and Kendall.

Best Regards
Chaoyi Huang (joehuang)

From: Kendall Nelson [kennelso...@gmail.com]
Sent: 26 April 2017 11:19
To: joehuang; OpenStack Development Mailing List (not for usage questions); 
Hongbin Lu
Subject: Re: [openstack-dev] project on-board schedule


Yes, I should be able to make that happen :)

- Kendall

On Tue, Apr 25, 2017, 10:03 PM joehuang 
<joehu...@huawei.com<mailto:joehu...@huawei.com>> wrote:
Hello, Kendall,

Thank you very much for the slot you provided, but consider that it's launch 
time, I am afraid that audience need to have launch too.

I just discussed with Hongbin, the PTL of Zun, he said it's OK to exchange the 
project on-boarding time slot between Zun[1] and Tricircle[2].

After exchange, Tricircle will share with Sahara and use the first half (45 
minutes) just like Zun in this time slot. And Zun's on-boarding session will be 
moved to Monday 2:00pm~3:30pm.

Is this exchange is feasible?

[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18701/zunsahara-project-onboarding
[2] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding

Best Regards
Chaoyi Huang (joehuang)

From: Kendall Nelson [kennelso...@gmail.com<mailto:kennelso...@gmail.com>]
Sent: 26 April 2017 4:07
To: OpenStack Development Mailing List (not for usage questions); joehuang

Subject: Re: [openstack-dev] project on-board schedule
Hello Joe,

I can offer TriCircle a lunch slot on Wednesday from 12:30-1:50?

-Kendall


On Tue, Apr 25, 2017 at 4:08 AM joehuang 
<joehu...@huawei.com<mailto:joehu...@huawei.com>> wrote:
Hi,

Thank you Tom, I found that the on-boarding session of Tricircle [1] is 
overlapping with my talk{2]:

[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding
[2] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18076/when-one-cloud-is-not-enough-an-overview-of-sites-regions-edges-distributed-clouds-and-more

Is there any other project can help us to exchange the on-boarding session? 
Thanks a lot, I just find the issue.

Best Regards
Chaoyi Huang (joehuang)


From: Tom Fifield [t...@openstack.org<mailto:t...@openstack.org>]
Sent: 25 April 2017 16:50
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] project on-board schedule

On 25/04/17 16:35, joehuang wrote:
> Hello,
>
> Where can I find the project on-board schedule in OpenStack Boston
> summit? I haven't found it yet, and maybe I missed some mail. Thanks a lot.

It's listed on the main summit schedule, under the Forum :)

Here's a direct link to the Forum category:

https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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

Re: [openstack-dev] [tricircle] mascot for the Tricircle

[joehuang]

Hello, team,

Great, if no other comment, then the following cute Panda is Tricircle's mascot.

Thank you all!

[X]

Best Regards
Chaoyi Huang (joehuang)

From: Yipei Niu [newy...@gmail.com]
Sent: 25 April 2017 9:25
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] mascot for the Tricircle

+1.

Best regards,
Yipei

__
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

Re: [openstack-dev] project on-board schedule

[joehuang]

Hello, Kendall,

Thank you very much for the slot you provided, but consider that it's launch 
time, I am afraid that audience need to have launch too.

I just discussed with Hongbin, the PTL of Zun, he said it's OK to exchange the 
project on-boarding time slot between Zun[1] and Tricircle[2].

After exchange, Tricircle will share with Sahara and use the first half (45 
minutes) just like Zun in this time slot. And Zun's on-boarding session will be 
moved to Monday 2:00pm~3:30pm.

Is this exchange is feasible?

[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18701/zunsahara-project-onboarding
[2] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding

Best Regards
Chaoyi Huang (joehuang)

From: Kendall Nelson [kennelso...@gmail.com]
Sent: 26 April 2017 4:07
To: OpenStack Development Mailing List (not for usage questions); joehuang
Subject: Re: [openstack-dev] project on-board schedule

Hello Joe,

I can offer TriCircle a lunch slot on Wednesday from 12:30-1:50?

-Kendall


On Tue, Apr 25, 2017 at 4:08 AM joehuang 
<joehu...@huawei.com<mailto:joehu...@huawei.com>> wrote:
Hi,

Thank you Tom, I found that the on-boarding session of Tricircle [1] is 
overlapping with my talk{2]:

[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding
[2] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18076/when-one-cloud-is-not-enough-an-overview-of-sites-regions-edges-distributed-clouds-and-more

Is there any other project can help us to exchange the on-boarding session? 
Thanks a lot, I just find the issue.

Best Regards
Chaoyi Huang (joehuang)


From: Tom Fifield [t...@openstack.org<mailto:t...@openstack.org>]
Sent: 25 April 2017 16:50
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] project on-board schedule

On 25/04/17 16:35, joehuang wrote:
> Hello,
>
> Where can I find the project on-board schedule in OpenStack Boston
> summit? I haven't found it yet, and maybe I missed some mail. Thanks a lot.

It's listed on the main summit schedule, under the Forum :)

Here's a direct link to the Forum category:

https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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

Re: [openstack-dev] project on-board schedule

[joehuang]

Hi, 

Thank you Tom, I found that the on-boarding session of Tricircle [1] is 
overlapping with my talk{2]:

[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18693/tricircle-project-onboarding
[2] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18076/when-one-cloud-is-not-enough-an-overview-of-sites-regions-edges-distributed-clouds-and-more

Is there any other project can help us to exchange the on-boarding session? 
Thanks a lot, I just find the issue.

Best Regards
Chaoyi Huang (joehuang)


From: Tom Fifield [t...@openstack.org]
Sent: 25 April 2017 16:50
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] project on-board schedule

On 25/04/17 16:35, joehuang wrote:
> Hello,
>
> Where can I find the project on-board schedule in OpenStack Boston
> summit? I haven't found it yet, and maybe I missed some mail. Thanks a lot.

It's listed on the main summit schedule, under the Forum :)

Here's a direct link to the Forum category:

https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146


__
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

__
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

[openstack-dev] project on-board schedule

[joehuang]

Hello,

Where can I find the project on-board schedule in OpenStack Boston summit? I 
haven't found it yet, and maybe I missed some mail. Thanks a lot.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]poll for new weekly meeting time slot

[joehuang]

Hello,

We's like to reschedule our weekly time according to our discussion, there are 
four options after some offline communication:

Wed  UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM
Wed  UTC 13:00, Beijing 9:00 PM, PDT 6:00 AM
Thu  UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM
Fri  UTC 01:00, Beijing 9:00 AM, PDT(-1 day) 6:00 PM


Please vote in the doodle poll: http://doodle.com/poll/ypd2xpqppzaqek5u thanks 
a lot.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]mascot for the Tricircle project

[joehuang]

Hello, team,

What about the mascot of Tricircle project?

Your comments are welcome.

Best Regards
Chaoyi Huang(joehuang)


From: Heidi Joy Tretheway [heidi...@openstack.org]
Sent: 22 April 2017 6:15
To: joehuang
Subject: Re: Question about the Tricircle mascot

Hi Joe,
Following up on your team’s mascot request, our illustrators came back with a 
beautiful piece. Would you please let me know what your team thinks?

[cid:37DEE8D2-1153-4E9B-B901-C8631599ECEB]





__
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

[openstack-dev] [tricircle]weekly meeting of Apr.19

[joehuang]

Hello, team,

Agenda of Apr.19 weekly meeting:

  1.  feature implementation review
  2.  weekly meeting time
  3.  Pike-1.5 (May.2) preparation
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi 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

Re: [openstack-dev] [tc][elections]questions about one platform vision

[joehuang]

 Interesting to know the idea considering OpenStack as group of constellations. 
Does it mean even
Nova/Cinder/Neutron are not necessary to be tied together in some user cases?

Seems that "one platform" has not been got consensus yet. But the marketing 
material of
OpenStack is claiming "one platform" [1][2]

[1] https://www.openstack.org/assets/marketing/OpenStack-101-Modular-Deck-1.pptx
[2] OpenStack 101,  https://www.openstack.org/marketing/#tab=collateral

Best Regards
Chaoyi Huang (joehuang)


From: John Garbutt [j...@johngarbutt.com]
Sent: 12 April 2017 18:51
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][elections]questions about one platform
vision

On 12 April 2017 at 03:54, joehuang <joehu...@huawei.com> wrote:
> What's the one platform will be in your own words? What's your proposal and
> your focus to help one platform vision being achieved?

The more I think about this, the less I like the phrase "one platform".

I like to think of OpenStack as group of constellations. Those
constellations are groups of projects that are built to be used
together around a shared set of use cases and users. Note that many
(all?) of those constellations involve open source projects that were
born and live outside of OpenStack.

I am trying to kick start the "VM and baremetal" working group to get
feedback on a specific constellation as a group of projects. Here I am
thinking about running Nova, Cinder, Neutron, Keystone, etc to give
you (in some sense) a Software Defined Data Center. Many applications
and services need to consume and integrate with that platform, like
Heat, Trove and Magnum, to can get access to the compute, networking
and storage they need to execute their workloads, such as containers.
Its like the next generation of consolidation to get to the next level
of utilization/efficiency. If you look at this constellation the
database and message queue are important non-OpenStack components of
the constellation. Maybe this is a false constellation, and there is a
different set of things that people use together. Thats some of the
feedback I hope we get at the forum.

The work ttx mentions is important. I hope the project maps will help
communicate how users can meet their needs by running various
combinations of OpenStack and non-OpenStack projects together.

To be clear, I am not claiming to have the answers here, this is just
my current thinking. I look forward to all the debate and discussions
around this topic, and all the interesting things I will learn about
along that journey, things that will likely make me change my mind.

Thanks,
johnthetubaguy

__
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

__
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

[openstack-dev] [tricircle]weekly meeting of Apr.12

[joehuang]

Hello, team,

Agenda of Apr.12 weekly meeting:

  1.  feature implementation review
  2.  Pike-1.5 (May.2) preparation
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi 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

[openstack-dev] [tc][elections]questions about one platform vision

[joehuang]

Hello,

I heard the one platform vision in OpenStack now and then: One platform for 
virtual machines, containers and bare metal.

I also learned that there are some groups working on making Kubernets being 
able to manage virtual machines. Except running containers in virtual machine, 
there is also the need for running containers in bare metal.

There are several projects connecting OpenStack to container world: Zun, 
Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, ...

Can all these efforts lead us to one platform vision? We have to think over the 
question.

What's the one platform will be in your own words? What's your proposal and 
your focus to help one platform vision being achieved?


Best Regards
Chaoyi 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

Re: [openstack-dev] [tc] [elections] Available time and top priority

[joehuang]

> When there are topics with a lot of people clamoring to talk, Thierry usually 
> lets people speak in order of "raising 
> their hand". This reduces cross-talk and lets everyone get their turn to 
> state what's on their mind. 

+1, impressive for the "raising their hand" in TC weekly IRC meeting :), 
especially  during Tricircle's big-tent application discussion.

Best Regards
Chaoyi Huang (joehuang)


From: Ed Leafe [e...@leafe.com]
Sent: 11 April 2017 5:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] [elections] Available time and top priority

On Apr 10, 2017, at 3:40 PM, Matt Riedemann <mriede...@gmail.com> wrote:
>
> I don't attend many TC meetings, it's usually on accident, but yeah, when I 
> do I always note the flurry of cross-talk chatter that just drowns everything 
> out. I feel like there are usually at least 3 parallel conversations going on 
> during a TC meeting and it's pretty frustrating to follow along, or get a 
> thought in the mix. That has to be much worse for a non-native English 
> speaker.
>
> So yeah, slow down folks. :)

When there are topics with a lot of people clamoring to talk, Thierry usually 
lets people speak in order of "raising their hand". This reduces cross-talk and 
lets everyone get their turn to state what's on their mind. Normally, though, 
it is a bit of an acquired skill to be able to follow along.

-- Ed Leafe






__
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

[openstack-dev] [tricircle]weekly meeting of Apr.5

[joehuang]

Hello, team,

Agenda of Apr.5 weekly meeting:

  1.  feature implementation review
  2.  Pike-2 planning
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.


Best Regards
Chaoyi 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

[openstack-dev] [tricircle]weekly meeting of Mar. 29

[joehuang]

Hello, team,

Agenda of Mar.29 weekly meeting:

  1.  Pike-1 prioritized patches
  2.  Requirements from  VNF high availability across OpenStack (which will be 
a demo in OPNFV Beijing Summit)
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.


Best Regards
Chaoyi 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

[openstack-dev] [tricircle]pike-1 patch prioritization

[joehuang]

Hello,

As we discussed in last weekly meeting, pike-1 is expected to be tagged by the 
end of this month, Mar.31.

These patches are must to have in pike-1:

1. Add multi-region configuration in 
gate_hook.sh<https://review.openstack.org/438382>: 
https://review.openstack.org/#/c/438382/
2. Cross-pod VxLAN network spec<https://review.openstack.org/429155>: 
https://review.openstack.org/#/c/429155/
3. Shared VxLAN (Part4: bridge network l3)<https://review.openstack.org/425131> 
: https://review.openstack.org/#/c/425131/
4. Shared VxLAN (Part5: bulk create shadow 
port)<https://review.openstack.org/444112>: 
https://review.openstack.org/#/c/444112/
5. Update doc and add release note for 
vxlan<https://review.openstack.org/448524>: 
https://review.openstack.org/#/c/448524/
6. Support WSGI deployment for Tricircle Admin 
API(part1)<https://review.openstack.org/440175>: 
https://review.openstack.org/#/c/440175/

These two patches are nice to have in pike-1
1. Networking Qos service spec<https://review.openstack.org/417947>： 
https://review.openstack.org/#/c/417947/
2. Update 
networking-guide-single-external-network<https://review.openstack.org/446883>: 
https://review.openstack.org/#/c/446883/

Other patches will be merged in best effort. That is, once it was considered 
ready to merge, it can be merged, regardless it's in pike-1 or pike-2.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]weekly meeting of Mar. 22

[joehuang]

Hello, team,

Agenda of Mar.22 weekly meeting:

  1.  Pike-1 patches review
  2.  Pike-1 release
  3.  Demo and talk of VNF high availability across OpenStack with Tricircle in 
OPNFV Beijing summit
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.



Best Regards
Chaoyi 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

Re: [openstack-dev] [all][ptl] Action required ! - Please submit Boston Forum sessions before April 2nd

[joehuang]

Hello,

Should we submit a session for the on-boarding slot which is being arranged by 
Kendall " first come first served process" ? Does this mean that the 
on-boarding slot allocation need another round of selection, not the " first 
come first served process" ?

Best Regards
Chaoyi Huang (joehuang)


From: Emilien Macchi [emil...@redhat.com]
Sent: 22 March 2017 0:40
To: OpenStack Development Mailing List
Subject: [openstack-dev] [all][ptl] Action required ! - Please submit Boston 
Forum sessions before April 2nd

Sorry for duplicating the original e-mail from User Committee, but we
want to make sure all projects are aware about the deadline.

http://lists.openstack.org/pipermail/user-committee/2017-March/001856.html

PTLs (and everyone), please make sure topics are submitted before April 2nd.
Please let us know any question,

Thanks!
--
Emilien Macchi

__
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

__
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

Re: [openstack-dev] [ptls] Project On-Boarding Rooms

[joehuang]

Hello, Kendall,

Tricircle need a slot too, if it's not too late :).

Thanks providing the project on-boarding opportunity.

Best Regards
Chaoyi Huang (joehuang)

From: Kendall Nelson [kennelso...@gmail.com]
Sent: 16 March 2017 2:20
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [ptls] Project On-Boarding Rooms

Hello All!

As you may have seen in a previous thread [1] the Forum will offer project 
on-boarding rooms! This idea is that these rooms will provide a place for new 
contributors to a given project to find out more about the project, people, and 
code base. The slots will be spread out throughout the whole Summit and will be 
90 min long.

We have a very limited slots available for interested projects so it will be a 
first come first served process. Let me know if you are interested and I will 
reserve a slot for you if there are spots left.

- Kendall Nelson (diablo_rojo)

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html
__
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

[openstack-dev] [tricircle]weekly meeting of Mar. 15

[joehuang]

Hello, team,

New weekly meeting time slot is UTC 14:00~UTC 15:00

Agenda of Mar.15 weekly meeting:

  1.  Test coverage requirement :  https://review.openstack.org/#/c/444394/
  2.  Demo of VNF high availability across OpenStack with Tricircle in OPNFV 
Beijing summit
  3.  Pike-1 prioritized patches progress review : 
https://etherpad.openstack.org/p/tricircle-pike-design-topics
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.


Best Regards
Chaoyi 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

[openstack-dev] [tricircle]weekly meeting of Mar. 8

[joehuang]

Hello, team,

Attention please, the new weekly meeting time slot is UTC 14:00~UTC 15:00

Agenda of Mar.8 weekly meeting:

  1.  Pike-1 feature priority discussion
  2.  Pike features development
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.


Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle]reschedule the weekly meeting

[joehuang]

Hello,

The patch was merged, the weekly meeting
will be held on UTC 1400 ~ UTC 1500 every
Wednesday from this week.

Best Regards
Chaoyi Huang(joehuang)
发件人：黄朝意
收件人：openstack-dev,Morales, 
Victor,sindhu.dev...@intel.com,prince.a.owusu.boat...@intel.com
时间：2017-03-06 10:07:14
主题:RE: [openstack-dev][tricircle]reschedule the weekly meeting

Hello,

According to the poll[1], the weekly meeting will be rescheduled to UTC 1400 ~ 
UTC 1500 every Wednesday, once the patch[2] was merged, we can start the weekly 
meeting at new time slot.

[1]poll of weekly meeting time: http://doodle.com/poll/hz436r6wm99h4eka#table
[2]new weekly meeting time patch: https://review.openstack.org/#/c/441727/

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 01 March 2017 11:59
To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; 
prince.a.owusu.boat...@intel.com
Subject: RE: [openstack-dev][tricircle]reschedule the weekly meeting

Hello, team,

According to the discussion in the IRC, we'd like to move the weekly meeting 
from UTC1300 to UTC1400, there are several options for this time slot, please 
vote before next Monday, then I'll submit a patch to occupy the new time slot 
and release the old time slot.

Poll link: http://doodle.com/poll/hz436r6wm99h4eka

Note: before the new weekly meeting time is settled, we have to have weekly 
meeting at old time slot.

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 27 February 2017 21:48
To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; 
prince.a.owusu.boat...@intel.com
Subject: [openstack-dev][tricircle]reschedule the weekly meeting

Hello,

Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 
every Wednesday, it's not convenient for contributors from USA.

The available time slots could be found at
https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0

Other contributors are mostly from East Asia, the time zone is around 
UTC+8/UTC+9.

Please propose some your preferred time slots, and then let's have a poll for 
the new weekly meeting time.

Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle]reschedule the weekly meeting

[joehuang]

Hello,

According to the poll[1], the weekly meeting will be rescheduled to UTC 1400 ~ 
UTC 1500 every Wednesday, once the patch[2] was merged, we can start the weekly 
meeting at new time slot.

[1]poll of weekly meeting time: http://doodle.com/poll/hz436r6wm99h4eka#table
[2]new weekly meeting time patch: https://review.openstack.org/#/c/441727/

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 01 March 2017 11:59
To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; 
prince.a.owusu.boat...@intel.com
Subject: RE: [openstack-dev][tricircle]reschedule the weekly meeting

Hello, team,

According to the discussion in the IRC, we'd like to move the weekly meeting 
from UTC1300 to UTC1400, there are several options for this time slot, please 
vote before next Monday, then I'll submit a patch to occupy the new time slot 
and release the old time slot.

Poll link: http://doodle.com/poll/hz436r6wm99h4eka

Note: before the new weekly meeting time is settled, we have to have weekly 
meeting at old time slot.

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 27 February 2017 21:48
To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; 
prince.a.owusu.boat...@intel.com
Subject: [openstack-dev][tricircle]reschedule the weekly meeting

Hello,

Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 
every Wednesday, it's not convenient for contributors from USA.

The available time slots could be found at
https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0

Other contributors are mostly from East Asia, the time zone is around 
UTC+8/UTC+9.

Please propose some your preferred time slots, and then let's have a poll for 
the new weekly meeting time.

Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core

[joehuang]

Thank you all for your voting.

Victor, you are now included in the core team.

Best Regards
Chaoyi Huang (joehuang)



From: Yipei Niu [newy...@gmail.com]
Sent: 01 March 2017 15:06
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle 
Core

+1.


From: joehuang
Sent: 01 March 2017 11:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle 
Core

+1 from my vote.

Best Regards
Chaoyi Huang (joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 01 March 2017 11:42
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle 
Core

+1

Zhiyuan

On Wed, 1 Mar 2017 at 11:41 Devale, Sindhu 
<sindhu.dev...@intel.com<mailto:sindhu.dev...@intel.com>> wrote:
+1

Sindhu

From: joehuang <joehu...@huawei.com<mailto:joehu...@huawei.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, February 28, 2017 at 8:38 PM
To: openstack-dev 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core

Hi Team,

Victor Morales has made many review contributions[1] to Trircircle since the 
Ocata cycle, and he also created the python-tricircleclient sub-project[2]. I 
would like to nominate him to be Tricircle core reviewer. I really think his 
experience will help us substantially improve Trircircle.

 It's now time to vote :)

[1] http://stackalytics.com/report/contribution/tricircle/120
[2] https://git.openstack.org/cgit/openstack/python-tricircleclient/


Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
BR
Zhiyuan
__
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

[openstack-dev] [tricircle]weekly meeting of Mar. 1

[joehuang]

Hello, team,

Before the new weekly meeting is settled, we'll still hold the weekly meeting 
in regular time slot: UTC 13:00~UTC 14:00

Agenda of Mar. 1 weekly meeting:

  1.  Pike release schedule: https://releases.openstack.org/pike/schedule.html
  2.  Launch pad blueprint registration and spec
  3.  Pike features development
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.


Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle]reschedule the weekly meeting

[joehuang]

Hello, team,

According to the discussion in the IRC, we'd like to move the weekly meeting 
from UTC1300 to UTC1400, there are several options for this time slot, please 
vote before next Monday, then I'll submit a patch to occupy the new time slot 
and release the old time slot.

Poll link: http://doodle.com/poll/hz436r6wm99h4eka

Note: before the new weekly meeting time is settled, we have to have weekly 
meeting at old time slot.

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 27 February 2017 21:48
To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; 
prince.a.owusu.boat...@intel.com
Subject: [openstack-dev][tricircle]reschedule the weekly meeting

Hello,

Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 
every Wednesday, it's not convenient for contributors from USA.

The available time slots could be found at
https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0

Other contributors are mostly from East Asia, the time zone is around 
UTC+8/UTC+9.

Please propose some your preferred time slots, and then let's have a poll for 
the new weekly meeting time.

Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core

[joehuang]

+1 from my vote.

Best Regards
Chaoyi Huang (joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 01 March 2017 11:42
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle 
Core

+1

Zhiyuan

On Wed, 1 Mar 2017 at 11:41 Devale, Sindhu 
<sindhu.dev...@intel.com<mailto:sindhu.dev...@intel.com>> wrote:
+1

Sindhu

From: joehuang <joehu...@huawei.com<mailto:joehu...@huawei.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, February 28, 2017 at 8:38 PM
To: openstack-dev 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core

Hi Team,

Victor Morales has made many review contributions[1] to Trircircle since the 
Ocata cycle, and he also created the python-tricircleclient sub-project[2]. I 
would like to nominate him to be Tricircle core reviewer. I really think his 
experience will help us substantially improve Trircircle.

 It's now time to vote :)

[1] http://stackalytics.com/report/contribution/tricircle/120
[2] https://git.openstack.org/cgit/openstack/python-tricircleclient/


Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
BR
Zhiyuan
__
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

[openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core

[joehuang]

Hi Team,

Victor Morales has made many review contributions[1] to Trircircle since the 
Ocata cycle, and he also created the python-tricircleclient sub-project[2]. I 
would like to nominate him to be Tricircle core reviewer. I really think his 
experience will help us substantially improve Trircircle.

 It's now time to vote :)

[1] http://stackalytics.com/report/contribution/tricircle/120
[2] https://git.openstack.org/cgit/openstack/python-tricircleclient/


Best Regards
Chaoyi 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

Re: [openstack-dev] Zuul v3 - What's Coming: What to expect with the Zuul v3 Rollout

[joehuang]

So cool! Look forward to multi-node jobs as first class

Best Regards
Chaoyi Huang (joehuang)


From: Monty Taylor [mord...@inaugust.com]
Sent: 01 March 2017 7:26
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Zuul v3 - What's Coming: What to expect with the   
Zuul v3 Rollout

Hi everybody!

This content can also be found at
http://inaugust.com/posts/whats-coming-zuulv3.html - but I've pasted it
in here directly because I know that some folks don't like clicking links.

tl;dr - At last week's OpenStack PTG, the OpenStack Infra team ran the
first Zuul v3 job, so it's time to start getting everybody ready for
what's coming

**Don't Panic!** Awesome changes are coming, but you are NOT on the hook
for rewriting all of your project's gate jobs or anything crazy like
that. Now grab a seat by the fire, pour yourself a drink while I spin a
yarn about days gone by and days yet to come.

First, some background

The OpenStack Infra team has been hard at work for quite a while on a
new version of Zuul (where by 'quite some time' I mean that Jim Blair
and I had our first Zuul v3 design whiteboarding session in 2014). As
you might be able to guess given the amount of time, there are some big
things coming that will have a real and visible impact on the OpenStack
community and beyond. Since we have a running Zuul v3 now [1], it seemed
like the time to start getting folks up to speed on what to expect.

There is other deep-dive information on architecture and rationale if
you're interested[2], but for now we'll focus on what's relevant for end
users. We're also going to start sending out a bi-weekly "Status of Zuul
v3" email to the openstack-dev@lists.openstack.org mailing list ... so
stay tuned!

**Important Note** This post includes some code snippets - but v3 is
still a work in progress. We know of at least one breaking change that
is coming to the config format, so please treat this not as a tutorial,
but as a conceptual overview. Syntax is subject to change.

The Big Ticket Items

While there are a bunch of changes behind the scenes, there are a
reasonably tractable number of user-facing differences.

* Self-testing In-Repo Job Config
* Ansible Job Content
* First-class Multi-node Jobs
* Improved Job Reuse
* Support for non-OpenStack Code and Node Systems
* and Much, Much More

Self-testing In-Repo Job Config

This is probably the biggest deal. There are a lot of OpenStack Devs
(around 2k in Ocata) and a lot of repositories (1689) There a lot fewer
folks on the project-config-core team who are the ones who review all of
the job config changes (please everyone thank Andreas Jaeger next time
you see him). That's not awesome.

Self-testing in-repo job config is awesome.

Many systems out there these days have an in-repo job config system.
Travis CI has had it since day one, and Jenkins has recently added
support for a Jenkinsfile inside of git repos. With Zuul v3, we'll have
it too.

Once we roll out v3 to everyone, as a supplement to jobs defined in our
central config repositories, each project will be able to add a
zuul.yaml file to their own repo:


- job:
name: my_awesome_job
nodes:
  - name: controller
label: centos-7

- project:
name: openstack/awesome_project
check:
  jobs:
- my_awesome_job

It's a small file, but there is a lot going on, so let's unpack it.

First we define a job to run. It's named my_awesome_job and it needs one
node. That node will be named controller and will be based on the
centos-7 base node in nodepool.

In the next section, we say that we want to run that job in the check
pipeline, which in OpenStack is defined as the jobs that run when
patchsets are proposed.

And it's also self-testing!

Everyone knows the fun game of writing a patch to the test jobs, getting
it approved, then hoping it works once it starts running. With Zuul v3
in-repo jobs, if there is a change to job definitions in a proposed
patch, that patch will be tested with those changes applied. And since
it's Zuul, Depends-On footers are honored as well - so iteration on
getting a test job right becomes just like iterating on any other patch
or sequence of patches.

Ansible Job Content

The job my_awesome_job isn't very useful if it doesn't define any
content. That's done in the repo as well, in playbooks/my_awesome_job.yaml:


- hosts: controller
  tasks:
- name: Run make tests
  shell: make distcheck

As previously mentioned, the job content is now defined in Ansible
rather than using our Jenkins Job Builder tool. This playbook is going
to run a tasks on a host called controller which you may remember we
requested in the job definition. On that host, it will run make
distcheck. Pretty much anything you can do in Ansible, you can do in a
Zuul job now, and the playbooks should also be re-usable outside of a
testing context.

First Class Multi-Node Jobs

The previous example was f

[openstack-dev] [tricircle]reschedule the weekly meeting

[joehuang]

Hello,

Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 
every Wednesday, it's not convenient for contributors from USA.

The available time slots could be found at
https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0

Other contributors are mostly from East Asia, the time zone is around 
UTC+8/UTC+9.

Please propose some your preferred time slots, and then let's have a poll for 
the new weekly meeting time.

Best Regards
Chaoyi 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

Re: [openstack-dev] [keystone]PKI token VS Fernet token

[joehuang]

Thank you all very much, the less data to be replicated, the better. 

Best Regards
Chaoyi Huang (joehuang)


From: Clint Byrum [cl...@fewbar.com]
Sent: 26 February 2017 12:06
To: openstack-dev
Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token

Excerpts from Lance Bragstad's message of 2017-02-25 13:07:58 -0600:
> Since both token formats rebuild the authorization context at validation
> time, we can remove some revocation events that are no longer needed. This
> means we won't be storing as many revocation events on role removal from
> domains and projects. Instead we will only rely on the revocation API to
> invalidate tokens for cases like specific token revocation or password
> changes (the new design of validation does role assignment enforcement for
> us automatically). This should reduce the amount of data being replicated
> due to massive amounts of revocation events.
>

I didn't know that the work to make role removal non-event based was
even started much less done. Cool.

> We do still have some more work to do on this front, but I can dig into it
> and see what's left.
>

Indeed, the less revocation events, the better the Fernet story is
for scalability.

__
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

__
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

Re: [openstack-dev] [keystone]PKI token VS Fernet token

[joehuang]

Hello, Matt,

Thank you for your reply, just as what you mentioned, for the slow changed 
data, aync. replication should work. My concerns is that the impact of 
replication delay, for example (though it's quite low chance to happen):

1) Add new user/group/role in RegionOne, before the new user/group/role are 
replicated to RegionTwo, the new user begin to access RegionTwo service, then 
because the data has not arrived yet, the user's request to RegionTwo may be 
rejected for the token vaildation failed in local KeyStone.

2)In token revoke case. If we remove the user'role in RegionOne, the token in 
RegionOne will be invalid immediately, but before the remove operation 
replicated to the RegionTwo, the user can still use the token to access the 
services in RegionTwo. Although it may last in very short interval.

Is there someone can evaluate the security risk is affordable or not.

Best Regards
Chaoyi Huang (joehuang)

From: Matt Fischer [m...@mattfischer.com]
Sent: 25 February 2017 11:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token


At last, we still have one question:
For public cloud, it is very common that multi regions are deployed. And the 
distance is usually very far between the regions. So the transport delay is 
really a problem. Fernet token requires the data must be the same. Because of 
the slow connection and high time delay, in our opinion, it is unrealistic that 
let the keystones from different regions to use the same keystone datacenter. 
Any idea about this problem? Thanks.



There's nothing in Fernet tokens that would cause an issue with the 
transportation delay. You could mail the Fernet keys to each region and you're 
still fine, why? Because key rotation means that the "next key" is already in 
place on every box when you rotate keys. There is a widely held misconception 
that all keystone nodes must instantaneously sync keys in every region or it 
won't work, that is simply not true. In fact the main reason we switched to 
Fernet was to REDUCE the load on our cross-region replication. Without a 
database full of tokens to deal with, there's basically nothing to replicate as 
joe says below. User/group/role changes for us was more of a few times a day 
operation rather than getting a token which is thousands of times per second.



__
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

Re: [openstack-dev] [keystone]PKI token VS Fernet token

[joehuang]

Database async. replication across data centers should work considering that 
the data in KeyStone is not updated frequently. There is a little delay for the 
data replication, may lead to quite few requests rejection in a data center 
where the data has not arrived. But I think it's quite short and acceptable. 
For public cloud, I would like to know others thoughts on the security risk, is 
the security risk also acceptable.

Best Regards
Chaoyi Huang (joehuang)

From: 王玺源 [wangxiyuan1...@gmail.com]
Sent: 23 February 2017 21:39
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token

Thanks for all your advices and opinions.

We'll try to solve the PKI issue and hope it can come back in the future.

About the fernet token, we'll test it with the new config options and show you 
the result later. Hope it performs well.

At last, we still have one question:
For public cloud, it is very common that multi regions are deployed. And the 
distance is usually very far between the regions. So the transport delay is 
really a problem. Fernet token requires the data must be the same. Because of 
the slow connection and high time delay, in our opinion, it is unrealistic that 
let the keystones from different regions to use the same keystone datacenter. 
Any idea about this problem? Thanks.



2017-02-21 8:58 GMT-05:00 Dolph Mathews 
<dolph.math...@gmail.com<mailto:dolph.math...@gmail.com>>:
It appears that you don't have caching enabled, then. Without enabling caching, 
Fernet performance is well known to be terrible, which would explain your 
benchmark results. If you run a similar benchmark with caching, I'd be eager to 
see the new configuration and benchmark results.


On Fri, Feb 17, 2017 at 8:16 AM 王玺源 
<wangxiyuan1...@gmail.com<mailto:wangxiyuan1...@gmail.com>> wrote:
Hi Dolph:

We made the keystone.conf same with the example.

[token]

provider = fernet



[fernet_tokens]   //all configuration is default

#

# From keystone

#



# Directory containing Fernet token keys. (string value)

#key_repository = /etc/keystone/fernet-keys/



# This controls how many keys are held in rotation by keystone-manage

# fernet_rotate before they are discarded. The default value of 3 means that

# keystone will maintain one staged key, one primary key, and one secondary

# key. Increasing this value means that additional secondary keys will be kept

# in the rotation. (integer value)

# max_active_keys = 3

Dolph Mathews 
<dolph.math...@gmail.com<mailto:dolph.math...@gmail.com>>于2017年2月17日 周五上午7:22写道：
Thank you for the data and your test scripts! As Lance and Stanek already 
alluded, Fernet performance is very sensitive to keystone's configuration. Can 
your share your keystone.conf as well?

I'll also be in Atlanta and would love to talk Fernet performance, even if we 
don't have a formal time slot on the schedule.

On Wed, Feb 15, 2017 at 9:08 AM Lance Bragstad 
<lbrags...@gmail.com<mailto:lbrags...@gmail.com>> wrote:
In addition to what David said, have you played around with caching in keystone 
[0]? After the initial implementation of fernet landed, we attempted to make it 
the default token provider. We ended up reverting the default back to uuid 
because we hit several issues. Around the Liberty and Mitaka timeframe, we 
reworked the caching implementation to fix those issues and improve overall 
performance of all token formats, especially fernet.

We have a few different performance perspectives available, too. Some were run 
nearly 2 years ago [1] and some are run today [2]. Since the Newton release, 
we've made drastic improvements to the overall structure of the token provider 
[3] [4] [5]. At the very least, it should make understanding keystone's 
approach to tokens easier. Maintaining out-of-tree token providers should also 
be easier since we cleaned up a lot of the interfaces that affect developers 
maintaining their own providers.

We can try and set something up at the PTG. We are getting pretty tight for 
time slots, but I'm sure we can find some time to work through the issues 
you're seeing (also, feel free to hop into #openstack-keystone on freenode if 
you want to visit prior to the PTG).


[0] 
https://docs.openstack.org/developer/keystone/configuration.html#caching-layer
[1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
[2] https://github.com/lbragstad/keystone-performance
[3] 
https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:make-fernet-default
[4] 
https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider
[5] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/token-provider-cleanup.html

On Wed, Feb 15, 2017 at 8:44 AM, David Stanek 
<dsta...@dstanek.com<mailto:dsta...@dstanek.com>> wrote

[openstack-dev] [tricircle]weekly meeting of Feb.22

[joehuang]

Hello, team,

Let's resume weekly meeting after Ocata 3.0.0 released.

Agenda of Feb. 22 weekly meeting:

  1.  Pike features development
  2.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.


Best Regards
Chaoyi 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

[openstack-dev] [tricircle][all] guide for reading source code

[joehuang]

Hello,

For those who are interested in digging into Tricircle source code, it'll be 
good to have a step by step guide. I prepared a wiki page to navigate the 
source code of Tricircle:

https://wiki.openstack.org/wiki/TricircleHowToReadCode

It was linked to the wiki page of Tricircle: 
https://wiki.openstack.org/wiki/Tricircle

And also please feel free to update the wiki to make it being more readable and 
consistent with the code.

Should we include it into the source code repo, and maintain it at the same 
time if we update the code logic?

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]Ocata released and Pike meetup

[joehuang]

Hello,

Thanks for your great contribution, Tricircle 3.0.0 (Ocata release) has been 
released after the patch[1] was approved, the release notes could be found at 
[2].

A meetup for Pike will be held: Feb.17, UTC 1:00~8:00( UTC+8: 9:00 am~4:00 pm), 
Block G, Huawei Industrial Base, Shenzhen. Etherpad [3]:

[1] https://review.openstack.org/#/c/432166/
[2] https://docs.openstack.org/releasenotes/tricircle/
[3] https://etherpad.openstack.org/p/tricircle-pike-design-topics


Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle] python-tricircleclient repo officially created

[joehuang]

Hi, Victor,

Pretty cool! No need to type the boring curl  any more.

Best Regards
Chaoyi Huang (joehuang)

From: Morales, Victor [victor.mora...@intel.com]
Sent: 16 February 2017 0:19
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] python-tricircleclient repo officially 
created

Howdy,

I’m happy to announce that after OpenStack Governance has approved[1] and infra 
them processed the request[2],  the python-tricircleclient repository  has been 
created[3].  This client pretends to make things simpler for users who require 
multi region solutions which can be addressed by Tricircle.  Hopefully this 
project helps for the adoption and visibility of this solution.  Lastly,  this 
client is still under developing and requires all your expertise to improve it 
so feel free to add new capabilities and features that you consider necessary.

Regards,
Victor Morales
irc: electrocucaracha

[1] https://review.openstack.org/#/c/426419/
[2] https://review.openstack.org/#/c/426859/
[3] http://git.openstack.org/cgit/openstack/python-tricircleclient/
__
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

[openstack-dev] [tricircle]no weekly meeting Feb.15

[joehuang]

Hello, team,

Due to the preparation for the Ocata release and meetup on Feb.17, there is no 
weekly meeting Feb.15. Let's meet on Friday, and for those who will attend 
Atlanta PTG, you can have a F2F talk with Zhiyuan, he is the representative of 
Tricircle team.

Best Regards
Chaoyi 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

Re: [openstack-dev] [neutron]CIDR overlapping

[joehuang]

O, it's being set to "True" in devstack installation. Thanks for clarification.

Best Regards
Chaoyi Huang (joehuang)

From: Kevin Benton [ke...@benton.pub]
Sent: 14 February 2017 12:17
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]CIDR overlapping

Do you have allow_overlapping_ips set to True?

On Mon, Feb 13, 2017 at 7:56 PM, joehuang 
<joehu...@huawei.com<mailto:joehu...@huawei.com>> wrote:
Hello,

During the regression test, I find that Neutron allows CIDR overlapping in same 
project.

neutron --os-region-name RegionOne net-create dup-net1
neutron --os-region-name RegionOne net-create dup-net2
neutron --os-region-name RegionOne subnet-create dup-net1 
20.0.1.0/24<http://20.0.1.0/24>
neutron --os-region-name RegionOne subnet-create dup-net2 
20.0.1.0/24<http://20.0.1.0/24>

all commands can be executed successfully, and after then the project has two 
subnets with same CIDR: 20.0.1.0/24<http://20.0.1.0/24>

Should it be allowed? Or it's just because it's too difficult to address the 
race condition.

Best Regards
Chaoyi Huang (joehuang)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
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

[openstack-dev] [neutron]CIDR overlapping

[joehuang]

Hello,

During the regression test, I find that Neutron allows CIDR overlapping in same 
project.

neutron --os-region-name RegionOne net-create dup-net1
neutron --os-region-name RegionOne net-create dup-net2
neutron --os-region-name RegionOne subnet-create dup-net1 20.0.1.0/24
neutron --os-region-name RegionOne subnet-create dup-net2 20.0.1.0/24

all commands can be executed successfully, and after then the project has two 
subnets with same CIDR: 20.0.1.0/24

Should it be allowed? Or it's just because it's too difficult to address the 
race condition.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]schedule for Ocata release and Pike meetup/PTG

[joehuang]

Hello,team,

Thanks for your great contribution, the Ocata cycle is almost done. As what we 
discussed in weekly meeting, the schedule for Ocata release and Pike meetup/PTG 
as follows:

1.Ocata branch this Friday or early
2.  Regression test until Feb.15
3.  Ocata release Feb.16
4.  Pike meetup on Feb.17, 9:00 am~4:00 pm, G section, Huawei Industrial Base, 
Shenzhen, China for those who can't go to Atalanta.  
https://etherpad.openstack.org/p/tricircle-pike-design-topics
5. Core developer LuckyVega (Cai Zhiyuan) will be representative to attend the 
PTG at Atalanta.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]weekly meeting of Feb. 8

[joehuang]

Hello, team,

Let's resume weekly meeting after breaks for Chinese New Year.

Agenda of Feb. 8 weekly meeting:

  1.  Ocata release dates
  2.  Pike meetup before PTG: 
https://etherpad.openstack.org/p/tricircle-pike-design-topics
  3.  Representative and topics to PTG
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]Ocata branch creation

[joehuang]

Hello,

Tricircle Ocata branch will be created after these two patches are merged 
before this Friday:

1. https://review.openstack.org/#/c/429457/
2. https://review.openstack.org/#/c/424601/

Best Regards
Chaoyi 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

Re: [openstack-dev] [tricircle] Example EVPN question/use-case

[joehuang]

Hello, Curtis and Greg,

This is a quite good use case. Thanks for the sharing.

Tricircle is working on VxLAN based L2 network across OpenStack clouds for 
different backends (non-SDN, SDN, L2 GW or non L2 GW). The spec is in review: 
https://review.openstack.org/#/c/429155/.

Currently only SDN controllers which can support using BGP to exchange 
tunneling endpoint information is considered. It's worth to take this use case 
into consideration.

Please join the review and give your comments, thanks.

Best Regards
Chaoyi Huang (joehuang)


From: Curtis [serverasc...@gmail.com]
Sent: 08 February 2017 1:49
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] Example EVPN question/use-case

Hi,

I'm not sure if this is useful at all, but there is a blog post [1]
from one of the people behind the PacketPushers podcast regarding
connecting two OpenStack clouds with a EVPN. They are wondering how to
do it.

They want to connect an NSX based cloud with a OpenContrail based
cloud and do it at very high speeds. Interesting use case, real world.

Thanks,
Curtis.

[1]: 
http://etherealmind.com/help-wanted-stitching-a-federated-sdn-on-openstack-with-evpn/

__
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

__
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

Re: [openstack-dev] [tricircle]Pike design topics discussion

[joehuang]

Hello,

(Repost)

As what's discussed during the weekly meeting, let's discuss what's to do in 
Pike in etherpad next Tuesday morning UTC 1:30 am (9:30am Beijing time, 10:30 
Korea/Japan time, Monday 5:30pm PST time)

The etherpad link https://etherpad.openstack.org/p/tricircle-pike-design-topics

Please input your concerns on what to do in Pike into the etherpad, and let's 
discuss that time, the duration is around 1.5 hour.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle][ptl] PTL Candidacy for Tricircle Pike cycle

[joehuang]

Hello,

I would like to announce my self nomination for the PTL candidacy for
Tricircle Pike cycle. My name is Chaoyi Huang, IRC handle joehuang.

It's great step that the Tricircle project joined the OpenStack big-tent
ecosystem in Ocata cycle, thanks to the effort from every Tricircle
contributor, and the help from TCs/PTLs/other project contributors.

Being one big-tent project is one very important milestone to build the
open community, attract more contributors, to accelrate the Tricircle
being more and more mature. Although lots of fundatemental features
and documentations are ready[1][2], it's time for us to think about
the question: when will Tricircle will be ready for production use?

Here are some ideas to make Tricircle to reach the goal for
production deployment in Pike cycle:

* function test ready, enhance scenario test cases and code coverage.
* encourage cloud operator to try Tricircle and get feedback from
cloud operators for quality, features, and what's to improvement.
* feature compliment - shared_vxlan supported L2/L3 networking,
  advanced networking features like QoS, LBaaS, python client etc.
* performance, reliability review and enhancement as needed.
* upgradable before production.
* keep community as open as any other team, make the contribution
  in Tricircle is comfortable for anyone, attract more and more
  contributors.
* help and grow any one who wants to try PTL in Queens cycle.

Hope everyone will enjoy the contribution in Tricircle.

Thank you for your kind consideration of my candidacy.

[1]https://github.com/openstack/tricircle/tree/master/releasenotes/notes
[2]http://docs.openstack.org/developer/tricircle/


Best Regards
Chaoyi 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

[openstack-dev] [tricircle]Pike design topics discussion

[joehuang]

Hello,

As what's discussed during the weekly meeting, let's discuss what's to do in 
Pike in etherpad next Tuesday morning UTC 1:30 am (9:30am Beijing time, 10:30 
Korea/Japan time, Monday 5:30pm PST time)

The etherpad link https://etherpad.openstack.org/p/tricircle-pike-design-topics

Please input your concerns on what to do in Pike into the etherpad, and let's 
discuss that time, the duration is around 1.5 hour.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]weekly meeting of Jan.18

[joehuang]

Hello, team,

Agenda of Jan.18 weekly meeting:

  1.  Ocata release preparation
  2.  Pike planning and design topics: 
https://etherpad.openstack.org/p/tricircle-pike-design-topics
  3.  QoS and LBaaS feature support
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi 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

Re: [openstack-dev] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC

[joehuang]

Hello,

I read the meeting log and etherpad, and find that you mentioned OPNFV 
Multisite and Kingbird
project. Some comment on these multi-site related projects: OPNFV multisite, 
kingbird, tricircle.

Multisite is a requirement project in OPNFV to identify the gap and requirement 
in OpenStack to make OpenStack work for NFV multi-site cloud.

Kingbird is one sub-project of Multisite, started after gap analysis in OPNFV, 
which is aiming at centralized quota management, centralized view for 
distributed virtual resources, synchronization of ssh keys, images, flavors, 
etc. across regions in OpenStack multi-region deployments. 
Currently the project is working on key-pair sync, and 
centralized quota management feature has been implemented in OPNFV
C release. Kingbird is one major topic in OPNFV Multisite weekly meeting.

While Tricircle is one OpenStack big-tent official project, which was accepted 
in
Nov.2016, and has been narrowed its scope on networking automation across 
Neutron in
OpenStack multi-region deployments during the big-tent application. 
Tricircle has basic features of L2/L3 networking across OpenStack cloud, 
currently local 
network and shared_VLAN based L2/L3 networking are supported, and is working on
VxLAN L2 networking across Neutron, so that L2/L3 networking can also leverage 
the 
VxLAN L2 networking capability. You can refer to (review) the networking guide 
prepared:
https://review.openstack.org/#/c/420316/.

During the discussion happened in 2015 , both kingbird / tricircle are 
candidate 
solutions to address the multisite clouds, Kingbird and Tricircle 
can work together or separately in OpenStack multi-region deployment scenario, 
they are 
complimented each other now. Kingbird has no features about networking 
automation, and Tricircle has no features related to Nova/Cinder...

Tricircle is mostly visible in OpenStack community, while Kingbird is mostly 
visible in OPNFV community.

Welcome to join the meeting:
   Tricircle: IRC meeting: 
https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday 
starting from UTC 13:00
   Multisite & Kingbird: IRC: 
http://webchat.freenode.net/?channels=opnfv-meeting on every Thursday 8:00-9:00 
UTC (During winter time, means CET 9:00 AM).

Best Regards
Chaoyi Huang (joehuang)


From: Anthony SIMONET [anthony.simo...@inria.fr]
Sent: 17 January 2017 22:11
To: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org
Subject: [openstack-dev] [MassivelyDistributed] IRC Meeting tomorrow 15:00  
UTC

Hi all,

The agenda is available at:
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 
82)
Please feel free to add items to the agenda.

The meeting while take place on #openstack-meeting.

Cheers,
Anthony


__
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

Re: [openstack-dev] [tricircle]Tricircle Pike PTG

[joehuang]

Hello,

As only few of us may go to Atlanta, the etherpad has been renamed to reflect 
the fact of our "virtually distributed PTG"

https://etherpad.openstack.org/p/tricircle-pike-design-topics

We will discuss this in the weekly meeting, "What date and time and venu during 
the PTG, and meetup for contributors who can't go to Atlanta? It would be great 
to hold it at the same time, like virtually distributed PTG: some in PTG 
Atlanta, some in other place, but are inter-connectted through online etherpad."

Best Regards
Chaoyi Huang (joehuang)
____
From: joehuang
Sent: 17 January 2017 10:22
To: openstack-dev
Subject: [openstack-dev][tricircle]Tricircle Pike PTG

As the Ocata stable branch will be created and released soon, it's time to 
prepare what we need to discuss and implement in Pike release:

The etherpad has been created at: 
https://etherpad.openstack.org/p/tricircle-ptg-pike

Please feel free to add the topics, ideas into the etherpad, and let's plan the 
agenda as well.

Best Regards
Chaoyi 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

[openstack-dev] [tricircle]Tricircle Pike PTG

[joehuang]

As the Ocata stable branch will be created and released soon, it's time to 
prepare what we need to discuss and implement in Pike release:

The etherpad has been created at: 
https://etherpad.openstack.org/p/tricircle-ptg-pike

Please feel free to add the topics, ideas into the etherpad, and let's plan the 
agenda as well.

Best Regards
Chaoyi 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

Re: [openstack-dev] [release][ptl] not planning to serve as release PTL for Pike

[joehuang]

Thank you very much for your guide, Doug, this is the first time for Tricircle 
to release as one big-tent project.

Best Regards
Chaoyi Huang (joehuang)


From: Doug Hellmann [d...@doughellmann.com]
Sent: 14 January 2017 4:00
To: openstack-dev
Subject: [openstack-dev] [release][ptl] not planning to serve as release PTL
for Pike

I announced this at the release team meeting on 6 Jan, but thought
I should also post to the list as well:  I do not plan to serve as
the Release Management team PTL for the Pike release cycle.

It has been my pleasure to serve as PTL, and we've almost finished
the automation work that I envisioned when I joined the team. Now
I would like to shift my focus to some other projects within the
community.  I will still be an active member of the Release Management
team, helping with new initiatives and reviews for releases.

Doug

__
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

__
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

Re: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20

[joehuang]

Great, got it, thanks a lot

Best Regards
Chaoyi Huang (joehuang)


From: Doug Hellmann [d...@doughellmann.com]
Sent: 13 January 2017 22:55
To: openstack-dev
Subject: Re: [openstack-dev] [release] Release countdown for week R-5,  Jan 
16-20

Excerpts from joehuang's message of 2017-01-13 01:23:08 +:
> Hello, Doug,
>
> One question, according to the guide for self-branch[1], the Ocata stable 
> branch should be created for RC1 tag for projects using the 
> cycle-with-milestone release model. The date for RC1 one is Jan 30 - Feb 03 
> according to the schedule [2]. Tricircle is one big-tent project with  
> cycle-with-intermediary mode, and has dependency on stable Neutron, should 
> Tricircle Ocata stable branch be created during  Jan 30 - Feb 03 or later 
> than Feb 03? I think Neutron Ocata stable branch will be created during Jan 
> 30 - Feb 03.

You'll probably want to wait until after the Neutron stable branch has
been created. You can submit the branch request and either mark it WIP
or add a Depends-On to prevent it from merging before the neutron
request.

Doug

>
> [1]http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n66
> [2] https://releases.openstack.org/ocata/schedule.html
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: 13 January 2017 2:34
> To: openstack-dev
> Subject: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20
>
> Focus
> -
>
> Feature work and major refactoring should be starting to wrap up
> as we approach the third milestone and various feature and release
> freeze dates.
>
> The deadline for non-client library releases is Thursday 19 Jan.
> We do not grant Feature Freeze Extensions for any libraries, so
> that is a hard freeze date. Any feature work that requires updates
> to non-client libraries should be prioritized so it can be completed
> by that time.
>
> Release Tasks
> -
>
> As we did at the end of Newton, when the time comes to create
> stable/ocata branches they will be configured so that members of
> the $project-release group in gerrit have permission to approve
> patches.  This group should be a small subset of the core review
> team, aware of the priorities and criteria for patches to be approved
> as we work toward release candidates. Release liaisons should ensure
> that these groups exist in gerrit and that their membership is
> correct for this cycle.  Please coordinate with the release management
> team if you have any questions.
>
> General Notes
> -
>
> We will start the soft string freeze during R-4 (23-27 Jan). See
> https://releases.openstack.org/ocata/schedule.html#o-soft-sf for
> details
>
> The release team is now publishing the release calendar using ICS.
> Subscribe your favorite calendaring software to
> https://releases.openstack.org/schedule.ics for automatic updates.
>
> Important Dates
> ---
>
> Final release of non-client libraries: 19 Jan
>
> Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan
>
> Ocata release schedule: http://releases.openstack.org/ocata/schedule.html
>

__
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

__
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

Re: [openstack-dev] [machine learning] Question: Why there is no serious project for machine learning ?

[joehuang]

What do you mean " serious project " ?

Best Regards
Chaoyi Huang (joehuang)

From: 严超 [yanchao...@gmail.com]
Sent: 13 January 2017 15:53
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [machine learning] Question: Why there is no serious 
project for machine learning ?

Hi, all,
I'm wondering if there is a serious project for machine learning in Openstack ? 
For us to easily build a model in industrial operational level.

Thanks,
Andy Yan

__
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

Re: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20

[joehuang]

Hello, Doug,

One question, according to the guide for self-branch[1], the Ocata stable 
branch should be created for RC1 tag for projects using the 
cycle-with-milestone release model. The date for RC1 one is Jan 30 - Feb 03 
according to the schedule [2]. Tricircle is one big-tent project with  
cycle-with-intermediary mode, and has dependency on stable Neutron, should 
Tricircle Ocata stable branch be created during  Jan 30 - Feb 03 or later than 
Feb 03? I think Neutron Ocata stable branch will be created during Jan 30 - Feb 
03.

[1]http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n66
[2] https://releases.openstack.org/ocata/schedule.html

Best Regards
Chaoyi Huang (joehuang)


From: Doug Hellmann [d...@doughellmann.com]
Sent: 13 January 2017 2:34
To: openstack-dev
Subject: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20

Focus
-

Feature work and major refactoring should be starting to wrap up
as we approach the third milestone and various feature and release
freeze dates.

The deadline for non-client library releases is Thursday 19 Jan.
We do not grant Feature Freeze Extensions for any libraries, so
that is a hard freeze date. Any feature work that requires updates
to non-client libraries should be prioritized so it can be completed
by that time.

Release Tasks
-

As we did at the end of Newton, when the time comes to create
stable/ocata branches they will be configured so that members of
the $project-release group in gerrit have permission to approve
patches.  This group should be a small subset of the core review
team, aware of the priorities and criteria for patches to be approved
as we work toward release candidates. Release liaisons should ensure
that these groups exist in gerrit and that their membership is
correct for this cycle.  Please coordinate with the release management
team if you have any questions.

General Notes
-

We will start the soft string freeze during R-4 (23-27 Jan). See
https://releases.openstack.org/ocata/schedule.html#o-soft-sf for
details

The release team is now publishing the release calendar using ICS.
Subscribe your favorite calendaring software to
https://releases.openstack.org/schedule.ics for automatic updates.

Important Dates
---

Final release of non-client libraries: 19 Jan

Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan

Ocata release schedule: http://releases.openstack.org/ocata/schedule.html

__
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

__
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