Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Nachi Ueno
Hi folks I think this thread is still mixing topics. I feel we can archive 1000 mails :P so let me name it and let me write my thought on this. [Topic1] Nova parity priority I do understand concern and this is highest priority. However, group based policy effort won't slower this effort. Bec

Re: [openstack-dev] [Nova] network_rpcapi.migrate_instance_start

2014-07-22 Thread Nachi Ueno
Hi Russell Thanks. I got it. 2014-07-22 14:21 GMT-07:00 Russell Bryant : > On 07/21/2014 04:10 PM, Nachi Ueno wrote: >> Hi nova folks >> >> QQ: Who uses migrate_instance_start/finish, and why we need this rpc call? >> >> I greped code but I couldn't f

[openstack-dev] [Nova] network_rpcapi.migrate_instance_start

2014-07-21 Thread Nachi Ueno
Hi nova folks QQ: Who uses migrate_instance_start/finish, and why we need this rpc call? I greped code but I couldn't find implementation for it. https://github.com/openstack/nova/blob/372c54927ab4f6c226f5a1a2aead40b89617cf77/nova/network/manager.py#L1683 Best Nachi ___

Re: [openstack-dev] [Neutron] minimal device driver for VPN

2014-07-16 Thread Nachi Ueno
QQ: do you have __init__.py in the directory? 2014-07-16 11:43 GMT-07:00 Julio Carlos Barrera Juez < juliocarlos.barr...@i2cat.net>: > I am fighting with this for months. I want to develop a VPN Neutron > plugin, but it is almost impossible to realize how to achieve it. this is a > thread I open

Re: [openstack-dev] [neutron]Performance of security group

2014-06-19 Thread Nachi Ueno
Hi folks Thank you for your starting this topic. Let me share some of my ideas (1) Improve security_group_rules_for_devices In current implementation, we are generating rules per port in server side. It is something like this. port1[SG_Rule1, SG_Rule2, SG_Rule3] .. port2, port3 This can be imp

Re: [openstack-dev] [neutron] Can tenants provide hints to router scheduling?

2014-06-13 Thread Nachi Ueno
Hi Paul I think this flavor bp is related. https://review.openstack.org/#/c/90070/ By using flavor, you can specify the flavor for routers ( high bandwidth or low bandwidth ) such as VM (vCPU vMemory etc). I don't see any bp for flavor based scheduling yet, but IMO it is great we could have such s

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

2014-06-05 Thread Nachi Ueno
> Yamamoto Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. >Yong Ya, we have already decided to have the driver architecture. IMO, this discussion is for reference impl. 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : > I think maybe we can device a kind of framework so that we can plu

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

2014-05-30 Thread Nachi Ueno
Hi folks ExaBGP won't suit for BGPVPN implementation because it isn't support vpnv4. Ryu is supporting it, however they have no internal api to binding neutron network & route target. so I think contrail is a only solution for BGPVPN implementation now. 2014-05-30 2:22 GMT-07:00 Mathieu Rohon

[openstack-dev] [Neutron] How about deprecate cfg.CONF.allow_overlapping_ips?

2014-05-29 Thread Nachi Ueno
Hi folks Today, we are can change allow overlapping ips or not by configuration. This has impact of database design, and actually, this flag complicate the implementations. Whey we have this flag is a historical reason. This was needed when many OS don't support namespaces, however Most of OS sup

Re: [openstack-dev] Policy for linking bug or bp in commit message

2014-05-29 Thread Nachi Ueno
I like the idea 2014-05-29 8:33 GMT-07:00 Yuriy Taraday : > On Wed, May 28, 2014 at 3:54 AM, Joe Gordon wrote: >> >> On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno wrote: >>> >>> (2) Avoid duplication of works >>> I have several experience of this. Anywa

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-05-28 Thread Nachi Ueno
Hi Zang Since, SSL-VPN for Juno bp is approved in neturon-spec, I would like to restart this work. Could you share your code if it is possible? Also, Let's discuss how we can collaborate in here. Best Nachi 2014-05-01 14:40 GMT-07:00 Nachi Ueno : > Hi folks > >> Clint >

Re: [openstack-dev] Policy for linking bug or bp in commit message

2014-05-28 Thread Nachi Ueno
comment for requesting bug report. Best Nachi 2014-05-27 16:54 GMT-07:00 Joe Gordon : > > > > On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno wrote: >> >> Hi Ben, Joe >> >> Thank you for your reply >> >> (2) Avoid duplication of works >> I have s

Re: [openstack-dev] Policy for linking bug or bp in commit message

