Re: [openstack-dev] [TripleO] Undercloud backup and restore

[Shinobu Kinjo]

Hi Carlos,

Since I thought that that is a kind of documentation bug, I filed a
bug on this as Doc bug.
Now I'm seeing that you were assigned...

Regards,
Shinobu Kinjo


On Tue, May 30, 2017 at 5:48 PM, Carlos Camacho Gonzalez
<ccama...@redhat.com> wrote:
> Hi Shinobu,
>
> It's really helpful to get feedback from customers, please, can you give me
> details about the failures you are having?. If so, sending me directly some
> logs would be great.
>
> Thanks,
> Carlos.
>
>
> On Mon, May 29, 2017 at 9:07 AM, Shinobu Kinjo <ski...@redhat.com> wrote:
>>
>> Here is feedback from the customer.
>>
>> Following the guide [1], undercloud restoration was not succeeded.
>>
>> Swift objects could haven't been downloaded after restoration even
>> though they followed all procedures during backing up / restoring
>> their system described in [1].
>>
>> Since that, I'm not 100% sure if `tar -czf` is good enough to take a
>> backup of the system or not.
>>
>> It would be great help to do dry-run against backed up data so that we
>> can make sure that backed up data is completely fine.
>>
>> [1]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/7/html/back_up_and_restore_red_hat_enterprise_linux_openstack_platform/back_up_and_restore_the_undercloud
>>
>>
>> On Wed, May 24, 2017 at 4:26 PM, Carlos Camacho Gonzalez
>> <ccama...@redhat.com> wrote:
>> > Hey folks,
>> >
>> > Based on what we discussed yesterday in the TripleO weekly team meeting,
>> > I'll like to propose a blueprint to create 2 features, basically to
>> > backup
>> > and restore the Undercloud.
>> >
>> > I'll like to follow in the first iteration the available docs for this
>> > purpose [1][2].
>> >
>> > With the addition of backing up the config files on /etc/ specifically
>> > to be
>> > able to recover from a failed Undercloud upgrade, i.e. recover the repos
>> > info removed in [3].
>> >
>> > I'll like to target this for P as I think I have enough time for
>> > coding/testing these features.
>> >
>> > I already have created a blueprint to track this effort
>> > https://blueprints.launchpad.net/tripleo/+spec/undercloud-backup-restore
>> >
>> > What do you think about it?
>> >
>> > Thanks,
>> > Carlos.
>> >
>> > [1]:
>> >
>> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/7/html/back_up_and_restore_red_hat_enterprise_linux_openstack_platform/restore
>> >
>> > [2]:
>> >
>> > https://docs.openstack.org/developer/tripleo-docs/post_deployment/backup_restore_undercloud.html
>> >
>> > [3]:
>> >
>> > https://docs.openstack.org/developer/tripleo-docs/installation/updating.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
>
> __
> 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] [TripleO] Undercloud backup and restore

[Shinobu Kinjo]

Here is feedback from the customer.

Following the guide [1], undercloud restoration was not succeeded.

Swift objects could haven't been downloaded after restoration even
though they followed all procedures during backing up / restoring
their system described in [1].

Since that, I'm not 100% sure if `tar -czf` is good enough to take a
backup of the system or not.

It would be great help to do dry-run against backed up data so that we
can make sure that backed up data is completely fine.

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/7/html/back_up_and_restore_red_hat_enterprise_linux_openstack_platform/back_up_and_restore_the_undercloud


On Wed, May 24, 2017 at 4:26 PM, Carlos Camacho Gonzalez
 wrote:
> Hey folks,
>
> Based on what we discussed yesterday in the TripleO weekly team meeting,
> I'll like to propose a blueprint to create 2 features, basically to backup
> and restore the Undercloud.
>
> I'll like to follow in the first iteration the available docs for this
> purpose [1][2].
>
> With the addition of backing up the config files on /etc/ specifically to be
> able to recover from a failed Undercloud upgrade, i.e. recover the repos
> info removed in [3].
>
> I'll like to target this for P as I think I have enough time for
> coding/testing these features.
>
> I already have created a blueprint to track this effort
> https://blueprints.launchpad.net/tripleo/+spec/undercloud-backup-restore
>
> What do you think about it?
>
> Thanks,
> Carlos.
>
> [1]:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/7/html/back_up_and_restore_red_hat_enterprise_linux_openstack_platform/restore
>
> [2]:
> https://docs.openstack.org/developer/tripleo-docs/post_deployment/backup_restore_undercloud.html
>
> [3]:
> https://docs.openstack.org/developer/tripleo-docs/installation/updating.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] [all][tricircle][neutron]Tricircle now is one of OpenStack Big-Tent project

[Shinobu Kinjo]

On Wed, Nov 16, 2016 at 6:46 PM, joehuang <joehu...@huawei.com> wrote:

> Hi, Shinobu,
>
> Team work leads the project here :)
>

Indeed.
Let's move on

 - Shinobu


>
> Gergely also provided use cases from OPNFV:
> https://lists.opnfv.org/pipermail/opnfv-tech-discuss/
> 2016-November/013661.html
>
> Or you can directly find it here: http://artifacts.opnfv.
> org/netready/docs/requirements/index.html#georedundancy
>
>
> Best Regards
> Chaoyi Huang (joehuang)
> --
> *From:* Shinobu Kinjo [shinobu...@gmail.com]
> *Sent:* 16 November 2016 15:25
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [all][tricircle][neutron]Tricircle now is
> one of OpenStack Big-Tent project
>
> Great!
>
>  - Shinobu
>
> On Wed, Nov 16, 2016 at 3:39 PM, joehuang <joehu...@huawei.com> wrote:
>
>> Hi all,
>>
>> Tricircle was officially accepted yesterday as a big-tent project.
>>
>> The purpose of the Tricircle project is to provide networking automation
>> across Neutron in multi-region OpenStack clouds deployment.
>>
>> Use cases for the Tricircle are described in
>> https://wiki.openstack.org/wiki/Tricircle#Use_Cases.
>>
>> A brief introduction of Tricircle is provided here:
>>
>> Each OpenStack cloud includes its own Nova, Cinder and Neutron, the
>> Neutron servers in these OpenStack clouds are called local Neuron
>> servers, all these local Neutron servers will be configured with the
>> Tricircle Local Neutron Plugin. A seperate Neutron server will be
>> installed and run standalone as the coordinator of networking automation
>> across local Neutron servers, this Neutron server will be configured
>> with the Tricircle Central Neutron Plugin, and is called central
>> Neutron server.
>>
>> Leverage the Tricircle Central Neutron Plugin and the Tricircle Local
>> Neutron Plugin configured in these Neutron servers, the Tricircle can
>> ensure the IP address pool, IP/MAC address allocation and network
>> segment allocation being managed globally without conflict, and the
>> Tricircle handles tenant oriented data link layer(Layer2) or network
>> layer(Layer3) networking automation across local Neutron servers,
>> resources like VMs, bare metal or containers of the tenant can
>> communicate with each other via Layer2 or Layer3, no matter in which
>> OpenStack cloud these resources are running on.
>>
>> How to start in Tricircle:
>> 1. The best entry point for the Tricircle project is its wiki page:
>> https://wiki.openstack.org/wiki/Tricircle. Source code repository is
>> https://github.com/openstack/tricircle.
>>
>> 2. You can play it through devstack:
>> https://github.com/openstack/tricircle/blob/master/doc/sourc
>> e/multi-node-installation-devstack.rst
>>
>> 3. The design blueprint provides general overview on the ongoing
>> discussion
>> on the design:
>> https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-
>> dUOtB-ObmzJTbV1uSQ6qTsY/edit#
>>
>> We are trying to tackle common use cases and challenges in OpenStack
>> multi-region cloud area, We welcome new contributors who wish to join our
>> effort.
>>
>> We are holding a weekly IRC meeting:
>> Weekly on Wednesdays at 1300 UTC, IRC channel: #openstack-meeting
>> Project IRC channel and other resources could be found here:
>> https://wiki.openstack.org/wiki/Tricircle#Resources.
>>
>> And everyone is welcome.
>>
>> (Neutron subject is also included in the mail title, inter-communication
>> and collaboration between Neutron and Tricircle is greatly welcome)
>>
>> Best Regards
>> Chaoyi Huang (joehuang)
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [all][tricircle][neutron]Tricircle now is one of OpenStack Big-Tent project

[Shinobu Kinjo]

Great!

 - Shinobu

On Wed, Nov 16, 2016 at 3:39 PM, joehuang  wrote:

> Hi all,
>
> Tricircle was officially accepted yesterday as a big-tent project.
>
> The purpose of the Tricircle project is to provide networking automation
> across Neutron in multi-region OpenStack clouds deployment.
>
> Use cases for the Tricircle are described in
> https://wiki.openstack.org/wiki/Tricircle#Use_Cases.
>
> A brief introduction of Tricircle is provided here:
>
> Each OpenStack cloud includes its own Nova, Cinder and Neutron, the
> Neutron servers in these OpenStack clouds are called local Neuron
> servers, all these local Neutron servers will be configured with the
> Tricircle Local Neutron Plugin. A seperate Neutron server will be
> installed and run standalone as the coordinator of networking automation
> across local Neutron servers, this Neutron server will be configured
> with the Tricircle Central Neutron Plugin, and is called central
> Neutron server.
>
> Leverage the Tricircle Central Neutron Plugin and the Tricircle Local
> Neutron Plugin configured in these Neutron servers, the Tricircle can
> ensure the IP address pool, IP/MAC address allocation and network
> segment allocation being managed globally without conflict, and the
> Tricircle handles tenant oriented data link layer(Layer2) or network
> layer(Layer3) networking automation across local Neutron servers,
> resources like VMs, bare metal or containers of the tenant can
> communicate with each other via Layer2 or Layer3, no matter in which
> OpenStack cloud these resources are running on.
>
> How to start in Tricircle:
> 1. The best entry point for the Tricircle project is its wiki page:
> https://wiki.openstack.org/wiki/Tricircle. Source code repository is
> https://github.com/openstack/tricircle.
>
> 2. You can play it through devstack:
> https://github.com/openstack/tricircle/blob/master/doc/source/multi-node-
> installation-devstack.rst
>
> 3. The design blueprint provides general overview on the ongoing discussion
> on the design:
> https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-
> ObmzJTbV1uSQ6qTsY/edit#
>
> We are trying to tackle common use cases and challenges in OpenStack
> multi-region cloud area, We welcome new contributors who wish to join our
> effort.
>
> We are holding a weekly IRC meeting:
> Weekly on Wednesdays at 1300 UTC, IRC channel: #openstack-meeting
> Project IRC channel and other resources could be found here:
> https://wiki.openstack.org/wiki/Tricircle#Resources.
>
> And everyone is welcome.
>
> (Neutron subject is also included in the mail title, inter-communication
> and collaboration between Neutron and Tricircle is greatly welcome)
>
> 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 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] [tripleo] Default the HA scenario to Ceph

[Shinobu Kinjo]

On Wed, Oct 12, 2016 at 9:59 PM, Giulio Fidente  wrote:

> On 10/12/2016 02:29 PM, Thiago da Silva wrote:
>
>>
>>
>> On 10/12/2016 07:10 AM, Giulio Fidente wrote:
>>
>>> hi,
>>>
>>> we introduced support for the deployment of Ceph in the liberty
>>> release so that it could optionally be used as backend for one or more
>>> of Cinder, Glance, Nova and more recently Gnocchi.
>>>
>>> We used to deploy Ceph MONs on the controller nodes and Ceph OSDs on
>>> dedicated ceph-storage nodes so a deployment of OpenStack with Ceph
>>> would need at least 1 more additional node to host a Ceph OSD.
>>>
>>> In our HA scenario the storage backends are configured as follows:
>>>
>>> Glance -> Swift
>>> Nova (ephemeral) -> Local
>>> Cinder (persistent) -> LVM (on controllers)
>>> Gnocchi -> Swift
>>>
>>> The downside of the above configuration is that Cinder volumes can not
>>> be replicated across the controller nodes and become unavailable if a
>>> controller fails, while production environments generally expect
>>> persistent storage to be highly available. Cinder volumes instead
>>> could even get lost completely in case of a permanent failure of a
>>> controller.
>>>
>>> With the Newton release and the composable roles we can now deploy
>>> Ceph OSDs on the compute nodes, removing the requirement we had for an
>>> additional node to host a Ceph OSD.
>>>
>>> I would like to ask for some feedback on the possibility of deploying
>>> Ceph by default in the HA scenario and use it as backend for Cinder.
>>>
>>> Also using Swift as backend for Glance and Gnocchi is enough to cover
>>> the availability issue for the data, but it also means we're storing
>>> that data on the controller nodes which might or might not be wanted;
>>> I don't see a strong reason for defaulting them to Ceph, but it might
>>> make more sense when Ceph is available; feedback about this would be
>>> appreciated as well.
>>>
>> I think it would be important to take into account the recently created
>> guiding principles [0]:
>>
>> "While the software that OpenStack produces has well defined and
>> documented APIs, the primary output of OpenStack is software, not API
>> definitions. We expect people who say they run “OpenStack” to run the
>> software produced by and in the community, rather than alternative
>> implementations of the API."
>>
>> In the case of Cinder, I think the situation is a bit muddy as LVM is
>> not openstack software, and my limited understanding is that LVM is used
>> as a reference implementation, but in the case of Swift, I think RGW
>> would be considered an 'alternative implementation of the API'.
>>
>> Thiago
>>
>
> hi Thiago,
>
> sorry if it wasn't clear in my original message but I did not suggest to
> replace Swift with Ceph RGW.
>
> Swift would continue to be deployed by default, not RGW.
>

RGW utilizes Swift. So Swift has to be there anyway -;


>
> The feedback I'm asking for is about storing (or not) the Cinder volumes
> in Ceph for the HA scenario by default, and also store the Glance images
> and Gnocchi metrics in Ceph or rather keep that data in Swift.
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com
__
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]freeze date and patches to be merged for Newton release

[Shinobu Kinjo]

Please add 1 line above description of each patch.

MUST TO HAVE
or
GOOD TO HAVE

e.g.,
https://review.openstack.org/#/c/356187/

 MUST TO HAVE
 The framework of dynamic pod binding.

So that we can prioritize clearly and easily.

Ideally we should have made priority for each *MUST* case.

Regards,
Shinobu


On Thu, Sep 22, 2016 at 10:42 AM, joehuang  wrote:

> Hello,
>
> During yesterday's weekly meeting, patches were identified for these must
> be merged before freeze date for Newton release:
>
> Freeze date: Sept.30, 2016
>
> Must to have: must be merged before Sept.30, basic feature for Tricircle
> Newton release
> https://review.openstack.org/#/c/356187/ framework for dynamic pod binding
> https://review.openstack.org/354604 floating ip deletion
> https://review.openstack.org/355847 subnet deletion
> https://review.openstack.org/360848 router deletion
> https://review.openstack.org/#/c/366606/ server action part1
> https://review.openstack.org/#/c/369958/ server action part2
> https://review.openstack.org/#/c/372414/ installation update
> https://review.openstack.org/#/c/326192/ volume detach
>
> Good to have: best effort
> https://review.openstack.org/#/c/323687/ add resource_affinity_tag
> https://review.openstack.org/368529 spec for local plugin
> https://review.openstack.org/#/c/359561/
> others not mentioned here
>
> You can also refer to https://etherpad.openstack.
> org/p/TricircleNewtonFreeze  for the discussion log.
>
> Let's update patch and review in time to ensure "Must to have" get merged
> before freeze date Sept.30.
>
> Thank you for your great effort. The Newton branch will be created at UTC
> 9:00AM Sept.30.
>
> 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
>
>


-- 
Email:
shin...@linux.com
shin...@redhat.com
__
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] [horizon] Browser Support

[Shinobu Kinjo]

Thanks, guys.

 - Shinobu

On Tue, Sep 20, 2016 at 5:46 PM, Rob Cresswell
<robert.cressw...@outlook.com> wrote:
> Agreed. I've created a bug here:
> https://bugs.launchpad.net/horizon/+bug/1625514
>
> Rob
>
> On 20 September 2016 at 09:40, amot...@gmail.com <amot...@gmail.com> wrote:
>>
>> I think It is time to merge the wiki into horizon devref.
>> It is not a good situation that we have two contents.
>>
>> 2016-09-20 17:01 GMT+09:00 Rob Cresswell <robert.cressw...@outlook.com>:
>> > As you've noticed, this doc isn't updated currently. The current
>> > browsers
>> > supported are listed here:
>> > http://docs.openstack.org/developer/horizon/faq.html (Stable Firefox and
>> > Chrome, and IE 11+)
>> >
>> > Rob
>> >
>> > On 20 September 2016 at 08:23, Shinobu Kinjo <ski...@redhat.com> wrote:
>> >>
>> >> There are ambiguous definitions like:
>> >>
>> >> IE 11 Good?
>> >>
>> >> Can we define this description as specific as possible?
>> >>
>> >>
>> >> On Tue, Sep 20, 2016 at 4:15 PM, Radomir Dopieralski
>> >> <openst...@sheep.art.pl> wrote:
>> >> > On Tue, Sep 20, 2016 at 3:53 AM, Jason Rist <jr...@redhat.com> wrote:
>> >> >>
>> >> >> This page hasn't been updated for a while - does anyone know the
>> >> >> latest?
>> >> >>
>> >> >> https://wiki.openstack.org/wiki/Horizon/BrowserSupport
>> >> >>
>> >> >
>> >> > As far as I know, there were no changes to the officially supported
>> >> > browser
>> >> > versions.
>> >> >
>> >> > The support for very old browsers (like msie 6) is going to
>> >> > deteriorate
>> >> > slowly, as the libraries that we use for styles and js drop support
>> >> > for
>> >> > them.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > __
>> >> > 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
>
>
>
> __
> 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] [horizon] Browser Support

[Shinobu Kinjo]

There are ambiguous definitions like:

IE 11 Good?

Can we define this description as specific as possible?


On Tue, Sep 20, 2016 at 4:15 PM, Radomir Dopieralski
 wrote:
> On Tue, Sep 20, 2016 at 3:53 AM, Jason Rist  wrote:
>>
>> This page hasn't been updated for a while - does anyone know the latest?
>>
>> https://wiki.openstack.org/wiki/Horizon/BrowserSupport
>>
>
> As far as I know, there were no changes to the officially supported browser
> versions.
>
> The support for very old browsers (like msie 6) is going to deteriorate
> slowly, as the libraries that we use for styles and js drop support for
> them.
>
>
> __
> 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]freeze date and tricircle splitting

[Shinobu Kinjo]

This announcement should have been first to avoid any unnecessary work -;

On Tue, Sep 20, 2016 at 12:51 PM, joehuang  wrote:
> Hello, as the Trio2o repository has been established, it's time for us to
> discuss the freeze date and tagging(newton branch) for the last release of
> Tricircle with gateway function.
>
> The freeze date is the gate for patches to be merged before tagging(newton
> branch). If a patch can't finish review process before the freeze date, and
> not able to be merged in Tricircle, then it's suggested to be handled like
> this:
>
> 1. If it's networking automation related patch, continue the review process
> in Tricircle after tagging(newton branch), will be merged in Tricircle trunk
> in the future .
>
> 2. If it's gateway related patch, abandon the patch, re-submit the patch in
> Trio2o.
>
> 3. If it's patch about pod management, for it's common feature, so continue
> the review process in tricircle  after tagging(newton branch) , and submit a
> new patch for this feature in Trio2o separately.
>
> Exception request after freeze date, before tagging(newton branch): If there
> is some patch must be merged before the tagging(newton branch), then need to
> send the exception request in the mail-list for the patch, and approved by
> PTL.
>
> That means we need to define a deadline for patches to be merged in
> Tricircle before tagging(newton branch), and define the scope of patches
> wish to be merged in Trcircle before splitting.
>
> Your thoughts, proposal for the freeze date and patches to be merged?
>
> (As the old thread containing both Trio2o and Tricircle in the subject, not
> good to follow, so a new thread is started)
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: joehuang
> Sent: 18 September 2016 16:34
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and
> tricircle splitting
>
> Thank you for your comment, Zhiyuan.
>
> For pod management, because these two projects need to run independently, I
> think submit patches separately as needed may be a better choice.
>
> Best Regards
> Chaoyi Huang(joehuang)
> 
> From: Vega Cai [luckyveg...@gmail.com]
> Sent: 18 September 2016 16:27
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and
> tricircle splitting
>
> +1 for the proposal. What about the codes for Pod operation? It seems that
> both Tricircle and Trio2o need these codes. We submit patches to these two
> projects separately?
>
> Zhiyuan
>
> joehuang 于2016年9月18日周日 下午4:17写道：
>>
>> hello, team,
>>
>> Trio2o git repository is ready now: https://github.com/openstack/trio2o
>>
>> The repository inherited all files and commit messages from Tricircle.
>>
>> It's now the time start to do the tricircle splitting: a blue print is
>> registere for Tricircle cleaning:
>> https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron.There
>> are lots of documentation work to do. Please review these doc in the BP,
>> thanks.
>>
>> There are some proposal for patches during the splitting:
>>
>> 1. For patch which is already in review status, let's review it in
>> Tricircle (no matter it's for Trio2o or Tricircle), after it's get merged,
>> then port it to Trio2o. After all patches get merged, let's have a last tag
>> for Tricircle to cover both gateway and networking automation function. Then
>> the cleaning will be done in Tricircle to make Tricircle as a project for
>> networking automation only
>> 2. For new patch which is only applicable to Trio2o, I propose that we
>> submit such patches in Trio2o only, no need to submit in Tricircle.
>>
>> Would like to know your thoughts on the splitting.
>>
>> 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 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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]a chance to meet all TCs for Tricircle big-tent application in Barcelona summit?

[Shinobu Kinjo]

On Mon, Sep 19, 2016 at 6:22 PM, joehuang  wrote:
> Hello, all TCs,
>
> Understand that you will be quite busy in Barcelona summit, all TCs will be
> shown in the Barcelona summit, and meet together(usually, I assumed). So is
> it possible to have a chance to meet all TCs there for Tricircle big-tent
> application https://review.openstack.org/#/c/338796/ ? F2f talk to answer
> the concerns may help the understanding and decision.
>
> The splitting and cleaning of Tricircle hopefully could be finished before
> Barcelona summit.
>
> Although Tricircle splitting and cleaning is WIP, some draft materials were
> prepared for the understanding on Tricircle and  open comments, contribution
> etc:
>
> 1. Tricircle focuses on networking automation across
> Neutron:https://docs.google.com/presentation/d/1Zkoi4vMOGN713Vv_YO0GP6YLyjLpQ7fRbHlirpq6ZK4/
>
> 2. Tricircle design blueprint
> update:https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-ObmzJTbV1uSQ6qTsY/
>
> 3. Tricircle wiki update: https://wiki.openstack.org/wiki/Tricircle
>
> (Caution: the git repo. of Tricircle will be purified, nova_apigw and
> cinder_apigw will be removed from the repo. soon
> https://github.com/openstack/tricircle/ , the description will also be
> updated)

Just removing 2 functionality from repo probably would be fine.

But what you should clarify more is:

  - How we should take care of existing commitments for those 2 functionality.
   Some people still have been making patches for them.

And what I'm really confused with is that, even you're telling that we
will have removed those two from repo, you're still talking about
those two in different thread with no clarification.

That should be stopped now, if we will really go with what you
proposed above. Probably it's better not to say Tricircle any more to
avoid any confusion.

You should make a progress more *carefully* because project is being
changed with contributors who have been submitting patches eve now.

Regards,
Shinobu

>
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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]PTL candidacy

[Shinobu Kinjo]

No objection.
I really appreciate your great leadership.

Cheers,
Shinobu

On Sun, Sep 18, 2016 at 6:26 PM, joehuang  wrote:
> Hello,
>
> This is Chaoyi Huang(nick: joehuang), I would like to nominate myself as
> Tricircle PTL in Ocata release.
>
> Before look forward to what to do in Ocata release, I want to have a short
> look back what's Tricircle has done in Newton release. The objectives and
> our progress in Newton release are:
>
> * Cross OpenStack L2 networking: "local network" and "shared vlan" supported
> in Tricircle for L2/L3 networking functionalities, this is a great
> fundamental for our Newton release.
> * Dynamic pod binding: the framework is in review.
> * Tempest and basic VM/Volume operation: tempest based check and gate test
> has been integrated into the process, support basic features tempest
> * Keep Tricircle follow OpenStack open source development guideline to make
> Tricircle project as open as any other OpenStack project, so that more and
> more talents would like to join and contribute in Tricircle, and target at
> being a big tent project of OpenStack, being member of OpenStack eco-system
> and help the eco-system to address the problem domain in multi-OpenStack
> cloud, no matter it's in one site or multi-site: now Tricircle is applying
> big-tent application, and the splitting is ongoing, and glad to see more and
> more contributors join Tricricle community.
>
>
> This is great progress for Tricricle based on every contributor's great
> effort.
>
> As the Tricircle will be splitted and dedicate for cross Neutron networking
> automation, my vision for Tricircle Ocata will based on our basis in Newton
> release and what we discussed in these weeks:
>
> * Ensure the Tricircle splitting smoothly with quality.
> * Continue cross OpenStack L2/L3 networking, and work with upstream projects
> like Neutron, L2GW
> * Being better citizen in OpenStack, continue the big-tent application, and
> collaboration with other projects
> * enhance the installation method and make it easier to play Tricircle, so
> that more contributors would like to join Tricircle.
> * Start advance networking service support in Ocata for Tricircle if
> possible
>
> Since the Tricircle project tries to address very fundamental cross Neutron
> networking automation chanllenges, it's exciting to work and contribute in
> such a project, let's enjoy the journey.
>
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] your proposal for the name of networking and gateway sub-projects

[Shinobu Kinjo]

I prefer this.

4. Trio2o, 3 votes

But I would like to make sure what this actually means more specifically.
How can we define this word?

openstack-to-openstack

Cheers,
Shinobu



On Tue, Sep 6, 2016 at 9:01 PM, liukun  wrote:
> Triangel +1
>
> At 2016-09-06 16:27:22, "joehuang"  wrote:
>
> Hello,
>
> After the discussion in the #openstack-tricircle channel and mail-list, 4
> candidates
> available now, please vote the name for the new sub-project for api-gateway
> functionality:
>
> 1. Triangel, 2 votes
>   The Triangel are dolls that bring luck. Found some meaning may not all
> people like it, Zhiyuan proposed another candidate "Trio2o"
> 2. Tridonut, 0 votes
>   Three Donuts. Delicious food, often buy 3 get 1 free.
> 3. Trifennel, 2 votes
>   Three Fennel. Fennel is highly prized for its licorice-like flavor and
>   the myriad of health benefits it provides
> 4. Trio2o, 3 votes
>   openstack-to-openstack
>
> Some team members just joined the mail-list, so please continue to vote for
> the api-gateway project name.
>
> Best Regards
> Chaoyi Huang(joehuang)
>
> 
> From: joehuang
> Sent: 06 September 2016 9:04
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [tricircle] your proposal for the name of
> networking and gateway sub-projects
>
> I also like trio2o, +1 for trio2o.
>
> 
> From: xiulin yin [yinxiuli...@gmail.com]
> Sent: 05 September 2016 18:44
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] your proposal for the name of
> networking and gateway sub-projects
>
> trio2o +1， Accurately express the function of the project.
>
> 2016-09-05 17:34 GMT+08:00 Vega Cai :
>>
>> Oops, sorry for "triangel". Then what about "trio2o",
>> openstack-to-openstack
>>
>> Zhiyuan
>>
>> Yipei Niu 于2016年9月5日周一 上午11:22写道：
>>>
>>> Trifennel +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
>>
>>
>> __
>> 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
>>
> From: Dongfeng Huang [dfhua...@gmail.com]
> Sent: 05 September 2016 20:17
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tricircle]your proposal for the name of
> networking and gateway sub-projects (joehuang)
>
>  Trifennel +1
>
>
>
>
>
>
> __
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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]your proposal for the name of networking and gateway sub-projects

[Shinobu Kinjo]

On Mon, Sep 5, 2016 at 10:35 AM, joehuang <joehu...@huawei.com> wrote:
> Hello,
>
> You can search "Triangel doll" from google: 
> https://www.google.com.hk/?gws_rd=ssl#safe=strict=triangel+doll
>
> But I also found a definition in 
> http://zh.urbandictionary.com/define.php?term=Triangel, so I don't know it's 
> a good candidate or not.

O.k, interesting enough.

Cheers,
Shinobu

>
> Please vote or recommend a new candidate. Thanks
>
> Best Regards
> Chaoyi Huang(joehuang)
>
> ____
> From: Shinobu Kinjo [shinobu...@gmail.com]
> Sent: 05 September 2016 6:21
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle]your proposal for the name of 
> networking and gateway sub-projects
>
> Be more careful before emailing the list.
>
>   Triangel is not true.
>
>   Triangle is true.
>
> If there is a word expressed by Triangel, please point it out to me.
>
> Cheers,
> Shinobu
>
>
> On Sun, Sep 4, 2016 at 10:49 PM, Vega Cai <luckyveg...@gmail.com> wrote:
>> +1 for Triangel
>>
>> On 2 September 2016 at 17:34, joehuang <joehu...@huawei.com> wrote:
>>>
>>> After the discussion in the #openstack-tricircle channel, 3 candidates
>>> available now, please vote the name for the new sub-project for api-gateway
>>> functionality:
>>>
>>> 1. Triangel
>>> The Triangel are dolls that bring luck
>>> 2. Tridonut
>>> Three Donuts. Delicious food, often buy 3 get 1 free.
>>> 3. Trifennel
>>> Three Fennel. Fennel is highly prized for its licorice-like flavor and
>>> the myriad of health benefits it provides
>>>
>>> Best Regards
>>> Chaoyi Huang(joehuang)
>>>
>>>
>>> From: joehuang
>>> Sent: 02 September 2016 11:19
>>> To: openstack-dev; mord...@inaugust.com
>>> Subject: RE: [openstack-dev][tricircle]your proposal for the name of
>>> networking and gateway sub-projects
>>>
>>> I have some rough ideas about the name of gateway sub-project, for
>>> example, triangle, tridonut, tricookie etc, so that we can see that
>>> Tricircle and the new sub-project are like sibling in OpenStack. And they
>>> often will be listed closely in order.
>>>
>>> Your thoughts?
>>>
>>> Best Regards
>>> Chaoyi Huang(joehuang)
>>>
>>> 
>>> From: joehuang
>>> Sent: 02 September 2016 10:22
>>> To: openstack-dev; mord...@inaugust.com
>>> Subject: [openstack-dev][tricircle]your proposal for the name of
>>> networking and gateway sub-projects
>>>
>>> Hello,
>>>
>>> If we want to divide Tricircle into two sub-projects, your proposals for
>>> the name of sub-projects are welcome.
>>>
>>> Because the Tricircle is applying big-tent application, and the networking
>>> part will be remained in the Tricircle repository, and continue the big-tent
>>> application. So if we change the networking sub-project name from
>>> "Tricircle" to another one, we have to update a lots of places: from infra,
>>> to source code, to documentation, google docs, to wiki, etc, it's a huge
>>> work, and history background will also be lost, from this point of view, I
>>> proposal to remain current Tricircle repository name, but shrink the
>>> Tricircle scope to cross Neutron networking automation.
>>>
>>> And for gateway part, a new repository is required, new project name is
>>> more applicable, this is just my thoughts, would like to know your
>>> proposals.
>>>
>>> Best Regards
>>> Chaoyi Huang(joehuang)
>>>
>>> 
>>> From: joehuang
>>> Sent: 01 September 2016 9:02
>>> To: Monty Taylor; openstack-dev
>>> Subject: RE: [openstack-dev][tricircle]How to address TCs concerns in
>>> Tricircle big-tent application
>>>
>>> Hello, Monty,
>>>
>>> Thank you very much for your guide and encouragement, then let's move on
>>> this direction.
>>>
>>> Best regards
>>> Chaoyi Huang (joehuang)
>>> 
>>> From: Monty Taylor [mord...@inaugust.com]
>>> Sent: 01 September 2016 0:37
>>> To: joehuang; openstack-dev
>>> Subject: Re: [openstack-dev][tricircle]How to address TCs concerns in
>>> Tricircle big-tent application
>&

Re: [openstack-dev] [tricircle]your proposal for the name of networking and gateway sub-projects

[Shinobu Kinjo]

Be more careful before emailing the list.

  Triangel is not true.

  Triangle is true.

If there is a word expressed by Triangel, please point it out to me.

Cheers,
Shinobu


On Sun, Sep 4, 2016 at 10:49 PM, Vega Cai  wrote:
> +1 for Triangel
>
> On 2 September 2016 at 17:34, joehuang  wrote:
>>
>> After the discussion in the #openstack-tricircle channel, 3 candidates
>> available now, please vote the name for the new sub-project for api-gateway
>> functionality:
>>
>> 1. Triangel
>> The Triangel are dolls that bring luck
>> 2. Tridonut
>> Three Donuts. Delicious food, often buy 3 get 1 free.
>> 3. Trifennel
>> Three Fennel. Fennel is highly prized for its licorice-like flavor and
>> the myriad of health benefits it provides
>>
>> Best Regards
>> Chaoyi Huang(joehuang)
>>
>>
>> From: joehuang
>> Sent: 02 September 2016 11:19
>> To: openstack-dev; mord...@inaugust.com
>> Subject: RE: [openstack-dev][tricircle]your proposal for the name of
>> networking and gateway sub-projects
>>
>> I have some rough ideas about the name of gateway sub-project, for
>> example, triangle, tridonut, tricookie etc, so that we can see that
>> Tricircle and the new sub-project are like sibling in OpenStack. And they
>> often will be listed closely in order.
>>
>> Your thoughts?
>>
>> Best Regards
>> Chaoyi Huang(joehuang)
>>
>> 
>> From: joehuang
>> Sent: 02 September 2016 10:22
>> To: openstack-dev; mord...@inaugust.com
>> Subject: [openstack-dev][tricircle]your proposal for the name of
>> networking and gateway sub-projects
>>
>> Hello,
>>
>> If we want to divide Tricircle into two sub-projects, your proposals for
>> the name of sub-projects are welcome.
>>
>> Because the Tricircle is applying big-tent application, and the networking
>> part will be remained in the Tricircle repository, and continue the big-tent
>> application. So if we change the networking sub-project name from
>> "Tricircle" to another one, we have to update a lots of places: from infra,
>> to source code, to documentation, google docs, to wiki, etc, it's a huge
>> work, and history background will also be lost, from this point of view, I
>> proposal to remain current Tricircle repository name, but shrink the
>> Tricircle scope to cross Neutron networking automation.
>>
>> And for gateway part, a new repository is required, new project name is
>> more applicable, this is just my thoughts, would like to know your
>> proposals.
>>
>> Best Regards
>> Chaoyi Huang(joehuang)
>>
>> 
>> From: joehuang
>> Sent: 01 September 2016 9:02
>> To: Monty Taylor; openstack-dev
>> Subject: RE: [openstack-dev][tricircle]How to address TCs concerns in
>> Tricircle big-tent application
>>
>> Hello, Monty,
>>
>> Thank you very much for your guide and encouragement, then let's move on
>> this direction.
>>
>> Best regards
>> Chaoyi Huang (joehuang)
>> 
>> From: Monty Taylor [mord...@inaugust.com]
>> Sent: 01 September 2016 0:37
>> To: joehuang; openstack-dev
>> Subject: Re: [openstack-dev][tricircle]How to address TCs concerns in
>> Tricircle big-tent application
>>
>> On 08/31/2016 02:16 AM, joehuang wrote:
>> > Hello, team,
>> >
>> > During last weekly meeting, we discussed how to address TCs concerns in
>> > Tricircle big-tent application. After the weekly meeting, the proposal
>> > was co-prepared by our
>> > contributors:
>> > https://docs.google.com/presentation/d/1kpVo5rsL6p_rq9TvkuczjommJSsisDiKJiurbhaQg7E
>> >
>> > The more doable way is to divide Tricircle into two independent and
>> > decoupled projects, only one of the projects which deal with networking
>> > automation will try to become an big-tent project, And Nova/Cinder
>> > API-GW will be removed from the scope of big-tent project application,
>> > and put them into another project:
>> >
>> > *TricircleNetworking:* Dedicated for cross Neutron networking automation
>> > in multi-region OpenStack deployment, run without or with
>> > TricircleGateway. Try to become big-tent project in the current
>> > application of https://review.openstack.org/#/c/338796/.
>>
>> Great idea.
>>
>> > *TricircleGateway:* Dedicated to provide API gateway for those who need
>> > single Nova/Cinder API endpoint in multi-region OpenStack deployment,
>> > run without or with TricircleNetworking. Live as non-big-tent,
>> > non-offical-openstack project, just like Tricircle toady’s status. And
>> > not pursue big-tent only if the consensus can be achieved in OpenStack
>> > community, including Arch WG and TCs, then decide how to get it on board
>> > in OpenStack. A new repository is needed to be applied for this project.
>> >
>> >
>> > And consider to remove some overlapping implementation in Nova/Cinder
>> > API-GW for global objects like flavor, volume type, we can configure one
>> > region as master region, all global objects like flavor, volume type,
>> > server group, 

[openstack-dev] [tricircle] A new contributor

[Shinobu Kinjo]

Hi Team,

Please welcome a new contributor (CCed) for the Tricircle project.

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.com
__
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/logo for Tricircle

[Shinobu Kinjo]

On Mon, Jul 18, 2016 at 1:58 PM, Zhipeng Huang 
wrote:

> Mascot does not necessarily need to reflect the team name, although would
> definitely be better if it does.
>

O.k, I am now pretty much wondering

  - Which is *true*
  - What is *necessary*
and
  - What are you, guys talking about here? I do know we are talking about
*mascot* here though.

Cheers,
Shinobu


>
> We could think outside the box, how about just use panda ? :P BTW Panda
> has three black circles on the face (eyes and nose) :P
>
> http://www.edinburghzoo.org.uk/media/3455/ezpanda.png
>
> On Mon, Jul 18, 2016 at 10:38 AM, joehuang  wrote:
>
>> Hello,
>>
>>
>>
>> According to the community proposal, let's select the Tricircle mascot
>> too?
>>
>>
>>
>> The project name of "Tricircle" itself is comming from a fractal:
>> https://www.google.com/search?q=tricircle+fractal=2=1366=667=isch=u=univ=X=0ahUKEwiut7_o-PvNAhXBj5QKHd1EB5AQsAQIUw=1
>>
>>
>>
>> So how do you think about to have a fractal animal or plant as our
>> project's mascot? I have created an etherpad for us to list the mascot and
>> vote, the top three will be selected before July 26, and send it to  Heidi
>> Joy Tretheway  on July 27.
>>
>>
>>
>> Etherpad for macot nomination and vote :
>> https://etherpad.openstack.org/p/TricircleMascotVote
>>
>>
>>
>> I just listed several items there.
>>
>>
>>
>> Best Regards
>>
>> Chaoyi Huang ( joehuang )
>>
>>
>> --
>> *From:* Heidi Joy Tretheway [heidi...@openstack.org]
>> *Sent:* 11 July 2016 23:00
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* [openstack-dev] Mascot/logo for your project
>>
>> The Foundation would like to help promote OpenStack projects in the big
>> tent with branding and marketing services. The idea is to create a family
>> of logos for OpenStack projects that are unique, yet immediately
>> identifiable as part of OpenStack. We’ll be using these logos to promote
>> your project on the OpenStack website, at the Summit and in marketing
>> materials.
>>
>> We’re asking project teams to choose a mascot to represent as their logo. 
>> Your
>> team can select your own mascot, and then we’ll have an illustrator create
>> the logo for you (and we also plan to print some special collateral for
>> your team in Barcelona).
>>
>> If your team already has a logo based on a mascot from nature, you’ll
>> have first priority to keep that mascot, and the illustrator will restyle
>> it to be consistent with the other projects. If you have a logo that
>> doesn’t have a mascot from nature, we encourage your team to choose a
>> mascot.
>>
>> Here’s an FAQ and examples of what the logos can look like:
>> http://www.openstack.org/project-mascots
>> We’ve also recorded a quick video with an overview of the project:
>> https://youtu.be/LOdsuNr2T-o
>>
>> You can get in touch with your PTL to participate in the logo choice
>> discussion. If you have more questions, I’m happy to help. :-)
>>
>> Cheers,
>> Heidi Joy
>>
>> __
>> Heidi Joy Tretheway
>> Senior Marketing Manager, OpenStack Foundation
>> 503 816 9769  |  skype: heidi.tretheway
>>
>>
>>
>>
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> 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
>
>


-- 
Email:
shin...@linux.com
shin...@redhat.com
__
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]

[Shinobu Kinjo]

# This email is true to reply.
Would you attach local.conf you're using?

On Mon, Jul 4, 2016 at 4:10 PM, Luck Dog  wrote:

> Hello everyone,
>
> I am trying to run DevStack on Ubuntu 14.04 in a single VirtualBox. An
> error turns up  before it successfully starts. Yesterday I clarified this
> question not  clearly enough，so I make a supplication for it. My steps are:
> 1), Git clone DevStack,
> 2), Copy devstack/local.conf.sample to DevStack folder and rename it to
> local.conf.
>
> the finished steps before the error turns up are listed as follows:
>
> 2016-06-29 09:11:53.081 | stack.sh log
> /opt/stack/logs/stack.sh.log.2016-06-29-171152
> 2016-06-29 09:12:19.797 | Installing package prerequisites
> 2016-06-29 09:15:27.224 | Installing OpenStack project source
> 2016-06-29 09:24:43.323 | Installing Tricircle
> 2016-06-29 09:24:55.979 | Starting RabbitMQ
> 2016-06-29 09:25:00.731 | Configuring and starting MySQL
> 2016-06-29 09:25:20.143 | Starting Keystone
> 2016-06-29 09:43:18.591 | Configuring Glance
> 2016-06-29 09:43:59.667 | Configuring Neutron
> 2016-06-29 09:46:30.646 | Configuring Cinder
> 2016-06-29 09:46:54.719 | Configuring Nova
> 2016-06-29 09:48:23.175 | Configuring Tricircle
> 2016-06-29 09:51:24.143 | Starting Glance
> 2016-06-29 09:52:11.133 | Uploading images
> 2016-06-29 09:52:45.460 | Starting Nova API
> 2016-06-29 09:53:27.511 | Starting Neutron
> 2016-06-29 09:54:21.476 | Creating initial neutron network elements
>
> The last errors when it stops running are:
>
> Request body: {u'network': {u'router:external': True,
> u'provider:network_type': u'flat', u'name': u'public',
> u'provider:physical_network': u'public', u'admin_state_up': True}}^[[00m
> ^[[00;33mfrom (pid=29980) prepare_request_body
> /opt/stack/neutron/neutron/api/v2/base.py:674^[[00m
> 2016-06-29 17:56:04.359 ^[[00;32mDEBUG neutron.db.quota.driver
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
> 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mResources
> subnetpool have unlimited quota limit. It is not required to calculate
> headroom ^[[00m ^[[00;33mfrom (pid=29980) make_reservation
> /opt/stack/neutron/neutron/db/quota/driver.py:191^[[00m
> 2016-06-29 17:56:04.381 ^[[00;32mDEBUG neutron.db.quota.driver
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
> 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mAttempting to
> reserve 1 items for resource network. Total usage: 0; quota limit: 10;
> headroom:10^[[00m ^[[00;33mfrom (pid=29980) make_reservation
> /opt/stack/neutron/neutron/db/quota/driver.py:223^[[00m
> 2016-06-29 17:56:04.425 ^[[01;31mERROR neutron.api.v2.resource
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin
> 13869ba8005b480bbcbe17b2695fd5e2^[[01;31m] ^[[01;35m^[[01;31mcreate
> failed^[[00m
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mTraceback (most recent call last):
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/resource.py", line
> 78, in resource
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mresult = method(request=request, **args)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/base.py", line
> 424, in create
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mreturn self._create(request, body, **kwargs)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in
> wrapper
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mectxt.value = e.inner_exc
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 221,
> in __exit__
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mself.force_reraise()
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 197,
> in force_reraise
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00msix.reraise(self.type_, self.value, self.tb)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File
> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in
> wrapper
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mreturn f(*args, **kwargs)
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/base.py", line
> 535, in _create
> [[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource
> ^[[01;35m^[[00mreturn obj_creator(request.context, **kwargs)
> 

Re: [openstack-dev] [tricircle] About registering and loading a plugin

[Shinobu Kinjo]

It may be better to attach setup.cfg you using, and paste traceback (if
there).

Cheers,
Shinobu

On Wed, Jun 29, 2016 at 4:57 PM, Yipei Niu  wrote:

> Hi all,
>
> I have succeed in registering a config option and obtaining it. So how to
> load an option from a customized file? Through
> cfg.CONF(default_config_files=[setup.cfg]? Still fails loading the config
> options in setup.cfg.
>
> Best regards,
> Yipei
>
> On Wed, Jun 29, 2016 at 8:36 AM, joehuang  wrote:
>
>> Hi, Yipei,
>>
>>
>> "Moreover, I tried to load drivers by line "cfg.CONF.nyp.plugins.simple",
>> the console prompts oslo_config.cfg.NoSuchOptError: no such option in group
>> DEFAULT: nyp. The setup.cfg is defined as follows."
>>
>> You are using entry point but not configuration options for plugin
>> discovery, and no config option you have registered in oslo_config.cfg, so
>> " no such option in group DEFAULT:".
>>
>> Best Regards
>> Chaoyi Huang ( joehuang )
>>
>> --
>> *From:* Yipei Niu [newy...@gmail.com]
>> *Sent:* 28 June 2016 22:05
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Cc:* joehuang; Vega Cai; ski...@redhat.com; 金城 忍
>> *Subject:* Re: [tricircle] About registering and loading a plugin
>>
>> Hi all,
>>
>> Thanks a lot for your valuable advice. I have already succeed in
>> registering and loading a self-defined plugin. The entry_point is generated
>> by executing setup.py, and found in .egg-info/entry_points.txt, which is
>> different from using setup.cfg in
>> https://review.openstack.org/#/c/331638/.
>>
>> Moreover, I tried to load drivers by line "cfg.CONF.nyp.plugins.simple",
>> the console prompts oslo_config.cfg.NoSuchOptError: no such option in group
>> DEFAULT: nyp. The setup.cfg is defined as follows.
>>
>> [entry_points]
>> nyp.plugins.formmater =
>> simple = nyp.plugins.simple:SimpleFormatter
>> plain = nyp.plugins.simple:SimpleFormatter
>> field = nyp.plugins.field:FieldList
>>
>> How to solve the problem?
>>
>> Best regards,
>> Yipei
>>
>> On Tue, Jun 28, 2016 at 10:35 AM, Vega Cai  wrote:
>>
>>> Hi Yipei,
>>>
>>> You can also refer to my network type driver implementation:
>>>
>>> https://review.openstack.org/#/c/331638/
>>>
>>> Type driver is registered in setup.cfg and loaded by code.
>>>
>>> BR
>>> Zhiyuan
>>>
>>> On 27 June 2016 at 21:44, Yipei Niu  wrote:
>>>
 Dear all,

 Recently, I learn to name a plugin based on the doc
 http://docs.openstack.org/developer/stevedore/tutorial/naming.html#. I
 define a new entry_point for the plugin, then it fails. The console prompts
 "stevedore.exception.NoMatches: No 'net.nyp.formatter' driver found,
 looking for 'simple'". After setting a new entry_point with setuptools, why
 stevedore cannot find the driver based on the entry_point?

 Best regards,
 Yipei

>>>
>>>
>>
>


-- 
Email:
shin...@linux.com
shin...@redhat.com
__
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] [OpenStack-Infra] [Infra][tricircle] patch not able to be merged

[Shinobu Kinjo]

Thank you for investigation and some manual operations to fix out the problem.
If there would be anything to prevent such as unexpected behaviour,
please let us know.

Cheers,
Shinobu


On Fri, Jun 3, 2016 at 11:04 PM, Jeremy Stanley  wrote:
> On 2016-06-03 03:45:31 + (+), joehuang wrote:
>> There is one quite strange issue in Tricircle stable/mitaka branch
>> (https://github.com/openstack/tricircle/tree/stable/mitaka) . Even
>> the patch ( https://review.openstack.org/#/c/324209/ ) were given
>> Code-Review +2 and Workflow +1, the gating job not started, and
>> the patch was not merged.
>>
>> This also happen even we cherry pick a patch from the master
>> branch to the stable/mitaka branch, for example,
>> https://review.openstack.org/#/c/307627/.
>>
>> Is there configuration missing for the stable branch after
>> tagging, or some issue in infra?
>
> For some reason, (based on my reading of debugging logs) when Zuul
> queried Gerrit for open changes needed by that one it decided
> https://review.openstack.org/306278 was required to merge first but
> thought it wasn't merged. Then it attempted to enqueue it but
> couldn't because it was actually already merged a couple months ago.
> I manually instructed Zuul to try and requeue 324209 and that seems
> to have worked.
> --
> Jeremy Stanley
>
> __
> 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



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] reviewed by multiple eyes

[Shinobu Kinjo]

Hi Team,

There are some patch sets reviewed by only myself.
>From my point of view, any patch set needs to be reviewed by multiple eyes.

It's because anyone is not perfect. And there should be anything missing.
Please take a look, if you get notification to review.

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] Launch work group for cross-pod L2 networking feature

[Shinobu Kinjo]

Hi Team,

Reading today's discussion log, I would encourage you to refer to each
documentation as much as you can.

[1] 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit#heading=h.fx4zy2u9se10
[2] https://bugs.launchpad.net/networking-l2gw/+bug/1529863/comments/5
[3] https://tools.ietf.org/html/draft-xia-nvo3-l2gw-02

Cheers,
Shinobu


On Wed, May 25, 2016 at 4:41 PM, Vega Cai  wrote:
> Hi members,
>
> Thanks for attending the work group meeting. Our discussion log can be
> viewed here:
>
> https://docs.google.com/document/d/15meGv7wL2ClWZMKd4BPN0Q3br-ac2JDmTvFPLOgUHt0/edit?usp=sharing
>
> BR
> Zhiyuan
>
> On 24 May 2016 at 09:51, Yipei Niu  wrote:
>>
>> Hi, all,
>>
>> Since I have to attend the dissertation defense of my master degree on
>> Wednesday morning, I cannot attend the group meeting. Sorry about that. If
>> it is inconvenient to reschedule the meeting, I will keep online in
>> #openstack-tricircle so as to receive the meeting log.
>>
>> 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
>>
>
>
> __
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] Cross OpenStac L2 Networking Specification

[Shinobu Kinjo]

Hi Team,

Probably we would not be able to make any progress without completing
${subject} which is under review right now. [1]

It's because:

 1.Blueprint of the Tricircle is almost based on this feature at the moment.
 2.Further implementation will be mostly based on this feature.
 3.Our direction at this stage will be based on Cross OpenStack L2
Networking specification.

Since that, I would like to complete this specification as soon as
possible. But we should not keep uncompromising standards as much as
possible as well.

What do you think?

Any suggestion, objection, idea or whatever you could come up with
would be really appreciated.

Thank you for your response in advance!

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

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] Coding style guidelines

[Shinobu Kinjo]

Hi Chaoyi,

Thank you for your double-check.

On Fri, May 20, 2016 at 1:12 PM, joehuang <joehu...@huawei.com> wrote:
> Hello, Shinobu,
>
> We have gate test for pep8 in the CI pipeline,

This is what I missed completely -;

Cheers,
Shinobu

> for import orders, if it's incorrect, pep8 gate check will give -1 in the 
> result.
>
> I checked the core.py in the repository, the import order is ok, first import 
> system level, then OSLO, then projects level with blank line between 
> different level import
>
> https://github.com/openstack/tricircle/blob/master/tricircle/db/core.py
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Friday, May 20, 2016 11:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] Coding style guidelines
>
> Hi Zhipeng,
>
> Please have a look at the following script.
>
> e.g.,
> import orders.
>
> ./tricirlce/db/core.py
>
> Cheers,
> Shinobu
>
>
> On Fri, May 20, 2016 at 12:41 PM, Zhipeng Huang <zhipengh...@gmail.com> wrote:
>> Hi shinobu, could you provide an example of which part of code need
>> modification to fit the guideline ?
>>
>> On Fri, May 20, 2016 at 11:04 AM, Shinobu Kinjo <shinobu...@gmail.com>
>> wrote:
>>>
>>> Hi Team,
>>>
>>> Please make sure that your coding style follows OpenStack style
>>> guidelines. [1]
>>>
>>> I understand that it's really painful but readability, and
>>> maintenanceability point of view, it is very important to follow
>>> standard.
>>>
>>> Working through code bases, some of them do not follow the guidelines.
>>> Please read the guide line.
>>>
>>> Thank you for your understanding.
>>>
>>> [1] http://docs.openstack.org/developer/hacking/
>>>
>>> Cheers,
>>> S
>>>
>>> --
>>> Email:
>>> shin...@linux.com
>>> shin...@redhat.com
>>>
>>> _
>>> _ 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
>>
>>
>>
>>
>> --
>> Zhipeng (Howard) Huang
>>
>> Standard Engineer
>> IT Standard & Patent/IT Prooduct Line
>> Huawei Technologies Co,. Ltd
>> Email: huangzhip...@huawei.com
>> Office: Huawei Industrial Base, Longgang, Shenzhen
>>
>> (Previous)
>> Research Assistant
>> Mobile Ad-Hoc Network Lab, Calit2
>> University of California, Irvine
>> Email: zhipe...@uci.edu
>> Office: Calit2 Building Room 2402
>>
>> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>
>> __
>>  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
>>
>
>
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com
>
> __
> 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



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] Coding style guidelines

[Shinobu Kinjo]

Hi Zhipeng,

Please have a look at the following script.

e.g.,
import orders.

./tricirlce/db/core.py

Cheers,
Shinobu


On Fri, May 20, 2016 at 12:41 PM, Zhipeng Huang <zhipengh...@gmail.com> wrote:
> Hi shinobu, could you provide an example of which part of code need
> modification to fit the guideline ?
>
> On Fri, May 20, 2016 at 11:04 AM, Shinobu Kinjo <shinobu...@gmail.com>
> wrote:
>>
>> Hi Team,
>>
>> Please make sure that your coding style follows OpenStack style
>> guidelines. [1]
>>
>> I understand that it's really painful but readability, and
>> maintenanceability point of view, it is very important to follow
>> standard.
>>
>> Working through code bases, some of them do not follow the guidelines.
>> Please read the guide line.
>>
>> Thank you for your understanding.
>>
>> [1] http://docs.openstack.org/developer/hacking/
>>
>> Cheers,
>> S
>>
>> --
>> Email:
>> shin...@linux.com
>> shin...@redhat.com
>>
>> __
>> 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
>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] Coding style guidelines

[Shinobu Kinjo]

Hi Team,

Please make sure that your coding style follows OpenStack style guidelines. [1]

I understand that it's really painful but readability, and
maintenanceability point of view, it is very important to follow
standard.

Working through code bases, some of them do not follow the guidelines.
Please read the guide line.

Thank you for your understanding.

[1] http://docs.openstack.org/developer/hacking/

Cheers,
S

-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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]PTL election conclusion

[Shinobu Kinjo]

Hi Chaoyi,

Great!

On Wed, May 18, 2016 at 5:31 PM, joehuang <joehu...@huawei.com> wrote:
> Hello, Team,
>
> From last Monday to today, only single candidate (myself, if I missed 
> someone's nomination, please point out) for the PTL election of Tricircle for 
> Newton release, according to the guideline from the community, no election is 
> needed.
>
> So I would like to serve as the PTL of Tricircle in Newton release, thanks 
> for your support, let's move Tricircle forward together.

But let me modify your message a bit because I'm picky, as you might
have noticed already -;
We do not support this project but do contribute, at least me.
Anyhow we're ready to become awesome!!

Cheers,
Shinobu

>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
> -Original Message-
> From: joehuang
> Sent: Monday, May 09, 2016 10:08 AM
> To: 'OpenStack Development Mailing List (not for usage questions)'
> Subject: RE: [openstack-dev][tricircle]PTL election of Tricircle for Newton 
> release
>
> Hi, team,
>
> If you want to be the PTL for Newton release of Tricircle, please send your 
> self nomination letter in the mail-list this week.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
> -Original Message-
> From: joehuang
> Sent: Thursday, May 05, 2016 9:44 AM
> To: 'ski...@redhat.com'; OpenStack Development Mailing List (not for usage 
> questions)
> Subject: [openstack-dev][tricircle]PTL election of Tricircle for Newton 
> release
>
> Hello,
>
> As discussed in yesterday weekly meeting, PTL nomination period from May 9 ~ 
> May 13, election from May 16 ~ May 20 if more than one nomination . If you 
> want to be the PTL for Newton release of Tricircle, please send your self 
> nomination letter in the mail-list. You can refer to the nomination letter of 
> other projects, for example, Kuryr[1], Glance[2], Neutron[3], others can also 
> be found in [4]
>
>
> [1]http://git.openstack.org/cgit/openstack/election/plain//candidates/newton/Kuryr/Gal_Sagie.txt
> [2]http://git.openstack.org/cgit/openstack/election/plain//candidates/newton/Glance/Nikhil_Komawar.txt
> [3]http://git.openstack.org/cgit/openstack/election/plain//candidates/newton/Neutron/Armando_Migliaccio.txt
> [4]https://wiki.openstack.org/wiki/PTL_Elections_March_2016
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Wednesday, May 04, 2016 5:35 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] Requirements for becoming approved 
> official project
>
> Hi Team,
>
> There is an additional work to become an official (approval) project.
> Once we complete PTL election with everyone's consensus, we need to update 
> projects.yaml. [1] I think that the OSPF to become approval project is to 
> elect PTL, then talk to other PTLs of other projects.
>
> [1] 
> https://github.com/openstack/governance/blob/master/reference/projects.yaml
>
> Cheers,
> Shinobu
>
>
> On Mon, May 2, 2016 at 10:40 PM, joehuang <joehu...@huawei.com> wrote:
>> Hi, Shinobu,
>>
>> Many thanks for the check for Tricircle to be an OpenStack project, and 
>> Thierry for the clarification. glad to know that we are close to OpenStack 
>> offical project criteria.
>>
>> Let's discuss the initial PTL election in weekly meeting, and start initial 
>> PTL election after that if needed.
>>
>> Best Regards
>> Chaoyi Huang ( joehuang )
>> 
>> From: Shinobu Kinjo [shinobu...@gmail.com]
>> Sent: 02 May 2016 18:48
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [tricircle] Requirements for becoming
>> approved official project
>>
>> Hi Thierry,
>>
>> On Mon, May 2, 2016 at 5:45 PM, Thierry Carrez <thie...@openstack.org> wrote:
>>> Shinobu Kinjo wrote:
>>>>
>>>> I guess, it's usable. [1] [2] [3], probably and more...
>>>>
>>>> The reason why still I can just guess is that there is a bunch of
>>>> documentations!!
>>>> It's one of great works but too much.
>>>
>>>
>>> We have transitioned most of the documentation off the wiki, but
>>> there are still a number of pages that are not properly deprecated.
>>>
>>>> [1] https://wiki.openstack.org/wiki/PTL_Guide
>>>
>>>
>>> This is now mostly replaced by the project team guide, so I marked
>>> this one as deprecated.
>>
>> Honestly, frankly we should clean up something 

Re: [openstack-dev] [tricircle] [Blueprint] Stateless design definition

[Shinobu Kinjo]

Hi Team,

Sorry for this spam -;
Please ignore previous message.

I will file that as a doc bug.

Cheers,
S


On Sat, May 14, 2016 at 3:36 PM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
> Hi Team,
>
> In page1, we define "stateless design" as follows:
>
> Note: Stateless proposal is working on the “experiment” branch:
> https://github.com/openstack/tricircle/tree/experiment
>
> But, in section 7, we define this design as follows:
>
> A PoC was done to verify the feasibility of stateless architecture.
> Since the feedback of this PoC was very positive, sorce codes of the
> stateless design was moved to the master branch of the Tricircle git
> repository
>
> Since that, I am thinking of deleting former description (definition in 
> page1).
>
> Make sense?
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] [Blueprint] Stateless design definition

[Shinobu Kinjo]

Hi Team,

In page1, we define "stateless design" as follows:

Note: Stateless proposal is working on the “experiment” branch:
https://github.com/openstack/tricircle/tree/experiment

But, in section 7, we define this design as follows:

A PoC was done to verify the feasibility of stateless architecture.
Since the feedback of this PoC was very positive, sorce codes of the
stateless design was moved to the master branch of the Tricircle git
repository

Since that, I am thinking of deleting former description (definition in page1).

Make sense?

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] [document] Experimental design

[Shinobu Kinjo]

Hi Chaoyi,

No, it's not necessary to remove the link itself from blueprint.
It's only necessary to freeze; meaning that it is going to be *read-only* mode.
No comment on this documentation is not expected.

Make sense?

Cheers,
Shinobu

- Original Message -
From: "joehuang" <joehu...@huawei.com>
To: ski...@redhat.com, "OpenStack Development Mailing List (not for usage 
questions)" <openstack-dev@lists.openstack.org>
Sent: Wednesday, May 11, 2016 5:23:34 PM
Subject: RE: [openstack-dev] [tricircle] [document] Experimental design

Hi, Shinobu, 

Do you think we need to remove this link? and freeze this old documentation?

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Wednesday, May 11, 2016 4:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] [document] Experimental design

Hi Team,

There is a link pointing to old documentation called "The experimental design" 
in blueprint. [1]

Since I would really like to focus on only blueprint, I would like to freeze 
this old documentation. That means that there is no comment expected, and 
required on that documentation.

What do you think?
Any message would be appreciated!

[1] 
https://docs.google.com/document/d/19BXf0RhkH8wEEymE2eHHqoDZ67gnzgvpr3atk4qwdGs/edit

Cheers,
 S

--
Email:
shin...@linux.com
shin...@redhat.com

__
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] [document] Experimental design

[Shinobu Kinjo]

Hi Team,

There is a link pointing to old documentation called "The experimental
design" in blueprint. [1]

Since I would really like to focus on only blueprint, I would like to
freeze this old documentation. That means that there is no comment
expected, and required on that documentation.

What do you think?
Any message would be appreciated!

[1] 
https://docs.google.com/document/d/19BXf0RhkH8wEEymE2eHHqoDZ67gnzgvpr3atk4qwdGs/edit

Cheers,
 S

-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] About the dynamic pod binding

[Shinobu Kinjo]

Hi Yipei,

On Tue, May 10, 2016 at 10:59 AM, Yipei Niu <newy...@gmail.com> wrote:
> Hi, all,
>
> I think I understand how does tricircle schedule pods. Based on the flavor
> extra_specs or volume extra_specs tags, tricircle queries the pod table for
> the records in which resource_affinity_tag is set. Those pods that have the
> same key-value pair with extra_specs tag will be selected. Is it correct?

Key points are described in our blueprint. [1]

6 Design Principles
 6.1 Overview
  Pod Table

7.2 Resource Routing Table

  especially,

7.3  Resource Create Request Dispatch

>
> Furthermore, I still have a question mentioned. Do we need to store
> historical pod binding records in the pod binding table?

If you are talking about `pod_binding` table, I think "yes".
This requirement is also described in our blueprint. [1]

6 Design Principles
 6.1 Overview
  Pod Table

But I think that the code bases need to be reflectorred a bit more, so
that we implement more necessary functionalities, sophisticate them
and make them simple as much as possible.

@Team,

If I've missed anything, please point them out to me.

[1] 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit#

Chees,
Shinobu

>
> Best regards,
> Yipei
>
> On Fri, May 6, 2016 at 2:58 PM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
>>
>> Yipei,
>>
>> According to Chaoyi, you have a bunch of experiences regarding to the
>> OpenStack, networking which is awesome.
>>
>> I look forward to hearing from you soon.
>>
>> Cheers,
>> Shinobu
>>
>> On Fri, May 6, 2016 at 12:05 PM, Yipei Niu <newy...@gmail.com> wrote:
>> > Got it with thanks.
>> >
>> > Best regards,
>> > Yipei
>> >
>> > On Fri, May 6, 2016 at 9:48 AM, joehuang <joehu...@huawei.com> wrote:
>> >>
>> >> Hi, Yipei,
>> >>
>> >> Shinobu is correct, this should be taken into consideration in the
>> >> design
>> >> of dynamic pod binding.
>> >>
>> >> How to schedule pod, you can refer to host-aggregate scheduling with
>> >> flavor, the difference is that the scheduling granularity is on pod
>> >> level.
>> >> By the tag in flavor extra-spec and volume type extrac_spec , tricircle
>> >> can
>> >> be aware of which type of resource the tenant wants to provision.
>> >>
>> >> For example:
>> >>
>> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Configuration_Reference_Guide/host-aggregates.html
>> >>
>> >> So in
>> >>
>> >> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit,
>> >> one field called resource_affinity_tag is proposed to be added into the
>> >> pod
>> >> table, it could be used for scheduling purpose. But this is only one
>> >> proposal, you may have better idea to do that, after the spec is
>> >> reviewed
>> >> and approved, the doc can be update to reflect the new idea.
>> >>
>> >> Best Regards
>> >> Chaoyi Huang ( Joe Huang )
>> >>
>> >>
>> >> -Original Message-
>> >> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> >> Sent: Friday, May 06, 2016 8:06 AM
>> >> To: Yipei Niu
>> >> Cc: OpenStack Development Mailing List (not for usage questions);
>> >> joehuang; Zhiyuan Cai; 金城 忍
>> >> Subject: Re: [tricircle] About the dynamic pod binding
>> >>
>> >> Hi Yipei,
>> >>
>> >> On Thu, May 5, 2016 at 9:54 PM, Yipei Niu <newy...@gmail.com> wrote:
>> >> > Hi, all,
>> >> >
>> >> > For dynamic pod binding, I have some questions.
>> >> >
>> >> [snip]
>> >> > 3. How is Tricircle aware of what type of resource wanted by tenants?
>> >> > For example, a tenant wants to boot VMs for CAD modelling with
>> >> > corresponding flavor. But in current code, the flavorRef is not get
>> >> > involved in function get_pod_by_az_tenant, when querying pod
>> >> > bindings.
>> >> > So do we need to modify the pod binding table to add such a column?
>> >>
>> >> Working through code bases, probably you are talking about future
>> >> implementation, I guess.
>> >>
>> >> Cheers,
>> >> Shinobu
>> >>
>> >> >
>> >> > Best regards,
>> >> > Yipei
>> >>
>> >>
>> >>
>> >> --
>> >> Email:
>> >> shin...@linux.com
>> >> shin...@redhat.com
>> >
>> >
>>
>>
>>
>> --
>> Email:
>> shin...@linux.com
>> shin...@redhat.com
>
>
>
> __
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] L2gw

[Shinobu Kinjo]

Good catch!

Cheers,
S

On Tue, May 10, 2016 at 10:03 AM, Gary Kotton  wrote:
> Hi,
> Are there plans to cut a a stable/mitaka version for the l2gw?
> https://github.com/openstack/networking-l2gw
> Thanks
> Gary
>
> __
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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]Welcome Shinobu Kinjo to be the core reviewer of Tricircle

[Shinobu Kinjo]

Hi Team,

On Mon, May 9, 2016 at 11:03 AM, joehuang <joehu...@huawei.com> wrote:
> Hello, Team,
>
> After the nomination and one week vote, all current core reviewers has voted 
> +1, and no -1 vote. So let's welcome Shinobu Kinjo to be the core reviewer of 
> Tricircle !

\o/

Cheers,
S

>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
> -Original Message-
> From: joehuang
> Sent: Tuesday, May 03, 2016 9:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev][tricircle]Proposing Shinobu Kinjo for Tricircle core 
> reviewer
>
> Hi,
>
> I would like to propose adding Shinobu Kinjo to the Tricircle core reviewer 
> team.
>
> Shinobu has been a highly valuable reviewer to Tricircle for the past few 
> months. His contribution covers each patch submitted, document, etherpad 
> discussion, and always give valueable, meaningful and helpful comment. His 
> review data could be found from http://stackalytics.com/ (but unfortuantely 
> something wrong in stackalytics temporary, tricircle is missing in the 
> project lists)
>
> I believe Shinobu will be a great addition to the Tricircle team.
>
> Please response with +1/-1. Thank you!
>
> 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



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] cross-OpenStack L2 Networking spec review

[Shinobu Kinjo]

Hi Chaoyi,

On Sun, May 8, 2016 at 4:48 PM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> Agree with you that it's a challenge to explain Tricircle and cross OpenStack 
> L2 networking in short.

Because the Tricircle is awesome!

> So do you have any suggestion to provide a short but very accurate and clear 
> (concise description) for Tricircle and the feature cross OpenStack L2 
> networking?
> And how to enhance the blueprint to help readers easy to understand?

This is what I'm trying to do *every single day*.
You may notice that, I guess -;

Cheers,
Shinobu

>
> Best Regards
> Chaoyi Huang ( joehuang )
>
> ________
> From: Shinobu Kinjo [shinobu...@gmail.com]
> Sent: 08 May 2016 10:12
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [tricircle] cross-OpenStack L2 Networking spec review
>
> Hi Team,
>
> Since there was no tag [tricircle] in subject, I'm emailing you again.
> Sorry for spam -;
>
> We are trying to describe specification [1] regarding to ""cross
> OpenStack L2 networking"" [0] as Chaoyi mentioned in previous message.
> Honestly that description [0] does not accurately describe what this
> project is trying to do. And it's hard to be described by few words as
> well.
>
> And he mentioned having a quick look at presentation material. [2]
> This is fine to understand this project. But it's still not good enough.
> AFAK it's because that those kind of materials are completely based on
> our blueprint. [3].
>
> IMHO I would recommend you to start from that blurprint.
> At least from:
>
>  7. Stateless Architecture Proposal
>
> If some sentences are not based on that blueprint, that's a problem.
>
> But even you read that blueprint, you do not really understand what
> this project is trying to do.
> This is a real problem. We have to fix a blueprint first.
>
> Otherwise we face double-writes issue which could cause huge risk to
> this project.
>
> [1] https://review.openstack.org/#/c/304540/
> [2] 
> https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit
> [3] 
> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit#
>
> If I've been missing anything, please point it out to me.
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com
>
> __
> 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



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] cross-OpenStack L2 Networking spec review

[Shinobu Kinjo]

Hi Team,

Since there was no tag [tricircle] in subject, I'm emailing you again.
Sorry for spam -;

We are trying to describe specification [1] regarding to ""cross
OpenStack L2 networking"" [0] as Chaoyi mentioned in previous message.
Honestly that description [0] does not accurately describe what this
project is trying to do. And it's hard to be described by few words as
well.

And he mentioned having a quick look at presentation material. [2]
This is fine to understand this project. But it's still not good enough.
AFAK it's because that those kind of materials are completely based on
our blueprint. [3].

IMHO I would recommend you to start from that blurprint.
At least from:

 7. Stateless Architecture Proposal

If some sentences are not based on that blueprint, that's a problem.

But even you read that blueprint, you do not really understand what
this project is trying to do.
This is a real problem. We have to fix a blueprint first.

Otherwise we face double-writes issue which could cause huge risk to
this project.

[1] https://review.openstack.org/#/c/304540/
[2] 
https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit
[3] 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit#

If I've been missing anything, please point it out to me.

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] cross-OpenStack L2 Networking spec review

[Shinobu Kinjo]

Hi Team,

We are trying to describe specification [1] regarding to ""cross
OpenStack L2 networking"" [0] as Chaoyi mentioned in previous message.
Honestly that description [0] does not accurately describe what this
project is trying to do. And it's hard to be described by few words as
well.

And he mentioned having a quick look at presentation material. [2]
This is fine to understand this project. But it's still not good
enough.
AFAK it's because that those kind of materials are completely based on
our blueprint. [3].

IMHO I would recommend you to start from that blurprint.
At least from:

 7. Stateless Architecture Proposal

If some sentences are not based on that blueprint, that's a problem.

But even you read that blueprint, you do not really understand what
this project is trying to do.
This is a real problem. We have to fix a blueprint first.

Otherwise we face double-writes issue which could cause huge risk to
this project.

[1] https://review.openstack.org/#/c/304540/
[2] 
https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit
[3] 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit#

If I've been missing anything, please point it out to me.

Cheers,
Shinobu

On Fri, May 6, 2016 at 7:25 AM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
> Hi Joe,
>
> Thank you for your message.
> I've CCed dev list since we are still seeking more awesome
> contributors to accelerate and improve this project.
> And I believe that this topic you wrote up in your previous message is
> one of interesting topics.
>
> Cheers,
> Shinobu
>
> On Thu, May 5, 2016 at 6:29 PM, joehuang <joehu...@huawei.com> wrote:
>> Hello,
>>
>> As discussed with Xiongqiu and Ronghui, the spec will be written co-author 
>> with Zhiyuan and I. So please review the spec after new patch updated.
>>
>> And for Feng Pan, he has deep knowledge in OpenStack and networking, and we 
>> met in Austin OpenStack summit, he is pleased to join the review.
>>
>> For Pan has not attended the initial cross OpenStack L2 networking 
>> discussion, the etherpad will be good to learn the background: 
>> https://etherpad.openstack.org/p/TricircleCrossPodL2Networking
>>
>> And this slides will help to learn Tricircle quickly: 
>> https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit
>>
>> Best Regards
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> -Original Message-
>> From: XiongQiu Long (Code Review) [mailto:rev...@openstack.org]
>> Sent: Wednesday, May 04, 2016 9:08 PM
>> To: Zhiyuan Cai; Shinobu KINJO; Liuhaixia; joehuang; lige; Ronghui Cao
>> Cc: Shinobu Kinjo; Khayam Gondal; tangzhuo; Yipei Niu; shiyangkai
>> Subject: Change in openstack/tricircle[master]: Add cross-pod L2 Networking 
>> spec file
>>
>> Hello Zhiyuan Cai, Shinobu KINJO, Jenkins, liuhaixia, Chaoyi Huang, lige, 
>> Ronghui Cao,
>>
>> I'd like you to reexamine a change.  Please visit
>>
>> https://review.openstack.org/304540
>>
>> to look at the new patch set (#4).
>>
>> Change subject: Add cross-pod L2 Networking spec file 
>> ..
>>
>> Add cross-pod L2 Networking spec file
>>
>> Change-Id: I616048c13d03f48aa16d9ff48572b0d5a49d6fb4
>> ---
>> A specs/cross-pod-l2-networking.rst
>> 1 file changed, 263 insertions(+), 0 deletions(-)
>>
>>
>>   git pull ssh://review.openstack.org:29418/openstack/tricircle 
>> refs/changes/40/304540/4
>> --
>> To view, visit https://review.openstack.org/304540
>> To unsubscribe, visit https://review.openstack.org/settings
>>
>> Gerrit-MessageType: newpatchset
>> Gerrit-Change-Id: I616048c13d03f48aa16d9ff48572b0d5a49d6fb4
>> Gerrit-PatchSet: 4
>> Gerrit-Project: openstack/tricircle
>> Gerrit-Branch: master
>> Gerrit-Owner: XiongQiu Long <longxiongqiu...@163.com>
>> Gerrit-Reviewer: Chaoyi Huang <joehu...@huawei.com>
>> Gerrit-Reviewer: Jenkins
>> Gerrit-Reviewer: Khayam Gondal <khayam.gon...@gmail.com>
>> Gerrit-Reviewer: Ronghui Cao <cr_...@126.com>
>> Gerrit-Reviewer: Shinobu KINJO <shin...@linux.com>
>> Gerrit-Reviewer: Shinobu Kinjo <shinobu...@gmail.com>
>> Gerrit-Reviewer: XiongQiu Long <longxiongqiu...@163.com>
>> Gerrit-Reviewer: Yipei Niu <newy...@gmail.com>
>> Gerrit-Reviewer: Zhiyuan Cai <luckyveg...@gmail.com>
>> Gerrit-Reviewer: lige <eros.l...@gmail.com>
>> Gerrit-Reviewer: liuhaixia <liuhaixia...@huawei.com>
>> Gerrit-Reviewer: shiyangkai <shiyangkai...@126.com>
>> Gerrit-Reviewer: tangzhuo <zt...@hnu.edu.cn>
>
>
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] [blueprint] Definition of strategies

[Shinobu Kinjo]

Hi Chaoyi,

In the Tricircle's blueprint, there is a section:

 7.3  Resource Create Request Dispatch

In this section, strategy for each resource is described.
It would be better to elaborate on *WHEN* more:

 *before* or *during* or *after*

e.g.,
security group's strategy is defined as follows:

 "cache when created and sync to bottom when creating server"

It would be better to describe as below:

 "cache when created and sync to bottom during creating server"

What do you think?
Any comment, suggestion or whatever you have would be appreciated!

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] About the dynamic pod binding

[Shinobu Kinjo]

Yipei,

Probably you may be interested in the following section in Blueprint [1].

7.1 AZ and Pod Binding
 ...
7.x

[1] 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit#heading=h.x14kdooqhai1

Cheers,
S


On Fri, May 6, 2016 at 3:58 PM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
> Yipei,
>
> According to Chaoyi, you have a bunch of experiences regarding to the
> OpenStack, networking which is awesome.
>
> I look forward to hearing from you soon.
>
> Cheers,
> Shinobu
>
> On Fri, May 6, 2016 at 12:05 PM, Yipei Niu <newy...@gmail.com> wrote:
>> Got it with thanks.
>>
>> Best regards,
>> Yipei
>>
>> On Fri, May 6, 2016 at 9:48 AM, joehuang <joehu...@huawei.com> wrote:
>>>
>>> Hi, Yipei,
>>>
>>> Shinobu is correct, this should be taken into consideration in the design
>>> of dynamic pod binding.
>>>
>>> How to schedule pod, you can refer to host-aggregate scheduling with
>>> flavor, the difference is that the scheduling granularity is on pod level.
>>> By the tag in flavor extra-spec and volume type extrac_spec , tricircle can
>>> be aware of which type of resource the tenant wants to provision.
>>>
>>> For example:
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Configuration_Reference_Guide/host-aggregates.html
>>>
>>> So in
>>> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit,
>>> one field called resource_affinity_tag is proposed to be added into the pod
>>> table, it could be used for scheduling purpose. But this is only one
>>> proposal, you may have better idea to do that, after the spec is reviewed
>>> and approved, the doc can be update to reflect the new idea.
>>>
>>> Best Regards
>>> Chaoyi Huang ( Joe Huang )
>>>
>>>
>>> -Original Message-
>>> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>>> Sent: Friday, May 06, 2016 8:06 AM
>>> To: Yipei Niu
>>> Cc: OpenStack Development Mailing List (not for usage questions);
>>> joehuang; Zhiyuan Cai; 金城 忍
>>> Subject: Re: [tricircle] About the dynamic pod binding
>>>
>>> Hi Yipei,
>>>
>>> On Thu, May 5, 2016 at 9:54 PM, Yipei Niu <newy...@gmail.com> wrote:
>>> > Hi, all,
>>> >
>>> > For dynamic pod binding, I have some questions.
>>> >
>>> [snip]
>>> > 3. How is Tricircle aware of what type of resource wanted by tenants?
>>> > For example, a tenant wants to boot VMs for CAD modelling with
>>> > corresponding flavor. But in current code, the flavorRef is not get
>>> > involved in function get_pod_by_az_tenant, when querying pod bindings.
>>> > So do we need to modify the pod binding table to add such a column?
>>>
>>> Working through code bases, probably you are talking about future
>>> implementation, I guess.
>>>
>>> Cheers,
>>> Shinobu
>>>
>>> >
>>> > Best regards,
>>> > Yipei
>>>
>>>
>>>
>>> --
>>> Email:
>>> shin...@linux.com
>>> shin...@redhat.com
>>
>>
>
>
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] About the dynamic pod binding

[Shinobu Kinjo]

Yipei,

According to Chaoyi, you have a bunch of experiences regarding to the
OpenStack, networking which is awesome.

I look forward to hearing from you soon.

Cheers,
Shinobu

On Fri, May 6, 2016 at 12:05 PM, Yipei Niu <newy...@gmail.com> wrote:
> Got it with thanks.
>
> Best regards,
> Yipei
>
> On Fri, May 6, 2016 at 9:48 AM, joehuang <joehu...@huawei.com> wrote:
>>
>> Hi, Yipei,
>>
>> Shinobu is correct, this should be taken into consideration in the design
>> of dynamic pod binding.
>>
>> How to schedule pod, you can refer to host-aggregate scheduling with
>> flavor, the difference is that the scheduling granularity is on pod level.
>> By the tag in flavor extra-spec and volume type extrac_spec , tricircle can
>> be aware of which type of resource the tenant wants to provision.
>>
>> For example:
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Configuration_Reference_Guide/host-aggregates.html
>>
>> So in
>> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit,
>> one field called resource_affinity_tag is proposed to be added into the pod
>> table, it could be used for scheduling purpose. But this is only one
>> proposal, you may have better idea to do that, after the spec is reviewed
>> and approved, the doc can be update to reflect the new idea.
>>
>> Best Regards
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> -Original Message-
>> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> Sent: Friday, May 06, 2016 8:06 AM
>> To: Yipei Niu
>> Cc: OpenStack Development Mailing List (not for usage questions);
>> joehuang; Zhiyuan Cai; 金城 忍
>> Subject: Re: [tricircle] About the dynamic pod binding
>>
>> Hi Yipei,
>>
>> On Thu, May 5, 2016 at 9:54 PM, Yipei Niu <newy...@gmail.com> wrote:
>> > Hi, all,
>> >
>> > For dynamic pod binding, I have some questions.
>> >
>> [snip]
>> > 3. How is Tricircle aware of what type of resource wanted by tenants?
>> > For example, a tenant wants to boot VMs for CAD modelling with
>> > corresponding flavor. But in current code, the flavorRef is not get
>> > involved in function get_pod_by_az_tenant, when querying pod bindings.
>> > So do we need to modify the pod binding table to add such a column?
>>
>> Working through code bases, probably you are talking about future
>> implementation, I guess.
>>
>> Cheers,
>> Shinobu
>>
>> >
>> > Best regards,
>> > Yipei
>>
>>
>>
>> --
>> Email:
>> shin...@linux.com
>> shin...@redhat.com
>
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] Easy Way to Test Tricircle North-South L3 Networking

[Shinobu Kinjo]

Hi Team,

If a main problem is a number of network interfaces (I guess it's a
problem), here is more eco solution.
In side your linux box, you can add virtual network interfaces with
multiple subnets.
It's not related to this project. But it may be better to show the
followings for someone who are interested in this project.

0. Create VMs and add virtual interfaces no matter what you want.

1. Create configuration files.
 * A number of files are up to your requirement.
 * In this scenario, ens9 and ens10 are new.

[root@bottom01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
HWADDR=52:54:00:7D:1A:6B
TYPE=Ethernet
BOOTPROTO=dhcp

[root@bottom01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens10
DEVICE=ens10
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=none
IPADDR=1.0.1.1
NETMASK=255.255.255.0

[root@bottom01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens11
DEVICE=ens11
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=none
IPADDR=1.0.2.1
NETMASK=255.255.255.0

2. Modify routing table
[root@localhost ~]# cat /etc/iproute2/rt_tables
[snip]
100 t1
101 t2
[snip]

3. Set default gateway for additional interfaces
[root@localhost ~]# cat /etc/rc.local
[snip]
# It's up to above settings
ip route add 1.0.1.0/24 dev ens10 src 1.0.1.1 table t1
ip route add table t1 default via 172.16.0.254 dev ens10

ip route add 1.0.2.0/24 dev ens11 src 1.0.2.1 table t2
ip route add table t2 default via 172.16.0.254 dev ens11

ip rule add table t1 from 1.0.1.1
ip rule add table t2 from 1.0.2.1

4. Set arp settings for additional interfaces
[root@localhost ~]# cat /etc/sysctl.d/arp.conf
net.ipv4.conf.all.filter = 1
net.ipv4.conf.default.filter = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2

5. Check ips
[root@bottom01 ~]# ip a | egrep 'eth|ens' | grep inet
inet 1.0.1.1/24 brd 1.0.1.255 scope global ens10
inet 1.0.2.1/24 brd 1.0.2.255 scope global ens11
inet 172.16.0.79/24 brd 172.16.0.255 scope global dynamic eth0

# Repeat 1 ~ 4, if necessary

6. Make sure network connectivity between hosts on additional network address
* bottom01
[root@bottom01 ~]# ip a | egrep 'eth|ens' | grep inet
inet 1.0.1.1/24 brd 1.0.1.255 scope global ens10
inet 1.0.2.1/24 brd 1.0.2.255 scope global ens11
inet 172.16.0.79/24 brd 172.16.0.255 scope global dynamic eth0

* bottom02
[root@bottom02 ~]# ip a | egrep 'eth|ens' | grep inet
inet 1.0.1.2/24 brd 1.0.1.255 scope global ens9
inet 1.0.2.2/24 brd 1.0.2.255 scope global ens10
inet 172.16.0.78/24 brd 172.16.0.255 scope global dynamic eth0

[root@bottom02 ~]# ping 1.0.1.1
PING 1.0.1.1 (1.0.1.1) 56(84) bytes of data.
64 bytes from 1.0.1.1: icmp_seq=1 ttl=64 time=0.502 ms
64 bytes from 1.0.1.1: icmp_seq=2 ttl=64 time=0.267 ms
64 bytes from 1.0.1.1: icmp_seq=3 ttl=64 time=0.366 ms
64 bytes from 1.0.1.1: icmp_seq=4 ttl=64 time=0.390 ms
64 bytes from 1.0.1.1: icmp_seq=5 ttl=64 time=0.335 ms

[root@bottom01 ~]# tcpdump -i ens10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens10, link-type EN10MB (Ethernet), capture size 65535 bytes
00:53:59.873858 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
7, length 64
00:53:59.873886 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
7, length 64
00:54:00.835425 STP 802.1d, Config, Flags [none], bridge-id
8000.8c:dc:d4:32:63:ad.8005, length 43
00:54:00.873897 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
8, length 64
00:54:00.873926 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
8, length 64
00:54:01.873828 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
9, length 64
00:54:01.873855 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
9, length 64
00:54:02.835464 STP 802.1d, Config, Flags [none], bridge-id
8000.8c:dc:d4:32:63:ad.8005, length 43
00:54:02.873849 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
10, length 64
00:54:02.873879 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
10, length 64
00:54:03.873843 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
11, length 64
00:54:03.873871 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
11, length 64
00:54:04.835573 STP 802.1d, Config, Flags [none], bridge-id
8000.8c:dc:d4:32:63:ad.8005, length 43
00:54:04.873870 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
12, length 64
00:54:04.873899 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
12, length 64

Cheers,
S

On Wed, May 4, 2016 at 11:17 AM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> Correct, this is not the normal deployment scenario and the way of testbed 
> setup.
>
> Cheers
>
> BR
> Chaoyi Huang ( joehuang )
>
> 
> From: Shinobu Kinjo [shinobu...@gmail.com]
> Sent: 04 May 2016 9:38
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] Easy Way to Test Tricircle 
> North-South L3 Networ

Re: [openstack-dev] [tricircle] About the dynamic pod binding

[Shinobu Kinjo]

Hi Yipei,

On Thu, May 5, 2016 at 9:54 PM, Yipei Niu  wrote:
> Hi, all,
>
> For dynamic pod binding, I have some questions.
>
[snip]
> 3. How is Tricircle aware of what type of resource wanted by tenants? For
> example, a tenant wants to boot VMs for CAD modelling with corresponding
> flavor. But in current code, the flavorRef is not get involved in function
> get_pod_by_az_tenant, when querying pod bindings. So do we need to modify
> the pod binding table to add such a column?

Working through code bases, probably you are talking about future
implementation, I guess.

Cheers,
Shinobu

>
> Best regards,
> Yipei



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] cross-OpenStack L2 Networking spec review

[Shinobu Kinjo]

Hi Joe,

Thank you for your message.
I've CCed dev list since we are still seeking more awesome
contributors to accelerate and improve this project.
And I believe that this topic you wrote up in your previous message is
one of interesting topics.

Cheers,
Shinobu

On Thu, May 5, 2016 at 6:29 PM, joehuang <joehu...@huawei.com> wrote:
> Hello,
>
> As discussed with Xiongqiu and Ronghui, the spec will be written co-author 
> with Zhiyuan and I. So please review the spec after new patch updated.
>
> And for Feng Pan, he has deep knowledge in OpenStack and networking, and we 
> met in Austin OpenStack summit, he is pleased to join the review.
>
> For Pan has not attended the initial cross OpenStack L2 networking 
> discussion, the etherpad will be good to learn the background: 
> https://etherpad.openstack.org/p/TricircleCrossPodL2Networking
>
> And this slides will help to learn Tricircle quickly: 
> https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: XiongQiu Long (Code Review) [mailto:rev...@openstack.org]
> Sent: Wednesday, May 04, 2016 9:08 PM
> To: Zhiyuan Cai; Shinobu KINJO; Liuhaixia; joehuang; lige; Ronghui Cao
> Cc: Shinobu Kinjo; Khayam Gondal; tangzhuo; Yipei Niu; shiyangkai
> Subject: Change in openstack/tricircle[master]: Add cross-pod L2 Networking 
> spec file
>
> Hello Zhiyuan Cai, Shinobu KINJO, Jenkins, liuhaixia, Chaoyi Huang, lige, 
> Ronghui Cao,
>
> I'd like you to reexamine a change.  Please visit
>
> https://review.openstack.org/304540
>
> to look at the new patch set (#4).
>
> Change subject: Add cross-pod L2 Networking spec file 
> ..
>
> Add cross-pod L2 Networking spec file
>
> Change-Id: I616048c13d03f48aa16d9ff48572b0d5a49d6fb4
> ---
> A specs/cross-pod-l2-networking.rst
> 1 file changed, 263 insertions(+), 0 deletions(-)
>
>
>   git pull ssh://review.openstack.org:29418/openstack/tricircle 
> refs/changes/40/304540/4
> --
> To view, visit https://review.openstack.org/304540
> To unsubscribe, visit https://review.openstack.org/settings
>
> Gerrit-MessageType: newpatchset
> Gerrit-Change-Id: I616048c13d03f48aa16d9ff48572b0d5a49d6fb4
> Gerrit-PatchSet: 4
> Gerrit-Project: openstack/tricircle
> Gerrit-Branch: master
> Gerrit-Owner: XiongQiu Long <longxiongqiu...@163.com>
> Gerrit-Reviewer: Chaoyi Huang <joehu...@huawei.com>
> Gerrit-Reviewer: Jenkins
> Gerrit-Reviewer: Khayam Gondal <khayam.gon...@gmail.com>
> Gerrit-Reviewer: Ronghui Cao <cr_...@126.com>
> Gerrit-Reviewer: Shinobu KINJO <shin...@linux.com>
> Gerrit-Reviewer: Shinobu Kinjo <shinobu...@gmail.com>
> Gerrit-Reviewer: XiongQiu Long <longxiongqiu...@163.com>
> Gerrit-Reviewer: Yipei Niu <newy...@gmail.com>
> Gerrit-Reviewer: Zhiyuan Cai <luckyveg...@gmail.com>
> Gerrit-Reviewer: lige <eros.l...@gmail.com>
> Gerrit-Reviewer: liuhaixia <liuhaixia...@huawei.com>
> Gerrit-Reviewer: shiyangkai <shiyangkai...@126.com>
> Gerrit-Reviewer: tangzhuo <zt...@hnu.edu.cn>



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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 for becoming approved official project

[Shinobu Kinjo]

Thank you for suggestions.
At this stage, we are just trying to become an official project.

Cheers,
S

On Fri, May 6, 2016 at 2:50 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Mike Perez's message of 2016-05-05 09:59:58 -0700:
>> On 14:40 Apr 30, Shinobu Kinjo wrote:
>> > Hi Tom,
>> >
>> > First sorry for bothering you -;
>> >
>> > We are trying to make the tricircle project [1] one of the opnestack
>> > official projects. And we are referring to project team guide to make
>> > sure what are requirements. [2]. Reading this guide, what we need to
>> > consider right now is open development, I think (but not 100% sure).
>> > [3]
>>
>> I think you're looking for:
>>
>> http://governance.openstack.org/reference/tags/tc-approved-release.html
>>
>
> That list is only for projects seeking to be included in DefCore.
> Nothing as new as tricircle is likely to qualify for that status, so I
> wouldn't worry too much about it, for now.
>
> If tricircle just wants to be an official project, the starting place is
> http://governance.openstack.org/reference/new-projects-requirements.html
>
> 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



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] A number of dummy functions

[Shinobu Kinjo]

Team,

How many dummy, fake function does the Tricircle have?
I understood that we are now in pre-production, and will be in
production hopefully soon!
But I don't need surprise any more -;

e.g.,
# ./tricircle/cinder_apigw/controllers/volume.py
337 def _convert_header(self, t_release, b_release, header):
338
339 return header

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] supporting Go

[Shinobu Kinjo]

- Could we kindly stop discussing radosgw at this moment?
+ Could we kindly stop discussing any particular application at this moment?

On Wed, May 4, 2016 at 7:02 PM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
> Could we kindly stop discussing radosgw at this moment?
>
> On Wed, May 4, 2016 at 6:47 PM, Thierry Carrez <thie...@openstack.org> wrote:
>> Fox, Kevin M wrote:
>>>
>>> RadosGW has been excluded from joining the OpenStack community in part due
>>> to its use of c++.
>>
>>
>> I'm not sure I'd use the word "excluded" since RadosGW was never actually
>> proposed. Maybe our past Python-centricity discouraged them to apply, but
>> that's conjecture.
>>
>>> Now that we're talking about alternate languages, that may be on the table
>>> now?
>>
>>
>> It's been a possibility for the last 8 months.
>>
>> That said, my personal view is that we should accept additional languages
>> when the current set of accepted languages is suboptimal for something we
>> want to write or create. A technical benefit to outweigh the community
>> fragmentation and increase in infrastructure tasks that result from adding
>> that language.
>>
>> I'm less convinced that we should add a language for the sole benefit of
>> being able to absorb an existing project into OpenStack which happens to be
>> written in a specific language. Especially if the then-supported set of
>> languages could provide the same technical benefits.
>>
>> --
>> 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
>
>
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] supporting Go

[Shinobu Kinjo]

Could we kindly stop discussing radosgw at this moment?

On Wed, May 4, 2016 at 6:47 PM, Thierry Carrez  wrote:
> Fox, Kevin M wrote:
>>
>> RadosGW has been excluded from joining the OpenStack community in part due
>> to its use of c++.
>
>
> I'm not sure I'd use the word "excluded" since RadosGW was never actually
> proposed. Maybe our past Python-centricity discouraged them to apply, but
> that's conjecture.
>
>> Now that we're talking about alternate languages, that may be on the table
>> now?
>
>
> It's been a possibility for the last 8 months.
>
> That said, my personal view is that we should accept additional languages
> when the current set of accepted languages is suboptimal for something we
> want to write or create. A technical benefit to outweigh the community
> fragmentation and increase in infrastructure tasks that result from adding
> that language.
>
> I'm less convinced that we should add a language for the sole benefit of
> being able to absorb an existing project into OpenStack which happens to be
> written in a specific language. Especially if the then-supported set of
> languages could provide the same technical benefits.
>
> --
> 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



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] Requirements for becoming approved official project

[Shinobu Kinjo]

Hi Team,

There is an additional work to become an official (approval) project.
Once we complete PTL election with everyone's consensus, we need to
update projects.yaml. [1]
I think that the OSPF to become approval project is to elect PTL, then
talk to other PTLs of other projects.

[1] https://github.com/openstack/governance/blob/master/reference/projects.yaml

Cheers,
Shinobu


On Mon, May 2, 2016 at 10:40 PM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> Many thanks for the check for Tricircle to be an OpenStack project, and 
> Thierry for the clarification. glad to know that we are close to OpenStack 
> offical project criteria.
>
> Let's discuss the initial PTL election in weekly meeting, and start initial 
> PTL election after that if needed.
>
> Best Regards
> Chaoyi Huang ( joehuang )
> ________
> From: Shinobu Kinjo [shinobu...@gmail.com]
> Sent: 02 May 2016 18:48
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] Requirements for becoming approved 
> official project
>
> Hi Thierry,
>
> On Mon, May 2, 2016 at 5:45 PM, Thierry Carrez <thie...@openstack.org> wrote:
>> Shinobu Kinjo wrote:
>>>
>>> I guess, it's usable. [1] [2] [3], probably and more...
>>>
>>> The reason why still I can just guess is that there is a bunch of
>>> documentations!!
>>> It's one of great works but too much.
>>
>>
>> We have transitioned most of the documentation off the wiki, but there are
>> still a number of pages that are not properly deprecated.
>>
>>> [1] https://wiki.openstack.org/wiki/PTL_Guide
>>
>>
>> This is now mostly replaced by the project team guide, so I marked this one
>> as deprecated.
>
> Honestly, frankly we should clean up something deprecated since there
> is a bunch of documentations -;
> It's really hard to read every singe piece...
>
> Anyway better than nothing though.
>
>>
>> As far as initial election goes, if there is a single candidate no need to
>> organize a formal election. If you need to run one, you can use CIVS
>> (http://civs.cs.cornell.edu/) since that is what we use for the official
>> elections: https://wiki.openstack.org/wiki/Election_Officiating_Guidelines
>
> Thank you for pointing it out.
> That is really good advice.
>
>>
>> Regards,
>>
>> --
>> 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
>
>
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> 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



-- 
Email:
shin...@linux.com
shin...@redhat.com

__
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] Easy Way to Test Tricircle North-South L3 Networking

[Shinobu Kinjo]

On Wed, May 4, 2016 at 10:38 AM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
> Hi Chaoyi,
>
> I didn't consider Ronghui's environment which I have no idea about.

Anyhow this is my bad -;
Sorry for that!

Cheers,
S

>
>> That's why Zhiyuan proposed hacking way to do it.
>
> Considering such a limited situation, I understood this solution is
> for particular situation which is not usual for cascaded stack
> environment.
> Is it same of what you are implying in your message?
>
> I would like to avoid any misunderstanding between members as much as 
> possible.
>
> Cheers,
> Shinobu
>
> On Wed, May 4, 2016 at 10:25 AM, joehuang <joehu...@huawei.com> wrote:
>> Hi, Shinobu,
>>
>> I think Zhiyuan's suggestion is mainly for Ronghui's environment, for his 
>> environment has very limited network infterfaces, it's difficult to 
>> experiment N-S feature. It would be recommended to use VMs for setting up 
>> Tricircle test bed with two bottom pods, so it's much more easier to manage 
>> networking plane for different purpose. But Ronghui's machine also have very 
>> limited vCPU and memory, so booting serveral VMs to establish the tricircle 
>> and two bottom pods test bed also not possible. That's why Zhiyuan proposed 
>> hacking way to do it.
>>
>> Best Regards
>> Chaoyi Huang ( joehuang )
>>
>> 
>> From: Shinobu Kinjo [shinobu...@gmail.com]
>> Sent: 04 May 2016 6:58
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [tricircle] Easy Way to Test Tricircle 
>> North-South L3 Networking
>>
>> Vega,
>>
>> On Tue, May 3, 2016 at 5:49 PM, Vega Cai <luckyveg...@gmail.com> wrote:
>>> Hi all,
>>>
>>> Just would like to share a way to test Tricircle north-south L3 networking
>>> without requiring the third interface.
>>>
>>> In the Tricircle readme, it is said that you need to add an interface in
>>> your host to br-ext bridge. One interface to access the host, one interface
>>> for east-west networking and one interface for north-south networking, so
>>> all together three interfaces are required.
>>>
>>> What if your host only have two interfaces? Here is another deployment
>>> choice.
>>>
>>> First, change your external network type to flat type. If you are using the
>>> DevStack script provided by Tricircle, do the following changes in node2
>>> local.conf then run DevStack in node2.
>>>
>>> (1) change Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS
>>> from (network_vlan_ranges=bridge:2001:3000,extern:3001:4000)
>>> to (network_vlan_ranges=bridge:2001:3000)
>>> (since we going to use flat external network, no need to configure VLAN
>>> range for extern)
>>> (2) add PHYSICAL_NETWORK=extern
>>> (3) keep OVS_BRIDGE_MAPPINGS=bridge:br-bridge,extern:br-ext
>>
>> Good point.
>>
>>>
>>> Second, specify flat type when creating external network.
>>>
>>> curl -X POST http://127.0.0.1:9696/v2.0/networks
>>>-H "Content-Type: application/json" \
>>>-H "X-Auth-Token: $token" \
>>>-d '{"network": {"name": "ext-net", "admin_state_up": true,
>>> "router:external": true, "provider:network_type": "flat",
>>> "provider:physical_network": "extern", "availability_zone_hints":
>>> ["Pod2"]}}'
>>
>> Understood.
>>
>>>
>>> Third, configure IP address of br-ext.
>>>
>>> sudo ifconfig br-ext 163.3.124.1 netmask 255.255.255.0
>>>
>>> Here 163.3.124.1 is your external network gateway IP, set net mask
>>> according to your CIDR.
>>>
>>> After the above steps, you can access your VM via floating IP in node2. Also
>>> your VM can ping the external gateway.
>>>
>>> Would like your VM to access the Internet?(Of course node2 should be able to
>>> access the Internet) Two more steps to follow:
>>> (1) Enable packet forward in node2
>>>
>>> sudo bash
>>> echo 1 >/proc/sys/net/ipv4/ip_forward
>>>
>>> (2) Configure SNAT in node2
>>>
>>> sudo iptables -t nat -I POSTROUTING -s 163.3.124.0/24 -o eth1 -j SNAT
>>> --to-source 10.250.201.21
>>>
>>> 163.3.124.0/24 is your external network CIDR, eth1

Re: [openstack-dev] [tricircle] Easy Way to Test Tricircle North-South L3 Networking

[Shinobu Kinjo]

Hi Chaoyi,

I didn't consider Ronghui's environment which I have no idea about.

> That's why Zhiyuan proposed hacking way to do it.

Considering such a limited situation, I understood this solution is
for particular situation which is not usual for cascaded stack
environment.
Is it same of what you are implying in your message?

I would like to avoid any misunderstanding between members as much as possible.

Cheers,
Shinobu

On Wed, May 4, 2016 at 10:25 AM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> I think Zhiyuan's suggestion is mainly for Ronghui's environment, for his 
> environment has very limited network infterfaces, it's difficult to 
> experiment N-S feature. It would be recommended to use VMs for setting up 
> Tricircle test bed with two bottom pods, so it's much more easier to manage 
> networking plane for different purpose. But Ronghui's machine also have very 
> limited vCPU and memory, so booting serveral VMs to establish the tricircle 
> and two bottom pods test bed also not possible. That's why Zhiyuan proposed 
> hacking way to do it.
>
> Best Regards
> Chaoyi Huang ( joehuang )
>
> ____
> From: Shinobu Kinjo [shinobu...@gmail.com]
> Sent: 04 May 2016 6:58
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] Easy Way to Test Tricircle 
> North-South L3 Networking
>
> Vega,
>
> On Tue, May 3, 2016 at 5:49 PM, Vega Cai <luckyveg...@gmail.com> wrote:
>> Hi all,
>>
>> Just would like to share a way to test Tricircle north-south L3 networking
>> without requiring the third interface.
>>
>> In the Tricircle readme, it is said that you need to add an interface in
>> your host to br-ext bridge. One interface to access the host, one interface
>> for east-west networking and one interface for north-south networking, so
>> all together three interfaces are required.
>>
>> What if your host only have two interfaces? Here is another deployment
>> choice.
>>
>> First, change your external network type to flat type. If you are using the
>> DevStack script provided by Tricircle, do the following changes in node2
>> local.conf then run DevStack in node2.
>>
>> (1) change Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS
>> from (network_vlan_ranges=bridge:2001:3000,extern:3001:4000)
>> to (network_vlan_ranges=bridge:2001:3000)
>> (since we going to use flat external network, no need to configure VLAN
>> range for extern)
>> (2) add PHYSICAL_NETWORK=extern
>> (3) keep OVS_BRIDGE_MAPPINGS=bridge:br-bridge,extern:br-ext
>
> Good point.
>
>>
>> Second, specify flat type when creating external network.
>>
>> curl -X POST http://127.0.0.1:9696/v2.0/networks
>>-H "Content-Type: application/json" \
>>-H "X-Auth-Token: $token" \
>>-d '{"network": {"name": "ext-net", "admin_state_up": true,
>> "router:external": true, "provider:network_type": "flat",
>> "provider:physical_network": "extern", "availability_zone_hints":
>> ["Pod2"]}}'
>
> Understood.
>
>>
>> Third, configure IP address of br-ext.
>>
>> sudo ifconfig br-ext 163.3.124.1 netmask 255.255.255.0
>>
>> Here 163.3.124.1 is your external network gateway IP, set net mask
>> according to your CIDR.
>>
>> After the above steps, you can access your VM via floating IP in node2. Also
>> your VM can ping the external gateway.
>>
>> Would like your VM to access the Internet?(Of course node2 should be able to
>> access the Internet) Two more steps to follow:
>> (1) Enable packet forward in node2
>>
>> sudo bash
>> echo 1 >/proc/sys/net/ipv4/ip_forward
>>
>> (2) Configure SNAT in node2
>>
>> sudo iptables -t nat -I POSTROUTING -s 163.3.124.0/24 -o eth1 -j SNAT
>> --to-source 10.250.201.21
>>
>> 163.3.124.0/24 is your external network CIDR, eth1 is the interface
>> associated with your default route in node2 and 10.250.201.21 is the IP of
>> eth1.
>
> I would like to avoid this kind of hackery way as much as possible.
> I would like to see your further recommendation so that we easily and
> quickly build cascaded stack system including top.
>
>>
>> Hope this information helps.
>>
>> BR
>> Zhiyuan
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [stackalytics]many projects missing in the "others" category

[Shinobu Kinjo]

AFAIK the Tricircle is one of them. [1]
How can we fix it out?

[1] http://stackalytics.com/report/contribution/tricircle/90

Cheers,
S

On Tue, May 3, 2016 at 10:11 PM, joehuang  wrote:
> Hello,
>
> Very sad to know that some projects are missing again in the "others" 
> category. When I want to cite some statistic data for Tricircle core reviewer 
> nomination, can't find the data for many "others" projects which usually are 
> listed "others" category. Is there any new rule in Stackalytics?
>
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Easy Way to Test Tricircle North-South L3 Networking

[Shinobu Kinjo]

Vega,

On Tue, May 3, 2016 at 5:49 PM, Vega Cai  wrote:
> Hi all,
>
> Just would like to share a way to test Tricircle north-south L3 networking
> without requiring the third interface.
>
> In the Tricircle readme, it is said that you need to add an interface in
> your host to br-ext bridge. One interface to access the host, one interface
> for east-west networking and one interface for north-south networking, so
> all together three interfaces are required.
>
> What if your host only have two interfaces? Here is another deployment
> choice.
>
> First, change your external network type to flat type. If you are using the
> DevStack script provided by Tricircle, do the following changes in node2
> local.conf then run DevStack in node2.
>
> (1) change Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS
> from (network_vlan_ranges=bridge:2001:3000,extern:3001:4000)
> to (network_vlan_ranges=bridge:2001:3000)
> (since we going to use flat external network, no need to configure VLAN
> range for extern)
> (2) add PHYSICAL_NETWORK=extern
> (3) keep OVS_BRIDGE_MAPPINGS=bridge:br-bridge,extern:br-ext

Good point.

>
> Second, specify flat type when creating external network.
>
> curl -X POST http://127.0.0.1:9696/v2.0/networks
>-H "Content-Type: application/json" \
>-H "X-Auth-Token: $token" \
>-d '{"network": {"name": "ext-net", "admin_state_up": true,
> "router:external": true, "provider:network_type": "flat",
> "provider:physical_network": "extern", "availability_zone_hints":
> ["Pod2"]}}'

Understood.

>
> Third, configure IP address of br-ext.
>
> sudo ifconfig br-ext 163.3.124.1 netmask 255.255.255.0
>
> Here 163.3.124.1 is your external network gateway IP, set net mask
> according to your CIDR.
>
> After the above steps, you can access your VM via floating IP in node2. Also
> your VM can ping the external gateway.
>
> Would like your VM to access the Internet?(Of course node2 should be able to
> access the Internet) Two more steps to follow:
> (1) Enable packet forward in node2
>
> sudo bash
> echo 1 >/proc/sys/net/ipv4/ip_forward
>
> (2) Configure SNAT in node2
>
> sudo iptables -t nat -I POSTROUTING -s 163.3.124.0/24 -o eth1 -j SNAT
> --to-source 10.250.201.21
>
> 163.3.124.0/24 is your external network CIDR, eth1 is the interface
> associated with your default route in node2 and 10.250.201.21 is the IP of
> eth1.

I would like to avoid this kind of hackery way as much as possible.
I would like to see your further recommendation so that we easily and
quickly build cascaded stack system including top.

>
> Hope this information helps.
>
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] [devstack] - suggested development workflow without ./rejoin-stack.sh ?

[Shinobu Kinjo]

Honestly those kind of major changes have to be discussed very carefully.

On Tue, May 3, 2016 at 7:10 AM, Kevin Benton  wrote:
> This patch removed the ./rejoin-stack.sh script:
> https://review.openstack.org/#/c/291453/
>
> I relied on this heavily in my development VM which sees lots of restarts
> because of various things (VM becomes unresponsive in load testing, my
> laptop has a kernel panic, etc). Normally this was not a big deal because I
> could ./rejoin-stack.sh and pick up where I left off (all db objects,
> virtual interfaces, instance images, etc all intact).
>
> Now am I correct in understanding that when this happens there is no way to
> restart the services in a simple manner without blowing away everything and
> starting over? Unless I'm missing some way to run ./stack.sh without losing
> previous state, this seems like a major regression (went from mostly working
> ./rejoin-stack.sh to nothing).
>
> What is the recommended way to use devstack without being a power outage
> away from losing hours of work?
>
> Thanks,
> Kevin Benton
>
> __
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Requirements for becoming approved official project

[Shinobu Kinjo]

Hi Thierry,

On Mon, May 2, 2016 at 5:45 PM, Thierry Carrez <thie...@openstack.org> wrote:
> Shinobu Kinjo wrote:
>>
>> I guess, it's usable. [1] [2] [3], probably and more...
>>
>> The reason why still I can just guess is that there is a bunch of
>> documentations!!
>> It's one of great works but too much.
>
>
> We have transitioned most of the documentation off the wiki, but there are
> still a number of pages that are not properly deprecated.
>
>> [1] https://wiki.openstack.org/wiki/PTL_Guide
>
>
> This is now mostly replaced by the project team guide, so I marked this one
> as deprecated.

Honestly, frankly we should clean up something deprecated since there
is a bunch of documentations -;
It's really hard to read every singe piece...

Anyway better than nothing though.

>
> As far as initial election goes, if there is a single candidate no need to
> organize a formal election. If you need to run one, you can use CIVS
> (http://civs.cs.cornell.edu/) since that is what we use for the official
> elections: https://wiki.openstack.org/wiki/Election_Officiating_Guidelines

Thank you for pointing it out.
That is really good advice.

>
> Regards,
>
> --
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Requirements for becoming approved official project

[Shinobu Kinjo]

I guess, it's usable. [1] [2] [3], probably and more...

The reason why still I can just guess is that there is a bunch of
documentations!!
It's one of great works but too much.

[1] https://wiki.openstack.org/wiki/PTL_Guide
[2] https://wiki.openstack.org/wiki/Project_Teams
[3] https://wiki.openstack.org/wiki/Governance/NewProjectTeams

Cheers,
Shinobu


On Mon, May 2, 2016 at 2:38 PM, Zhipeng Huang <zhipengh...@gmail.com> wrote:
> Thx shinobu,
>
> This is a great checklist ! Re PTL election, could we use community tools
> for that ?
>
> On May 2, 2016 1:09 PM, "Shinobu Kinjo" <shinobu...@gmail.com> wrote:
>
> Hi Team,
>
> According to Documentation team, the Tricircle project seems to close
> to be official (but not really official kind of) since we have
> standard directory structure. [1]
>
> What we need to do from here is to submit a project-config patch to
> publish the documentation to [2]. Once we finish this stage, we would
> have a guide underneath developer.
>
> With this process, we're required to apply to the TC with adding your
> repository to the governance repository. [3] [4] What TC will check
> are described in [5].
>
> As of now, a summary of remaining processes to join the OpenStack,
>
>  1.Approval process by TC
>  2.PTL election.
>
> Probably still I've been missing something. If there, please point
> them out to me.
>
> BTW since we've been already done some bug fixes, it's worth noticing
> and keeping it mind [6].
>
> [1] https://git.openstack.org/cgit/openstack/tricircle/tree/
> [2] http://docs.openstack.org/developer/tricircle
> [3]
> http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections
> [4] http://governance.openstack.org/
> [5] http://governance.openstack.org/reference/new-projects-requirements.html
> [6] http://governance.openstack.org/reference/project-testing-interface.html
>
> Cheers,
> Shinobu
>
> __
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Requirements for becoming approved official project

[Shinobu Kinjo]

Hi Team,

According to Documentation team, the Tricircle project seems to close
to be official (but not really official kind of) since we have
standard directory structure. [1]

What we need to do from here is to submit a project-config patch to
publish the documentation to [2]. Once we finish this stage, we would
have a guide underneath developer.

With this process, we're required to apply to the TC with adding your
repository to the governance repository. [3] [4] What TC will check
are described in [5].

As of now, a summary of remaining processes to join the OpenStack,

 1.Approval process by TC
 2.PTL election.

Probably still I've been missing something. If there, please point
them out to me.

BTW since we've been already done some bug fixes, it's worth noticing
and keeping it mind [6].

[1] https://git.openstack.org/cgit/openstack/tricircle/tree/
[2] http://docs.openstack.org/developer/tricircle
[3] 
http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections
[4] http://governance.openstack.org/
[5] http://governance.openstack.org/reference/new-projects-requirements.html
[6] http://governance.openstack.org/reference/project-testing-interface.html

Cheers,
Shinobu

__
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 for becoming approved official project

[Shinobu Kinjo]

Hi Lana,

Thank you for your advice regarding to documentation.
I will email the list.

Cheers,
Shinobu

On Sun, May 1, 2016 at 12:20 PM, Lana Brindley
<openst...@lanabrindley.com> wrote:
> Hi Shinobu,
>
> I can help you with the documentation piece, at least.
>
> The documentation team are working on a new method to help projects document 
> their installation guides in their own repo, with publishing to 
> docs.openstack.org. This is explicitly to help projects meet the project 
> navigator requirements.
>
> Before Newton, we will have the infrastructure up, and hope to also have a 
> template and some other guides for you to help you do this. If you have 
> questions about getting started on this, please email the docs mailing list: 
> openstack-d...@lists.openstack.org
>
> Thanks,
> Lana
>
> On 29/04/16 22:40, Shinobu Kinjo wrote:
>> Hi Tom,
>>
>> First sorry for bothering you -;
>>
>> We are trying to make the tricircle project [1] one of the opnestack
>> official projects. And we are referring to project team guide to make
>> sure what are requirements. [2]. Reading this guide, what we need to
>> consider right now is open development, I think (but not 100% sure).
>> [3]
>>
>> We have a blueprint. [4] We also have git repositories in
>> openstack.org and github.com. [5] [6]
>> There is a few bugs filed. [7] There are few contributors.
>>
>> What we don't have now is official documentation which is supposed to
>> be located at openstack.org. [8] This is because we are not officially
>> approved project. [9] This situation is now huge bottleneck for our
>> project.
>>
>> There were some advices from one of developers, which pointed to
>> guides. [1] [10]
>> If you could provide some suggestions, advices or no matter what are
>> really necessary for becoming officially approved project with us, it
>> would be MUCH appreciated.
>>
>> [1] https://wiki.openstack.org/wiki/Tricircle
>> [2] http://docs.openstack.org/project-team-guide/
>> [3] http://docs.openstack.org/project-team-guide/open-development.html
>> [4]https://launchpad.net/tricircle
>> [5] https://git.openstack.org/openstack/tricircle
>> [6] https://github.com/openstack/tricircle/
>> [7] http://bugs.launchpad.net/tricircle
>> [8] http://docs.openstack.org/developer/tricircle
>> [9] 
>> http://docs.openstack.org/infra/manual/creators.html#add-link-to-your-developer-documentation
>> [10] http://governance.openstack.org/reference/new-projects-requirements.html
>>
>> Thanks for your great help in advance!
>>
>> Cheers,
>> Shinobu
>>
>> __
>> 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
>>
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
>
> __
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Requirements for becoming approved official project

[Shinobu Kinjo]

Hi Tom,

First sorry for bothering you -;

We are trying to make the tricircle project [1] one of the opnestack
official projects. And we are referring to project team guide to make
sure what are requirements. [2]. Reading this guide, what we need to
consider right now is open development, I think (but not 100% sure).
[3]

We have a blueprint. [4] We also have git repositories in
openstack.org and github.com. [5] [6]
There is a few bugs filed. [7] There are few contributors.

What we don't have now is official documentation which is supposed to
be located at openstack.org. [8] This is because we are not officially
approved project. [9] This situation is now huge bottleneck for our
project.

There were some advices from one of developers, which pointed to
guides. [1] [10]
If you could provide some suggestions, advices or no matter what are
really necessary for becoming officially approved project with us, it
would be MUCH appreciated.

[1] https://wiki.openstack.org/wiki/Tricircle
[2] http://docs.openstack.org/project-team-guide/
[3] http://docs.openstack.org/project-team-guide/open-development.html
[4]https://launchpad.net/tricircle
[5] https://git.openstack.org/openstack/tricircle
[6] https://github.com/openstack/tricircle/
[7] http://bugs.launchpad.net/tricircle
[8] http://docs.openstack.org/developer/tricircle
[9] 
http://docs.openstack.org/infra/manual/creators.html#add-link-to-your-developer-documentation
[10] http://governance.openstack.org/reference/new-projects-requirements.html

Thanks for your great help in advance!

Cheers,
Shinobu

__
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]call for contributors for Tricircle project - for massive distributed edge clouds and large scale cloud.

[Shinobu Kinjo]

Hi Chaoyi,

At a meeting today, we had a great update from you.
I don't write any details here but I'm quite happy with that.
I believe that we will have awesome contributors and the Tricircle
become one of important projects soon.

Cheers,
Shinobu


On Mon, Apr 25, 2016 at 1:59 PM, joehuang  wrote:
> Hi,
>
>
>
> Two sessions to learn more about Tricircle:
>
>
>
> 1. lightning talks about Tricircle use case: modularized capacity expansion
> in OpenStack based public cloud
> Monday, April 25 14:50 – 16:20 in the Hilton room Salon E
> a. https://www.openstack.org/summit/austin-2016/summit-schedule/events/9499
> b. https://www.openstack.org/summit/austin-2016/venues/#venue=39
> c. https://etherpad.openstack.org/p/AUS-ops-lightning-talks
>
>
>
> 2. Tricircle in a nutshell – 15 minutes talk in Massively Distributed Clouds
> Working Group Inaugural Meeting
>
> Tuesday, April 26, 4:40pm-6:10pm (Hilton, Level 6, Salon J)
>
> a.https://www.openstack.org/summit/austin-2016/summit-schedule/events/9533
>
> b. https://etherpad.openstack.org/p/massively-distributed-clouds
>
> BR
>
> Chaoyi Huang(joehuang)
>
> 
> From: joehuang
> Sent: 19 April 2016 14:37
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev][all]call for contributors for Tricircle project -
> for massive distributed edge clouds and large scale cloud.
>
> Hello,
>
>
>
> There are lots of challenges in massive distributed edge clouds. Enterprise
> as the customer of large public cloud already asked for putting the cloud to
> close to the end user for its distributed branches, to fulfill the user
> experience expectation for bandwidth and latency sensitive application like
> CAD modeling, the experience is not good to run in remote centralized cloud.
> The common problem domain is how to address the challenges in a cloud which
> is consisted of a lots of OpenStack instances, in one site or distributed in
> multiple sites:
>
>
>
> For example:
>
> Tenant level L2/L3 networking across OpenStack instances for isolation to
> tenant's E-W traffic
>
> Tenant level Volume/VM/object backup/migration/distribution across OpenStack
> instances
>
> Distributed image management, if an user create image from VM/volume, how to
> use the image in another OpenStack instance in another site.
>
> Distributed quota management, how to control the quota if tenant’s resources
> spread into multiple OpenStack instances across multiple sites.
>
> ...
>
>
>
> All these challenges and requirements already happened in current production
> cloud built upon OpenStack.
>
>
>
> Tricircle project tries to provide an OpenStack API gateway and networking
> automation to allow multiple OpenStack instances, spanning in one site or
> multiple sites or in hybrid cloud, to be managed as a single OpenStack
> cloud.
>
>
>
> All challenges mentioned above have not been developed in Tricircle, and
> hope to be developed in next several cycles, need your contribution.
>
>
>
> All source code in Tricircle were written from zero since Jun, 2015, and
> decoupled from current Nova/Cinder/Neutron etc service, that means the
> Tricircle is developed loose coupling with current OpenStack. The code base
> is still very small, about 25 kloc(including test cases), and working on the
> first release, it’s easy to get on board.
>
>
>
> Compared to other broker method for multi-OpenStacks management, Tricricle
> provides the OpenStack API and seamlessly work together with software like
> Heat, Magnum, Murano, CLI, Horizon, SDK, ….
>
>
>
> Tricircle will be talked in two sessions in OpenStack Austin Summit ( for
> NFV cloud is multi-site in nature, but doesn’t mean Tricircle only for NFV):
>
>
>
> 1) multisite-openstack-for-nfv-bridging-the-gap:
>
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/7480/multisite-openstack-for-nfv-bridging-the-gap
>
> 2) NFV Orchestration - Project Landscape:
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/8468
>
>
>
> How to get involved in Tricricle quickly:
>
> 1.  Read wiki of Tricircle: https://wiki.openstack.org/wiki/Tricircle
>
> 2.  Register BP or report bug in https://launchpad.net/tricircle, found
> items not implemented yet in:
> https://etherpad.openstack.org/p/TricircleToDo, submit your patch for review
> just like any other OpenStack project.
>
> 3.  regular weekly meeting at #openstack-meeting on every Wednesday
> starting from UTC 13:00
>
> 4.  openstack-dev mail-list discussion, with [Tricircle] tag in the mail
> title
>
> 5.  You can follow the framework blueprint to read the source code:
> https://blueprints.launchpad.net/tricircle/+spec/implement-stateless the
> design doc for the blueprint is
> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit?usp=sharing
>
>
>
> Hope this mail will help you to join Tricircle J
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
> 

Re: [openstack-dev] [tricircle] virtual design summit for Newton

[Shinobu Kinjo]

Hi Team,

There was no enough time to discuss all topics in the meeting today. 
I wrote up what we discussed. Please make sure what need to be done and add 
anything if I've missed.

Cheers,
Shinobu

- Original Message -
From: "joehuang" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, April 29, 2016 10:59:48 AM
Subject: Re: [openstack-dev] [tricircle] virtual design summit for Newton



repost for reminder 

From: joehuang 
Sent: 26 April 2016 11:40 
To: OpenStack Development Mailing List (not for usage questions) 
Subject: [openstack-dev][tricircle] virtual design summit for Newton 



Hello, 



Most of our team members in Tricircle are not able to attend the OpenStack 
Austin summit, so we have to have a virtual design summit: 



One etherpad is opened for the topics to be discussed for the Newton design 
summit, please list the topics you want to discuss in the etherpad: 



https://etherpad.openstack.org/p/TricircleNeutonDesignSummit 



The date and time to have this virtual design summit will be at UTC 2:00am on 
Friday ( Beijing Time 10:00am) Apr. 29. ( Austin time: 9:00pm Apr.28 ) 



To make Tricircle fully follow OpenStack projects open source development, I 
think we need to apply Tricircle as TC approved big tent project in Newton, so 
this is also one important topic to be discussed. 



Any suggestion are welcome. 



Best Regards 

Chaoyi Huang ( joehuang ) 

From: joehuang 
Sent: 19 April 2016 16:33 
To: OpenStack Development Mailing List (not for usage questions) 
Subject: [openstack-dev] [tricircle]weekly meeting of Apr. 19 



This week we will discuss the object operation not implemented . 



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



Agenda: 

# object operation not implemented 

# tempest test 

# Reliable aync. Job – items left 

# Link: https://etherpad.openstack.org/p/TricircleToDo 



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



Best Regards 

Chaoyi Huang ( Joe Huang ) 



__
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] [TC][tricircle] ask help from TC and other guru in the OpenStack community