2014-05-23 Thread Nachi Ueno
at 4:02 AM, Joe Gordon wrote: >> >> >> >> >> On Sat, May 24, 2014 at 2:23 AM, Nachi Ueno wrote: >>> >>> Hi folks >>> >>> I believed we should link bug or bp for any commit except automated >>> commit by infra. >>> However, I

[openstack-dev] Policy for linking bug or bp in commit message

2014-05-23 Thread Nachi Ueno
Hi folks I believed we should link bug or bp for any commit except automated commit by infra. However, I found also there is no written policy for this. so may be, I'm wrong for here. The reason, we need bug or bp linked , is (1) Triage for core reviewing (2) Avoid duplication of works (3) Relea

Re: [openstack-dev] [Neutron] Introducing task oriented workflows

2014-05-22 Thread Nachi Ueno
Hi Salvatore Thank you for your posting this. IMO, this topic shouldn't be limited for Neutron only. Users wants consistent API between OpenStack project, right? In Nova, a server has task_state, so Neutron should do same way. 2014-05-22 15:34 GMT-07:00 Salvatore Orlando : > As most of you pr

Re: [openstack-dev] [neutron] Proposed changes to core team

2014-05-21 Thread Nachi Ueno
+1! Carl is doing great contribution for the community. He is really active on reviews with very high quality comments. His input based on large scale deployment is also very valuable for the community. 2014-05-21 13:59 GMT-07:00 Kyle Mestery : > I would like to propose a few changes to the Neut

Re: [openstack-dev] [ReviewStat] WebUI for review stat

2014-05-20 Thread Nachi Ueno
Hi folks I could deploy it on openshift http://reviewstat-nachi.rhcloud.com/ 2014-05-19 20:36 GMT-07:00 Nachi Ueno : > Hi Boris > > Ya, I know this stats. > The primary usecase for this patch is helping reviewer assignment for > each patch. > > 2014-05-19 18:50 GMT-07:00 B

Re: [openstack-dev] [ReviewStat] WebUI for review stat

2014-05-19 Thread Nachi Ueno
ntribution/neutron/30 > > Best regards, > Boris Pavlovic > > > > > On Tue, May 20, 2014 at 5:20 AM, Nachi Ueno wrote: >> >> Hi folks >> >> As per neutron discussion, we agreed there is really important to >> distribute >> core-review

[openstack-dev] [ReviewStat] WebUI for review stat

2014-05-19 Thread Nachi Ueno
Hi folks As per neutron discussion, we agreed there is really important to distribute core-reviewer loads. so we got an idea to specify primary/secondary reviewers for each reviews. IMO, this is almost impossible without some helper tool. so, I wrote it. https://www.youtube.com/watch?v=ouS5h5

[openstack-dev] [Barbican][Neturon] Cred management for ssl-vpn