[Shinobu Kinjo]

Flavio,

On Tue, Apr 26, 2016 at 11:12 PM, Flavio Percoco <fla...@redhat.com> wrote:
> On 26/04/16 20:39 +0900, Shinobu Kinjo wrote:
>>
>> On Tue, Apr 26, 2016 at 12:47 PM, joehuang <joehu...@huawei.com> wrote:
>>>
>>> Hi, TCs and guru,
>>>
>>>
>>>
>>> If tricircle planned to apply being TC approved big tent project, would
>>> someone help to guide our project?
>>
>>
>> I also would like to know what we should do for that so that we focus
>> on specific things.
>
>
> Hey Folks,
>
> I'm not sure if you have read these docs but I'd probably start here:
>
> - http://governance.openstack.org/reference/new-projects-requirements.html
> - http://docs.openstack.org/project-team-guide

Thanks for those pointers.
My original question is:

https://bugs.launchpad.net/tricircle/+bug/1562416

Cheers,
S

>
> I see you guys have a repo and you're actively contributing to it, which is
> great. What kind of guidance are you guys looking for?
>
> Cheers,
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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][tricircle] ask help from TC and other guru in the OpenStack community

[Shinobu Kinjo]

On Tue, Apr 26, 2016 at 12:47 PM, joehuang  wrote:
> Hi, TCs and guru,
>
>
>
> If tricircle planned to apply being TC approved big tent project, would
> someone help to guide our project?

I also would like to know what we should do for that so that we focus
on specific things.

>
>
>
> I would like to have one  virtual design summit for Tricircle on UTC 2:00am
> on Friday ( Beijing Time 10:00am Apr. 29), ( Austin time: 9:00pm Apr.28 )
>
>
>
> Best Regards
>
> Chaoyi Huang ( joehuang )
>
>
>
> 
> From: joehuang
> Sent: 26 April 2016 11:40
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev][tricircle] virtual design summit for Newton
>
> Hello,
>
>
>
> Most of our team members in Tricircle are not able to attend the OpenStack
> Austin summit, so we have to have a virtual design summit:
>
>
>
> One etherpad is opened for the topics to be discussed for the virtual Newton
> design summit, please list the topics you want to discuss in the etherpad:
>
>
>
> https://etherpad.openstack.org/p/TricircleNeutonDesignSummit
>
>
>
> The date and time to have this virtual design summit will be at UTC 2:00am
> on Friday ( Beijing Time 10:00am) Apr. 29. ( Austin time: 9:00pm Apr.28 )
>
>
>
> To make Tricircle fully follow OpenStack projects open source development, I
> think we need to apply Tricircle as TC approved big tent project in Newton,
> so this is also one important topic to be discussed.
>
>
>
> Any suggestion are welcome.
>
>
>
> Best Regards
>
> Chaoyi Huang ( joehuang )
>
> 
> From: joehuang
> Sent: 19 April 2016 16:33
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [tricircle]weekly meeting of Apr. 19
>
> This week we will discuss the object operation not implemented.
>
>
>
> IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on
> every Wednesday starting from UTC 13:00.
>
>
>
> Agenda:
>
> # object operation not implemented
>
> # tempest test
>
> # Reliable aync. Job – items left
>
> # Link: https://etherpad.openstack.org/p/TricircleToDo
>
>
>
> If you  have other topics to be discussed in the weekly meeting, please
> reply the mail.
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
>
>
> __
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] [TripleO] Change 247669: Ceph Puppet: implement per-pool parameters:

[Shinobu Kinjo]

Thanks, Steve.

Cheers,
S

- Original Message -
From: "Steven Hardy" <sha...@redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: ski...@redhat.com
Sent: Sunday, April 24, 2016 11:14:58 PM
Subject: Re: [openstack-dev] [TripleO] Change 247669: Ceph Puppet: implement 
per-pool parameters:

On Fri, Apr 22, 2016 at 08:00:02AM -0400, Emilien Macchi wrote:
> On Fri, Apr 22, 2016 at 3:51 AM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
> > Hi TripleO Team,
> >
> > If you could take care of ${subject}, it would be nice.
> >
> > [1] https://review.openstack.org/#/c/247669
> >
> 
> Well, the patch is in merge conflict, and has negative review from Cyril.
> I would suggest the committer, Felipe Alfaro Solana, to rebase it, and
> address the review (or at least shows some activity).

Agreed it looks like the patch needs an update.

I added the bug to our newton-1 milestone and increased the priority so we
can track landing the fix and prioritize reviews when the patch is updated.

Steve

__
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] [TripleO] Change 247669: Ceph Puppet: implement per-pool parameters:

[Shinobu Kinjo]

Hi TripleO Team,

If you could take care of ${subject}, it would be nice.

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

Cheers,
S

__
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] http response code

[Shinobu Kinjo]

This might be answer for your question.

https://github.com/openstack/tricircle/blob/master/tricircle/api/controllers/pod.py

Cheers,
S

On Wed, Apr 20, 2016 at 6:37 PM, 李戈  wrote:

> Hi
> I read api source code recently and have a question. Do we uniform the
> "http response code"?
>
>
> such as, 404 means "Not Found".
>
>
>
>
>
>
> __
> 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
>
>


-- 
Email:
shin...@linux.com
GitHub:
shinobu-x 
Blog:
Life with Distributed Computational System based on OpenSource

__
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][kilo] - vxlan's max bandwidth

[Shinobu Kinjo]

How did you test it out?
Would you elaborate on this more?

Cheers,
Shinobu

On Fri, Apr 15, 2016 at 11:10 AM, Kenny Ji-work  wrote:
> Hi all,
>
> In the environment of openstack kilo, I test the bandwidth in the scene
> which VxLan being used. The result show that the vxlan can only support up
> to 1 gbits bandwidth. Is this a bug or any else issue, or is there some
> hotfix to solve the issue? Thank you for answering!
>
> Sincerely,
> Kenny Ji
>
> __
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] RPC Communication Errors Might Lead to a Bad State

[Shinobu Kinjo]

Hi,

Just coming from my curiosity (inline).

On Thu, Apr 14, 2016 at 12:34 AM, Dan Smith  wrote:
>>   * nova-api should receive an acknowledgement from nova-compute. It is
>> unclear to me why today it uses a non-reply mechanism - probably to
>> free the worker as fast as it can.
>
> Yes, wherever possible, we want the API to return immediately and let
> the action complete later. Making a wholesale change to blocking calls
> from the API to any other service is not a good idea, IMHO.
>
>>   * Change the task_state mechanism to prevent this kind of a stuck
>> state to stay in the DB. nova-compute can be the one that writes the
>> task_state to the DB, but this is not enough of course, but maybe
>> there's another way?
>
> The task_state being set in the API is our way of limiting/locking the
> operation so that if the request is queued for a long time, a user
> doesn't reissue the command a bunch of time and add load to the API
> and/or jam up the queue with a thousand requests to do the same
> operation just because it's taking a while.
>
>>   * nova-api could start a timer for the action to complete. If the
>> shelving operation hasn't completed in X seconds, it will clean it
>> by itself and rollback\try-again.
>
> I have wanted to make a change for a while that involves a TTL on
> messages, along with a deadline record so that we can know when to retry
> or revert things that were in flight. This requires a lot of machinery
> to accomplish, and is probably interwoven with the task concept we've
> had on the back burner for a while. The complexity of moving nova to
> this sort of scheme means that nobody has picked it up as of yet, but
> it's certainly in the minds of many of us as something we need to do
> before too long.