2014-05-07 Thread Nachi Ueno
Hi Barbican folks I'm trying to rewrite existing ssl-vpn bp with integration with barbican. so I'm really appliciate if I can get your input. In original proposal, we have vpn credential resource who has followings - id - ca (PEM encoded) - server_certificate (PEM encoded) - server_key (PEM enco

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-05-01 Thread Nachi Ueno
enVPN process download key to memory >> >> directly from Babican? >> >> >> >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham : >> >> > Excuse me interrupting but couldn't you treat the key as largely >> >> > ephemeral, pull it down f

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-05-01 Thread Nachi Ueno
u treat the key as largely >> > ephemeral, pull it down from Barbican, start the OpenVPN process and >> > then purge the key? It would of course still be resident in the memory >> > of the OpenVPN process but should otherwise be protected against >> > filesys

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-05-01 Thread Nachi Ueno
ican, start the OpenVPN process and > then purge the key? It would of course still be resident in the memory > of the OpenVPN process but should otherwise be protected against > filesystem disk-residency issues. > > >> -Original Message- >> From: Nachi Ueno [mailto

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-05-01 Thread Nachi Ueno
ig file. If the config files are generated and > can be stored, then storing the whole config file in Barbican protects the > private key (and any other settings) without having to try to deliver the > key to the OpenVPN endpoint in some non-standard way. > > > Jarret > > On 4/

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-30 Thread Nachi Ueno
> Jarret Thanks! Currently, the config will be generated on demand by the agent. What's merit storing entire config in the Barbican? > Kyle Thanks! 2014-04-30 7:05 GMT-07:00 Kyle Mestery : > On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno wrote: >> Hi Clint >> >&g

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Nachi Ueno
of 2014-04-29 10:58:53 -0700: >> Hi Kyle >> >> 2014-04-29 10:52 GMT-07:00 Kyle Mestery : >> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: >> >> Hi Zang >> >> >> >> Thank you for your contribution on this! >> >> The p

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Nachi Ueno
Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery : > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote: >> Hi Zang >> >> Thank you for your contribution on this! >> The private key management is what I want to discuss in the summit. >> > Has the idea of

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Nachi Ueno
Hi Zang Thank you for your contribution on this! The private key management is what I want to discuss in the summit. [1] We are depending DB security, anyway When we get stolen the private key in the DB, it means we are also stolen ID/PW for DB. If we stolen the key, even if we keep the private k

Re: [openstack-dev] [Neutron] review hour?

2014-04-21 Thread Nachi Ueno
Hi folks I'm +1 for "Review Hour" on IRC because it shorten communication round trip time. As Akihiro said, it won't solve everything, but we can improve it Best Nachi 2014-04-21 9:20 GMT-07:00 Akihiro Motoki : > Hi, > > Previously Neutron team had ReviewDays [1] and core members made themselv

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

2014-04-16 Thread Nachi Ueno
Hi folks My bad,, Issue (1) was my mistake, and fixed 2014-04-16 15:16 GMT-07:00 Nachi Ueno : > Hi folks > > I submitted a wip patch which has diagram examples for both of ascii > flow and blockdiag. > > https://review.openstack.org/#/c/88095/1 > > This is both ou

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

2014-04-16 Thread Nachi Ueno
Hi folks I submitted a wip patch which has diagram examples for both of ascii flow and blockdiag. https://review.openstack.org/#/c/88095/1 This is both output from ascii flow and blockdiag. https://wiki.openstack.org/wiki/File:Screenshot.png I faced two issue in ascii flow. May be, I'm missing

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

2014-04-16 Thread Nachi Ueno
Hi folks I don't think to use ASCII digrams is good idea because it is hard to maintenance & update diagrams.. so I would like to recommend Blockdiag & Netdiag which are plugins for sphinx. Blockdiag http://blockdiag.com/en/blockdiag/ blockdiag { A -> B -> C -> D; A -> E -> F -> G; } wil

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

2014-04-15 Thread Nachi Ueno
+10 ! 2014-04-15 15:07 GMT-07:00 Kyle Mestery : > Given the success the Nova team has had in handling reviews using > their new nova-specs gerrit repository, I think it makes a lot of > sense for Neutron to do the same. With this in mind, I've added > instructions to the BP wiki [1] for how to

Re: [openstack-dev] TripleO fully uploaded to Debian Experimental

2014-04-11 Thread Nachi Ueno
Hi Thomas Great! Do we have a doc how to use these packages? 2014-04-11 0:00 GMT-07:00 Thomas Goirand : > Hi, > > it's with a great joy that I can announce today, that TripleO is now > fully in Debian [1]. It is currently only uploaded to Debian > experimental, like for all Icehouse (I don't thi

Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch?

2014-04-10 Thread Nachi Ueno
Hi Julio Unfortunately, we couldn't get forward about VPNaaS much in Icehouse. We will discuss this design in next summit, so let's get this progress in Juno. 2014-04-10 10:51 GMT-07:00 Julio Carlos Barrera Juez < juliocarlos.barr...@i2cat.net>: > Hi. > > After 8 months of the patch creation a

Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo

2014-04-10 Thread Nachi Ueno
Hi Jarda Congratulations This release and the demo is super awesome!! Do you have any instruction to install this one? 2014-04-10 1:32 GMT-07:00 Jaromir Coufal : > Dear Stackers, > > I am happy to announce that yesterday Tuskar UI (TripleO UI) has tagged > branch 0.1.0 for Icehouse release [0]

Re: [openstack-dev] [Neutron][Heat] The Neutron API and orchestration

2014-04-07 Thread Nachi Ueno
Hi Zane Thank you for your very valuable post. We should convert your suggest to multiple bps. 2014-04-07 17:28 GMT-07:00 Zane Bitter : > The Neutron API is a constant cause of pain for us as Heat developers, but > afaik we've never attempted to bring up the issues we have found in a > cross-proj

Re: [openstack-dev] [Nova][Neutron] Neutron + Nova + OVS security group fix

2014-03-25 Thread Nachi Ueno
Hi Salvatore 2014-03-25 17:57 GMT-07:00 Salvatore Orlando : > I hope we can sort this out on the mailing list IRC, without having to > schedule emergency meetings. Russel requested to have a conf call on this, so let him decide it. > Salvatore > > On 25 March 2014 22:58, Na

[openstack-dev] [Nova][Neutron] Neutron + Nova + OVS security group fix

2014-03-25 Thread Nachi Ueno
Hi Nova, Neturon Team I would like to discuss issue of Neutron + Nova + OVS security group fix. We have a discussion in IRC today, but the issue is complicated so we will have a conf call tomorrow 17:00 UST (10AM PDT). #openstack-neutron (I'll put conf call information in IRC) <-- Please let me k

Re: [openstack-dev] Neutron: Need help with tox failure in VPN code

2014-03-03 Thread Nachi Ueno
./run_test.sh or ./run_test.sh -d package_name is working? 2014-03-03 21:28 GMT-08:00 Paul Michali : > Hi, > > I'm stuck and can use some guidance here...please! > > I have a change set out for review that used the VPN Service Type Framework > ( https://review.openstack.org/74144). Everything work

[openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review

2014-02-26 Thread Nachi Ueno
Hi folks I wrote an bookmarklet for neutron gerrit review. This bookmarklet make the comment title for 3rd party ci as gray. javascript:(function(){list = document.querySelectorAll('td.GJEA35ODGC'); for(i in list){if(!list[i].innerHTML){continue;};if(list[i].innerHTML && list[i].innerHTML.search(

Re: [openstack-dev] [Neutron] We should wait approving code due to bug 1280035

2014-02-19 Thread Nachi Ueno
Hi folks Good news. 74882 is merged. I'm still not sure the current UT failure rate yet with 1280035, so I think we should wait to see the failure rate. so please check current gating status when you approve codes. Best Nachi 2014-02-19 16:59 GMT-08:00 Nachi Ueno : > Hi Neutron core&

[openstack-dev] [Neutron] We should wait approving code due to bug 1280035

2014-02-19 Thread Nachi Ueno
Hi Neutron core's We should wait approving code due to bug 1280035. https://bugs.launchpad.net/neutron/+bug/1280035 Unittest fails very high rate in the gating and blocks gating queue. Salvatore is working on the issue. At first, we skip the failing unit test. https://review.openstack.org/#/c/73

Re: [openstack-dev] [Neutron] Urgent questions on Service Type Framework for VPNaaS

2014-02-18 Thread Nachi Ueno
Hi Paul Sorry, I have missed this mail. The reason for putting -1 was the gating issue, so it is OK now. PS Thank you for your rebasing this one 2014-02-16 16:43 GMT-08:00 Sumit Naiksatam : > Hi Paul, > > Our plan with FWaaS was to get it to parity with LBaaS as far as STF > is concerned. That w

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

2014-02-13 Thread Nachi Ueno
+1 2014年2月12日水曜日、Mayur Patilさんは書きました: > +1 > > *--* > *Cheers,* > *Mayur* > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Representing PEM Format file as string

2014-01-27 Thread Nachi Ueno
ad String in the > database, I assumed we need to give string as input. > > I guess, the neutron client will convert the file to string and then call > the API. That should work. Thanks for the clarification. > > > > > On Mon, Jan 27, 2014 at 10:49 AM, Nachi Ueno wrote:

Re: [openstack-dev] [Neutron] Representing PEM Format file as string

2014-01-27 Thread Nachi Ueno
Hi Rajesh May I ask why we need single line representation of PEM format? For CLI, we will use file_name as same as nova keypair-add. We won't specify PEM on the URL. 2014-01-27 Rajesh Mohan : > Thanks John. > > My initial approach is similar to Keystone's. This is mainly to unblock me > from

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

2014-01-16 Thread Nachi Ueno
Thanks! Kyle 2014/1/16 Kyle Mestery : > On Jan 16, 2014, at 4:27 PM, Nachi Ueno wrote: > >> Hi Bob, Kyle >> >> I pushed (A) https://review.openstack.org/#/c/67281/. >> so could you review it? >> > Just did, looks good Nachi, thanks! > >> 2014/1/16

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

2014-01-16 Thread Nachi Ueno
Hi Bob, Kyle I pushed (A) https://review.openstack.org/#/c/67281/. so could you review it? 2014/1/16 Robert Kukura : > On 01/16/2014 03:13 PM, Kyle Mestery wrote: >> >> On Jan 16, 2014, at 1:37 PM, Nachi Ueno wrote: >> >>> Hi Amir >>> >>> 2014/1/

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

2014-01-16 Thread Nachi Ueno
nfiguration, then update vif_security based on this value. > Thanks, > > Amir > > > On Jan 16, 2014, at 11:42 AM, Nachi Ueno wrote: > >> Hi Mathieu, Bob >> >> Thank you for your reply >> OK let's do (A) - (C) for now. >> >> (A) Re

Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

2014-01-16 Thread Nachi Ueno
, but those values may need to depend on the value of > enable_security_group from proposal 1. > > -Bob > >> Once OVSfirewallDriver will be available, the firewall drivers that >> the operator wants to use should be in a MD config file/section and >> ovs MD could bind

[openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

2014-01-15 Thread Nachi Ueno
Hi folks Security group for OVS agent (ovs plugin or ML2) is being broken. so we need vif_security port binding to fix this (https://review.openstack.org/#/c/21946/) We got discussed about the architecture for ML2 on ML2 weekly meetings, and I wanna continue discussion in here. Here is my propos

Re: [openstack-dev] [Neturon][CI] Embrane CI is attacking gerrit

2014-01-13 Thread Nachi Ueno
Hi Russell Thanks. I got it 2014/1/13 Russell Bryant : > On 01/13/2014 05:26 PM, Nachi Ueno wrote: >> Hi folks >> >> I get Embrane CI comment in my review about 10 times in min. >> https://review.openstack.org/#/c/58897/ >> >> Embrane CI looks like broken

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-13 Thread Nachi Ueno
2014/1/13 Clint Byrum : > Excerpts from Nachi Ueno's message of 2014-01-13 10:35:07 -0800: >> Hi Clint >> >> 2014/1/10 Clint Byrum : >> > Excerpts from Nachi Ueno's message of 2014-01-10 13:42:30 -0700: >> >> Hi Flavio, Clint >> >> >> >> I agree with you guys. >> >> sorry, may be, I wasn't clear. M

[openstack-dev] [Neturon][CI] Embrane CI is attacking gerrit

2014-01-13 Thread Nachi Ueno
Hi folks I get Embrane CI comment in my review about 10 times in min. https://review.openstack.org/#/c/58897/ Embrane CI looks like broken, and we should stop it now. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://l

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

2014-01-13 Thread Nachi Ueno
Hi Anita Location: I am about to sign the contract for Salle du Parc at 3625 Parc > avenue, a room in a residence of McGill University. ^^^ Let's me confirmed the room number? 2014/1/7 Anita Kuno : > On 01/08/2014 03:10 AM, Nachi Ueno wrote: >> Hi Anita >> >> Le

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-13 Thread Nachi Ueno
Hi Clint 2014/1/10 Clint Byrum : > Excerpts from Nachi Ueno's message of 2014-01-10 13:42:30 -0700: >> Hi Flavio, Clint >> >> I agree with you guys. >> sorry, may be, I wasn't clear. My opinion is to remove every >> configuration in the node, >> and every configuration should be done by API from c

Re: [openstack-dev] [Neutron][qa] The 'spec' parameter of mock.patch()

2014-01-10 Thread Nachi Ueno
+1 but fixing this looks like take not small time 2014/1/10 Maru Newby : > I recently saw a case [1] where a misspelled assertion method > (asoptt_called_once_with vs assert_called_once_with) did not result in a test > failure because the object it was called on was created by mock.patch() > wi

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-10 Thread Nachi Ueno
> Excerpts from Doug Hellmann's message of 2014-01-09 12:21:05 -0700: >> On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote: >> >> > Hi folks >> > >> > Thank you for your input. >> > >> > The key difference from external configuration s

Re: [openstack-dev] Less option (was: [oslo.config] Centralized config management)

2014-01-10 Thread Nachi Ueno
01-09 at 23:56 +0100, Julien Danjou wrote: >> > > > On Thu, Jan 09 2014, Jay Pipes wrote: >> > > > >> > > > > Hope you don't mind, I'll jump in here :) >> > > > > >> > > > > On Thu, 2014-01-09 at 11:08 -0800

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
2014/1/9 Doug Hellmann : > > > > On Thu, Jan 9, 2014 at 3:56 PM, Nachi Ueno wrote: >> >> Hi Oleg >> >> 2014/1/9 Oleg Gelbukh : >> > On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno wrote: >> >> >> >> 2014/1/9 Jeremy Hanmer : >&

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
Hi Oleg 2014/1/9 Oleg Gelbukh : > On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno wrote: >> >> 2014/1/9 Jeremy Hanmer : >> >> > How do you see these interactions defined? For instance, if I deploy >> > a custom driver for Neutron, does that mean I also hav

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
Hi Jay 2014/1/9 Jay Pipes : > Hope you don't mind, I'll jump in here :) I'll never mind to discuss with you :) > On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote: >> Hi Jeremy >> >> Don't you think it is burden for operators if we should choose c

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
Hi Bob 2014/1/9 Robert Kukura : > On 01/09/2014 02:34 PM, Nachi Ueno wrote: >> Hi Doug >> >> 2014/1/9 Doug Hellmann : >>> >>> >>> >>> On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote: >>>> >>>> Hi folks >>>

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
n point for me, and it's get more worse if the env is heterogeneous. I have also some experience to run openstack clusters, but it is still pain for me.. My experience is something like this # Wow, new release! ohh this chef repo didn't supported.. # hmm i should modify chef recipe.. hmm debug..

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
Hi Doug Thank you for your input. 2014/1/9 Doug Hellmann : > > > > On Thu, Jan 9, 2014 at 2:34 PM, Nachi Ueno wrote: >> >> Hi Doug >> >> 2014/1/9 Doug Hellmann : >> > >> > >> > >> > On Thu, Jan 9, 2014 at 1:53 PM, Nach

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
Hi Doug 2014/1/9 Doug Hellmann : > > > > On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote: >> >> Hi folks >> >> Thank you for your input. >> >> The key difference from external configuration system (Chef, puppet >> etc) is integration wi

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
information in the environment rather than in roles). I > assume Puppet offers the same. Please don't re-invent this hugely > complicated wheel. > > On Thu, Jan 9, 2014 at 10:28 AM, Jay Pipes wrote: >> On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote: >>>

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
would this new service give us that existing, proven, > configuration management tools like chef and puppet don't have? > > > On Thu, Jan 9, 2014 at 12:52 PM, Nachi Ueno wrote: >> >> Hi Flavio >> >> Thank you for your input. >> I agree with you. oslo.config isn&#x

Re: [openstack-dev] [oslo.config] Centralized config management

2014-01-09 Thread Nachi Ueno
Hi Flavio Thank you for your input. I agree with you. oslo.config isn't right place to have server side code. How about oslo.configserver ? For authentication, we can reuse keystone auth and oslo.rpc. Best Nachi 2014/1/9 Flavio Percoco : > On 08/01/14 17:13 -0800, Nachi Ueno wrote:

[openstack-dev] [oslo.config] Centralized config management

2014-01-08 Thread Nachi Ueno
Hi folks OpenStack process tend to have many config options, and many hosts. It is a pain to manage this tons of config options. To centralize this management helps operation. We can use chef or puppet kind of tools, however sometimes each process depends on the other processes configuration. For

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

2014-01-07 Thread Nachi Ueno
Hi Anita Let's me join this session also. Nachi Ueno NTT i3 2014/1/5 Anita Kuno : > On 01/05/2014 03:42 AM, Sukhdev Kapur wrote: >> Folks, >> >> I finally got over my fear of weather and booked my flight and hotel for >> this sprint. >> >> I am

Re: [openstack-dev] [QA][Neutron] About paramiko's "SSHException: Error reading SSH protocol banner"

2013-12-27 Thread Nachi Ueno
Hi Salvatore The metadata server is working well? (or may be timing issue) I saw similar issue when VM failed to get the certificate from the metadata server. Best Nachi 2013/12/27 Salvatore Orlando : > Yair, > > The 'isolated' mode makes the tempest session more realistic by simulating a > clou

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

2013-12-10 Thread Nachi Ueno
+1 ! I'll join. I'm also working on investigating how to use openstack gating system. (This document is still draft version) https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1eefQalL5Q0/edit#slide=id.p 2013/12/10 Ivar Lazzaro : > +1 for 1700UTC Thursday on IRC > > -Origi

Re: [openstack-dev] Neutron Distributed Virtual Router

2013-12-10 Thread Nachi Ueno
I'm +1 for 'provider'. 2013/12/9 Akihiro Motoki : > Neutron defines "provider" attribute and it is/will be used in advanced > services (LB, FW, VPN). > Doesn't it fit for a distributed router case? If we can cover all services > with one concept, it would be nice. > > According to this thread, w

Re: [openstack-dev] Neutron Distributed Virtual Router

2013-12-09 Thread Nachi Ueno
Hi Yong NSX have two kind of router. Edge and distributed router. Edge node will work as some VPN services and advanced service nodes. Actually, VPNaaS OSS impl is running in l3-agent. so IMO, we need l3-agent also for basis of some edge services. 2013/12/9 Yongsheng Gong : > If distributed

Re: [openstack-dev] [neutron] only one subnet_id is allowed behind a router for vpnservice object

2013-12-06 Thread Nachi Ueno
Thanks! Commented on bp whiteboard. 2013/12/5 Yongsheng Gong : > ok, My pleasure to help, > I created a bp for it: > https://blueprints.launchpad.net/neutron/+spec/vpn-multiple-subnet > > > On Fri, Dec 6, 2013 at 2:11 PM, Nachi Ueno wrote: >> >> Hi Yong >> &

Re: [openstack-dev] [neutron] only one subnet_id is allowed behind a router for vpnservice object

2013-12-05 Thread Nachi Ueno
Hi Yong Yes, to support multiple subnet is on the roadmap. I'll definitely welcome your help :P 2013/12/5 Yongsheng Gong : > I think we should allow more than subnet_id in one vpnservice object. > but the model below limits only one subnet_id is used. > https://github.com/openstack/neutron/blob/m

Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)

2013-12-05 Thread Nachi Ueno
Hi folks OK, It looks like we get consensus on separate resource" way. Best Nachi 2013/12/5 Eugene Nikanorov : > Hi, > > My vote is for separate resource (e.g. 'New Model'). Also I'd like to see > certificate handling as a separate extension/db mixing(in fact, persistence > driver) similar to se

Re: [openstack-dev] Tool for detecting commonly misspelled words

2013-12-03 Thread Nachi Ueno
2013/12/3 John Griffith : > On Tue, Dec 3, 2013 at 11:54 AM, Nachi Ueno wrote: >> 2013/12/3 John Griffith : >>> On Tue, Dec 3, 2013 at 11:38 AM, Russell Bryant wrote: >>>> On 12/03/2013 09:22 AM, Joe Gordon wrote: >>>>> HI all, >>>>>

Re: [openstack-dev] Tool for detecting commonly misspelled words

2013-12-03 Thread Nachi Ueno
2013/12/3 John Griffith : > On Tue, Dec 3, 2013 at 11:38 AM, Russell Bryant wrote: >> On 12/03/2013 09:22 AM, Joe Gordon wrote: >>> HI all, >>> >>> Recently I have seen a few patches fixing a few typos. I would like to >>> point out a really nifty tool to detect commonly misspelled words. So >>>

Re: [openstack-dev] Tool for detecting commonly misspelled words

2013-12-03 Thread Nachi Ueno
Great tool especially for non-native guys such as me! Thanks Joe Best Nachi 2013/12/3 Sylvain Bauza : > Great tool ! > Just discovered that openstack.common.rpc does have typos, another good > reason to migrate to oslo.messaging.rpc :-) > > -Sylvain > > > 2013/12/3 Joe Gordon >> >> HI all, >> >

Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)

2013-12-02 Thread Nachi Ueno
Hi Vijay I was thinking about we should store this kind of information on the keystone. However, I changed my mind after checking keystone API. The keystone api is very generic, so we can't provider application specific helper method and validations on that. The form of certificate is different b

Re: [openstack-dev] [Neutron][Tempest] Heat template for services

2013-11-26 Thread Nachi Ueno
1/26 Steve Baker : > On 11/27/2013 07:16 AM, Nachi Ueno wrote: > > Hi Summit, Eugene > > We have submitted a Heat template for advanced services. > This is combination of LBaaS, FWaaS and VPN. > This is a also good demo for how to use neutron services. > > https://revie

[openstack-dev] [Neutron][Tempest] Heat template for services

2013-11-26 Thread Nachi Ueno
Hi Summit, Eugene We have submitted a Heat template for advanced services. This is combination of LBaaS, FWaaS and VPN. This is a also good demo for how to use neutron services. https://review.openstack.org/#/c/58496/1 It is great if we could get feedback from yours. FYI, here is existing heat

[openstack-dev] [Keystone] Blob in keystone v3 certificate API

2013-11-14 Thread Nachi Ueno
Hi Keystone guys I'm going to use keystone credentials API to store SSL-VPN certificate. However I have a concern about blob attribute. Since it is really free format. We can't provider validation on the data. Of course, we can write some helper validation function, but users can break it... A

Re: [openstack-dev] [Neturon][Tempest] A test scenario for services

2013-11-13 Thread Nachi Ueno
ove to more complex topologies and scenarios. > > Thanks, > Eugene. > > > On Thu, Nov 14, 2013 at 7:47 AM, Nachi Ueno wrote: >> >> Hi Salvatore, Sumit >> >> > Salvatore >> Thank you for your comment. I replied on the google doc. >> >&g

Re: [openstack-dev] [Neturon][Tempest] A test scenario for services

2013-11-13 Thread Nachi Ueno
sting API) > for each individual service? > > ~Sumit. > > > On Wed, Nov 13, 2013 at 5:55 PM, Nachi Ueno wrote: >> >> Hi Sumit, Eugene >> >> How about to have one test scenario for services? >> IMO, we need to combine LBaaS, FWaaS, VPNaaS scenario tests &

[openstack-dev] [Neturon][Tempest] A test scenario for services

2013-11-13 Thread Nachi Ueno
Hi Sumit, Eugene How about to have one test scenario for services? IMO, we need to combine LBaaS, FWaaS, VPNaaS scenario tests because of utilization of test resources. I wrote my proposal here. https://docs.google.com/presentation/d/1gu12liw-9el_pR_FDQ7qDRuFpnSXxVzOsp6K0ZzX-_o/edit#slide=id.g295

Re: [openstack-dev] L3 advanced features blueprint mapping to IETF and IEEE standards

2013-11-07 Thread Nachi Ueno
meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m > in Japan and 6 a.m CET on the 20th. > It is not ideal but i suspect we will have interest in participating from > both Europe and Asia. > I volunteer myself and Nachi Ueno na...@ntti3.com (the author of the BGP > MPLS blueprin

Re: [openstack-dev] Neutron - an issue regarding what API to follow

2013-10-23 Thread Nachi Ueno
Hi GROSZ, Akihiro Yes, the wiki is only for discussion. Please see the official API docs. I updated the wiki page as OUTDATED. https://wiki.openstack.org/wiki/Neutron/VPNaaS#OUTDATED Thank you for your pointing out. Best Nachi 2013/10/21 Akihiro Motoki : > Hi, > > The API document is the offic

Re: [openstack-dev] Disable async network allocation

2013-10-23 Thread Nachi Ueno
Hi Phil 2013/10/21 Day, Phil : > Hi Folks, > > > > I’m trying to track down a couple of obsecure issues in network port > creation where it would be really useful if I could disable the async > network allocation so that everything happens in the context of a single > eventlet rather than two (and

Re: [openstack-dev] [Neutron] tempest failure: No more IP addresses available on network

2013-10-23 Thread Nachi Ueno
Hi folks This patch was the culprit, so we have reverted it. https://review.openstack.org/#/c/53459/1 (Note, this is revert of revert ) However even if it is reverted, the error happens http://logstash.openstack.org/index.html#eyJzZWFyY2giOiJcIklwQWRkcmVzc0dlbmVyYXRpb25GYWlsdXJlQ2xpZW50OiBObyBtb3

Re: [openstack-dev] VPNaaS questions...

2013-10-23 Thread Nachi Ueno
Hi Paul I rebased the patch, and working on unit testing too https://review.openstack.org/#/c/41827/ 2013/10/23 Paul Michali : > See PCM: in-line. > > > PCM (Paul Michali) > > MAIL p...@cisco.com > IRC pcm_ (irc.freenode.net) > TW @pmichali > > On Oct 23, 2013, at 9:41 AM, Akihiro Motoki w

Re: [openstack-dev] [Neutron] Extraroute and router extensions

2013-10-11 Thread Nachi Ueno
Hi Artem Thank you for your pointing out this. I'm still thinking about the design. Once I got the draft, I'll share it in the bp and here.. Best Nachi 2013/10/10 Artem Dmytrenko : > Hi Rudra, Nachi. > > Glad to see this discussion on the mailing list! The ExtraRoute routes are > fairly > limite

Re: [openstack-dev] [neutron] VPNaaS (and services) questions

2013-10-11 Thread Nachi Ueno
2013/10/11 Paul Michali : > Added several more questions inline… > > > PCM (Paul Michali) > > MAIL p...@cisco.com > IRC pcm_ (irc.freenode.net) > TW @pmichali > > On Oct 11, 2013, at 3:28 PM, Paul Michali wrote: > > Hi folks, > > I have a bunch of questions for you on VPNaaS in specific, and

Re: [openstack-dev] [neutron] VPNaaS questions

2013-10-11 Thread Nachi Ueno
Hi Paul 2013/10/11 Paul Michali : > Hi folks, > > I have a bunch of questions for you on VPNaaS in specific, and services in > general... > > Nachi, > > 1) You hd a bug fix to do service provider framework support for VPN > (41827). It was held for Icehouse. Is that pretty much a working patch? >

Re: [openstack-dev] Blueprint for IPAM and Policy extensions in Neutron

2013-10-10 Thread Nachi Ueno
Hi Rudra 2013/10/8 Rudra Rugge : > Hi Nachi, > > Please see inline: > > On Oct 8, 2013, at 10:42 AM, Nachi Ueno wrote: > >> Hi Rudra >> >> Thanks! >> >> Some questions and comments >> >> - name and fq_name >> How we us

Re: [openstack-dev] [neutron] Extraroute and router extensions

2013-10-10 Thread Nachi Ueno
Hi Rudra ExtraRoute bp was designed for adding some "extra" routing for the router. The spec is very handy for simple and small use cases. However it won't fit large use cases, because it takes all route in a Json List. # It means we need to send full route for updating. As Salvatore suggests, we

Re: [openstack-dev] Blueprint for IPAM and Policy extensions in Neutron

2013-10-08 Thread Nachi Ueno
omments: > https://wiki.openstack.org/wiki/Blueprint-policy-extensions-for-neutron > > Thanks, > Rudra > > On Oct 4, 2013, at 4:56 PM, Nachi Ueno wrote: > >> 2013/10/4 Rudra Rugge : >>> Hi Nachi, >>> >>> Inline response >>> >>

  1   2   >