Are you still thinking of this kind of mechanism deployment?
We need any kind of RPC handling mechanism at the end of the day.

>
> --Dan
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] [puppet][ceph] Puppet-ceph is now a formal member of puppet-openstack

[Shinobu Kinjo]

Great!

On Tue, Apr 12, 2016 at 6:24 AM, Andrew Woodward  wrote:
> It's been a while since we started the puppet-ceph module on stackforge as a
> friend of OpenStack. Since then Ceph's usage in OpenStack has increased
> greatly and we have both the puppet-openstack deployment scenarios as well
> as check-trippleo running against the module.
>
> We've been receiving leadership from the puppet-openstack team for a while
> now and our small core team has struggled to keep up. As such we have added
> the puppet-openstack cores to the review ACL's in gerrit and have been
> formally added to the puppet-openstack project in governance. [1]
>
> I thank the puppet-openstack team for their support and, I am glad to see
> the module move under their leadership.
>
> [1] https://review.openstack.org/300191
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
> __
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Shinobu Kinjo]

Tom,

Would you elaborate more?

- Original Message -
From: "Tom Fifield" 
To: openstack-dev@lists.openstack.org
Sent: Saturday, April 9, 2016 6:20:31 PM
Subject: Re: [openstack-dev] Constant attempts from Matthew Kassawara to remove 
Debian from the install-guide

On 09/04/16 14:49, Thomas Goirand wrote:
> I still don't have any idea what's wrong with the
> Debian guide.

The standing issue that I recall that raises the maintenance burden is 
the use of debconf rather than/in addition to manual config file edits 
as per the other distros. I can't remember whether you already tried a 
version without debconf or not though.

__
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] [jacket] Introduction to jacket, a new project

[Shinobu Kinjo]

Kevin,

Quick question.
Does one OpenStack infrastructure have to be dedicated for one Jacket instance?

Cheers,
Shinobu


On Thu, Mar 24, 2016 at 8:24 PM, Kevin.ZhangSen  wrote:
> Hi Ghanshyam,
>
> Thank you for your sugesstions, and I agree with your opinion that the
> service outside OpenStack is better. In fact I am considering what API
> Jacket will offer. It is better to offer the OpenStack API directly. But
> there will be a question how to modify as little code as possible to keep
> the same API compatibility with OpenStack after OpenStack updates the API
> version. I think this will be an interesting question, but we can try to let
> Jacket offer the OpenStack API.
>
> The reply about other query is below. If there are any questions, please
> tell me. Thank you again.
>
> Best Regards,
> Kevin (Sen Zhang)
>
> At 2016-03-24 11:58:47, "GHANSHYAM MANN"  wrote:
>>Hi Kevin,
>>
>>Its always nice idea as jacket has but not sure how feasible and
>>valuable it would be. For doing API translation and gateway, there are
>>many available and one I remember is Aviator (based on ruby gem) [1],
>>not sure how active it is now.
>>
>>As your idea is more about consuming all differences between different
>>cloud, few query-
>>
>> 1. Different clouds have very much different API model and feature
>>they provides, how  worth it is to provide missing/different features
>>at jacket layer? its then kind of another layer of cloud layer you
>>will end up.
> Kevin: We will provide the commonly used functions to let the users manage
> the different clouds just like one kind of cloud, for example VMs
> management(create/destroy/start/stop/restart/rebuild...) and volume
> management(create/delete/backup/snapshot). About network, there is a
> solution to use neutron to offer network function through the overlay
> virtual network based on the provider clouds’ virtual network. This will be
> another project, not in Jacket.
>> 2. To support that idea through OpenStack standard API, you need to
>>inserting jacket driver all over the components which end up having
>>another layer gets inserted there. Maintainability of that is another
>>issue for each OpenStack components.
> Kevin: I agree with you. Jacket offer OpenStack will be better.
>>IMO, outside layer (from OpenStack ) which can do all these would be
>>nice something which can redirect API services at top level top and do
>>what all conversion, consume difference etc.
>>
>>[1] https://github.com/aviator/aviator
>>
>>Regards
>>Ghanshyam Mann
>>
>>
>>On Wed, Mar 16, 2016 at 9:58 PM, zs  wrote:
>>> Hi Gordon,
>>>
>>> Thank you for your suggestion.
>>>
>>> I think jacket is different from tricircle. Because tricircle focuses on
>>> OpenStack deployment across multiple sites, but jacket focuses on how to
>>> manage the different clouds just like one cloud.  There are some
>>> differences:
>>> 1. Account management and API model: Tricircle faces multiply OpenStack
>>> instances which can share one Keystone and have the same API model, but
>>> jacket will face the different clouds which have the respective service
>>> and
>>> different API model. For example, VMware vCloud Director has no volume
>>> management like OpenStack and AWS, jacket will offer a fake volume
>>> management for this kind of cloud.
>>> 2. Image management: One image just can run in one cloud, jacket need
>>> consider how to solve this problem.
>>> 3. Flavor management: Different clouds have different flavors which can
>>> not
>>> be operated by users. Jacket will face this problem but there will be no
>>> this problem in tricircle.
>>> 4. Legacy resources adoption: Because of the different API modles, it
>>> will
>>> be a huge challenge for jacket.
>>>
>>> I think it is maybe a good solution that jacket works to unify the API
>>> model
>>> for different clouds, and then using tricircle to offer the management of
>>> a
>>> large scale VMs.
>>>
>>> Best Regards,
>>> Kevin (Sen Zhang)
>>>
>>>
>>> At 2016-03-16 19:51:33, "gordon chung"  wrote:


On 16/03/2016 4:03 AM, zs wrote:
> Hi all,
>
> There is a new project "jacket" to manage multiply clouds. The jacket
> wiki is: https://wiki.openstack.org/wiki/Jacket
>   Please review it and give your comments. Thanks.
>
> Best Regards,
>
> Kevin (Sen Zhang)
>
>

i don't know exact details of either project, but i suggest you
collaborate with tricircle project[1] because it seems you are
addressing the same user story (and in a very similar fashion). not sure
if it's a user story for OpenStack itself, but no point duplicating
 efforts.

[1] https://wiki.openstack.org/wiki/Tricircle

cheers,

--
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
 

Re: [openstack-dev] [Tricircle] Original Blueprint

[Shinobu Kinjo]

All clear.

Cheers,
Shinobu

On Thu, Apr 7, 2016 at 5:21 PM, joehuang <joehu...@huawei.com> wrote:
> Yes, of course.
>
> And in Newton release, we want to use BP + spec for review and approve for 
> new features, just like https://review.openstack.org/#/c/282180/.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Thursday, April 07, 2016 4:16 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Tricircle] Original Blueprint
>
> Hi Chaoyi,
>
> Just to clarify more.
>
> On Thu, Apr 7, 2016 at 5:02 PM, joehuang <joehu...@huawei.com> wrote:
>> Hi, Shinobu,
>>
>> Thanks for your review. Just replied in the google doc, that the table is 
>> the latest design, not old one, and some fields need to be implemented in 
>> new patches.
>
> I'm now expecting that *blueprint* is always master; meaning that anyone who 
> would contribute to the Tricircle need to refer, follow *blueprint*.
>
> Is it same of what you are thinking of?
>
> Cheers,
> Shinobu
>
>>
>> Best Regards
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> -Original Message-
>> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> Sent: Thursday, April 07, 2016 12:44 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Tricircle] Original Blueprint
>>
>> Hi Chaoyi,
>>
>> In blueprint you described for PoC, there are information of tables. [1] 
>> They seem to out-to-date.
>>
>> Do you think that those information need to be up-to-date in your blueprint?
>> If it's not necessary, it's better to move those information to different 
>> sheet or put some comment like "Won't be updated", I think.
>>
>> [1]
>> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l
>> 2zNqMEd3g
>>
>> Cheers,
>> Shinobu
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __
>>  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
>
>
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Original Blueprint

[Shinobu Kinjo]

Hi Chaoyi,

Just to clarify more.

On Thu, Apr 7, 2016 at 5:02 PM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> Thanks for your review. Just replied in the google doc, that the table is the 
> latest design, not old one, and some fields need to be implemented in new 
> patches.

I'm now expecting that *blueprint* is always master; meaning that
anyone who would contribute to the Tricircle need to refer, follow
*blueprint*.

Is it same of what you are thinking of?

Cheers,
Shinobu

>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -----Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Thursday, April 07, 2016 12:44 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Tricircle] Original Blueprint
>
> Hi Chaoyi,
>
> In blueprint you described for PoC, there are information of tables. [1] They 
> seem to out-to-date.
>
> Do you think that those information need to be up-to-date in your blueprint?
> If it's not necessary, it's better to move those information to different 
> sheet or put some comment like "Won't be updated", I think.
>
> [1] 
> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] UUID Mapping

[Shinobu Kinjo]

Hi Chaoyi,

Thank you for your reply.
All clear.

Cheers,
Shinobu

On Thu, Apr 7, 2016 at 5:00 PM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> This part has been deleted just few minutes ago. No UUID mapping in stateless 
> design, but a resource routing table is used there, but read the "7.2 
> Resource Routing Table".
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Thursday, April 07, 2016 2:35 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Tricircle] UUID Mapping
>
> Hi Team,
>
> Can we elaborate on uuid mapping more?
> As described in blueprint, it's expected to be a solution for one of 
> challenges.
>
>> The object UUID in the top layer is different from the UUIDs in the bottom 
>> layers.
>
> There should theoretical logic, mechanism. But I've not been able to find any 
> docs about that.
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] UUID Mapping

[Shinobu Kinjo]

Hi Team,

Can we elaborate on uuid mapping more?
As described in blueprint, it's expected to be a solution for one of challenges.

> The object UUID in the top layer is different from the UUIDs in the bottom 
> layers.

There should theoretical logic, mechanism. But I've not been able to
find any docs about that.

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Original Blueprint

[Shinobu Kinjo]

Hi Chaoyi,

In blueprint you described for PoC, there are information of tables. [1]
They seem to out-to-date.

Do you think that those information need to be up-to-date in your blueprint?
If it's not necessary, it's better to move those information to
different sheet or put some comment like "Won't be updated", I think.

[1] 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] FYI: Removing default flavors from nova

[Shinobu Kinjo]

On Wed, Apr 6, 2016 at 7:47 PM, Sean Dague  wrote:
> On 04/06/2016 04:19 AM, Sylvain Bauza wrote:
>>
>>
>> Le 06/04/2016 06:44, Qiming Teng a écrit :
>>> Not an expert of Nova but I am really shocked by such a change. Because
>>> I'm not a Nova expert, I don't have a say on the *huge* efforts in
>>> maintaining some builtin/default flavors. As a user I don't care where
>>> the data have been stored, but I do care that they are gone. They are
>>> gone because they **WILL** be supported by devstack. They are gone with
>>> the workflow +1'ed **BEFORE** the devstack patch gets merged (many
>>> thanks to the depends-on tag). They are gone in hope that all deployment
>>> tools will know this when they fail, or fortunately they read this email,
>>> or they were reviewing nova patches.
>>>
>>> It would be a little nicer to initiate a discussion on the mailinglist
>>> before such a change is introduced.
>>
>>
>> It was communicated accordingly to operators with no strong arguments :
>> http://lists.openstack.org/pipermail/openstack-operators/2016-March/010045.html
>
> Not only with no strong arguments, but with a general - "yes please,
> that simplifies our life".
>
>> You can also see that https://review.openstack.org/#/c/300127/ is having
>> three items :
>>  - a DocImpact tag creating a Launchpad bug for documentation about that
>>  - a reno file meaning that our release notes will provide also some
>> comments about that
>>  - a Depends-On tag (like you said) on a devstack change meaning that
>> people using devstack won't see a modified behavior.
>>
>> Not sure what you need more.
>
> The default flavors were originally hardcoded in Nova (in the initial
> commit) -
> https://github.com/openstack/nova/commit/bf6e6e718cdc7488e2da87b21e258ccc065fe499#diff-5ca8c06795ef481818ea1710fce91800R64
>  and moved into the db 5 years ago to be a copy of the EC2 flavors at
> the time -
> https://github.com/openstack/nova/commit/563a77fd4aa80da9bddac5cf7f8f27ed2dedb39d.
> Those flavors were meant to be examples, not the final story.
>
> All the public clouds delete these and do their own thing, as do I
> expect many of the products. Any assumption that software or users have
> that these will exist is a bad assumption.
>
> It is a big change, which is why it's being communicated on Mailing
> Lists in addition to in the release notes so that people have time to
> make any of their tooling not assume these flavors by name will be
> there, or to inject them yourself if you are sure you need them (as was
> done in the devstack case).

I'm clear. Thanks, Sean.

Cheers,
Shinobu

>
> -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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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]weekly meeting of Apr. 6

[Shinobu Kinjo]

Hi Chaoyi,

I will write up what I'm assuming regarding to connection between top
and bottom[s] across data centres based on your blueprint and brief
discussion by now with you, and share it with team.

Cheer,
Shinobu


On Wed, Apr 6, 2016 at 3:16 PM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> Do you have some ideas on trust relationship between top and bottoms over BGP 
> across Ass?
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Tuesday, April 05, 2016 6:54 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle]weekly meeting of Apr. 6
>
> Hi Chaoyi,
>
> Thank you for team mtg every week.
> One day, we may need to discuss about trust relationship considering secure 
> connection and no-latency issue between top and bottoms over BGP across ASs, 
> in short between DCs.
> Any thought would be appreciated as usual.
>
> Cheers,
> Shinobu
>
> On Tue, Apr 5, 2016 at 6:24 PM, joehuang <joehu...@huawei.com> wrote:
>> Hi,
>>
>>
>>
>> We have a very good discussion about cross OpenStack L2 networking
>> last
>> week: https://etherpad.openstack.org/p/TricircleCrossPodL2Networking
>>
>>
>>
>> Let’s continue the discussion and other topics in this weekly meeting.
>>
>>
>>
>> IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting
>> on every Wednesday starting from UTC 13:00.
>>
>>
>>
>> Agenda:
>>
>> # Cross OpenStack L2 networking
>>
>> # pod scheduling
>>
>> # Reliable aync. Job
>>
>> # Link: https://etherpad.openstack.org/p/TricircleToDo
>>
>>
>>
>> If you  have other topics to be discussed in the weekly meeting,
>> please reply the mail.
>>
>>
>>
>> Best Regards
>>
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> __
>>  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
>>
>
>
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] FYI: Removing default flavors from nova

[Shinobu Kinjo]

On Wed, Apr 6, 2016 at 1:44 PM, Qiming Teng  wrote:
> Not an expert of Nova but I am really shocked by such a change. Because
> I'm not a Nova expert, I don't have a say on the *huge* efforts in
> maintaining some builtin/default flavors. As a user I don't care where
> the data have been stored, but I do care that they are gone. They are
> gone because they **WILL** be supported by devstack. They are gone with
> the workflow +1'ed **BEFORE** the devstack patch gets merged (many
> thanks to the depends-on tag). They are gone in hope that all deployment
> tools will know this when they fail, or fortunately they read this email,
> or they were reviewing nova patches.
>
> It would be a little nicer to initiate a discussion on the mailinglist
> before such a change is introduced.

Agree.

Cheers,
Shinobu

>
> Regards,
>   Qiming
>
> On Tue, Apr 05, 2016 at 08:09:50AM -0700, Dan Smith wrote:
>> Just as a heads up, we are removing the default flavors from nova in
>> this patch:
>>
>>   https://review.openstack.org/#/c/300127/
>>
>> Since long ago, Nova's default flavors were baked in at the database
>> migration level. Now that we have moved them to another database
>> entirely, this means we have to migrate them from the old/original place
>> to the new one, even for new deployments. It also means that our tests
>> have flavor assumptions that run (way too) deep.
>>
>> Devstack will get support for auto-creating the flavors you are used to,
>> as well as some less-useless ones:
>>
>>   https://review.openstack.org/#/c/301257/
>>
>> Normal developers shouldn't really notice, but the deployment tool
>> projects may want/need to do something here along the same lines.
>>
>> --Dan
>>
>
>
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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]weekly meeting of Apr. 6

[Shinobu Kinjo]

Hi Chaoyi,

Thank you for team mtg every week.
One day, we may need to discuss about trust relationship considering
secure connection and no-latency issue between top and bottoms over
BGP across ASs, in short between DCs.
Any thought would be appreciated as usual.

Cheers,
Shinobu

On Tue, Apr 5, 2016 at 6:24 PM, joehuang  wrote:
> Hi,
>
>
>
> We have a very good discussion about cross OpenStack L2 networking last
> week: https://etherpad.openstack.org/p/TricircleCrossPodL2Networking
>
>
>
> Let’s continue the discussion and other topics in this weekly meeting.
>
>
>
> IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on
> every Wednesday starting from UTC 13:00.
>
>
>
> Agenda:
>
> # Cross OpenStack L2 networking
>
> # pod scheduling
>
> # Reliable aync. Job
>
> # Link: https://etherpad.openstack.org/p/TricircleToDo
>
>
>
> If you  have other topics to be discussed in the weekly meeting, please
> reply the mail.
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
> __
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Naming convention

[Shinobu Kinjo]

Hi Chaoyi,

> In the experience of development, using full name as far as possible to 
> reduce the PEP8 naming convention prompt ion. But if the naming will make us 
> hard to write one clause less than 80 characters(ensure one clause in one 
> line), then sometimes the abbreviation has to be done to balance the code 
> readability. 

That is fine.

If we decide that how many characters in one word are not acceptable and need 
to be shortened beforehand, we can make more better rule for other members who 
will be in this project in the future.
But once we get more people and make more lines in source(current: only 16483 
lines), it's going to be difficult.

Any thought would be appreciated.

Cheers,
Shinobu 

- Original Message -
From: "joehuang" <joehu...@huawei.com>
To: ski...@redhat.com, "OpenStack Development Mailing List (not for usage 
questions)" <openstack-dev@lists.openstack.org>
Sent: Tuesday, April 5, 2016 11:09:38 AM
Subject: RE: [openstack-dev] [Tricircle] Naming convention

Hi, Shinobu, 

Fully agree with you that this is a dilemma situation: If we use full word, for 
example "availaibility_zone_aggregate", then the length of one line easily 
exceed 80 characters, especially if there are several indents, if we don't use 
short name, it's very difficult to make sure one clause in one line as far as 
possible. Even after we use shorter name, sometimes, this issue is still there 
:(

In the experience of development, using full name as far as possible to reduce 
the PEP8 naming convention prompt ion. But if the naming will make us hard to 
write one clause less than 80 characters(ensure one clause in one line), then 
sometimes the abbreviation has to be done to balance the code readability. 

How do you think about this?

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Tuesday, April 05, 2016 9:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Tricircle] Naming convention

Hi Chaoyi,

Thank you for your reply.
How about this:

# tricircle/api/pod.py
94 aggregate = az_ag.create_ag_az(context,

 95
ag_name=ag_name,
96az_name=az_name)
 ...
161ag = az_ag.get_ag_by_name(context, ag_name)

Since there is zero impact on the system, you could ignore though.

Cheers,
Shinobu


On Tue, Apr 5, 2016 at 10:08 AM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> Thanks for your suggestion. When using PyCharm as the IDE, one issue is that 
> if we use abbreviation for the word to name the function or variables, there 
> is some PEP8 promotion that you'd better to name it in a whole word, but not 
> abbreviation.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Saturday, April 02, 2016 7:40 AM
> To: joehuang; OpenStack Development Mailing List (not for usage 
> questions)
> Subject: Re: [openstack-dev] [Tricircle] Naming convention
>
> One of examples is:
>
> """
>  tricircle/db/api.py
> """
> authorize_quota_class_context(context, class_name):
>
> # This could become:
>
> auth_quota_class_ctx(ctx, class_name):
>
> # If we put some comment for this, this also could become:
>
> """
>   Function: Ensure a request has right permission to given the project.
>   @ctx: user context
>   @class: class name
> """
> auth_quota_ctx(ctx, class):
>
> Point here is, honestly not only name but also appropriate length of comment.
> What do you think?
>
> Cheers,
> Shinobu
>
>
> On Sat, Apr 2, 2016 at 8:20 AM, joehuang <joehu...@huawei.com> wrote:
>> yes, good idea, could you point out or  report a bug which are not 
>> good naming.
>>
>> thanks.
>>
>> Sent from HUAWEI AnyOffice
>> 发件人：shinobu.kj
>> 收件人：openstack-dev,
>> 时间：2016-04-02 06:21:50
>> 主题:[openstack-dev] [Tricircle] Naming convention
>>
>> Hi Team,
>>
>> Probably it's worth thinking of naming convention for classes, 
>> methods or whatever we define in source codes.
>>
>> Some names are lengthy and there might be no consistency. At the 
>> moment it's fine. But once this project gets growing, situation would 
>> become chaotic and could cause bugs.
>>
>> What do you think?
>>
>> Cheers,
>> Shinobu
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational

Re: [openstack-dev] [Tricircle] Naming convention

[Shinobu Kinjo]

Hi Chaoyi,

Thank you for your reply.
How about this:

# tricircle/api/pod.py
94 aggregate = az_ag.create_ag_az(context,

 95
ag_name=ag_name,
96az_name=az_name)
 ...
161ag = az_ag.get_ag_by_name(context, ag_name)

Since there is zero impact on the system, you could ignore though.

Cheers,
Shinobu


On Tue, Apr 5, 2016 at 10:08 AM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> Thanks for your suggestion. When using PyCharm as the IDE, one issue is that 
> if we use abbreviation for the word to name the function or variables, there 
> is some PEP8 promotion that you'd better to name it in a whole word, but not 
> abbreviation.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Saturday, April 02, 2016 7:40 AM
> To: joehuang; OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Tricircle] Naming convention
>
> One of examples is:
>
> """
>  tricircle/db/api.py
> """
> authorize_quota_class_context(context, class_name):
>
> # This could become:
>
> auth_quota_class_ctx(ctx, class_name):
>
> # If we put some comment for this, this also could become:
>
> """
>   Function: Ensure a request has right permission to given the project.
>   @ctx: user context
>   @class: class name
> """
> auth_quota_ctx(ctx, class):
>
> Point here is, honestly not only name but also appropriate length of comment.
> What do you think?
>
> Cheers,
> Shinobu
>
>
> On Sat, Apr 2, 2016 at 8:20 AM, joehuang <joehu...@huawei.com> wrote:
>> yes, good idea, could you point out or  report a bug which are not
>> good naming.
>>
>> thanks.
>>
>> Sent from HUAWEI AnyOffice
>> 发件人：shinobu.kj
>> 收件人：openstack-dev,
>> 时间：2016-04-02 06:21:50
>> 主题:[openstack-dev] [Tricircle] Naming convention
>>
>> Hi Team,
>>
>> Probably it's worth thinking of naming convention for classes, methods
>> or whatever we define in source codes.
>>
>> Some names are lengthy and there might be no consistency. At the
>> moment it's fine. But once this project gets growing, situation would
>> become chaotic and could cause bugs.
>>
>> What do you think?
>>
>> Cheers,
>> Shinobu
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __
>>  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
>
>
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Naming convention

[Shinobu Kinjo]

One of examples is:

"""
 tricircle/db/api.py
"""
authorize_quota_class_context(context, class_name):

# This could become:

auth_quota_class_ctx(ctx, class_name):

# If we put some comment for this, this also could become:

"""
  Function: Ensure a request has right permission to given the project.
  @ctx: user context
  @class: class name
"""
auth_quota_ctx(ctx, class):

Point here is, honestly not only name but also appropriate length of comment.
What do you think?

Cheers,
Shinobu


On Sat, Apr 2, 2016 at 8:20 AM, joehuang  wrote:
> yes, good idea, could you point out or
>  report a bug which are not good naming.
>
> thanks.
>
> Sent from HUAWEI AnyOffice
> 发件人：shinobu.kj
> 收件人：openstack-dev,
> 时间：2016-04-02 06:21:50
> 主题:[openstack-dev] [Tricircle] Naming convention
>
> Hi Team,
>
> Probably it's worth thinking of naming convention for classes, methods
> or whatever we define in source codes.
>
> Some names are lengthy and there might be no consistency. At the
> moment it's fine. But once this project gets growing, situation would
> become chaotic and could cause bugs.
>
> What do you think?
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Naming convention

[Shinobu Kinjo]

Hi Team,

Probably it's worth thinking of naming convention for classes, methods
or whatever we define in source codes.

Some names are lengthy and there might be no consistency. At the
moment it's fine. But once this project gets growing, situation would
become chaotic and could cause bugs.

What do you think?

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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][Neutron] Improving development and review velocity - Is it time for a drastic change?

[Shinobu Kinjo]

On Fri, Apr 1, 2016 at 10:12 AM, Assaf Muller  wrote:
> Have you been negatively impacted by slow development and review
> velocity? Read on.
>
> OpenStack has had a slow review velocity for as long as I can
> remember. This has a cascading effect where people take up multiple
> tasks, so that they can work on something while the other is being
> reviewed. This adds even more patches to ever growing queues. Features
> miss releases and bugs never get fixed. Even worse, we turn away new
> contributors due to an agonizing process.
>
> In the Neutron community, we've tried a few things over the years.
> Neutron's growing scope was identified and load balancing, VPN and
> firewall as a service were split out to their own repositories.
> Neutron core reviewers had less load, *aaS contributors could iterate
> faster, it was a win win. Following that, Neutron plugins were split
> off as well. Neutron core reviewers did not have the expertise or
> access to specialized hardware of vendors anyway, vendors could
> iterate faster, and everybody were happy. Finally, a specialization
> system was created. Areas of the Neutron code base were determined and
> a "Lieutenant" was chosen for each area. That lieutenant could then
> nominate core reviewers, and those reviewers were then expected to +2
> only within their area. This led to doubling the core team, and for my
> money was a great success. Leading us to today.
>
> Today, I think it's clear we still have a grave problem. Patches sit
> idle for months, turning contributors away. I believe we've reached a
> tipping point, and now is the time for out of the box thinking. I am
> proposing two changes:
>
> 1) Changing what a core reviewer is. It is time to move to a system of
> trust: Everyone have +2 rights to begin with, and the system
> self-regulates by shaming offending individuals and eventually taking
> away rights for repeated errors in judgement. I've proposed a Neutron
> governance change here:
>
> https://review.openstack.org/300271

This change would make sense. But will we have core reviewers election?

>
> 2) Now, transform yourself six to twelve months in the future. We now
> face a new problem. Patches are flying in. You're no longer working on
> a dozen patches in parallel. You push up something, it is reviewed
> promptly, and you move on to the next thing. Our next issue is then CI
> run-time. The time it takes to test (Check queue), approve and test a
> patch again (Gate queue) is simply too long. How do we cut this down?
> Again, by using a proven open source methodology of trust. As
> Neutron's testing lieutenant, I hereby propose that we remove the
> tests. Why deal with a problem you can avoid in the first place? The
> Neutron team has been putting out fires in the form of gate issues on
> a weekly basis, double so late in to a release cycle. The gate has so
> many false negatives, the tests are riddled with race conditions,
> we've clearly failed to get testing right. Needless to say, my
> proposal keeps pep8 in place. We all know how important a consistent
> style is. I've proposed a patch that removes Neutron's tests here:
>
> https://review.openstack.org/300272
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] playing tricircle with two node configuration

[Shinobu Kinjo]

_plugin for 
configuration in nova/network/neutronv2/api.py, which therefore leads to none 
in auth_plugin option. I change the files to their original versions, 
respectively. Now I have booted two VMs successfully. Is the solution OK?

BTW, I have some trouble with creating router and I am trying to fix it.

Best regards,
Yipei

On Tue, Mar 29, 2016 at 2:25 PM, joehuang 
<joehu...@huawei.com<mailto:joehu...@huawei.com>> wrote:
I think we can do it later. It's still a little bit strange that if 
nova-network in the Local.conf is disabled at first before devstack 
installation, the devstack should use Neutron instead, not sure how clean 
Yipei's environment is.

I suggest Yipei to use clean virtual machines running in virtualbox, and follow 
the readme[1] and pengfei's experience[2] to install Tricircle.

[1] https://github.com/openstack/tricircle/blob/master/README.md
[2] http://shipengfei92.cn/play_tricircle_with_virtualbox

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com<mailto:shinobu...@gmail.com>]
Sent: Tuesday, March 29, 2016 10:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Yipei Niu
Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node 
configuration
Sorry for interruption.

>> I followed the README.md in github, every thing goes well until I
>> boot virtual machines with the following command

Point here is that even Yipei was following READM provided by us, setting up 
the tricircle was failed. [1] It may be required to review it, I think.

[1] https://github.com/openstack/tricircle/blob/master/README.md

Cheers,
Shinobu


On Tue, Mar 29, 2016 at 11:21 AM, Vega Cai 
<luckyveg...@gmail.com<mailto:luckyveg...@gmail.com>> wrote:
> Hi Yipei,
>
> If you want to use neutron, you need to set "nova_api_class" to
> "nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
> network.
>
> Related code:
> https://github.com/openstack/nova/blob/master/nova/network/__init__.py
> #L47
>
> Simply search "Unknown argument: port" which is the error showed in
> the log in the nova code tree then you can find the above code.
>
> Also, if all the services are running but you want to change some of
> the configuration options, you can just modify the configuration files
> then restart the services, so you can quickly check if your
> modification works without restarting devstack.
>
> BR
> Zhiyuan
>
> On 29 March 2016 at 08:56, Yipei Niu 
> <newy...@gmail.com<mailto:newy...@gmail.com>> wrote:
>>
>> Hi, all,
>>
>> I checked nova.conf and local.conf both.
>>
>> In nova.conf, the option "nova_api_class" is missing while "use_neutron"
>> is set as True. I modify the lib/nova so that the devstack can write
>> "nova_api_class=nova.network.api.API" to nova.conf [1]. However,
>> after installing devstack with tricircle, the same error still happens as 
>> before.
>>
>> In local.conf, n-net is disabled, which is the same as the sample
>> file of tricircle.
>>
>> [1] http://docs.openstack.org/developer/nova/sample_config.html
>>
>> Best regards,
>> Yipei
>>
>> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo 
>> <shinobu...@gmail.com<mailto:shinobu...@gmail.com>>
>> wrote:
>>>
>>> FYI:
>>> This is the reason is that there is still n-net. [1]
>>>
>>> [1]
>>> http://docs.openstack.org/openstack-ops/content/nova-network-depreca
>>> tion.html
>>>
>>> Cheers,
>>> S
>>>
>>> On Mon, Mar 28, 2016 at 5:08 PM, joehuang 
>>> <joehu...@huawei.com<mailto:joehu...@huawei.com>> wrote:
>>> > Hi,
>>> >
>>> >
>>> >
>>> > Agree, it’s quite important not to use Nova-network in devstack.
>>> > In devstack local.conf, make sure the Neutron service is enabled
>>> > and Nova-network is disabled.
>>> >
>>> >
>>> >
>>> > # Use Neutron instead of nova-network
>>> >
>>> > disable_service n-net
>>> >
>>> > enable_service q-svc
>>> >
>>> > enable_service q-svc1
>>> >
>>> > enable_service q-dhcp
>>> >
>>> > enable_service q-agt
>>> >
>>> >
>>> >
>>> > And also check the configuration in Nova to use Neutron
>>> >
>>> >
>>> >
>>> > Best Regards
>>> >
>>> > Chaoyi Huang ( Joe Huang )
>>> >
>>&g

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Shinobu Kinjo]

It may not be best practice what we did here even this time is o.k.

On Tue, Mar 29, 2016 at 5:10 PM, Yipei Niu <newy...@gmail.com> wrote:
> Hi, all,
>
> I follow the advice given by Zhiyuan, and it works. For the port error,
> somebody removes the line "iniset $NOVA_CONF DEFAULT network_api_class
> nova.network.neutronv2.api.API" in lib/neutron-legacy.

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

> For the unknown
> auth_plugin error in the first mail, somebody changes the auth_plugin to
> auth_type in lib/neutron-legacy,

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

> but the loader still searches auth_plugin
> for configuration in nova/network/neutronv2/api.py, which therefore leads to
> none in auth_plugin option. I change the files to their original versions,
> respectively. Now I have booted two VMs successfully. Is the solution OK?
>
> BTW, I have some trouble with creating router and I am trying to fix it.
>
> Best regards,
> Yipei
>
> On Tue, Mar 29, 2016 at 2:25 PM, joehuang <joehu...@huawei.com> wrote:
>>
>> I think we can do it later. It's still a little bit strange that if
>> nova-network in the Local.conf is disabled at first before devstack
>> installation, the devstack should use Neutron instead, not sure how clean
>> Yipei's environment is.
>>
>> I suggest Yipei to use clean virtual machines running in virtualbox, and
>> follow the readme[1] and pengfei's experience[2] to install Tricircle.
>>
>> [1] https://github.com/openstack/tricircle/blob/master/README.md
>> [2] http://shipengfei92.cn/play_tricircle_with_virtualbox
>>
>> Best Regards
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> -Original Message-
>> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> Sent: Tuesday, March 29, 2016 10:48 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: Yipei Niu
>> Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node
>> configuration
>>
>> Sorry for interruption.
>>
>> >> I followed the README.md in github, every thing goes well until I
>> >> boot virtual machines with the following command
>>
>> Point here is that even Yipei was following READM provided by us, setting
>> up the tricircle was failed. [1] It may be required to review it, I think.
>>
>> [1] https://github.com/openstack/tricircle/blob/master/README.md
>>
>> Cheers,
>> Shinobu
>>
>>
>> On Tue, Mar 29, 2016 at 11:21 AM, Vega Cai <luckyveg...@gmail.com> wrote:
>> > Hi Yipei,
>> >
>> > If you want to use neutron, you need to set "nova_api_class" to
>> > "nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
>> > network.
>> >
>> > Related code:
>> > https://github.com/openstack/nova/blob/master/nova/network/__init__.py
>> > #L47
>> >
>> > Simply search "Unknown argument: port" which is the error showed in
>> > the log in the nova code tree then you can find the above code.
>> >
>> > Also, if all the services are running but you want to change some of
>> > the configuration options, you can just modify the configuration files
>> > then restart the services, so you can quickly check if your
>> > modification works without restarting devstack.
>> >
>> > BR
>> > Zhiyuan
>> >
>> > On 29 March 2016 at 08:56, Yipei Niu <newy...@gmail.com> wrote:
>> >>
>> >> Hi, all,
>> >>
>> >> I checked nova.conf and local.conf both.
>> >>
>> >> In nova.conf, the option "nova_api_class" is missing while
>> >> "use_neutron"
>> >> is set as True. I modify the lib/nova so that the devstack can write
>> >> "nova_api_class=nova.network.api.API" to nova.conf [1]. However,
>> >> after installing devstack with tricircle, the same error still happens
>> >> as before.
>> >>
>> >> In local.conf, n-net is disabled, which is the same as the sample
>> >> file of tricircle.
>> >>
>> >> [1] http://docs.openstack.org/developer/nova/sample_config.html
>> >>
>> >> Best regards,
>> >> Yipei
>> >>
>> >> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo <shinobu...@gmail.com>
>> >> wrote:
>> >>>
>> >>> FYI:
>> >>> This is the reason is that there is still n-net. [1]
>> >>>
>> >>> [1]
>> &g

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Shinobu Kinjo]

On Tue, Mar 29, 2016 at 3:25 PM, joehuang <joehu...@huawei.com> wrote:
> I think we can do it later.

Yes, it's not priority at the moment. Priority is to find out what's
going on. But honestly it would be time consuming because of below.

> It's still a little bit strange that if nova-network in the Local.conf is 
> disabled at first before devstack installation, the devstack should use 
> Neutron instead, not sure how clean Yipei's environment is.

It may be difficult to completely clean up envirnment without os fresh
installation.

>
> I suggest Yipei to use clean virtual machines running in virtualbox, and 
> follow the readme[1] and pengfei's experience[2] to install Tricircle.

Yes, it would save our life. Of course **backing up configurations**
is 1st, if necessary.

Cheers,
S

>
> [1] https://github.com/openstack/tricircle/blob/master/README.md
> [2] http://shipengfei92.cn/play_tricircle_with_virtualbox
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Tuesday, March 29, 2016 10:48 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Yipei Niu
> Subject: Re: [openstack-dev] [tricircle] playing tricircle with two node 
> configuration
>
> Sorry for interruption.
>
>>> I followed the README.md in github, every thing goes well until I
>>> boot virtual machines with the following command
>
> Point here is that even Yipei was following READM provided by us, setting up 
> the tricircle was failed. [1] It may be required to review it, I think.
>
> [1] https://github.com/openstack/tricircle/blob/master/README.md
>
> Cheers,
> Shinobu
>
>
> On Tue, Mar 29, 2016 at 11:21 AM, Vega Cai <luckyveg...@gmail.com> wrote:
>> Hi Yipei,
>>
>> If you want to use neutron, you need to set "nova_api_class" to
>> "nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
>> network.
>>
>> Related code:
>> https://github.com/openstack/nova/blob/master/nova/network/__init__.py
>> #L47
>>
>> Simply search "Unknown argument: port" which is the error showed in
>> the log in the nova code tree then you can find the above code.
>>
>> Also, if all the services are running but you want to change some of
>> the configuration options, you can just modify the configuration files
>> then restart the services, so you can quickly check if your
>> modification works without restarting devstack.
>>
>> BR
>> Zhiyuan
>>
>> On 29 March 2016 at 08:56, Yipei Niu <newy...@gmail.com> wrote:
>>>
>>> Hi, all,
>>>
>>> I checked nova.conf and local.conf both.
>>>
>>> In nova.conf, the option "nova_api_class" is missing while "use_neutron"
>>> is set as True. I modify the lib/nova so that the devstack can write
>>> "nova_api_class=nova.network.api.API" to nova.conf [1]. However,
>>> after installing devstack with tricircle, the same error still happens as 
>>> before.
>>>
>>> In local.conf, n-net is disabled, which is the same as the sample
>>> file of tricircle.
>>>
>>> [1] http://docs.openstack.org/developer/nova/sample_config.html
>>>
>>> Best regards,
>>> Yipei
>>>
>>> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo <shinobu...@gmail.com>
>>> wrote:
>>>>
>>>> FYI:
>>>> This is the reason is that there is still n-net. [1]
>>>>
>>>> [1]
>>>> http://docs.openstack.org/openstack-ops/content/nova-network-depreca
>>>> tion.html
>>>>
>>>> Cheers,
>>>> S
>>>>
>>>> On Mon, Mar 28, 2016 at 5:08 PM, joehuang <joehu...@huawei.com> wrote:
>>>> > Hi,
>>>> >
>>>> >
>>>> >
>>>> > Agree, it’s quite important not to use Nova-network in devstack.
>>>> > In devstack local.conf, make sure the Neutron service is enabled
>>>> > and Nova-network is disabled.
>>>> >
>>>> >
>>>> >
>>>> > # Use Neutron instead of nova-network
>>>> >
>>>> > disable_service n-net
>>>> >
>>>> > enable_service q-svc
>>>> >
>>>> > enable_service q-svc1
>>>> >
>>>> > enable_service q-dhcp
>>>> >
>>>> > enable_service q-agt
>>>> >
>>>> >
>>>

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Shinobu Kinjo]

Sorry for interruption.

>> I followed the README.md in github, every thing goes well until I boot 
>> virtual machines with the following command

Point here is that even Yipei was following READM provided by us,
setting up the tricircle was failed. [1] It may be required to review
it, I think.

[1] https://github.com/openstack/tricircle/blob/master/README.md

Cheers,
Shinobu


On Tue, Mar 29, 2016 at 11:21 AM, Vega Cai <luckyveg...@gmail.com> wrote:
> Hi Yipei,
>
> If you want to use neutron, you need to set "nova_api_class" to
> "nova.network.neutronv2.api.API", "nova.network.api.API" is for nova
> network.
>
> Related code:
> https://github.com/openstack/nova/blob/master/nova/network/__init__.py#L47
>
> Simply search "Unknown argument: port" which is the error showed in the log
> in the nova code tree then you can find the above code.
>
> Also, if all the services are running but you want to change some of the
> configuration options, you can just modify the configuration files then
> restart the services, so you can quickly check if your modification works
> without restarting devstack.
>
> BR
> Zhiyuan
>
> On 29 March 2016 at 08:56, Yipei Niu <newy...@gmail.com> wrote:
>>
>> Hi, all,
>>
>> I checked nova.conf and local.conf both.
>>
>> In nova.conf, the option "nova_api_class" is missing while "use_neutron"
>> is set as True. I modify the lib/nova so that the devstack can write
>> "nova_api_class=nova.network.api.API" to nova.conf [1]. However, after
>> installing devstack with tricircle, the same error still happens as before.
>>
>> In local.conf, n-net is disabled, which is the same as the sample file of
>> tricircle.
>>
>> [1] http://docs.openstack.org/developer/nova/sample_config.html
>>
>> Best regards,
>> Yipei
>>
>> On Mon, Mar 28, 2016 at 4:46 PM, Shinobu Kinjo <shinobu...@gmail.com>
>> wrote:
>>>
>>> FYI:
>>> This is the reason is that there is still n-net. [1]
>>>
>>> [1]
>>> http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html
>>>
>>> Cheers,
>>> S
>>>
>>> On Mon, Mar 28, 2016 at 5:08 PM, joehuang <joehu...@huawei.com> wrote:
>>> > Hi,
>>> >
>>> >
>>> >
>>> > Agree, it’s quite important not to use Nova-network in devstack. In
>>> > devstack
>>> > local.conf, make sure the Neutron service is enabled and Nova-network
>>> > is
>>> > disabled.
>>> >
>>> >
>>> >
>>> > # Use Neutron instead of nova-network
>>> >
>>> > disable_service n-net
>>> >
>>> > enable_service q-svc
>>> >
>>> > enable_service q-svc1
>>> >
>>> > enable_service q-dhcp
>>> >
>>> > enable_service q-agt
>>> >
>>> >
>>> >
>>> > And also check the configuration in Nova to use Neutron
>>> >
>>> >
>>> >
>>> > Best Regards
>>> >
>>> > Chaoyi Huang ( Joe Huang )
>>> >
>>> >
>>> >
>>> > From: Vega Cai [mailto:luckyveg...@gmail.com]
>>> > Sent: Monday, March 28, 2016 2:55 PM
>>> > To: Yipei Niu
>>> > Cc: OpenStack Development Mailing List (not for usage questions);
>>> > joehuang
>>> > Subject: Re: [openstack-dev] [tricircle] playing tricircle with two
>>> > node
>>> > configuration
>>> >
>>> >
>>> >
>>> > Hi Yipei,
>>> >
>>> >
>>> >
>>> > Check "network_api_class" and "use_neutron" options in your nova.conf.
>>> > It
>>> > seems that your nova API is not configured to use neutron.
>>> >
>>> >
>>> >
>>> > BR
>>> >
>>> > Zhiyuan
>>> >
>>> >
>>> >
>>> > On 28 March 2016 at 13:25, Yipei Niu <newy...@gmail.com> wrote:
>>> >
>>> > Hi, all,
>>> >
>>> >
>>> >
>>> > After I execute the command "nova boot --flavor 1 --image
>>> > c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
>>> > net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1
>>> > vm1",
>>> > there exist some problem with the argument port. In t-ngw.log, I f

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Shinobu Kinjo]

(self.environ, start_response)
>
>   File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
> __call__
>
> resp = self.call_func(req, *args, **self.kwargs)
>
>   File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
> call_func
>
> return self.func(req, *args, **kwargs)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/oslo_middleware/request_id.py", line
> 37, in __call__
>
> response = req.get_response(self.application)
>
>   File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1317,
> in send
>
> application, catch_exc_info=False)
>
> return self.func(req, *args, **kwargs)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/oslo_middleware/request_id.py", line
> 37, in __call__
>
> response = req.get_response(self.application)
>
>   File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1317,
> in send
>
> application, catch_exc_info=False)
>
>   File "/usr/local/lib/python2.7/dist-packages/pecan/core.py", line 829, in
> __call__
>
> return super(Pecan, self).__call__(environ, start_response)
>
>   File "/usr/local/lib/python2.7/dist-packages/pecan/core.py", line 678, in
> __call__
>
> self.invoke_controller(controller, args, kwargs, state)
>
>   File "/usr/local/lib/python2.7/dist-packages/pecan/core.py", line 572, in
> invoke_controller
>
> result = controller(*args, **kwargs)
>
>   File "/opt/stack/tricircle/tricircle/nova_apigw/controllers/server.py",
> line 376, in post
>
> nics=nics)
>
>   File "/opt/stack/tricircle/tricircle/common/client.py", line 87, in
> handle_args
>
> return func(*args, **kwargs)
>
>   File "/opt/stack/tricircle/tricircle/common/client.py", line 358, in
> create_resources
>
> return handle.handle_create(cxt, resource, *args, **kwargs)
>
>   File "/opt/stack/tricircle/tricircle/common/resource_handle.py", line 227,
> in handle_create
>
> *args, **kwargs).to_dict()
>
>   File "/usr/local/lib/python2.7/dist-packages/novaclient/v2/servers.py",
> line 1038, in create
>
> **boot_kwargs)
>
>   File "/usr/local/lib/python2.7/dist-packages/novaclient/v2/servers.py",
> line 555, in _boot
>
> return_raw=return_raw, **kwargs)
>
>   File "/usr/local/lib/python2.7/dist-packages/novaclient/base.py", line
> 302, in _create
>
> _resp, body = self.api.client.post(url, body=body)
>
>   File "/usr/local/lib/python2.7/dist-packages/novaclient/client.py", line
> 451, in post
>
> return self._cs_request(url, 'POST', **kwargs)
>
>   File "/usr/local/lib/python2.7/dist-packages/novaclient/client.py", line
> 426, in _cs_request
>
> resp, body = self._time_request(url, method, **kwargs)
>
>   File "/usr/local/lib/python2.7/dist-packages/novaclient/client.py", line
> 399, in _time_request
>
> resp, body = self.request(url, method, **kwargs)
>
>   File "/usr/local/lib/python2.7/dist-packages/novaclient/client.py", line
> 393, in request
>
> raise exceptions.from_response(resp, body, url, method)
>
> BadRequest: Unknown argument: port (HTTP 400) (Request-ID:
> req-d6719f21-ee97-49ed-a058-a303b16abcf1)
>
> ^[[00m
>
> 2016-03-28 11:49:44.814 ^[[00;36mINFO eventlet.wsgi.server
> [^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
> admin^[[00;36m] ^[[01;35m^[[00;36m192.168.56.101 "POST
> /v2.1/29a524d386754a94850277afea1e569f/servers HTTP/1.1" status: 500  len:
> 139 time: 2.1919141^[[00m
>
>
>
> Best regards,
>
> Yipei
>
>
>
> On Wed, Mar 23, 2016 at 1:19 PM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
>
> On Wed, Mar 23, 2016 at 12:41 PM, joehuang <joehu...@huawei.com> wrote:
>> Hi, Yipei,
>>
>>
>>
>> When you play Tricircle, it’s important to know that Tricircle is the
>> OpenStack API gateway to other OpenStack instances. In the Readme, Pod1,
>> Pod2 are two OpenStack instances, before trying Tricircle, you can make
>> sure
>> the environment is normal or not by executeing command separately on Pod1,
>> Pod2, just  Nova –os-region-name Pod1, or Nova –os-region-name Pod2, in
>> fact, because Pod1,Pod2 are two normal OpenStack instances, any command to
>> Pod1,Pod2 should be successful.  Otherwise that means there are some issue
>> in the installation of the environment itself. Only when each bottom
>> OpenStack can work correctly, then you can even manually add Tricircle, 

Re: [openstack-dev] [Tricircle] Using the reserved keywords reserved as field name

[Shinobu Kinjo]

Hi Zhipeng,

I've not elaborate on gRPC in detail at all.

What I meant about one of possibilities is that, since gRPC was
designed for fully distributed computing system, the features of this
framework would be available in any kind of distributed computing
system potentially.
Of course it may be necessary to build a new feature of infrastructure
to make use of it, which is quite challenge and would cause a big
change on some layer. But since the OpenStack wouldn't stop growing
because of demands by end-users (I guess), it's worth thinking of that
features for our future.

Cheers,
Shinobu


On Sat, Mar 26, 2016 at 9:48 PM, Zhipeng Huang <zhipengh...@gmail.com> wrote:
> Great:) Do you have any more thoughts on that ?
>
> It might need both Tricircle and bottom OpenStack entity to deploy gRPC
> server and client, while it is ok for Tricircle, it is not easy to mandate
> gRPC endpoints as part of official OpenStack functionality.
>
> The whole point about Tricircle is to ensure Users could manage multiple
> cloud via normal OpenStack API.
>
> Or shall we only use gRPC endpoints internally in Tricircle ? That is to say
> to use it between gateways and Xjobs
>
> On Sat, Mar 26, 2016 at 8:11 PM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
>>
>> Yes, that's one of possibilities.
>>
>> Cheers,
>> Shinobu
>>
>> On Sat, Mar 26, 2016 at 8:55 PM, Zhipeng Huang <zhipengh...@gmail.com>
>> wrote:
>> > any possible that we use gRPC for Tricircle ?
>> >
>> > On Sat, Mar 26, 2016 at 6:11 PM, Shinobu Kinjo <shinobu...@gmail.com>
>> > wrote:
>> >>
>> >> Hi Chaoyi,
>> >>
>> >> Thank you for the pointer.
>> >> I'm also researching privately how we can improve RPC protocol
>> >> reasonably like HTTP2.
>> >> It's quite easy to foreseen that it would be bottleneck, and be able
>> >> not to realize what the Tricircle is trying to do.
>> >> Honestly it's already bottleneck.
>> >>
>> >> Cheers,
>> >> Shinobu
>> >>
>> >> On Sat, Mar 26, 2016 at 6:31 PM, joehuang <joehu...@huawei.com> wrote:
>> >> > Hi, Shinobu,
>> >> >
>> >> > This BP is a good entrance for Tricircle source code, this BP listed
>> >> > the
>> >> > all basic patches building Tricircle from scratches.
>> >> >
>> >> > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless
>> >> >
>> >> > Best Regards
>> >> > Chaoyi Huang ( Joe Huang )
>> >> >
>> >> >
>> >> > -Original Message-
>> >> > From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> >> > Sent: Saturday, March 26, 2016 2:39 PM
>> >> > To: OpenStack Development Mailing List (not for usage questions)
>> >> > Subject: [openstack-dev] [Tricircle] Using the reserved keywords
>> >> > reserved as field name
>> >> >
>> >> > Hi Team,
>> >> >
>> >> > In the Tricircle database, there are three tables having a field name
>> >> > which the MySQL (MariaDB) has as one of the reserved keywords. [1]
>> >> >
>> >> >  Table Name:
>> >> >   aggregate_metadata
>> >> >   instance_type_extra_specs
>> >> >   quality_of_service_specs
>> >> >
>> >> >  Field Name:
>> >> >   key
>> >> >
>> >> > I think it would not be best practice to use any reserved word by the
>> >> > any system because it could cause bug once the component is bigger.
>> >> >
>> >> > What do you think?
>> >> >
>> >> > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html
>> >> >
>> >> > Cheers,
>> >> > Shinobu
>> >> >
>> >> > --
>> >> > Email:
>> >> > shin...@linux.com
>> >> > GitHub:
>> >> > shinobu-x
>> >> > Blog:
>> >> > Life with Distributed Computational System based on OpenSource
>> >> >
>> >> >
>> >> >
>> >> > __
>> >> > OpenStack Development Mailing List (not for usage questions)
>> >> > Unsubscribe:
>> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> > http://lists.openstack.org/cgi-bin/mailma

Re: [openstack-dev] [Tricircle] Using the reserved keywords reserved as field name

[Shinobu Kinjo]

Yes, that's one of possibilities.

Cheers,
Shinobu

On Sat, Mar 26, 2016 at 8:55 PM, Zhipeng Huang <zhipengh...@gmail.com> wrote:
> any possible that we use gRPC for Tricircle ?
>
> On Sat, Mar 26, 2016 at 6:11 PM, Shinobu Kinjo <shinobu...@gmail.com> wrote:
>>
>> Hi Chaoyi,
>>
>> Thank you for the pointer.
>> I'm also researching privately how we can improve RPC protocol
>> reasonably like HTTP2.
>> It's quite easy to foreseen that it would be bottleneck, and be able
>> not to realize what the Tricircle is trying to do.
>> Honestly it's already bottleneck.
>>
>> Cheers,
>> Shinobu
>>
>> On Sat, Mar 26, 2016 at 6:31 PM, joehuang <joehu...@huawei.com> wrote:
>> > Hi, Shinobu,
>> >
>> > This BP is a good entrance for Tricircle source code, this BP listed the
>> > all basic patches building Tricircle from scratches.
>> >
>> > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless
>> >
>> > Best Regards
>> > Chaoyi Huang ( Joe Huang )
>> >
>> >
>> > -Original Message-
>> > From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> > Sent: Saturday, March 26, 2016 2:39 PM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: [openstack-dev] [Tricircle] Using the reserved keywords
>> > reserved as field name
>> >
>> > Hi Team,
>> >
>> > In the Tricircle database, there are three tables having a field name
>> > which the MySQL (MariaDB) has as one of the reserved keywords. [1]
>> >
>> >  Table Name:
>> >   aggregate_metadata
>> >   instance_type_extra_specs
>> >   quality_of_service_specs
>> >
>> >  Field Name:
>> >   key
>> >
>> > I think it would not be best practice to use any reserved word by the
>> > any system because it could cause bug once the component is bigger.
>> >
>> > What do you think?
>> >
>> > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html
>> >
>> > Cheers,
>> > Shinobu
>> >
>> > --
>> > Email:
>> > shin...@linux.com
>> > GitHub:
>> > shinobu-x
>> > Blog:
>> > Life with Distributed Computational System based on OpenSource
>> >
>> >
>> > __
>> > 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
>>
>>
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __
>> 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
>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Using the reserved keywords reserved as field name

[Shinobu Kinjo]

Hi Vega,

Thank you for your quick action.

Cheers,
Shinobu


On Sat, Mar 26, 2016 at 6:39 PM, Vega Cai <luckyveg...@gmail.com> wrote:
> Added a work item in phase 4 in our todo list:
>
> https://etherpad.openstack.org/p/TricircleToDo
>
> On 26 March 2016 at 17:31, joehuang <joehu...@huawei.com> wrote:
>>
>> Hi, Shinobu,
>>
>> This BP is a good entrance for Tricircle source code, this BP listed the
>> all basic patches building Tricircle from scratches.
>>
>> https://blueprints.launchpad.net/tricircle/+spec/implement-stateless
>>
>> Best Regards
>> Chaoyi Huang ( Joe Huang )
>>
>>
>> -Original Message-
>> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
>> Sent: Saturday, March 26, 2016 2:39 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved
>> as field name
>>
>> Hi Team,
>>
>> In the Tricircle database, there are three tables having a field name
>> which the MySQL (MariaDB) has as one of the reserved keywords. [1]
>>
>>  Table Name:
>>   aggregate_metadata
>>   instance_type_extra_specs
>>   quality_of_service_specs
>>
>>  Field Name:
>>   key
>>
>> I think it would not be best practice to use any reserved word by the any
>> system because it could cause bug once the component is bigger.
>>
>> What do you think?
>>
>> [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html
>>
>> Cheers,
>> Shinobu
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __
>> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Using the reserved keywords reserved as field name

[Shinobu Kinjo]

Hi Chaoyi,

Thank you for the pointer.
I'm also researching privately how we can improve RPC protocol
reasonably like HTTP2.
It's quite easy to foreseen that it would be bottleneck, and be able
not to realize what the Tricircle is trying to do.
Honestly it's already bottleneck.

Cheers,
Shinobu

On Sat, Mar 26, 2016 at 6:31 PM, joehuang <joehu...@huawei.com> wrote:
> Hi, Shinobu,
>
> This BP is a good entrance for Tricircle source code, this BP listed the all 
> basic patches building Tricircle from scratches.
>
> https://blueprints.launchpad.net/tricircle/+spec/implement-stateless
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Saturday, March 26, 2016 2:39 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved as 
> field name
>
> Hi Team,
>
> In the Tricircle database, there are three tables having a field name which 
> the MySQL (MariaDB) has as one of the reserved keywords. [1]
>
>  Table Name:
>   aggregate_metadata
>   instance_type_extra_specs
>   quality_of_service_specs
>
>  Field Name:
>   key
>
> I think it would not be best practice to use any reserved word by the any 
> system because it could cause bug once the component is bigger.
>
> What do you think?
>
> [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Using the reserved keywords reserved as field name

[Shinobu Kinjo]

Hi Team,

In the Tricircle database, there are three tables having a field name
which the MySQL (MariaDB) has as one of the reserved keywords. [1]

 Table Name:
  aggregate_metadata
  instance_type_extra_specs
  quality_of_service_specs

 Field Name:
  key

I think it would not be best practice to use any reserved word by the
any system because it could cause bug once the component is bigger.

What do you think?

[1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Using in-memory database for unit tests

[Shinobu Kinjo]

On Wed, Mar 23, 2016 at 2:33 PM, Vega Cai <luckyveg...@gmail.com> wrote:
>
>
> On 22 March 2016 at 12:09, Shinobu Kinjo <shinobu...@gmail.com> wrote:
>>
>> Thank you for your comment (inline for my message).
>>
>> On Tue, Mar 22, 2016 at 11:53 AM, Vega Cai <luckyveg...@gmail.com> wrote:
>> > Let me try to explain some.
>> >
>> > On 22 March 2016 at 10:09, Shinobu Kinjo <shinobu...@gmail.com> wrote:
>> >>
>> >> On Tue, Mar 22, 2016 at 10:22 AM, joehuang <joehu...@huawei.com> wrote:
>> >> > Hello, Shinobu,
>> >> >
>> >> > Yes, as what you described here, the "initialize" in "core.py" is
>> >> > used
>> >> > for unit/function test only. For system integration test( for
>> >> > example,
>> >> > tempest ), it would be better to use mysql like DB, this is done by
>> >> > the
>> >> > configuration in DB part.
>> >>
>> >> Thank you for your thought.
>> >>
>> >> >
>> >> > From my point of view, the tricircle DB part could be enhanced in the
>> >> > DB
>> >> > model and migration scripts. Currently unit test use DB model to
>> >> > initialize
>> >> > the data base, but not using the migration scripts,
>> >>
>> >> I'm assuming the migration scripts are in "tricircle/db". Is it right?
>> >
>> >
>> > migration scripts are in tricircle/db/migrate_repo
>> >>
>> >>
>> >> What is the DB model?
>> >> Why do we need 2-way-methods at the moment?
>> >
>> >
>> > DB models are defined in tricircle/db/models.py. Models.py defines
>> > tables in
>> > object level, so other modules can import models.py then operate the
>> > tables
>> > by operating the objects. Migration scripts defines tables in table
>> > level,
>> > you define table fields, constraints in the scripts then migration tool
>> > will
>> > read the scripts and build the tables.
>>
>> Dose "models.py" manage database schema(e.g., create / delete columns,
>> tables, etc)?
>
>
> In "models.py" we only define database schema. SQLAlchemy provides
> functionality to create tables based on schema definition, which is
> "ModelBase.metadata.create_all". This is used to initialized the in-memory
> database for tests currently.
>>
>>
>> > Migration tool has a feature to
>> > generate migration scripts from DB models automatically but it may make
>> > mistakes sometimes, so currently we manually maintain the table
>> > structure in
>> > both DB model and migration scripts.
>>
>> Is *migration tool* different from bot DB models and migration scripts?
>
>
> Migration tool is Alembic, a lightweight database migration tool for usage
> of SQLAlchemy:
>
> https://alembic.readthedocs.org/en/latest/
>
> It runs migration scripts to update database schema. Each database version
> has one migrate script. After defining "upgrade" and "downgrade" method in
> the script, you can update your database from one version to another
> version. Alembic isn't aware of DB models defined in "models.py", users need
> to guarantee the version of database and the version of "models.py" match.
>
> If you create a new database, both "ModelBase.metadata.create_all" and
> Alembic can be used. But Alembic can also be used to update an existing
> database to a specific version of schema.

Thank you for your additional explanation.
Those inputs save my life.

Cheers,
S

>>
>>
>> >>
>> >>
>> >> > so the migration scripts can only be tested when using devstack for
>> >> > integration test. It would better to using migration script to
>> >> > instantiate
>> >> > the DB, and tested in the unit test too.
>> >>
>> >> If I understand you correctly, we are moving forward to using the
>> >> migration scripts for both unit and integration tests.
>> >>
>> >> Cheers,
>> >> Shinobu
>> >>
>> >> >
>> >> > (Also move the discussion to the openstack-dev mail-list)
>> >> >
>> >> > Best Regards
>> >> > Chaoyi Huang ( joehuang )
>> >> >
>> >> > -Original Message-
>> >> > From: Shinobu Kinjo [mailto:ski...@re

Re: [openstack-dev] [tricircle] playing tricircle with two node configuration

[Shinobu Kinjo]

On Wed, Mar 23, 2016 at 12:41 PM, joehuang  wrote:
> Hi, Yipei,
>
>
>
> When you play Tricircle, it’s important to know that Tricircle is the
> OpenStack API gateway to other OpenStack instances. In the Readme, Pod1,
> Pod2 are two OpenStack instances, before trying Tricircle, you can make sure
> the environment is normal or not by executeing command separately on Pod1,
> Pod2, just  Nova –os-region-name Pod1, or Nova –os-region-name Pod2, in
> fact, because Pod1,Pod2 are two normal OpenStack instances, any command to
> Pod1,Pod2 should be successful.  Otherwise that means there are some issue
> in the installation of the environment itself. Only when each bottom
> OpenStack can work correctly, then you can even manually add Tricircle, or
> through the scripts in the github to install Tircircle automaticly, as the
> API gateway to Pod1 and Pod2, just like you add one load balancer before
> your multiple web servers.

Yeah, above explanation is really essential for the tricircle.

>
>
>
> After the Tricircle was added, then the API will flow from Tricircle
> services like Nova-APIGW/Cinder-APIGW/Neutron API to the bottom Pod1, Pod2.
>
>
>
> So if you use Nova boot, and some error happened, you can ask question:
>
> 1.  Is the command sent to the Tricircle Nova-APIGW?
>
> 2.  What’ll will do for the Nova-APIGW for the next step?
>
> 3.  Is the API request forwarded by Tricircle correctly to the proper
> bottom OpenStack?
>
> 4.  Is the bottom OpenStack working normal even without Tricircle?
>
> 5.  Is the API request forwarded by Tricircle includes the correct
> request content?
>
> 6.  …
>
>
>
> You can carry the map before you try to fix the issue. And break down a big
> system into smaller part, and make sure which part works fine, which not in
> order.
>
>
>
> From the information you provided, can’t make judgment the error is occurred
> at Tricircle services, or bottom pod, or which pod. Don’t know which step
> the error occurred. And don’t know the request information, how the
> requested will be routed and processed, a lot of context needed to diagnose
> an error.
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
>
> From: Yipei Niu [mailto:newy...@gmail.com]
> Sent: Wednesday, March 23, 2016 10:36 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: joehuang; Zhiyuan Cai
> Subject: [tricircle] playing tricircle with two node configuration
>
>
>
> Hi, Joe and Zhiyuan,
>
>
>
> I have already finished installing devstack in two nodes with tricircle. I
> encounter some errors when testing cross-pod L3 networking with DevStack. I
> followed the README.md in github, every thing goes well until I boot virtual
> machines with the following command:
>
>
>
> nova boot --flavor 1 --image 60a8184b-a4be-463d-a8a1-48719edc37a3 --nic
> net-id=76356099-f3bd-40a5-83bd-600b78b671eb --availability-zone az1 vm1
>
>
>
> The info in the terminal is as follows:
>
> Your request was processed by a Nova API which does not support
> microversions (X-OpenStack-Nova-API-Version header is missing from
> response). Warning: Response may be incorrect.
>
> Your request was processed by a Nova API which does not support
> microversions (X-OpenStack-Nova-API-Version header is missing from
> response). Warning: Response may be incorrect.
>
> Your request was processed by a Nova API which does not support
> microversions (X-OpenStack-Nova-API-Version header is missing from
> response). Warning: Response may be incorrect.
>
> ERROR (ClientException): Unknown Error (HTTP 500)
>
>
>
> I run rejoin-stack.sh and find some error in n-api screen. In n-api.log, the
> error is as follows:
>
> 2016-03-22 19:19:38.248 ^[[01;31mERROR nova.api.openstack.extensions
> [^[[01;36mreq-cf58e7aa-bd7d-483f-aa57-bca5268ce963 ^[[00;36madmin
> admin^[[01;31m] ^[[01;35m^[[01;31mUnexpected exception in API method^[[00m
>
> ^[[01;31m2016-03-22 19:19:38.248 TRACE nova.api.openstack.extensions
> ^[[01;35m^[[00mTraceback (most recent call last):
>
> ^[[01;31m2016-03-22 19:19:38.248 TRACE nova.api.openstack.extensions
> ^[[01;35m^[[00m  File "/opt/stack/nova/nova/api/openstack/extensions.py",
> line 478, in wrapped
>
> ^[[01;31m2016-03-22 19:19:38.248 TRACE nova.api.openstack.extensions
> ^[[01;35m^[[00mreturn f(*args, **kwargs)
>
> ^[[01;31m2016-03-22 19:19:38.248 TRACE nova.api.openstack.extensions
> ^[[01;35m^[[00m  File "/opt/stack/nova/nova/api/validation/__init__.py",
> line 73, in wrapper
>
> ^[[01;31m2016-03-22 19:19:38.248 TRACE nova.api.openstack.extensions
> ^[[01;35m^[[00mreturn func(*args, **kwargs)
>
> ^[[01;31m2016-03-22 19:19:38.248 TRACE nova.api.openstack.extensions
> ^[[01;35m^[[00m  File "/opt/stack/nova/nova/api/validation/__init__.py",
> line 73, in wrapper
>
> ^[[01;31m2016-03-22 19:19:38.248 TRACE nova.api.openstack.extensions
> ^[[01;35m^[[00mreturn func(*args, **kwargs)
>
> ^[[01;31m2016-03-22 19:19:38.248 TRACE nova.api.openstack.extensions
> 

Re: [openstack-dev] [tricircle] Using in-memory database for unit tests

[Shinobu Kinjo]

Thank you for your comment (inline for my message).

On Tue, Mar 22, 2016 at 11:53 AM, Vega Cai <luckyveg...@gmail.com> wrote:
> Let me try to explain some.
>
> On 22 March 2016 at 10:09, Shinobu Kinjo <shinobu...@gmail.com> wrote:
>>
>> On Tue, Mar 22, 2016 at 10:22 AM, joehuang <joehu...@huawei.com> wrote:
>> > Hello, Shinobu,
>> >
>> > Yes, as what you described here, the "initialize" in "core.py" is used
>> > for unit/function test only. For system integration test( for example,
>> > tempest ), it would be better to use mysql like DB, this is done by the
>> > configuration in DB part.
>>
>> Thank you for your thought.
>>
>> >
>> > From my point of view, the tricircle DB part could be enhanced in the DB
>> > model and migration scripts. Currently unit test use DB model to initialize
>> > the data base, but not using the migration scripts,
>>
>> I'm assuming the migration scripts are in "tricircle/db". Is it right?
>
>
> migration scripts are in tricircle/db/migrate_repo
>>
>>
>> What is the DB model?
>> Why do we need 2-way-methods at the moment?
>
>
> DB models are defined in tricircle/db/models.py. Models.py defines tables in
> object level, so other modules can import models.py then operate the tables
> by operating the objects. Migration scripts defines tables in table level,
> you define table fields, constraints in the scripts then migration tool will
> read the scripts and build the tables.

Dose "models.py" manage database schema(e.g., create / delete columns,
tables, etc)?

> Migration tool has a feature to
> generate migration scripts from DB models automatically but it may make
> mistakes sometimes, so currently we manually maintain the table structure in
> both DB model and migration scripts.

Is *migration tool* different from bot DB models and migration scripts?

>>
>>
>> > so the migration scripts can only be tested when using devstack for
>> > integration test. It would better to using migration script to instantiate
>> > the DB, and tested in the unit test too.
>>
>> If I understand you correctly, we are moving forward to using the
>> migration scripts for both unit and integration tests.
>>
>> Cheers,
>> Shinobu
>>
>> >
>> > (Also move the discussion to the openstack-dev mail-list)
>> >
>> > Best Regards
>> > Chaoyi Huang ( joehuang )
>> >
>> > -Original Message-
>> > From: Shinobu Kinjo [mailto:ski...@redhat.com]
>> > Sent: Tuesday, March 22, 2016 7:43 AM
>> > To: joehuang; khayam.gondal; zhangbinsjtu; shipengfei92; newypei;
>> > Liuhaixia; caizhiyuan (A); huangzhipeng
>> > Subject: Using in-memory database for unit tests
>> >
>> > Hello,
>> >
>> > In "initialize" method defined in "core.py", we're using *in-memory*
>> > strategy making use of sqlite. AFAIK we are using this solution for only
>> > testing purpose. Unit tests using this solution should be fine for small
>> > scale environment. But it's not good enough even it's for testing.
>> >
>> > What do you think?
>> > Any thought, suggestion would be appreciated.
>> >
>> > [1]
>> > https://github.com/openstack/tricircle/blob/master/tricircle/db/core.py#L124-L127
>> >
>> > Cheers,
>> > Shinobu
>> >
>> > __
>> > 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
>>
>>
>>
>> --
>> Email:
>> shin...@linux.com
>> GitHub:
>> shinobu-x
>> Blog:
>> Life with Distributed Computational System based on OpenSource
>>
>> __
>> 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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Using in-memory database for unit tests

[Shinobu Kinjo]

On Tue, Mar 22, 2016 at 10:22 AM, joehuang <joehu...@huawei.com> wrote:
> Hello, Shinobu,
>
> Yes, as what you described here, the "initialize" in "core.py" is used for 
> unit/function test only. For system integration test( for example, tempest ), 
> it would be better to use mysql like DB, this is done by the configuration in 
> DB part.

Thank you for your thought.

>
> From my point of view, the tricircle DB part could be enhanced in the DB 
> model and migration scripts. Currently unit test use DB model to initialize 
> the data base, but not using the migration scripts,

I'm assuming the migration scripts are in "tricircle/db". Is it right?

What is the DB model?
Why do we need 2-way-methods at the moment?

> so the migration scripts can only be tested when using devstack for 
> integration test. It would better to using migration script to instantiate 
> the DB, and tested in the unit test too.

If I understand you correctly, we are moving forward to using the
migration scripts for both unit and integration tests.

Cheers,
Shinobu

>
> (Also move the discussion to the openstack-dev mail-list)
>
> Best Regards
> Chaoyi Huang ( joehuang )
>
> -Original Message-
> From: Shinobu Kinjo [mailto:ski...@redhat.com]
> Sent: Tuesday, March 22, 2016 7:43 AM
> To: joehuang; khayam.gondal; zhangbinsjtu; shipengfei92; newypei; Liuhaixia; 
> caizhiyuan (A); huangzhipeng
> Subject: Using in-memory database for unit tests
>
> Hello,
>
> In "initialize" method defined in "core.py", we're using *in-memory* strategy 
> making use of sqlite. AFAIK we are using this solution for only testing 
> purpose. Unit tests using this solution should be fine for small scale 
> environment. But it's not good enough even it's for testing.
>
> What do you think?
> Any thought, suggestion would be appreciated.
>
> [1] 
> https://github.com/openstack/tricircle/blob/master/tricircle/db/core.py#L124-L127
>
> Cheers,
> Shinobu
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] [Manila] Mitaka RC1 done

[Shinobu Kinjo]

On Sun, Mar 20, 2016 at 9:34 AM, Ben Swartzlander  wrote:
> Thanks everyone for the hard work getting RC1 done. We had record high
> number of bugs at feature freeze this cycle, and we ended up pushing a few
> out, but there were SIXTY bugs fixed in the last 2 weeks which I consider a
> great accomplishment!
>
> Soon the official RC1 tag should be posted and everyone should start testing
> the release to look for any bugs we missed. While you wait for the tag, go
> ahead and vote for one of these logo designs for the stickers in Austin:
>
> http://surveymonkey.com/r/J8266ZH

Nice -;

Cheers,
S

>
> -Ben Swartzlander
>
>
> __
> 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] [jacket] Introduction to jacket, a new project

[Shinobu Kinjo]

Thank you for your explanation in detail.

On Thu, Mar 17, 2016 at 12:57 PM, zs <okay22m...@163.com> wrote:
> Hi Shinobu,
>
> There are some differences between clouds, the major task of jacket is how
> to shield the differences. So that jacket will not be an API gateway, it has
> the objects management and function processing, for example :
> 1.  Unified resource uuid allocation: When users call jacket resource create
> API, jacket will allocate the uuid for the resource according to jacket's
> uuid format, then jacket will associate it with the unique identification in
> provider cloud, because of the different unique identification and the
> different behaviour in clouds.

The Jacket will absorb the difference between clouds, won't it?

> e.g.  a)  AWS can't support to create a volume from an AMI image and
> boot a virtual machine from a boot volume, so that when users create a
> volume from an image, jacket will just create a volume record in database,
> after the virtual machine is created in AWS, jacket will get the boot
> volume's uuid in AWS and write the relations into the mapping table in
> database.
> b) Creating a volume's snapshot, AWS will return a job id, and
> users will get the snapshot's id after the job startes. Jacket will return
> the snapshot's id in jacket, then jacket will query the snapshot's id in AWS
> and  write the relations into the mapping table in database.
>

Then will the Tricircle make use of mapped uuid to manage whatever
created resource, If both components will interact each other?

> 2. Fake volume management: Some clouds have not the complete volume
> management, for example, VMware vCloud Director have no the boot volume
> object, and it can't support volume's backup and snapshot, so that jacket
> will implement these functions for this kind of clouds.
>

Reading your explanation, at the initial stage of the Jacket, it seems
to focus on management of the Cinder resource, but it aims to:

> There will be more differences of clouds' behaviour and function. Jacket's
> target is to shield these differences and let users feel that
they are using
> just one cloud.

Cheers,
Shinobu

> Thanks.
>
> Best Regards,
> Kevin (Sen Zhang)
>
>
> At 2016-03-17 05:47:35, "Shinobu Kinjo" <shinobu...@gmail.com> wrote:
>>On Wed, Mar 16, 2016 at 9:58 PM, zs <okay22m...@163.com> wrote:
>>> Hi Gordon,
>>>
>>> Thank you for your suggestion.
>>>
>>> I think jacket is different from tricircle. Because tricircle focuses on
>>> OpenStack deployment across multiple sites, but jacket focuses on how to
>>> manage the different clouds just like one cloud.  There are some
>>> differences:
>>> 1. Account management and API model: Tricircle faces multiply OpenStack
>>> instances which can share one Keystone and have the same API model, but
>>> jacket will face the different clouds which have the respective service
>>> and
>>> different API model. For example, VMware vCloud Director has no volume
>>> management like OpenStack and AWS, jacket will offer a fake volume
>>> management for this kind of cloud.
>>
>>The Jacket will be kind of API gateway for different cloud systems, won't
>> it?
>>
>>> 2. Image management: One image just can run in one cloud, jacket need
>>> consider how to solve this problem.
>>> 3. Flavor management: Different clouds have different flavors which can
>>> not
>>> be operated by users. Jacket will face this problem but there will be no
>>> this problem in tricircle.
>>> 4. Legacy resources adoption: Because of the different API modles, it
>>> will
>>> be a huge challenge for jacket.
>>>
>>> I think it is maybe a good solution that jacket works to unify the API
>>> model
>>> for different clouds, and then using tricircle to offer the management of
>>> a
>>> large scale VMs.
>>>
>>> Best Regards,
>>> Kevin (Sen Zhang)
>>>
>>>
>>> At 2016-03-16 19:51:33, "gordon chung" <g...@live.ca> wrote:
>>>>
>>>>
>>>>On 16/03/2016 4:03 AM, zs wrote:
>>>>> Hi all,
>>>>>
>>>>> There is a new project "jacket" to manage multiply clouds. The jacket
>>>>> wiki is: https://wiki.openstack.org/wiki/Jacket
>>>>>   Please review it and give your comments. Thanks.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Kevin (Sen Zhang)
>>>>>
&g

Re: [openstack-dev] [jacket] Introduction to jacket, a new project

[Shinobu Kinjo]

On Wed, Mar 16, 2016 at 9:58 PM, zs  wrote:
> Hi Gordon,
>
> Thank you for your suggestion.
>
> I think jacket is different from tricircle. Because tricircle focuses on
> OpenStack deployment across multiple sites, but jacket focuses on how to
> manage the different clouds just like one cloud.  There are some
> differences:
> 1. Account management and API model: Tricircle faces multiply OpenStack
> instances which can share one Keystone and have the same API model, but
> jacket will face the different clouds which have the respective service and
> different API model. For example, VMware vCloud Director has no volume
> management like OpenStack and AWS, jacket will offer a fake volume
> management for this kind of cloud.

The Jacket will be kind of API gateway for different cloud systems, won't it?

> 2. Image management: One image just can run in one cloud, jacket need
> consider how to solve this problem.
> 3. Flavor management: Different clouds have different flavors which can not
> be operated by users. Jacket will face this problem but there will be no
> this problem in tricircle.
> 4. Legacy resources adoption: Because of the different API modles, it will
> be a huge challenge for jacket.
>
> I think it is maybe a good solution that jacket works to unify the API model
> for different clouds, and then using tricircle to offer the management of  a
> large scale VMs.
>
> Best Regards,
> Kevin (Sen Zhang)
>
>
> At 2016-03-16 19:51:33, "gordon chung"  wrote:
>>
>>
>>On 16/03/2016 4:03 AM, zs wrote:
>>> Hi all,
>>>
>>> There is a new project "jacket" to manage multiply clouds. The jacket
>>> wiki is: https://wiki.openstack.org/wiki/Jacket
>>>   Please review it and give your comments. Thanks.
>>>
>>> Best Regards,
>>>
>>> Kevin (Sen Zhang)
>>>
>>>
>>
>>i don't know exact details of either project, but i suggest you
>>collaborate with tricircle project[1] because it seems you are
>>addressing the same user story (and in a very similar fashion). not sure
>>if it's a user story for OpenStack itself, but no point duplicating
>> efforts.
>>
>>[1] https://wiki.openstack.org/wiki/Tricircle
>>
>>cheers,
>>
>>--
>>gord
>>
>>__
>>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
>



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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