Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward
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. Because most skilled developers such as Mark, Oleg and Carl are working hard for this making happen. I'm also trying to POC non-DVR approach such as migrating nova-network directly to the neutron. (Sorry, this is off topic, but if you are interested in this, https://docs.google.com/presentation/d/12w28HhNpLltSpA6pJvKWBiqeEusaI-NM-OZo8HNyH2w/edit#slide=id.p is my thought ) Even if codes for GBP and Nova parity is really independent, so it won't conflict. Note that if you have any task item related with nova parity work, plz ping me. [Topic2] Neutron community decision making process I'm super lazy guy, so I'll be very disappointed the code i write rejected.. ( http://openstackreactions.enovance.com/2013/09/when-my-patch-get-2/ ) We are discussing this spec for couple of releases… IMO, we should have voting process such as IETF or let PTL make final decision like TTX saying. [Topic3] Group based policy specs I'm not jumped in this one. I have already shared my thought on this. This is still extension proposal. so we should let user choose use this or not. If it is proven for wide use, then we can discuss making it for core API. I'm also working on another extension spec. It is deferred for next release, (http://openstackreactions.enovance.com/2014/04/getting-told-that-this-feature-will-not-be-accepted-before-next-release/ ) but if you have any interest on this plz ping me http://docs-draft.openstack.org/12/93112/16/check/gate-neutron-specs-docs/afb346d/doc/build/html/specs/juno/security_group_action.html http://docs-draft.openstack.org/12/93112/16/check/gate-neutron-specs-docs/afb346d/doc/build/html/specs/juno/security_group_for_network.html [Topic4] Where we develop group based policy stuffs. And generally, service related stuffs. I do remember the LBaaS new project meeting at the Summit. I remember someone says I don't trust neutron makes this feature make it working in Juno timeframe.. I guess he was right.. We should have a new project for service related stuffs. ( http://openstackreactions.enovance.com/2013/11/when-a-new-openstack-project-announce-itself/ ) Best Nachi 2014-08-07 19:23 GMT+09:00 Thierry Carrez thie...@openstack.org: Armando M. wrote: This thread is moving so fast I can't keep up! The fact that troubles me is that I am unable to grasp how we move forward, which was the point of this thread to start with. It seems we have 2 options: - We make GBP to merge as is, in the Neutron tree, with some minor revision (e.g. naming?); - We make GBP a stackforge project, that integrates with Neutron in some shape or form; Another option, might be something in between, where GBP is in tree, but in some sort of experimental staging area (even though I am not sure how well baked this idea is). Now, as a community we all need make a decision; arguing about the fact that the blueprint was approved is pointless. I agree with you: it is possible to change your mind on a topic and revisit past decisions. In past OpenStack history we did revert merged commits and remove existing functionality because we felt it wasn't that much of a great idea after all. Here we are talking about making the right decision *before* the final merging and shipping into a release, which is kind of an improvement. The spec system was supposed to help limit such cases, but it's not bullet-proof. In the end, if there is no consensus on that question within the Neutron project (and I hear both sides have good arguments), our governance gives the elected Neutron PTL the power to make the final call. If the disagreement is between projects (like if Nova disagreed with the Neutron decision), then the issue could be escalated to the TC. Regards, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] network_rpcapi.migrate_instance_start
Hi Russell Thanks. I got it. 2014-07-22 14:21 GMT-07:00 Russell Bryant rbry...@redhat.com: 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 find implementation for it. https://github.com/openstack/nova/blob/372c54927ab4f6c226f5a1a2aead40b89617cf77/nova/network/manager.py#L1683 Agree that it appears to be a no-op and could probably be dropped (with proper rpc backwards compat handling). The manger side can't be removed until the next major rev of the API. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] network_rpcapi.migrate_instance_start
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] minimal device driver for VPN
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 opened months ago and Paul Mchali helped me a lot: http://lists.openstack.org/pipermail/openstack-dev/2014-February/028389.html I want to know the minimum requirements to develop a device driver and a service driver for a VPN Neutron plugin. I tried adding an empty device driver and I got this error: DeviceDriverImportError: Can not load driver :neutron.services.vpn.junos_vpnaas.device_drivers.fake_device_driver.FakeDeviceDriver Both Python file and class exists, but the implementation is empty. What is the problem? What I need to include in this file/class to avoid this error? Thank you. http://dana.i2cat.net http://www.i2cat.net/en Julio C. Barrera Juez [image: View my profile on LinkedIn] http://es.linkedin.com/in/jcbarrera/en Office phone: (+34) 93 357 99 27 (ext. 527) Office mobile phone: (+34) 625 66 77 26 Distributed Applications and Networks Area (DANA) i2CAT Foundation, Barcelona ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron]Performance of security group
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 improved by using this payload data model.
SG_LIST [ SG1, SG2]
SG_RULE_LIST = [SG_Rule1, SG_Rule2] ..
port[SG_ID1, SG_ID2], port2 , port3
(2) Applying security group for network.
I have bp for applying security group for network.
IMO, this usecase1 and usecase2 can cover most of usecases.
(Usecase1) default group for all network
(Usecase2) security group per network
so if we can specify security group for network, we can optimize many payload
especially for default security group.
https://blueprints.launchpad.net/neutron/+spec/network-security-group
spec
http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/security_group_for_network.rst#n156
Best
Nachi
2014-06-19 7:11 GMT-07:00 Miguel Angel Ajo Pelayo mangel...@redhat.com:
Hi it's a very interesting topic, I was getting ready to raise
the same concerns about our security groups implementation, shihanzhang
thank you for starting this topic.
Not only at low level where (with our default security group
rules -allow all incoming from 'default' sg- the iptable rules
will grow in ~X^2 for a tenant, and, the security_group_rules_for_devices
rpc call from ovs-agent to neutron-server grows to message sizes of 100MB,
generating serious scalability issues or timeouts/retries that
totally break neutron service.
(example trace of that RPC call with a few instances
http://www.fpaste.org/104401/14008522/)
I believe that we also need to review the RPC calling mechanism
for the OVS agent here, there are several possible approaches to breaking
down (or/and CIDR compressing) the information we return via this api call.
So we have to look at two things here:
* physical implementation on the hosts (ipsets, nftables, ... )
* rpc communication mechanisms.
Best regards,
Miguel Ángel.
- Mensaje original -
Do you though about nftables that will replace {ip,ip6,arp,eb}tables?
It also based on the rule set mechanism.
The issue in that proposition, it's only stable since the begin of the year
and on Linux kernel 3.13.
But there lot of pros I don't list here (leverage iptables limitation,
efficient update rule, rule set, standardization of netfilter commands...).
Édouard.
On Thu, Jun 19, 2014 at 8:25 AM, henry hly henry4...@gmail.com wrote:
we have done some tests, but have different result: the performance is
nearly
the same for empty and 5k rules in iptable, but huge gap between
enable/disable iptable hook on linux bridge
On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang ayshihanzh...@126.com
wrote:
Now I have not get accurate test data, but I can confirm the following
points：
1. In compute node, the iptable's chain of a VM is liner, iptable filter
it
one by one, if a VM in default security group and this default security
group have many members, but ipset chain is set, the time ipset filter
one
and many member is not much difference.
2. when the iptable rule is very large, the probability of failure that
iptable-save save the iptable rule is very large.
At 2014-06-19 10:55:56, Kevin Benton blak...@gmail.com wrote:
This sounds like a good idea to handle some of the performance issues
until
the ovs firewall can be implemented down the the line.
Do you have any performance comparisons?
On Jun 18, 2014 7:46 PM, shihanzhang ayshihanzh...@126.com wrote:
Hello all,
Now in neutron, it use iptable implementing security group, but the
performance of this implementation is very poor, there is a bug:
https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this
problem.
In
his test, w ith default security groups(which has remote security
group),
beyond 250-300 VMs, there were around 6k Iptable rules on evry
compute
node,
although his patch can reduce the processing time, but it don't solve
this
problem fundamentally. I have commit a BP to solve this problem:
https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security
There are other people interested in this it?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
Re: [openstack-dev] [neutron] Can tenants provide hints to router scheduling?
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 scheduler such as Nova's filter scheduler. Best Nachi 2014-06-13 11:24 GMT-07:00 CARVER, PAUL pc2...@att.com: Suppose a tenant knows that some of their networks are particularly high bandwidth and others are relatively low bandwidth. Is there any mechanism that a tenant can use to let Neutron know what sort of bandwidth is expected through a particular router? I’m concerned about the physical NICs on some of our network nodes getting saturated if several virtual routers that end up on the same network node happen to be serving multi –Gbps networks. I’m looking through https://github.com/openstack/neutron/blob/master/neutron/scheduler/l3_agent_scheduler.py and it appears the only choices are ChanceScheduler which just calls random.choice and LeastRoutersScheduler which appears to make its decision based on simple quantity of routers per L3 agent. Are there any blueprints or WIP for taking bandwidth utilization into account when scheduling routers? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
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 gong...@unitedstack.com: I think maybe we can device a kind of framework so that we can plugin different BGP speakers. On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: hi, ExaBgp was our first choice because we thought that run something in library mode would be much more easy to deal with (especially the exceptions and corner cases) and the code would be much cleaner. But seems that Ryu BGP also can fit in this requirement. And having the help from a Ryu developer like you turns it into a promising candidate! I'll start working now in a proof of concept to run the agent with these implementations and see if we need more requirements to compare between the speakers. we (ryu team) love to hear any suggestions and/or requests. we are currently working on our bgp api refinement and documentation. hopefully they will be available early next week. for both of bgp blueprints, it would be possible, and might be desirable, to create reference implementations in python using ryu or exabgp. (i prefer ryu. :-) YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
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 mathieu.ro...@gmail.com: Hi, I was about mentionning ExaBGP too! can we also consider using those BGP speakers for BGPVPN implementation [1]. This would be consistent to have the same BGP speaker used for every BGP needs inside Neutron. [1]https://review.openstack.org/#/c/93329/ On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa devv...@gmail.com wrote: Hello Takashi, thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing blueprint[2], I've added a new column for this speaker in the wiki page. I plan to fill it soon. ExaBgp was our first choice because we thought that run something in library mode would be much more easy to deal with (especially the exceptions and corner cases) and the code would be much cleaner. But seems that Ryu BGP also can fit in this requirement. And having the help from a Ryu developer like you turns it into a promising candidate! I'll start working now in a proof of concept to run the agent with these implementations and see if we need more requirements to compare between the speakers. [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison [2]: https://review.openstack.org/#/c/90833/ Regards, On 29 May 2014 18:42, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: as per discussions on l3 subteem meeting today, i started a bgp speakers comparison wiki page for this bp. https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison Artem, can you add other requirements as columns? as one of ryu developers, i'm naturally biased to ryu bgp. i appreciate if someone provides more info for other bgp speakers. YAMAMOTO Takashi Good afternoon Neutron developers! There has been a discussion about dynamic routing in Neutron for the past few weeks in the L3 subteam weekly meetings. I've submitted a review request of the blueprint documenting the proposal of this feature: https://review.openstack.org/#/c/90833/. If you have any feedback or suggestions for improvement, I would love to hear your comments and include your thoughts in the document. Thank you. Sincerely, Artem Dmytrenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Policy for linking bug or bp in commit message
I like the idea 2014-05-29 8:33 GMT-07:00 Yuriy Taraday yorik@gmail.com: On Wed, May 28, 2014 at 3:54 AM, Joe Gordon joe.gord...@gmail.com wrote: On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno na...@ntti3.com wrote: (2) Avoid duplication of works I have several experience of this. Anyway, we should encourage people to check listed bug before writing patches. That's a very good point, but I don't think requiring a bug/bp for every patch is a good way to address this. Perhaps there is another way. We can require developer to either link to bp/bug or explicitly add Minor-fix line to the commit message. I think that would force commit author to at least think about whether commit worth submitting a bug/bp or not. -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] How about deprecate cfg.CONF.allow_overlapping_ips?
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 support namespace. so IMO, we can deprecate it. Any thought on this? Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Policy for linking bug or bp in commit message
Hi folks OK, so it looks like this is consensus in the community, Link bug or bp for most of commit Exception for not linking bug: (1) Infra sync (2) minor fix. (typo, small code refactor, fix doc string etc) Ihar, Assaf Sorry for taking time for this discussion, I'll remove my comment for requesting bug report. Best Nachi 2014-05-27 16:54 GMT-07:00 Joe Gordon joe.gord...@gmail.com: On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno na...@ntti3.com wrote: Hi Ben, Joe Thank you for your reply (2) Avoid duplication of works I have several experience of this. Anyway, we should encourage people to check listed bug before writing patches. That's a very good point, but I don't think requiring a bug/bp for every patch is a good way to address this. Perhaps there is another way. (3) Release management - TTX is doing this after each release. so we can know how many bugs we fixed. (or we can know how many bugs remaining in this release) (4) sync code from oslo-incubator IMO, this kind of 'sync' commit don't need to filing bug such as Transmaniax, requirement update etc. This is why a strict rule won't work IMHO. 2014-05-23 12:16 GMT-07:00 Joe Gordon joe.gord...@gmail.com: On Sat, May 24, 2014 at 4:02 AM, Joe Gordon joe.gord...@gmail.com wrote: On Sat, May 24, 2014 at 2:23 AM, Nachi Ueno na...@ntti3.com wrote: 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 I'm not sure how this will help. folks will just file duplicate bugs write before the push there patch for review. (3) Release management Can you give some examples to show why requiring a bug or bp helps with the items listed above. IMO, generally, the answer is yes. However, how about small 5-6 nit change? so such patch will be exception or not? I wanna ask community opinion, and I'll update gerrit workflow page based on this discussion. I don't trying to enforce this policy alone will help. For a patch that doesn't have a bug or blueprint assocatiated we have two options. * File a blueprint. Now that many projects use specs repos blueprints have a significant overhead associated with them, so we should be careful about incurring that overhead. * File a bug. Sure we can file a bug for every patch, but there is still an overhead associated with that, and in most cases I don't think it really buys us much. If the change isn't a real bug but say 'sync code from oslo-incubator' what does adding a linked bug really buy us? Wow, that came out garbled, I guess that is what a long flight does. Here is take two: I don't think this policy of requiring a linked blueprint or bug for every patch is enough to significantly help with the list of items listed above. Now that many projects use specs repositories, we have just ratcheted up the overhead associated with using blueprints. While this is a good thing overall, this also means we should be careful about making process changes that require folks to file more blueprints. As for bugs, it is unclear to me what the value of filing a bug for a patch that 'synces code from oslo-incubator' is. How would this help with review triage, especially when we don't do a great job of bug triage? Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
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 na...@ntti3.com: Hi folks Clint Thanks, things get clear for me now :) 2014-05-01 13:21 GMT-07:00 John Wood john.w...@rackspace.com: I was going to bring up Postern [1] as well, Clint. Unfortunately not much work has been done on it though. [1] https://github.com/cloudkeep/postern Thanks, John From: Clint Byrum [cl...@fewbar.com] Sent: Thursday, May 01, 2014 2:22 PM To: openstack-dev Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700: Ah I got it now! so even if we get stolen HDD, we can keep password safe. However, I'm still not sure why this is more secure.. anyway, the ID/PW to access barbican will be written in neutron.conf, right? Yes. However, you can surround the secret in policies. You'll have an audit trail of when and where it was accessed, and you can even restrict access, so that out of band you have to open up access with barbican. So while the server may have access, that access is now audited and limited by policy, instead of just being dependent on the security measures you can take to protect a file. Furthermore, ID/PW for mysql will be written in conf file.. so if we can't trust unix file system protection, there is no security in OpenStack. The ID/PW for mysql only grants you access to mysql for as long as that id/pw are enabled for access. However, the encryption keys for OpenVPN will grant any passive listener access for as long as they keep any sniffed traffic. They'll also grant an attacker the ability to MITM traffic between peers. So when an encryption key has been accessed, from where, etc, is quite a bit more crucial than knowing when a username/password combo have been accessed. Producing a trustworthy audit log for access to /etc/neutron/neutron.conf is a lot harder than producing an audit log for a REST API. So it isn't so much that file system permissions aren't enough, it is that file system observability is expensive. Note that at some point there was a POC to have a FUSE driver backed by Barbican called 'Postern' I think. That would make these discussions a lot simpler. :) 2014-05-01 10:31 GMT-07:00 Clint Byrum cl...@fewbar.com: I think you'd do something like this (Note that I don't know off the top of my head the barbican CLI or openvpn cli switches... just pseudo-code): oconf=$(mktemp -d /tmp/openvpnconfig.XX) mount -o tmpfs $oconf size=1M barbican get my-secret-openvpn-conf $oconf/foo.conf openvpn --config-dir $oconf foo --daemonize umount $oconf rmdir $oconf Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: Hi Robert Thank you for your suggestion. so your suggestion is let OpenVPN process download key to memory directly from Babican? 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham robert.cl...@hp.com: Excuse me interrupting but couldn't you 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 filesystem disk-residency issues. -Original Message- From: Nachi Ueno [mailto:na...@ntti3.com] Sent: 01 May 2014 17:36 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation Hi Jarret IMO, Zang point is the issue saving plain private key in the filesystem for OpenVPN. Isn't this same even if we use Barbican? 2014-05-01 2:56 GMT-07:00 Jarret Raim jarret.r...@rackspace.com: Zang mentioned that part of the issue is that the private key has to be stored in the OpenVPN config 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/30/14, 6:08 PM, Nachi Ueno na...@ntti3.com wrote: 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 mest...@noironetworks.com: On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno na...@ntti3.com wrote: Hi Clint Thank you for your suggestion. Your point get taken :) Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? Yes! I think we should definitely
[openstack-dev] Policy for linking bug or bp in commit message
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) Release management IMO, generally, the answer is yes. However, how about small 5-6 nit change? so such patch will be exception or not? I wanna ask community opinion, and I'll update gerrit workflow page based on this discussion. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Policy for linking bug or bp in commit message
Hi Ben, Joe Thank you for your reply (2) Avoid duplication of works I have several experience of this. Anyway, we should encourage people to check listed bug before writing patches. (3) Release management - TTX is doing this after each release. so we can know how many bugs we fixed. (or we can know how many bugs remaining in this release) (4) sync code from oslo-incubator IMO, this kind of 'sync' commit don't need to filing bug such as Transmaniax, requirement update etc. 2014-05-23 12:16 GMT-07:00 Joe Gordon joe.gord...@gmail.com: On Sat, May 24, 2014 at 4:02 AM, Joe Gordon joe.gord...@gmail.com wrote: On Sat, May 24, 2014 at 2:23 AM, Nachi Ueno na...@ntti3.com wrote: 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 I'm not sure how this will help. folks will just file duplicate bugs write before the push there patch for review. (3) Release management Can you give some examples to show why requiring a bug or bp helps with the items listed above. IMO, generally, the answer is yes. However, how about small 5-6 nit change? so such patch will be exception or not? I wanna ask community opinion, and I'll update gerrit workflow page based on this discussion. I don't trying to enforce this policy alone will help. For a patch that doesn't have a bug or blueprint assocatiated we have two options. * File a blueprint. Now that many projects use specs repos blueprints have a significant overhead associated with them, so we should be careful about incurring that overhead. * File a bug. Sure we can file a bug for every patch, but there is still an overhead associated with that, and in most cases I don't think it really buys us much. If the change isn't a real bug but say 'sync code from oslo-incubator' what does adding a linked bug really buy us? Wow, that came out garbled, I guess that is what a long flight does. Here is take two: I don't think this policy of requiring a linked blueprint or bug for every patch is enough to significantly help with the list of items listed above. Now that many projects use specs repositories, we have just ratcheted up the overhead associated with using blueprints. While this is a good thing overall, this also means we should be careful about making process changes that require folks to file more blueprints. As for bugs, it is unclear to me what the value of filing a bug for a patch that 'synces code from oslo-incubator' is. How would this help with review triage, especially when we don't do a great job of bug triage? Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Introducing task oriented workflows
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 sorla...@nicira.com: As most of you probably know already, this is one of the topics discussed during the Juno summit [1]. I would like to kick off the discussion in order to move towards a concrete design. Preamble: Considering the meat that's already on the plate for Juno, I'm not advocating that whatever comes out of this discussion should be put on the Juno roadmap. However, preparation (or yak shaving) activities that should be identified as pre-requisite might happen during the Juno time frame assuming that they won't interfere with other critical or high priority activities. This is also a very long post; the TL;DR summary is that I would like to explore task-oriented communication with the backend and how it should be reflected in the API - gauging how the community feels about this, and collecting feedback regarding design, constructs, and related tools/techniques/technologies. At the summit a broad range of items were discussed during the session, and most of them have been reported in the etherpad [1]. First, I think it would be good to clarify whether we're advocating a task-based API, a workflow-oriented operation processing, or both. -- About a task-based API In a task-based API, most PUT/POST API operations would return tasks rather than neutron resources, and users of the API will interact directly with tasks. I put an example in [2] to avoid cluttering this post with too much text. As the API operation simply launches a task - the database state won't be updated until the task is completed. Needless to say, this would be a radical change to Neutron's API; it should be carefully evaluated and not considered for the v2 API. Even if it is easily recognisable that this approach has a few benefits, I don't think this will improve usability of the API at all. Indeed this will limit the ability of operating on a resource will a task is in execution on it, and will also require neutron API users to change the paradigm the use to interact with the API; for not mentioning the fact that it would look weird if neutron is the only API endpoint in Openstack operating in this way. For the Neutron API, I think that its operations should still be manipulating the database state, and possibly return immediately after that (*) - a task, or to better say a workflow will then be started, executed asynchronously, and update the resource status on completion. -- On workflow-oriented operations The benefits of it when it comes to easily controlling operations and ensuring consistency in case of failures are obvious. For what is worth, I have been experimenting introducing this kind of capability in the NSX plugin in the past few months. I've been using celery as a task queue, and writing the task management code from scratch - only to realize that the same features I was implementing are already supported by taskflow. I think that all parts of Neutron API can greatly benefit from introducing a flow-based approach. Some examples: - pre/post commit operations in the ML2 plugin can be orchestrated a lot better as a workflow, articulating operations on the various drivers in a graph - operation spanning multiple plugins (eg: add router interface) could be simplified using clearly defined tasks for the L2 and L3 parts - it would be finally possible to properly manage resources' operational status, as well as knowing whether the actual configuration of the backend matches the database configuration - synchronous plugins might be converted into asynchronous thus improving their API throughput Now, the caveats: - during the sessions it was correctly pointed out that special care is required with multiple producers (ie: api servers) as workflows should be always executed in the correct order - it is probably be advisable to serialize workflows operating on the same resource; this might lead to unexpected situations (potentially to deadlocks) with workflows operating on multiple resources - if the API is asynchronous, and multiple workflows might be queued or in execution at a given time, rolling back the DB operation on failures is probably not advisable (it would not be advisable anyway in any asynchronous framework). If the API instead stays synchronous the revert action for a failed task might also restore the db state for a resource; but I think that keeping the API synchronous missed a bit the point of this whole work - feel free to show your disagreement here! - some neutron workflows are actually initiated by agents; this is the case, for instance, of the workflow for doing initial L2 and security group configuration for a port. - it's going to be a lot of
Re: [openstack-dev] [neutron] Proposed changes to core team
+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 mest...@noironetworks.com: I would like to propose a few changes to the Neutron core team. Looking at how current cores are contributing, both in terms of review [1] as well as project participation and attendance at the summit sessions last week, I am proposing a few changes. As cores, I believe reviews are critical, but I also believe interacting with the Neutron and OpenStack communities in general is important. The first change I'd like to propose is removing Yong Sheng Gong from neutron-core. Yong has been a core for a long time. I'd like to thank him for all of his work on Neutron over the years. Going forward, I'd also to propose that if Yong's participation and review stats improve he could be fast-tracked back to core status. But for now, his review stats for the past 90 days do not line up with current cores, and his participation in general has dropped off. So I am proposing his removal from neutron-core. Since we're losing a core team member, I'd like to propose Carl Baldwin (carl_baldwin) for Neutron core. Carl has been a very active reviewer for Neutron, his stats are well in-line with other core reviewers. Additionally, Carl has been leading the L3 sub-team [2] for a while now. He's a very active member of the Neutron community, and he is actively leading development of some important features for the Juno release. Neutron cores, please vote +1/-1 for the proposed addition of Carl Baldwin to Neutron core. I also wanted to mention the process for adding, removing, and maintaining neutron-core membership is now documented on the wiki here [3]. Thank you! Kyle [1] http://stackalytics.com/report/contribution/neutron/90 [2] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam [3] https://wiki.openstack.org/wiki/NeutronCore ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ReviewStat] WebUI for review stat
Hi folks I could deploy it on openshift http://reviewstat-nachi.rhcloud.com/ 2014-05-19 20:36 GMT-07:00 Nachi Ueno na...@ntti3.com: 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 Boris Pavlovic bo...@pavlovic.me: Hi Nachi, Sorry for question, but did you try stackalytics? E.g. this page http://stackalytics.com/report/contribution/neutron/30 Best regards, Boris Pavlovic On Tue, May 20, 2014 at 5:20 AM, Nachi Ueno na...@ntti3.com wrote: 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=ouS5h5Z-W50feature=youtu.be This is a review for review stats. https://review.openstack.org/#/c/94288/ # Note, this code is my side work,, so hopefully we can get lower bar for review :) sudo python setup.py develop ./run_server.sh open http://127.0.0.1:8080/ This webui identifies primary/secondary reviewers from comment. so if you put the comment like this, primary: mestery, secondary:maru Kyle, and Maru will be assigned as primary/secondary reviewer. This is regexp primary:\s*(.+),\s*secondary:\s*(.+) Otherwise, this webui selects primary/secondary from existing core-reviewer who are reviewing the change set. Some my thoughts for next steps. (1) core-reviewer-scheduler Currently, 208 patch needs core in Neutron related projects. I feel manual assignment by discussion won't work in this scale... I think we need core-reviewer-scheduler such as nova-scheduler too. # I'm not sure cores likes this idea, though (2) launchpad integration Yep, it is great if we can also show priorities by launchpad data in here. (3) Hosting this code in somewhere, (hopefully, in infra) (4) Performance impact for review.openstack.org This code is using a heavy rest api call (get all reviews,comment, reviews for all patches for a project). I hope this code won't kill the review.openstack.org Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ReviewStat] WebUI for review stat
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=ouS5h5Z-W50feature=youtu.be This is a review for review stats. https://review.openstack.org/#/c/94288/ # Note, this code is my side work,, so hopefully we can get lower bar for review :) sudo python setup.py develop ./run_server.sh open http://127.0.0.1:8080/ This webui identifies primary/secondary reviewers from comment. so if you put the comment like this, primary: mestery, secondary:maru Kyle, and Maru will be assigned as primary/secondary reviewer. This is regexp primary:\s*(.+),\s*secondary:\s*(.+) Otherwise, this webui selects primary/secondary from existing core-reviewer who are reviewing the change set. Some my thoughts for next steps. (1) core-reviewer-scheduler Currently, 208 patch needs core in Neutron related projects. I feel manual assignment by discussion won't work in this scale... I think we need core-reviewer-scheduler such as nova-scheduler too. # I'm not sure cores likes this idea, though (2) launchpad integration Yep, it is great if we can also show priorities by launchpad data in here. (3) Hosting this code in somewhere, (hopefully, in infra) (4) Performance impact for review.openstack.org This code is using a heavy rest api call (get all reviews,comment, reviews for all patches for a project). I hope this code won't kill the review.openstack.org Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ReviewStat] WebUI for review stat
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 Boris Pavlovic bo...@pavlovic.me: Hi Nachi, Sorry for question, but did you try stackalytics? E.g. this page http://stackalytics.com/report/contribution/neutron/30 Best regards, Boris Pavlovic On Tue, May 20, 2014 at 5:20 AM, Nachi Ueno na...@ntti3.com wrote: 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=ouS5h5Z-W50feature=youtu.be This is a review for review stats. https://review.openstack.org/#/c/94288/ # Note, this code is my side work,, so hopefully we can get lower bar for review :) sudo python setup.py develop ./run_server.sh open http://127.0.0.1:8080/ This webui identifies primary/secondary reviewers from comment. so if you put the comment like this, primary: mestery, secondary:maru Kyle, and Maru will be assigned as primary/secondary reviewer. This is regexp primary:\s*(.+),\s*secondary:\s*(.+) Otherwise, this webui selects primary/secondary from existing core-reviewer who are reviewing the change set. Some my thoughts for next steps. (1) core-reviewer-scheduler Currently, 208 patch needs core in Neutron related projects. I feel manual assignment by discussion won't work in this scale... I think we need core-reviewer-scheduler such as nova-scheduler too. # I'm not sure cores likes this idea, though (2) launchpad integration Yep, it is great if we can also show priorities by launchpad data in here. (3) Hosting this code in somewhere, (hopefully, in infra) (4) Performance impact for review.openstack.org This code is using a heavy rest api call (get all reviews,comment, reviews for all patches for a project). I hope this code won't kill the review.openstack.org Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Barbican][Neturon] Cred management for ssl-vpn
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 encoded)
- dh (PEM encoded)
- crl (PEM encoded)
We have also ssl-vpn-connection resource who has
credential_id
https://wiki.openstack.org/wiki/Neutron/VPNaaS/SSLVPN
IMO, we can remove vpn credential resources completely if we use Barbican.
What's I'm thinking is having payload something like this.
{payload: {
ca : xxx,
'server_key': 'xxx
}}
Is this good idea in Barbican context?
Best
Nachi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Jarret IMO, Zang point is the issue saving plain private key in the filesystem for OpenVPN. Isn't this same even if we use Barbican? 2014-05-01 2:56 GMT-07:00 Jarret Raim jarret.r...@rackspace.com: Zang mentioned that part of the issue is that the private key has to be stored in the OpenVPN config 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/30/14, 6:08 PM, Nachi Ueno na...@ntti3.com wrote: 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 mest...@noironetworks.com: On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno na...@ntti3.com wrote: Hi Clint Thank you for your suggestion. Your point get taken :) Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? Yes! I think we should definitely discuss this in the advanced services meeting today. I've added it to the agenda [1]. Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_for_next _meeting Zang Could you join the discussion? 2014-04-29 15:48 GMT-07:00 Clint Byrum cl...@fewbar.com: Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com: On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com 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 using Barbican been discussed before? There are many reasons why using Barbican for this may be better than developing key management ourselves. No, however I'm +1 for using Barbican. Let's discuss this in certificate management topic in advanced service session. Just a suggestion: Don't defer that until the summit. Sounds like you've already got some consensus, so you don't need the summit just to rubber stamp it. I suggest discussing as much as you can right now on the mailing list, and using the time at the summit to resolve any complicated issues including any a or b things that need crowd-sourced idea making. You can also use the summit time to communicate your requirements to the Barbican developers. Point is: just because you'll have face time, doesn't mean you should use it for what can be done via the mailing list. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Robert Thank you for your suggestion. so your suggestion is let OpenVPN process download key to memory directly from Babican? 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham robert.cl...@hp.com: Excuse me interrupting but couldn't you 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 filesystem disk-residency issues. -Original Message- From: Nachi Ueno [mailto:na...@ntti3.com] Sent: 01 May 2014 17:36 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation Hi Jarret IMO, Zang point is the issue saving plain private key in the filesystem for OpenVPN. Isn't this same even if we use Barbican? 2014-05-01 2:56 GMT-07:00 Jarret Raim jarret.r...@rackspace.com: Zang mentioned that part of the issue is that the private key has to be stored in the OpenVPN config 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/30/14, 6:08 PM, Nachi Ueno na...@ntti3.com wrote: 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 mest...@noironetworks.com: On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno na...@ntti3.com wrote: Hi Clint Thank you for your suggestion. Your point get taken :) Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? Yes! I think we should definitely discuss this in the advanced services meeting today. I've added it to the agenda [1]. Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f or_ next _meeting Zang Could you join the discussion? 2014-04-29 15:48 GMT-07:00 Clint Byrum cl...@fewbar.com: Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com: On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com 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 using Barbican been discussed before? There are many reasons why using Barbican for this may be better than developing key management ourselves. No, however I'm +1 for using Barbican. Let's discuss this in certificate management topic in advanced service session. Just a suggestion: Don't defer that until the summit. Sounds like you've already got some consensus, so you don't need the summit just to rubber stamp it. I suggest discussing as much as you can right now on the mailing list, and using the time at the summit to resolve any complicated issues including any a or b things that need crowd-sourced idea making. You can also use the summit time to communicate your requirements to the Barbican developers. Point is: just because you'll have face time, doesn't mean you should use it for what can be done via the mailing list. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Ah I got it now! so even if we get stolen HDD, we can keep password safe. However, I'm still not sure why this is more secure.. anyway, the ID/PW to access barbican will be written in neutron.conf, right? Furthermore, ID/PW for mysql will be written in conf file.. so if we can't trust unix file system protection, there is no security in OpenStack. 2014-05-01 10:31 GMT-07:00 Clint Byrum cl...@fewbar.com: I think you'd do something like this (Note that I don't know off the top of my head the barbican CLI or openvpn cli switches... just pseudo-code): oconf=$(mktemp -d /tmp/openvpnconfig.XX) mount -o tmpfs $oconf size=1M barbican get my-secret-openvpn-conf $oconf/foo.conf openvpn --config-dir $oconf foo --daemonize umount $oconf rmdir $oconf Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: Hi Robert Thank you for your suggestion. so your suggestion is let OpenVPN process download key to memory directly from Babican? 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham robert.cl...@hp.com: Excuse me interrupting but couldn't you 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 filesystem disk-residency issues. -Original Message- From: Nachi Ueno [mailto:na...@ntti3.com] Sent: 01 May 2014 17:36 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation Hi Jarret IMO, Zang point is the issue saving plain private key in the filesystem for OpenVPN. Isn't this same even if we use Barbican? 2014-05-01 2:56 GMT-07:00 Jarret Raim jarret.r...@rackspace.com: Zang mentioned that part of the issue is that the private key has to be stored in the OpenVPN config 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/30/14, 6:08 PM, Nachi Ueno na...@ntti3.com wrote: 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 mest...@noironetworks.com: On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno na...@ntti3.com wrote: Hi Clint Thank you for your suggestion. Your point get taken :) Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? Yes! I think we should definitely discuss this in the advanced services meeting today. I've added it to the agenda [1]. Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f or_ next _meeting Zang Could you join the discussion? 2014-04-29 15:48 GMT-07:00 Clint Byrum cl...@fewbar.com: Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com: On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com 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 using Barbican been discussed before? There are many reasons why using Barbican for this may be better than developing key management ourselves. No, however I'm +1 for using Barbican. Let's discuss this in certificate management topic in advanced service session. Just a suggestion: Don't defer that until the summit. Sounds like you've already got some consensus, so you don't need the summit just to rubber stamp it. I suggest discussing as much as you can right now on the mailing list, and using the time at the summit to resolve any complicated issues including any a or b things that need crowd-sourced idea making. You can also use the summit time to communicate your requirements to the Barbican developers. Point is: just because you'll have face time, doesn't mean you should use it for what can be done via the mailing list. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi folks Clint Thanks, things get clear for me now :) 2014-05-01 13:21 GMT-07:00 John Wood john.w...@rackspace.com: I was going to bring up Postern [1] as well, Clint. Unfortunately not much work has been done on it though. [1] https://github.com/cloudkeep/postern Thanks, John From: Clint Byrum [cl...@fewbar.com] Sent: Thursday, May 01, 2014 2:22 PM To: openstack-dev Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700: Ah I got it now! so even if we get stolen HDD, we can keep password safe. However, I'm still not sure why this is more secure.. anyway, the ID/PW to access barbican will be written in neutron.conf, right? Yes. However, you can surround the secret in policies. You'll have an audit trail of when and where it was accessed, and you can even restrict access, so that out of band you have to open up access with barbican. So while the server may have access, that access is now audited and limited by policy, instead of just being dependent on the security measures you can take to protect a file. Furthermore, ID/PW for mysql will be written in conf file.. so if we can't trust unix file system protection, there is no security in OpenStack. The ID/PW for mysql only grants you access to mysql for as long as that id/pw are enabled for access. However, the encryption keys for OpenVPN will grant any passive listener access for as long as they keep any sniffed traffic. They'll also grant an attacker the ability to MITM traffic between peers. So when an encryption key has been accessed, from where, etc, is quite a bit more crucial than knowing when a username/password combo have been accessed. Producing a trustworthy audit log for access to /etc/neutron/neutron.conf is a lot harder than producing an audit log for a REST API. So it isn't so much that file system permissions aren't enough, it is that file system observability is expensive. Note that at some point there was a POC to have a FUSE driver backed by Barbican called 'Postern' I think. That would make these discussions a lot simpler. :) 2014-05-01 10:31 GMT-07:00 Clint Byrum cl...@fewbar.com: I think you'd do something like this (Note that I don't know off the top of my head the barbican CLI or openvpn cli switches... just pseudo-code): oconf=$(mktemp -d /tmp/openvpnconfig.XX) mount -o tmpfs $oconf size=1M barbican get my-secret-openvpn-conf $oconf/foo.conf openvpn --config-dir $oconf foo --daemonize umount $oconf rmdir $oconf Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700: Hi Robert Thank you for your suggestion. so your suggestion is let OpenVPN process download key to memory directly from Babican? 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham robert.cl...@hp.com: Excuse me interrupting but couldn't you 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 filesystem disk-residency issues. -Original Message- From: Nachi Ueno [mailto:na...@ntti3.com] Sent: 01 May 2014 17:36 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation Hi Jarret IMO, Zang point is the issue saving plain private key in the filesystem for OpenVPN. Isn't this same even if we use Barbican? 2014-05-01 2:56 GMT-07:00 Jarret Raim jarret.r...@rackspace.com: Zang mentioned that part of the issue is that the private key has to be stored in the OpenVPN config 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/30/14, 6:08 PM, Nachi Ueno na...@ntti3.com wrote: 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 mest...@noironetworks.com: On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno na...@ntti3.com wrote: Hi Clint Thank you for your suggestion. Your point get taken :) Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? Yes! I think we should definitely discuss this in the advanced services meeting today. I've added it to the agenda [1]. Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f or_ next _meeting Zang Could you join the discussion
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
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 mest...@noironetworks.com: On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno na...@ntti3.com wrote: Hi Clint Thank you for your suggestion. Your point get taken :) Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? Yes! I think we should definitely discuss this in the advanced services meeting today. I've added it to the agenda [1]. Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_for_next_meeting Zang Could you join the discussion? 2014-04-29 15:48 GMT-07:00 Clint Byrum cl...@fewbar.com: Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com: On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com 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 using Barbican been discussed before? There are many reasons why using Barbican for this may be better than developing key management ourselves. No, however I'm +1 for using Barbican. Let's discuss this in certificate management topic in advanced service session. Just a suggestion: Don't defer that until the summit. Sounds like you've already got some consensus, so you don't need the summit just to rubber stamp it. I suggest discussing as much as you can right now on the mailing list, and using the time at the summit to resolve any complicated issues including any a or b things that need crowd-sourced idea making. You can also use the summit time to communicate your requirements to the Barbican developers. Point is: just because you'll have face time, doesn't mean you should use it for what can be done via the mailing list. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
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 key secret, the attacker can connect the NW for anywhere. [2] How we manage a passcode for encrypting private key? so even if openvpn supports encripted keys, when we input the passcode? Vpn process will be launched automatically by neutron-server, so we need to store it in the memory. This is same security with plain private key. For example, most of apache servers using plain private key, I guess. so the security of ssl-vpn impl depends on db, rpc trasport, file system security even if we encrypt the private key or not. may be, we have better way, but I think current design isn't so bad to prevent get merged. Best Nachi 2014-04-28 23:02 GMT-07:00 Zang MingJie zealot0...@gmail.com: Hi all: Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and Rajesh[2] There are secure issues pointed by mark, that ssl private keys are stored plain in database and in config files of vpn-agents. As Barbican is incubated, we can store certs and their private keys in Barbican. But after checking openvpn configurations, I don't think there is any way to prevent storing private key in openvpn config files without modify the openvpn implementation. I have also made several changes, added a optional port field to sslvpn-connection table, integrated with service plugin framework (I'll follow service flavor framework when it is ready), and completed the neutronclient part. It is already developed in our testing environment, I'll upload my patch sooner or later. [1] https://review.openstack.org/#/c/58897/ [2] https://review.openstack.org/#/c/70274/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com: On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com 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 using Barbican been discussed before? There are many reasons why using Barbican for this may be better than developing key management ourselves. No, however I'm +1 for using Barbican. Let's discuss this in certificate management topic in advanced service session. Thanks, Kyle [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 key secret, the attacker can connect the NW for anywhere. [2] How we manage a passcode for encrypting private key? so even if openvpn supports encripted keys, when we input the passcode? Vpn process will be launched automatically by neutron-server, so we need to store it in the memory. This is same security with plain private key. For example, most of apache servers using plain private key, I guess. so the security of ssl-vpn impl depends on db, rpc trasport, file system security even if we encrypt the private key or not. may be, we have better way, but I think current design isn't so bad to prevent get merged. Best Nachi 2014-04-28 23:02 GMT-07:00 Zang MingJie zealot0...@gmail.com: Hi all: Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and Rajesh[2] There are secure issues pointed by mark, that ssl private keys are stored plain in database and in config files of vpn-agents. As Barbican is incubated, we can store certs and their private keys in Barbican. But after checking openvpn configurations, I don't think there is any way to prevent storing private key in openvpn config files without modify the openvpn implementation. I have also made several changes, added a optional port field to sslvpn-connection table, integrated with service plugin framework (I'll follow service flavor framework when it is ready), and completed the neutronclient part. It is already developed in our testing environment, I'll upload my patch sooner or later. [1] https://review.openstack.org/#/c/58897/ [2] https://review.openstack.org/#/c/70274/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
Hi Clint Thank you for your suggestion. Your point get taken :) Kyle This is also a same discussion for LBaaS Can we discuss this in advanced service meeting? Zang Could you join the discussion? 2014-04-29 15:48 GMT-07:00 Clint Byrum cl...@fewbar.com: Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700: Hi Kyle 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com: On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com 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 using Barbican been discussed before? There are many reasons why using Barbican for this may be better than developing key management ourselves. No, however I'm +1 for using Barbican. Let's discuss this in certificate management topic in advanced service session. Just a suggestion: Don't defer that until the summit. Sounds like you've already got some consensus, so you don't need the summit just to rubber stamp it. I suggest discussing as much as you can right now on the mailing list, and using the time at the summit to resolve any complicated issues including any a or b things that need crowd-sourced idea making. You can also use the summit time to communicate your requirements to the Barbican developers. Point is: just because you'll have face time, doesn't mean you should use it for what can be done via the mailing list. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
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 amot...@gmail.com: Hi, Previously Neutron team had ReviewDays [1] and core members made themselves focus on reviews and be available on IRC channel one or more day(s) of each week (as possible as they can). The number of neutron reviews has increased compared to that time and I am afraid one or two days reviews cannot deal with neutron reviews, but the similar mechanism might work to make things better. [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Neutron BP review process for Juno
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;
}
will be
http://blockdiag.com/en/_images/blockdiag-69b48ddf499e79e437fbdf9f0e767e365f846d7a.png
(see more example
http://blockdiag.com/en/blockdiag/examples.html )
or you can try online http://blockdiag.appspot.com/
NetDiag
http://blockdiag.com/en/nwdiag/
nwdiag {
network dmz {
address = 210.x.x.x/24
web01 [address = 210.x.x.1];
web02 [address = 210.x.x.2];
}
network internal {
address = 172.x.x.x/24;
web01 [address = 172.x.x.1];
web02 [address = 172.x.x.2];
db01;
db02;
}
}
will be
http://blockdiag.com/en/_images/nwdiag-472a0e8ead9b236d7d929e645767514615bb2392.png
try
http://blockdiag.appspot.com/nwdiag/
http://blockdiag.com/en/nwdiag/nwdiag-examples.html
We have more diagrams can be generated
Activity diagram
http://blockdiag.appspot.com/actdiag/
Sequence diagram
http://blockdiag.appspot.com/seqdiag/
Best
Nachi
2014-04-16 10:42 GMT-07:00 Kyle Mestery mest...@noironetworks.com:
On Wed, Apr 16, 2014 at 12:23 PM, Russell Bryant rbry...@redhat.com wrote:
On 04/16/2014 09:51 AM, Russell Bryant wrote:
On 04/16/2014 09:39 AM, Salvatore Orlando wrote:
if the image you're adding is a diagram, I would think about
asciiflow.com http://asciiflow.com first!
In all seriousness, I think that's a very nice solution for simple
diagrams. :-)
For other diagrams, I wonder if it makes sense to just upload them to
the wiki and include links to them from the spec using the image directive.
Another thread got started on this topic for Nova.
I put up a proposal to require ASCII digrams for nova-specs here:
https://review.openstack.org/#/c/88028/
Great idea! I've done the same for neutron-specs here:
https://review.openstack.org/88037
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Neutron BP review process for Juno
Hi folks My bad,, Issue (1) was my mistake, and fixed 2014-04-16 15:16 GMT-07:00 Nachi Ueno na...@ntti3.com: 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 something. (1) Test fails == FAIL: tests.test_titles.TestTitles.test_template tags: worker-0 -- Traceback (most recent call last): File tests/test_titles.py, line 105, in test_template self._check_titles(titles) File tests/test_titles.py, line 55, in _check_titles self.assertEqual(7, len(titles)) File /home/ubuntu/neutron-specs/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py, line 321, in assertEqual self.assertThat(observed, matcher, message) File /home/ubuntu/neutron-specs/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py, line 406, in assertThat raise mismatch_error MismatchError: 7 != 8 (2) looks fine in text but broken in html (3) Productivity it takes 28 sec to write A - B - C diagram using ascii flow. It was 5 sec using block diag. 2014-04-16 14:43 GMT-07:00 Kyle Mestery mest...@noironetworks.com: On Wed, Apr 16, 2014 at 4:26 PM, Carl Baldwin c...@ecbaldwin.net wrote: Neutron (and Nova), I have had one thing come up as I've been using the template. I find that I would like to add just a little document structure in the form of a sub-heading or two under the Proposed change heading but before the required Alternatives sub-heading. However, this is not allowed by the tests. Proposed change = I want to add a little bit of document structure here but I cannot because any sub-headings would be counted among the exactly 9 sub-headings I'm required to have starting with Alternatives. This seems a bit unnatural to me. Alternatives ... The sub-headings allow structure underneath but the first heading doesn't. Could be do it a little bit differentely? Maybe something like this? Proposed change = Overview I could add structure under here. Alternatives ... Thoughts? Another idea might be to change the test to require at least the nine required sub-headings but allow for the addition of another. I'm fine with either of these proposed changes to be honest. Carl, please submit a patch to neutron-specs and we can review it there. Also, I'm in the process of adding some jenkins jobs for neutron-specs similar to nova-specs. Thanks, Kyle Carl On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery mest...@noironetworks.com wrote: 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 do. Going forward in Juno, this is how Neutron BPs will be handled by the Neutron core team. If you are currently working on a BP or code for Juno which is attached to a BP, please file the BP using the process here [1]. Given this is our first attempt at using this for reviews, I anticipate there may be a few hiccups along the way. Please reply on this thread or reach out in #openstack-neutron and we'll sort through whatever issues we find. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Blueprints#Neutron ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Neutron BP review process for Juno
+10 ! 2014-04-15 15:07 GMT-07:00 Kyle Mestery mest...@noironetworks.com: 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 do. Going forward in Juno, this is how Neutron BPs will be handled by the Neutron core team. If you are currently working on a BP or code for Juno which is attached to a BP, please file the BP using the process here [1]. Given this is our first attempt at using this for reviews, I anticipate there may be a few hiccups along the way. Please reply on this thread or reach out in #openstack-neutron and we'll sort through whatever issues we find. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Blueprints#Neutron ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TripleO fully uploaded to Debian Experimental
Hi Thomas Great! Do we have a doc how to use these packages? 2014-04-11 0:00 GMT-07:00 Thomas Goirand z...@debian.org: 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 think I can upload to normal Sid until Icehouse is released). Feedback (and bug reports to the Debian BTS) would be more than welcome, as I had no time to test it myself! Of course, the plan is to have it updated again soon. Cheers, Thomas Goirand (zigo) [1] http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo
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 jcou...@redhat.com: Dear Stackers, I am happy to announce that yesterday Tuskar UI (TripleO UI) has tagged branch 0.1.0 for Icehouse release [0]. I put together a narrated demo of all included features [1]. You can find one manual part in the whole workflow - cloud initialization. There is ongoing work on automatic os-cloud-config, but for the release we had to include manual way. Automation should be added soon though. I want to thank all contributors for hard work to make this happen. It has been pleasure to cooperate with all of you guys and I am looking forward to bringing new features [2] in. -- Jarda [0] 0.1.0 Icehouse Release of the UI: https://github.com/openstack/tuskar-ui/releases/tag/0.1.0 [1] Narrated demo of TripleO UI 0.1.0: https://www.youtube.com/watch?v=-6whFIqCqLU [2] Juno Planning for Tuskar: https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch?
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 and being abandoned weeks ago ( https://review.openstack.org/#/c/41827/) I still don't how can we develop a VPNaaS plugin following Bo Lin instructions. Is there any other patch trying to solve the problem? Is there any way to workaround the issue to get a VPNaaS plugin working? Thank you! Julio C. Barrera Juez Office phone: +34 93 357 99 27 Distributed Applications and Networks Area (DANA) i2CAT Foundation, Barcelona, Spain http://dana.i2cat.net On 27 February 2014 10:51, Bo Lin l...@vmware.com wrote: Hi Julio, You can take https://review.openstack.org/#/c/74156/ and https://review.openstack.org/#/c/74144/ as examples to write your own vpnaas driver. More info about service type framework, you can also refer to neutron/services/loadbalancer codes. -- *From: *Julio Carlos Barrera Juez juliocarlos.barr...@i2cat.net *To: *OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Sent: *Thursday, February 27, 2014 5:26:32 PM *Subject: *Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch? I'm following the change you pointed a week ago. It seems that it is working now, and will be eventually approved soon. I will be happy when it is approved. Anyway, I need more information about how to develop a service driver and a device driver for VPN plugin. I realize doing reverse-engineering that I need and RPC agent and and RPC between them to communicate and use a kind of callbacks to answer. Where I can find documentation about it and some examples? Is there any best practise guide of the use of this architecture? Thank you again! [image: i2cat] Julio C. Barrera Juez Office phone: +34 93 357 99 27 Distributed Applications and Networks Area (DANA) i2CAT Foundation, Barcelona, Spain http://dana.i2cat.nethttps://urldefense.proofpoint.com/v1/url?u=http://dana.i2cat.net/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0Am=YmmNfPyv1TNDbHlwFZT9xRPhyBxsQW%2B2aJ3daQ8RC%2BI%3D%0As=c98b2d74b41b9c8efe74e5f89d418dc5b64cd5b5003dc82b3d794c290d876d04 On 19 February 2014 09:13, Julio Carlos Barrera Juez juliocarlos.barr...@i2cat.net wrote: Thank you very much Bo. I will try all your advices and check if it works! [image: i2cat] Julio C. Barrera Juez Office phone: +34 93 357 99 27 Distributed Applications and Networks Area (DANA) i2CAT Foundation, Barcelona, Spain http://dana.i2cat.nethttps://urldefense.proofpoint.com/v1/url?u=http://dana.i2cat.net/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0Am=YmmNfPyv1TNDbHlwFZT9xRPhyBxsQW%2B2aJ3daQ8RC%2BI%3D%0As=c98b2d74b41b9c8efe74e5f89d418dc5b64cd5b5003dc82b3d794c290d876d04 On 18 February 2014 09:18, Bo Lin l...@vmware.com wrote: I wonder whether your neutron server codes have added the VPNaaS integration with service type framework change on https://review.openstack.org/#/c/41827/21https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/41827/21k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0Am=YmmNfPyv1TNDbHlwFZT9xRPhyBxsQW%2B2aJ3daQ8RC%2BI%3D%0As=4a935821d551bb10de76c121ea8f83f57c00bf3a88ac0c73b51d87f96be1524f , if not, the service_provider option is useless. You need to include the change before developing your own driver. QA (In my opinion and sth may be missing): - What is the difference between service drivers and device drivers? service drivers are driven by vpn service plugin and are responsible for casting rpc request (CRUD of vpnservices) to and do callbacks from vpn agent. device drivers are driven by vpn agent and are responsible for implementing specific vpn operations and report vpn running status. - Could I implement only one of them? device driver must be implemented based on your own device. Unless the default ipsec service driver is definitely appropriate, suggest you implement both of them. After including VPNaaS integration with service type framework, the service driver work is simple. - Where I need to put my Python implementation in my OpenStack instance? Do you mean let your instance runs your new codes? The default source codes dir is /opt/stack/neutron, you need to put your new changes into the dir and restart the neutron server. - How could I configure my OpenStack instance to use this implementation? 1. Add your new codes into source dir 2. Add appropriate vpnaas service_provider into neutron.conf and add appropriate vpn_device_driver option into vpn_agent.ini 3. restart n-svc and q-vpn Hope help you. -- *From: *Julio Carlos Barrera
Re: [openstack-dev] [Neutron][Heat] The Neutron API and orchestration
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 zbit...@redhat.com:
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-project forum. I've recently been doing some more investigation and I
want to document the exact ways in which the current Neutron API breaks
orchestration, both in the hope that a future version of it might be better
and as a guide for other API authors.
BTW it's my contention that an API that is bad for orchestration is also
hard to use for the ordinary user as well. When you're trying to figure out
the order of operations you need to do, there are two times at which you
could find out you've got it wrong:
1) Before you run the command, when you realise you don't have all of the
required data yet; or
2) After you run the command, when you get a cryptic error message.
Not only is (1) *mandatory* for a data-driven orchestration system like
Heat, it offers orders-of-magnitude better user experience for everyone.
I should say at the outset that I know next to nothing about Neutron, and
one of the goals of this message is to find out which parts I am completely
wrong about. I did know a little bit about traditional networking at one
time, and even remember some of it ;)
Neutron has a little documentation on workflow, so let's begin there:
http://docs.openstack.org/api/openstack-network/2.0/content/Overview-d1e71.html#Theory
(1) Create a network
Instinctively, I want a Network to be something like a virtual VRF (VVRF?):
a separate namespace with it's own route table, within which subnet prefixes
are not overlapping, but which is completely independent of other Networks
that may contain overlapping subnets. As far as I can tell, this basically
seems to be the case. The difference, of course, is that instead of having
to configure a VRF on every switch/router and make sure they're all in sync
and connected up in the right ways, I just define it in one place globally
and Neutron does the rest. I call this #winning. Nice work, Neutron.
In Neutron, A network is an isolated virtual layer-2 broadcast domain
http://docs.openstack.org/api/openstack-network/2.0/content/Overview-d1e71.html#subnet
so the model don't have any L3 stuffs.
(2) Associate a subnet with the network
Slightly odd choice of words, because you're actually creating a new Subnet
(there's no such thing as a Subnet not associated with a Network), but this
is probably just a minor documentation nit. Instinctively, I want a Subnet
to be something like a virtual VLAN (VVLAN?): at its most basic level, just
a group of ports that share a broadcast domain, but also having other
properties (e.g. if L3 is in use, all IP addresses in the subnet should be
in the same CIDR). This doesn't seem to be the case, though, it's just a
CIDR prefix, which leaves me wondering how L2 traffic will be treated, as
well as how I would do things like use both IPv4 and IPv6 on a single port
(by assigning a port to multiple Subnets?). Looking at the docs, there is a
much bigger emphasis on DHCP client settings than I expected - surely I
might want to want to give two sets of ports in the same Subnet different
DHCP configs? Still, this is not bad - the DHCP configuration is done by the
time the Subnet is created, so there's no problem in connecting stuff to it
immediately after.
so, subnet has many meanings.
In neutron, it means
A subnet represents an IP address block that can be used to assign IP
addresses to virtual instances.
http://docs.openstack.org/api/openstack-network/2.0/content/Overview-d1e71.html#subnet
so subnet in your definition is more like network in neutron.
(3) Boot a VM and attach it to the network
Here's where you completely lost me. I just created a Subnet - maybe a bunch
of Subnets. I don't want to attach my VM just anywhere in the *Network*, I
want to attach it to a *particular* Subnet. It's not at all obvious where my
instance will get attached (at random?), because this API just plain takes
the Wrong data type. As a user, I'm irritated and confused.
+1 for specifying subnet on booting server.
We should have a bp in nova side and neutron.
The situation for orchestration, though, is much, much worse. Because the
server takes a reference to a network, the dependency graph generated from
my template will look like this:
Network -- Subnet
^
\
Server
And yet if the Server is created before the Subnet (as will happen ~50% of
the time), it will fail. And vice-versa on delete, where the server must be
removed before the subnet. The dependency graph we needed to create was
this:
Network -- Subnet -- Server
The solution used here was to jury-rig the resource types in Heat with a
hidden dependency. We can't know
[openstack-dev] [Nova][Neutron] Neutron + Nova + OVS security group fix
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 know if this time won't work with you. Bug Report https://bugs.launchpad.net/neutron/+bug/1297469 Background of this issue: ML2 + OVSDriver + IptablesBasedFirewall combination is a default plugin setting in the Neutron. In this case, we need a special handing in VIF. Because OpenVSwitch don't support iptables, we are using linuxbride + openvswitch bridge. We are calling this as hybrid driver. On the other discussion, we generalized the Nova side VIF plugging to the Libvirt GenericVIFDriver. The idea is let neturon tell the VIF plugging configration details to the GenericDriver, and GerericDriver takes care of it. Unfortunatly, HybridDriver is removed before GenericDriver is ready for security group. This makes ML2 + OVSDriver + IptablesBasedFirewall combination unfunctional. We were working on realfix, but we can't make it until Icehouse release due to design discussions [1]. # Even if neturon side patch isn't merged yet. So we are proposing a workaround fix to Nova side. In this fix, we are adding special version of the GenericVIFDriver which can work with the combination. There is two point on this new Driver. (1) It prevent set conf.filtername. Because we should use NoopFirewallDriver, we need conf.filtername should be None when we use it. (2) use plug_ovs_hybrid and unplug_ovs_hybrid by enforcing get_require_firewall as True. Here is patchs with UT. Workaournd fix: Nova https://review.openstack.org/#/c/82904/ Devstack patch for ML2 (Tested with 82904) https://review.openstack.org/#/c/82937/ We have tested the patch 82904 with following test, and this works. - Launch VM - Assign floating ip - make sure ping to the floating ip is failing from GW - modify security group rule to allow ping from anywhere - make sure ping is working [1] Real fix: (defered to Juno) Improve vif attributes related with firewalling https://review.openstack.org/#/c/21946/ Support binding:vif_security parameter in neutron https://review.openstack.org/#/c/44596/ -- I'll put latest update on here https://etherpad.openstack.org/p/neturon_security_group_fix_workaround_icehouse Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Neutron + Nova + OVS security group fix
Hi Salvatore 2014-03-25 17:57 GMT-07:00 Salvatore Orlando sorla...@nicira.com: 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, Nachi Ueno na...@ntti3.com wrote: 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) thanks, but I'd prefer you discuss the matter on IRC. I won't be available at that time and having IRC logs on eavesdrop will allow me to catch up without having to ask people or waiting for minutes on the mailing list. -- Please let me know if this time won't work with you. Bug Report https://bugs.launchpad.net/neutron/+bug/1297469 Background of this issue: ML2 + OVSDriver + IptablesBasedFirewall combination is a default plugin setting in the Neutron. In this case, we need a special handing in VIF. Because OpenVSwitch don't support iptables, we are using linuxbride + openvswitch bridge. We are calling this as hybrid driver. The hybrid solution in Neutron has been around for such a long time that I would hardly call it a special handling. To summarize, the VIF is plugged into a linux bridge, which has another leg plugged in the OVS integration bridge. On the other discussion, we generalized the Nova side VIF plugging to the Libvirt GenericVIFDriver. The idea is let neturon tell the VIF plugging configration details to the GenericDriver, and GerericDriver takes care of it. The downside of the generic driver is that so far it's assuming local configuration values are sufficient to correctly determine VIF plugging. The generic VIF driver will use the hybrid driver if get_firewall_required is true. And this will happen if the firewall driver is anything different from the NoOp driver. This was uncovered by a devstack commit (1143f7e). When I previously discussed with the people involved this issue, I was under the impression that the devstack patch introduced the problem. Apparently the Generic VIF driver is not taking at the moments hints from neutron regarding the driver to use, and therefore, from what I gather, makes a decision based on nova conf flags only. So a quick fix would be to tell the Generic VIF driver to always use hybrid plugging when neutron is enabled (which can be gathered by nova conf flags). This will fix the issue for ML2, but will either break or insert an unnecessary extra hop for other plugins. get_firewall_required = True won't fix this issue. We need to make sure we won't set config.filtername in this case. Unfortunatly, HybridDriver is removed before GenericDriver is ready for security group. The drivers were marked for deprecation in Havana, and if we thought the GenericDriver was not good for neutron security groups we had enough time to scream. The reason we missed this issue is we lack the negative test for security groups.. so we couldn't realize this. This makes ML2 + OVSDriver + IptablesBasedFirewall combination unfunctional. We were working on realfix, but we can't make it until Icehouse release due to design discussions [1]. # Even if neturon side patch isn't merged yet. So we are proposing a workaround fix to Nova side. In this fix, we are adding special version of the GenericVIFDriver which can work with the combination. There is two point on this new Driver. (1) It prevent set conf.filtername. Because we should use NoopFirewallDriver, we need conf.filtername should be None when we use it. (2) use plug_ovs_hybrid and unplug_ovs_hybrid by enforcing get_require_firewall as True. Here is patchs with UT. Workaournd fix: Nova https://review.openstack.org/#/c/82904/ Devstack patch for ML2 (Tested with 82904) https://review.openstack.org/#/c/82937/ Are there other plugins which need the hybrid driver for sec groups to work? I think so. And also - the patch does not seem to work according to Jenkins. The failures look genuine to me. I agere with you, however we should start with minimal fix for this. We can work for another plugin in another patch. This patch will fail in Jenkins because it needs 82904. We have tested the patch 82904 with following test, and this works. - Launch VM - Assign floating ip - make sure ping to the floating ip is failing from GW - modify security group rule to allow ping from anywhere - make sure ping is working You can actually run your devstack patch with your patch under review in the check queue. Check what Aaron did here: https://review.openstack.org/#/c/78694/11 Nice hack. let me try it I wonder if instead of putting this bit of tape, we could just leverage the VIF_TYPE attribute of the port binding extension. Most plugins use
Re: [openstack-dev] Neutron: Need help with tox failure in VPN code
./run_test.sh or ./run_test.sh -d package_name is working? 2014-03-03 21:28 GMT-08:00 Paul Michali p...@cisco.com: 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 worked fine, passed Jenkins, etc. Found out that the STF won't make it to I-3, so I removed the dependency from my change set and tried to modify the plugin.py file to use some STF logic (like LBaaS uses) to load the desired service driver that is specified as the default. Adjusted the code to no longer use provider info. Well, in doing so, tox fails, and unfortunately there little info on the failure. This can be seen by running a subset of the tests, where 2 fail: tox -e py27 -v -- neutron.tests.unit.services.vpn only the name of a failing test case for one, and a mention of return code 10 on another and no other info on the failure reason. I didn't see this on a full tox run in my repo, but Jenkins failed and Akihiro noticed it too, in running the above subset of the suite (thanks!). I've narrow it down a bit, but have no idea why it fails... One, it seems to be some interaction between test_vpnaas_driver_plugin.py and the two service driver tests (cisco_ipsec.py and ipsec.py). I can remove either one of the service driver tests cases, and it will still fail with the other one (so even the reference code fails). Two, if I change plugin.py to set self.driver to the reference device driver (as is done in the latest patch set) it works fine with all test cases. Three, it seems to be a test only issue, because I can run devstack with the login I have in plugin.py, currently commented out in __init__(), and successfully load either the reference or cisco service driver, by changing neutron.conf. It seems like I'm doing something wrong in the loading of the service driver, or using this implementation, is somehow interacting with the tests. If anyone has ideas on what is wrong, or a better way to load the service driver, please let me know. I was thinking I could read and parse neutron.conf manually and then load the service driver, but there must be a better way! Thanks! PCM (Paul Michali) MAIL p...@cisco.com IRCpcm_ (irc.freenode.net) TW@pmichali GPG key4525ECC253E31A83 Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review
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('CI|Ryu|Testing|Mine')
0){list[i].style.color='#66'}else{list[i].style.color='red'}};})()
enjoy :)
Nachi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] We should wait approving code due to bug 1280035
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/73832/ However, unfortunately, we get hit another issue what's we are facing. And, the situation get worse. so we are going to revert the change https://review.openstack.org/#/c/74882/ This revert fix will be merged in 4 hours (hopefully) However, the situation is only back to the 1280035.. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] We should wait approving code due to bug 1280035
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 na...@ntti3.com: 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/73832/ However, unfortunately, we get hit another issue what's we are facing. And, the situation get worse. so we are going to revert the change https://review.openstack.org/#/c/74882/ This revert fix will be merged in 4 hours (hopefully) However, the situation is only back to the 1280035.. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Urgent questions on Service Type Framework for VPNaaS
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 sumitnaiksa...@gmail.com: Hi Paul, Our plan with FWaaS was to get it to parity with LBaaS as far as STF is concerned. That way any changes to STF can be explored in the context of all services, and the migration can also be performed for all services. Accordingly, Gary Duan has been actively working on the patch: https://review.openstack.org/#/c/60699/ and we hope to get it approved and merged soon. Thanks, ~Sumit. On Sat, Feb 15, 2014 at 5:09 PM, Paul Michali p...@cisco.com wrote: Hi Nachi and other cores! I'm very close to publishing my vendor based VPNaaS driver (service driver is ready, device driver is a day or two out), but have a bit of an issue. This code uses the Service Type Framework, which, as you know, is still out for review (and has been idle for a long time). I updated the STF client code and it is updated in Gerrit. I saw you put a -1 on your STF server code. Is the feature being abandoned or was that for some other reason? If going forward with it, can you update the server STF code, or should I do it (I have a branch with the STF based on master of about 2 weeks ago, so it should update OK)? Also, I'm wondering (worried) about the logistics of my reviews. I wanted to do my service driver and device driver separately (I guess making the latter dependent on the former in Gerrit). However, because of the STF, I'd need to make my service driver dependent on the STF server code too (my current branch has both code pieces). Really worried about the complexity there and about it getting hung up, if there is more delay on the STF review. I've been working on another branch without the STF dependency, however that has to hack in part of the STF to be able to select the service driver based on config vs hardwired to the reference driver. Should I proceed with the STF review chaining or push out my code w/o the STF? Thanks! PCM (Paul Michali) MAIL p...@cisco.com IRCpcm_ (irc.freenode.net) TW@pmichali GPG key4525ECC253E31A83 Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core
+1 2014年2月12日水曜日、Mayur Patilram.nath241...@gmail.comさんは書きました: +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
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 rajesh.mli...@gmail.com: Thanks John. My initial approach is similar to Keystone's. This is mainly to unblock me from making progress on the driver. Nachi is doing the API part. I will discuss with him to explore other options. Can you send us the link to your review? Thanks, -Rajesh Mohan On Mon, Jan 27, 2014 at 6:00 AM, John Dennis jden...@redhat.com wrote: On 01/26/2014 05:36 PM, rajesh_moh...@dell.com wrote: I am working on SSL VPN BP. CA certificate is one of the resources. We decided to use PEM formatted certificates. It is multi-line string 1 -BEGIN CERTIFICATE- 2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD snip 21 0vO728pEcn6QtOpU7ZjEv8JLKRHwyq8kwd8gKMflWZRng4R2dj3cdd24oYJxn5HW 22 atXnq+N9H9dFgMfw5NNefwJrZ3zAE6mu0bAIoXVsKT2S 23 -END CERTIFICATE- Is there a standard way to represent this as single line string? Maybe there is some other project that passes certificates on command line/url. I am looking for some accepted way to represent PEM formatted file on command line. I am thinking of concatenating all lines into single string and rebuilding the file when configuration file is generated.Will we hit any CLI size limitations if we pass long strings. In general PEM formatted certificates and other X509 binary data objects should be exchanged in the original PEM format for interoperabilty purposes. For command line tools it's best to pass PEM objects via a filename. However, having said that there is at least one place in Openstack which passes PEM data via a HTTP header and/or URL, it's the Keystone token id which is a binary CMS object normally exchanged in PEM format. Keystone strips the PEM header and footer, strips line endings and modifies one of the base64 alphabet characters which was incompatible with HTTP and URL encoding. However what keystone was doing was not correct and in fact did not follow an existing RFC (e.g. URL safe base64). I fixed these problems and in the process wrote two small Python modules base64utils and pemutils to do PEM transformations correctly (plus general utilities for working with base64 and PEM data). These were submitted to both keystone and oslo, Oslo on the assumption they should be general purpose utilities available to all of openstack. I believe these have languished in review purgatory, because I was pulled off to work on other issues I haven't had the time to babysit the review. -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ 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
Hi Rajesh yes. Please take a looks nova keypair-add implementation https://github.com/openstack/python-novaclient/blob/e3d686f39ad9787a70894dff3db9352be6b3f0dd/novaclient/v1_1/shell.py#L2372 2014-01-27 Rajesh Mohan rajesh.mli...@gmail.com: Nachi, I did not know that we could give files names. Since we had 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 na...@ntti3.com wrote: 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 rajesh.mli...@gmail.com: Thanks John. My initial approach is similar to Keystone's. This is mainly to unblock me from making progress on the driver. Nachi is doing the API part. I will discuss with him to explore other options. Can you send us the link to your review? Thanks, -Rajesh Mohan On Mon, Jan 27, 2014 at 6:00 AM, John Dennis jden...@redhat.com wrote: On 01/26/2014 05:36 PM, rajesh_moh...@dell.com wrote: I am working on SSL VPN BP. CA certificate is one of the resources. We decided to use PEM formatted certificates. It is multi-line string 1 -BEGIN CERTIFICATE- 2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD snip 21 0vO728pEcn6QtOpU7ZjEv8JLKRHwyq8kwd8gKMflWZRng4R2dj3cdd24oYJxn5HW 22 atXnq+N9H9dFgMfw5NNefwJrZ3zAE6mu0bAIoXVsKT2S 23 -END CERTIFICATE- Is there a standard way to represent this as single line string? Maybe there is some other project that passes certificates on command line/url. I am looking for some accepted way to represent PEM formatted file on command line. I am thinking of concatenating all lines into single string and rebuilding the file when configuration file is generated.Will we hit any CLI size limitations if we pass long strings. In general PEM formatted certificates and other X509 binary data objects should be exchanged in the original PEM format for interoperabilty purposes. For command line tools it's best to pass PEM objects via a filename. However, having said that there is at least one place in Openstack which passes PEM data via a HTTP header and/or URL, it's the Keystone token id which is a binary CMS object normally exchanged in PEM format. Keystone strips the PEM header and footer, strips line endings and modifies one of the base64 alphabet characters which was incompatible with HTTP and URL encoding. However what keystone was doing was not correct and in fact did not follow an existing RFC (e.g. URL safe base64). I fixed these problems and in the process wrote two small Python modules base64utils and pemutils to do PEM transformations correctly (plus general utilities for working with base64 and PEM data). These were submitted to both keystone and oslo, Oslo on the assumption they should be general purpose utilities available to all of openstack. I believe these have languished in review purgatory, because I was pulled off to work on other issues I haven't had the time to babysit the review. -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion
Hi Mathieu, Bob Thank you for your reply OK let's do (A) - (C) for now. (A) Remove firewall_driver from server side Remove Noop -- I'll write patch for this (B) update ML2 with extend_port_dict -- Bob will push new review for this (C) Fix vif_security patch using (1) and (2). -- I'll update the patch after (A) and (B) merged # config is hardwired for each mech drivers for now (Optional D) Rething firewall_driver config in the agent 2014/1/16 Robert Kukura rkuk...@redhat.com: On 01/16/2014 04:43 AM, Mathieu Rohon wrote: Hi, your proposals make sense. Having the firewall driver configuring so much things looks pretty stange. Agreed. I fully support proposed fix 1, adding enable_security_group config, at least for ml2. I'm not sure whether making this sort of change go the openvswitch or linuxbridge plugins at this stage is needed. Enabling security group should be a plugin/MD decision, not a driver decision. I'm not so sure I support proposed fix 2, removing firewall_driver configuration. I think with proposed fix 1, firewall_driver becomes an agent-only configuration variable, which seems fine to me, at least for now. The people working on ovs-firewall-driver need something like this to choose the between their new driver and the iptables driver. Each L2 agent could obviously revisit this later if needed. For ML2, in a first implementation, having vif security based on vif_type looks good too. I'm not convinced to support proposed fix 3, basing ml2's vif_security on the value of vif_type. It seems to me that if vif_type was all that determines how nova handles security groups, there would be no need for either the old capabilities or new vif_security port attribute. I think each ML2 bound MechanismDriver should be able to supply whatever vif_security (or capabilities) value it needs. It should be free to determine that however it wants. It could be made configurable on the server-side as Mathieu suggest below, or could be kept configurable in the L2 agent and transmitted via agents_db RPC to the MechanismDriver in the server as I have previously suggested. As an initial step, until we really have multiple firewall drivers to choose from, I think we can just hardwire each agent-based MechanismDriver to return the correct vif_security value for its normal firewall driver, as we currently do for the capabilities attribute. Also note that I really like the extend_port_dict() MechanismDriver methods in Nachi's current patch set. This is a much nicer way for the bound MechanismDriver to return binding-specific attributes than what ml2 currently does for vif_type and capabilities. I'm working on a patch taking that part of Nachi's code, fixing a few things, and extending it to handle the vif_type attribute as well as the current capabilities attribute. I'm hoping to post at least a WIP version of this today. I do support hardwiring the other plugins to return specific vif_security values, 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 one of the firewall driver during port_create/update/get. Best, Mathieu On Wed, Jan 15, 2014 at 6:29 PM, Nachi Ueno na...@ntti3.com wrote: 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 proposal for how to fix it. https://docs.google.com/presentation/d/1ktF7NOFY_0cBAhfqE4XjxVG9yyl88RU_w9JcNiOukzI/edit#slide=id.p Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion
Hi Amir 2014/1/16 Amir Sadoughi amir.sadou...@rackspace.com: Hi all, I just want to make sure I understand the plan and its consequences. I’m on board with the YAGNI principle of hardwiring mechanism drivers to return their firewall_driver types for now. However, after (A), (B), and (C) are completed, to allow for Open vSwitch-based security groups (blueprint ovs-firewall-driver) is it correct to say: we’ll need to implement a method such that the ML2 mechanism driver is aware of its agents and each of the agents' configured firewall_driver? i.e. additional RPC communication? From yesterday’s meeting: http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-01-15-16.00.log.html 16:44:17 rkukura I've suggested that the L2 agent could get the vif_security info from its firewall_driver, and include this in its agents_db info 16:44:39 rkukura then the bound MD would return this as the vif_security for the port 16:45:47 rkukura existing agents_db RPC would send it from agent to server and store it in the agents_db table Does the above suggestion change with the plan as-is now? From Nachi’s response, it seemed like maybe we should support concurrent firewall_driver instances in a single agent. i.e. don’t statically configure firewall_driver in the agent, but let the MD choose the firewall_driver for the port based on what firewall_drivers the agent supports. Let's say we have OpenFlowBasedFirewallDriver and IptablesBasedFirewallDriver in future. I believe there is no usecase to let user to select such implementation detail by host. so it is enough if we have a config security_group_mode=(openflow or iptables) in OVS MD configuration, then update vif_security based on this value. Thanks, Amir On Jan 16, 2014, at 11:42 AM, Nachi Ueno na...@ntti3.com wrote: Hi Mathieu, Bob Thank you for your reply OK let's do (A) - (C) for now. (A) Remove firewall_driver from server side Remove Noop -- I'll write patch for this (B) update ML2 with extend_port_dict -- Bob will push new review for this (C) Fix vif_security patch using (1) and (2). -- I'll update the patch after (A) and (B) merged # config is hardwired for each mech drivers for now (Optional D) Rething firewall_driver config in the agent 2014/1/16 Robert Kukura rkuk...@redhat.com: On 01/16/2014 04:43 AM, Mathieu Rohon wrote: Hi, your proposals make sense. Having the firewall driver configuring so much things looks pretty stange. Agreed. I fully support proposed fix 1, adding enable_security_group config, at least for ml2. I'm not sure whether making this sort of change go the openvswitch or linuxbridge plugins at this stage is needed. Enabling security group should be a plugin/MD decision, not a driver decision. I'm not so sure I support proposed fix 2, removing firewall_driver configuration. I think with proposed fix 1, firewall_driver becomes an agent-only configuration variable, which seems fine to me, at least for now. The people working on ovs-firewall-driver need something like this to choose the between their new driver and the iptables driver. Each L2 agent could obviously revisit this later if needed. For ML2, in a first implementation, having vif security based on vif_type looks good too. I'm not convinced to support proposed fix 3, basing ml2's vif_security on the value of vif_type. It seems to me that if vif_type was all that determines how nova handles security groups, there would be no need for either the old capabilities or new vif_security port attribute. I think each ML2 bound MechanismDriver should be able to supply whatever vif_security (or capabilities) value it needs. It should be free to determine that however it wants. It could be made configurable on the server-side as Mathieu suggest below, or could be kept configurable in the L2 agent and transmitted via agents_db RPC to the MechanismDriver in the server as I have previously suggested. As an initial step, until we really have multiple firewall drivers to choose from, I think we can just hardwire each agent-based MechanismDriver to return the correct vif_security value for its normal firewall driver, as we currently do for the capabilities attribute. Also note that I really like the extend_port_dict() MechanismDriver methods in Nachi's current patch set. This is a much nicer way for the bound MechanismDriver to return binding-specific attributes than what ml2 currently does for vif_type and capabilities. I'm working on a patch taking that part of Nachi's code, fixing a few things, and extending it to handle the vif_type attribute as well as the current capabilities attribute. I'm hoping to post at least a WIP version of this today. I do support hardwiring the other plugins to return specific vif_security values, but those values may need to depend on the value of enable_security_group from proposal 1. -Bob Once OVSfirewallDriver
Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion
Hi Bob, Kyle I pushed (A) https://review.openstack.org/#/c/67281/. so could you review it? 2014/1/16 Robert Kukura rkuk...@redhat.com: On 01/16/2014 03:13 PM, Kyle Mestery wrote: On Jan 16, 2014, at 1:37 PM, Nachi Ueno na...@ntti3.com wrote: Hi Amir 2014/1/16 Amir Sadoughi amir.sadou...@rackspace.com: Hi all, I just want to make sure I understand the plan and its consequences. I’m on board with the YAGNI principle of hardwiring mechanism drivers to return their firewall_driver types for now. However, after (A), (B), and (C) are completed, to allow for Open vSwitch-based security groups (blueprint ovs-firewall-driver) is it correct to say: we’ll need to implement a method such that the ML2 mechanism driver is aware of its agents and each of the agents' configured firewall_driver? i.e. additional RPC communication? From yesterday’s meeting: http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-01-15-16.00.log.html 16:44:17 rkukura I've suggested that the L2 agent could get the vif_security info from its firewall_driver, and include this in its agents_db info 16:44:39 rkukura then the bound MD would return this as the vif_security for the port 16:45:47 rkukura existing agents_db RPC would send it from agent to server and store it in the agents_db table Does the above suggestion change with the plan as-is now? From Nachi’s response, it seemed like maybe we should support concurrent firewall_driver instances in a single agent. i.e. don’t statically configure firewall_driver in the agent, but let the MD choose the firewall_driver for the port based on what firewall_drivers the agent supports. I don't see the need for anything that complex, although it could certainly be done in any MD+agent that needed it. I personally feel statically configuring a firewall driver for an L2 agent is sufficient right now, and all ports handled by that agent will use that firewall driver. Clearly, different kinds of L2 agents that coexist within a deployment may use different firewall drivers. For example, linuxbridge-agent might use iptables-firewall-driver, openvswitch-agent might use ovs-firewall-driver, and hyperv-agent might use something else. I can also imagine cases where different instances of the same kind of L2 agent on different nodes might use different firewall drivers. Just as a hypothetical example, lets say that the ovs-firewall-driver requires new OVS features (maybe connection tracking). A deployment might have this new OVS feature available on some if its nodes, but not on others. It could be useful to configure openvswitch-agent on the nodes with the new OVS version to use ovs-firewall-driver, and configure openvswitch-agent on the nodes without the new OVS version to use iptables-firewall-driver. That kind of flexibility seems best supported by simply configuring the firewall driver in /ovs_neutron_plugin.ini on each node, which is what we currently do. Let's say we have OpenFlowBasedFirewallDriver and IptablesBasedFirewallDriver in future. I believe there is no usecase to let user to select such implementation detail by host. I suggest a hypothetical use case above. Not sure how important it is, but I'm hesitant to rule it out without good reason. Our community resource is limited, so we should focus on some usecase and functionalities. If there is no strong supporter for this usecase, we shouldn't do it. We should take simplest implementation for our focused usecase. so it is enough if we have a config security_group_mode=(openflow or iptables) in OVS MD configuration, then update vif_security based on this value. This is certainly one way the MD+agent combination could do it. It would require some RPC to transmit the choice of driver or mode to the agent. But I really don't think the MD and server have any business worrying about which firewall driver class runs in the L2 agent. Theoretically, the agent could be written in java;-). And don't forget that users may want to plug in a custom firewall driver class instead. I think these are the options, in my descending or of current preference: 1) Configure firewall_driver only in the agent and pass vif_security from the agent to the server. Each L2 agent gets the vif_security value from its configured driver and includes it in the agents_db RPC data. The MD copies the vif_security value from the agents_db to the port dictionary. 2) Configure firewall_driver only in the agent but the hardwire vif_security value for each MD. This is a reasonable short term solution until we actually have multiple firewall drivers that can work with single MD+agent. 3) Configure firewall_driver only in the agent and configure the vif_security value for each MD in the server. This is a slight improvement on #2 but doesn't handle the use case above. It seems more complicated and error prone for the user than #1. 4) Configure
Re: [openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion
Thanks! Kyle 2014/1/16 Kyle Mestery mest...@siliconloons.com: On Jan 16, 2014, at 4:27 PM, Nachi Ueno na...@ntti3.com 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 Robert Kukura rkuk...@redhat.com: On 01/16/2014 03:13 PM, Kyle Mestery wrote: On Jan 16, 2014, at 1:37 PM, Nachi Ueno na...@ntti3.com wrote: Hi Amir 2014/1/16 Amir Sadoughi amir.sadou...@rackspace.com: Hi all, I just want to make sure I understand the plan and its consequences. I’m on board with the YAGNI principle of hardwiring mechanism drivers to return their firewall_driver types for now. However, after (A), (B), and (C) are completed, to allow for Open vSwitch-based security groups (blueprint ovs-firewall-driver) is it correct to say: we’ll need to implement a method such that the ML2 mechanism driver is aware of its agents and each of the agents' configured firewall_driver? i.e. additional RPC communication? From yesterday’s meeting: http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-01-15-16.00.log.html 16:44:17 rkukura I've suggested that the L2 agent could get the vif_security info from its firewall_driver, and include this in its agents_db info 16:44:39 rkukura then the bound MD would return this as the vif_security for the port 16:45:47 rkukura existing agents_db RPC would send it from agent to server and store it in the agents_db table Does the above suggestion change with the plan as-is now? From Nachi’s response, it seemed like maybe we should support concurrent firewall_driver instances in a single agent. i.e. don’t statically configure firewall_driver in the agent, but let the MD choose the firewall_driver for the port based on what firewall_drivers the agent supports. I don't see the need for anything that complex, although it could certainly be done in any MD+agent that needed it. I personally feel statically configuring a firewall driver for an L2 agent is sufficient right now, and all ports handled by that agent will use that firewall driver. Clearly, different kinds of L2 agents that coexist within a deployment may use different firewall drivers. For example, linuxbridge-agent might use iptables-firewall-driver, openvswitch-agent might use ovs-firewall-driver, and hyperv-agent might use something else. I can also imagine cases where different instances of the same kind of L2 agent on different nodes might use different firewall drivers. Just as a hypothetical example, lets say that the ovs-firewall-driver requires new OVS features (maybe connection tracking). A deployment might have this new OVS feature available on some if its nodes, but not on others. It could be useful to configure openvswitch-agent on the nodes with the new OVS version to use ovs-firewall-driver, and configure openvswitch-agent on the nodes without the new OVS version to use iptables-firewall-driver. That kind of flexibility seems best supported by simply configuring the firewall driver in /ovs_neutron_plugin.ini on each node, which is what we currently do. Let's say we have OpenFlowBasedFirewallDriver and IptablesBasedFirewallDriver in future. I believe there is no usecase to let user to select such implementation detail by host. I suggest a hypothetical use case above. Not sure how important it is, but I'm hesitant to rule it out without good reason. Our community resource is limited, so we should focus on some usecase and functionalities. If there is no strong supporter for this usecase, we shouldn't do it. We should take simplest implementation for our focused usecase. so it is enough if we have a config security_group_mode=(openflow or iptables) in OVS MD configuration, then update vif_security based on this value. This is certainly one way the MD+agent combination could do it. It would require some RPC to transmit the choice of driver or mode to the agent. But I really don't think the MD and server have any business worrying about which firewall driver class runs in the L2 agent. Theoretically, the agent could be written in java;-). And don't forget that users may want to plug in a custom firewall driver class instead. I think these are the options, in my descending or of current preference: 1) Configure firewall_driver only in the agent and pass vif_security from the agent to the server. Each L2 agent gets the vif_security value from its configured driver and includes it in the agents_db RPC data. The MD copies the vif_security value from the agents_db to the port dictionary. 2) Configure firewall_driver only in the agent but the hardwire vif_security value for each MD. This is a reasonable short term solution until we actually have multiple firewall drivers that can work with single MD+agent. 3) Configure firewall_driver only in the agent and configure the vif_security value for each MD
[openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion
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 proposal for how to fix it. https://docs.google.com/presentation/d/1ktF7NOFY_0cBAhfqE4XjxVG9yyl88RU_w9JcNiOukzI/edit#slide=id.p Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
Hi Clint 2014/1/10 Clint Byrum cl...@fewbar.com: 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 central resource manager. (nova-api or neturon server etc). This is how to add new hosts, in cloudstack, vcenter, and openstack. Cloudstack: Go to web UI, add Host/ID/PW. http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/host-add.html vCenter: Go to vsphere client, Host/ID/PW. https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.solutions.doc%2FGUID-A367585C-EB0E-4CEB-B147-817C1E5E8D1D.html Openstack, - Manual - setup mysql connection config, rabbitmq/qpid connection config, keystone config,, neturon config, http://docs.openstack.org/havana/install-guide/install/apt/content/nova-compute.html We have some deployment system including chef / puppet / packstack, TripleO - Chef/Puppet Setup chef node Add node/ apply role - Packstack - Generate answer file https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/sect-Running_PackStack_Non-interactively.html - packstack --install-hosts=192.168.1.0,192.168.1.1,192.168.1.2 - TripleO - UnderCloud nova baremetal node add - OverCloud modify heat template For residence in this mailing list, Chef/Puppet or third party tool is easy to use. However, I believe they are magical tools to use for many operators. Furthermore, these development system tend to take time to support newest release. so most of users, OpenStack release didn't means it can be usable for them. IMO, current way to manage configuration is the cause of this issue. If we manage everything via API, we can manage cluster by horizon. Then user can do go to horizon, just add host. It may take time to migrate config to API, so one easy step is to convert existing config for API resources. This is the purpose of this proposal. Hi Nachi. What you've described is the vision for TripleO and Tuskar. We do not lag the release. We run CD and will be in the gate real soon now so that TripleO should be able to fully deploy Icehouse on Icehouse release day. yeah, I'm big fan of TripleO and Tuskar. However, may be, it is difficult to let TripleO/Tuskar up-to-dated with newest releases. so let's say Nova and neutron added new function in 3rd release (I3 for icehouse), there is no way to support it in TripleO/Tuskar. This is natural, because TripleO/Tuskar is 3rd party tool for nova or neutron. (same as Chef/Puppet). IMO, Tuskar API and existing projects(nova, neturon) should be integrated in design level. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada
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 ante...@anteaya.info: On 01/08/2014 03:10 AM, Nachi Ueno wrote: Hi Anita Let's me join this session also. Nachi Ueno NTT i3 Wonderful Nachi. We have spoken on irc to ensure you have your questions answered. It will be great to have another neutron-core at the code sprint. Thank you, Anita. 2014/1/5 Anita Kuno ante...@anteaya.info: 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 relatively new to OpenStack community with a strong desire to learn and contribute. Having a strong desire to participate effectively is great. The difficulty for us is that we have already indicated that we need experienced participants at the code sprint. [0] Having long periods of silence and then simply announcing you have booked your flights makes things difficult since we have been in conversation with others about this for some time. I'm not saying don't come, I am saying that this now puts myself and Mark in a position of having to explain ourselves to others regarding consistency. Mark and I will address this, though I will need to discuss this with Mark to hear his thoughts and I am unable right now since I am at a conference all week. [1] Going forward, having regular conversations about items of this nature (irc is a great tool for this) is something I would like to see happen more often. You may have seen that Arista Testing has come alive and is voting on the newly submitted neutron patches. I have been busy putting together the framework, and learning the Jenkins/Gerrit interface. Yes. Can you respond on the Remove voting until your testing structure works thread please? This enables people who wish to respond to you on this point a place to conduct the conversation. It also preserves a history of the topic so that those searching the archives have all the relevant information in one place. Now, I have shifted my focus on Neutron/networking tempest tests. I notice some of these tests are failing on my setup. I have started to dig into these with the intent to understand them. That is a great place to begin. Thank you for taking interest and pursuing test bugs. In terms of this upcoming sprint, if you folks can give some pointers that will help me get better prepared and productive, that will be appreciated. We need folks attending the sprint who are familiar with offering patches to tempest. Seeing your name in this list would be a great indicator that you are at least able to offer a patch. [3] If you are able to focus this week on getting up to speed on Tempest and the Neutron Tempest process, then your attendance at the conference may possibly be effective both for yourself and for the rest of the participants. This wiki page is probably a good place to begin. [4] The etherpad tracking the Neutron Tempest team's progress is here. [5] Familiarizing yourself with the status of the conversation during the meetings will help as well, though it isn't as important in terms of being useful at the sprint as offering a tempest patch. Neutron meeting logs can be found here. [6] Also being available in channel will go a long way to fostering the kind of interactions which are constructive now and in the future. I don't see you in channel much, it would be great to see you more. Looking forward to meeting and working with you. And I you. Let's consider this an opportunity for greater participation with Neutron and having more conversations in irc is a great way to begin. Though I am not available in -neutron this week others are, so please announce when you are ready to work and hopefully someone will be keeping an eye out for you and offer you a hand. regards.. -Sukhdev Thanks Sukhdev, Anita. [0] http://lists.openstack.org/pipermail/openstack-dev/2013-December/022918.html [1] http://eavesdrop.openstack.org/meetings/networking/2013/networking.2013-12-16-21.02.log.html timestamp 21:57:46 [2] http://lists.openstack.org/pipermail/openstack-dev/2013-December/023228.html [3] https://review.openstack.org/#/q/status:open+project:openstack/tempest,n,z [4] https://wiki.openstack.org/wiki/Neutron/TempestAPITests [5] https://etherpad.openstack.org/p/icehouse-summit-qa-neutron [6] http://eavesdrop.openstack.org/meetings/networking/2013/ On Fri, Dec 27, 2013 at 9:00 AM, Anita Kuno ante...@anteaya.info wrote: On 12/18/2013 04:17 PM, Anita Kuno wrote: Okay time for a recap. What: Neutron Tempest code sprint Where: Montreal, QC, Canada When: January 15, 16, 17 2014 Location: I am about to sign the contract for Salle du Parc at 3625 Parc avenue, a room in a residence of McGill University. Time: 9am - 5am Time: 9am - 5pm I am
[openstack-dev] [Neturon][CI] Embrane CI is attacking gerrit
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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
2014/1/13 Clint Byrum cl...@fewbar.com: Excerpts from Nachi Ueno's message of 2014-01-13 10:35:07 -0800: Hi Clint 2014/1/10 Clint Byrum cl...@fewbar.com: 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 central resource manager. (nova-api or neturon server etc). This is how to add new hosts, in cloudstack, vcenter, and openstack. Cloudstack: Go to web UI, add Host/ID/PW. http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/host-add.html vCenter: Go to vsphere client, Host/ID/PW. https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.solutions.doc%2FGUID-A367585C-EB0E-4CEB-B147-817C1E5E8D1D.html Openstack, - Manual - setup mysql connection config, rabbitmq/qpid connection config, keystone config,, neturon config, http://docs.openstack.org/havana/install-guide/install/apt/content/nova-compute.html We have some deployment system including chef / puppet / packstack, TripleO - Chef/Puppet Setup chef node Add node/ apply role - Packstack - Generate answer file https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/sect-Running_PackStack_Non-interactively.html - packstack --install-hosts=192.168.1.0,192.168.1.1,192.168.1.2 - TripleO - UnderCloud nova baremetal node add - OverCloud modify heat template For residence in this mailing list, Chef/Puppet or third party tool is easy to use. However, I believe they are magical tools to use for many operators. Furthermore, these development system tend to take time to support newest release. so most of users, OpenStack release didn't means it can be usable for them. IMO, current way to manage configuration is the cause of this issue. If we manage everything via API, we can manage cluster by horizon. Then user can do go to horizon, just add host. It may take time to migrate config to API, so one easy step is to convert existing config for API resources. This is the purpose of this proposal. Hi Nachi. What you've described is the vision for TripleO and Tuskar. We do not lag the release. We run CD and will be in the gate real soon now so that TripleO should be able to fully deploy Icehouse on Icehouse release day. yeah, I'm big fan of TripleO and Tuskar. However, may be, it is difficult to let TripleO/Tuskar up-to-dated with newest releases. so let's say Nova and neutron added new function in 3rd release (I3 for icehouse), there is no way to support it in TripleO/Tuskar. This is natural, because TripleO/Tuskar is 3rd party tool for nova or neutron. (same as Chef/Puppet). IMO, Tuskar API and existing projects(nova, neturon) should be integrated in design level. This is false. TripleO is the official OpenStack deployment program. It is not a 3rd party tool. Of course sometimes TripleO may lag the same way Heat may lag other integrated release components. But that is one reason we have release meetings, blueprints, and summits, so that projects like Heat and TripleO can be aware of what is landing in i3 and at least attempt to have some support in place ASAP. This is a beauty we could have TripleO as official project. However, this is solution by management. We should have an architecture for supporting this resource management. Trying to make this happen inside the individual projects instead of in projects dedicated to working well in this space is a recipe for frustration, and I don't believe it would lead to any less lag. I believe existing situation is Resource management happen inside the individual projects instead of in projects dedicated to working well in this space. Neutron and nova has db table related with 'host'. (scheduler, agents) TripleO/Tushar has a resource management table ( I don't know detail of the project, so please correct me if I were wrong here) Nova-scheduler monitors compute nodes, neutron also monitors agents. It looks like TripleO/Tushar is planning to monitor nodes. People would just land features with FIXME: support config api. My original proposal won't change config api, so this won't happen. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neturon][CI] Embrane CI is attacking gerrit
Hi Russell Thanks. I got it 2014/1/13 Russell Bryant rbry...@redhat.com: 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, and we should stop it now. A good place to bring up issues like this is #openstack-infra on IRC. I brought it up there and Jeremy Stanley got it disabled quickly. Thanks, Jeremy! -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Less option (was: [oslo.config] Centralized config management)
+100 also :) 2014/1/10 Joe Gordon joe.gord...@gmail.com: On Fri, Jan 10, 2014 at 4:01 AM, Mark McLoughlin mar...@redhat.com wrote: On Thu, 2014-01-09 at 16:34 -0800, Joe Gordon wrote: On Thu, Jan 9, 2014 at 3:01 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, 2014-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, Nachi Ueno wrote: Hi Jeremy Don't you think it is burden for operators if we should choose correct combination of config for multiple nodes even if we have chef and puppet? It's more of a burden for operators to have to configure OpenStack in multiple ways. I also think projects should try to minimize configuration options at their minimum so operators are completely lost. Opening the sample nova.conf and seeing 696 options is not what I would call user friendly. There was talk a while back about marking different config options as basic and advanced (or something along those lines) to help make it easier for operators. You might be thinking of this session summit I led: https://etherpad.openstack.org/p/grizzly-nova-config-options My thinking was we first move config options into groups to make it easier for operators to make sense of the available options and then we would classify them (as e.g. tuning, experimental, debug) and exclude some classifications from the sample config file. Sadly, I never even made good progress on Tedious Task 2 :: Group. That is exactly what I was thinking of. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
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 central resource manager. (nova-api or neturon server etc). This is how to add new hosts, in cloudstack, vcenter, and openstack. Cloudstack: Go to web UI, add Host/ID/PW. http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/host-add.html vCenter: Go to vsphere client, Host/ID/PW. https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.solutions.doc%2FGUID-A367585C-EB0E-4CEB-B147-817C1E5E8D1D.html Openstack, - Manual - setup mysql connection config, rabbitmq/qpid connection config, keystone config,, neturon config, http://docs.openstack.org/havana/install-guide/install/apt/content/nova-compute.html We have some deployment system including chef / puppet / packstack, TripleO - Chef/Puppet Setup chef node Add node/ apply role - Packstack - Generate answer file https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/sect-Running_PackStack_Non-interactively.html - packstack --install-hosts=192.168.1.0,192.168.1.1,192.168.1.2 - TripleO - UnderCloud nova baremetal node add - OverCloud modify heat template For residence in this mailing list, Chef/Puppet or third party tool is easy to use. However, I believe they are magical tools to use for many operators. Furthermore, these development system tend to take time to support newest release. so most of users, OpenStack release didn't means it can be usable for them. IMO, current way to manage configuration is the cause of this issue. If we manage everything via API, we can manage cluster by horizon. Then user can do go to horizon, just add host. It may take time to migrate config to API, so one easy step is to convert existing config for API resources. This is the purpose of this proposal. Best Nachi 2014/1/10 Clint Byrum cl...@fewbar.com: 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 na...@ntti3.com wrote: Hi folks Thank you for your input. The key difference from external configuration system (Chef, puppet etc) is integration with openstack services. There are cases a process should know the config value in the other hosts. If we could have centralized config storage api, we can solve this issue. One example of such case is neuron + nova vif parameter configuration regarding to security group. The workflow is something like this. nova asks vif configuration information for neutron server. Neutron server ask configuration in neutron l2-agent on the same host of nova-compute. That extra round trip does sound like a potential performance bottleneck, but sharing the configuration data directly is not the right solution. If the configuration setting names are shared, they become part of the integration API between the two services. Nova should ask neutron how to connect the VIF, and it shouldn't care how neutron decides to answer that question. The configuration setting is an implementation detail of neutron that shouldn't be exposed directly to nova. That is where I think my resistance to such a change starts. If Nova and Neutron need to share a value, they should just do that via their API's. There is no need for a config server in the middle. If it is networking related, it lives in Neutron's configs, and if it is compute related, Nova's configs. Is there any example where values need to be in sync but are not sharable via normal API chatter? Running a configuration service also introduces what could be a single point of failure for all of the other distributed services in OpenStack. An out-of-band tool like chef or puppet doesn't result in the same sort of situation, because the tool does not have to be online in order for the cloud to be online. Configuration shouldn't ever have a rapid pattern of change, so even if this service existed I'd suggest that it would be used just like current config management solutions: scrape values out, write to config files. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][qa] The 'spec' parameter of mock.patch()
+1 but fixing this looks like take not small time 2014/1/10 Maru Newby ma...@redhat.com: 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() without any of the spec/spec_set/autospec parameters being set. Might it make sense to require that calls to mock.patch() set autospec=True [2]? m. 1: https://review.openstack.org/#/c/61105/7/neutron/tests/unit/openvswitch/test_ovs_lib.py (line 162) 2: http://www.voidspace.org.uk/python/mock/patch.html#mock.patch ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
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 fla...@redhat.com: On 08/01/14 17:13 -0800, Nachi Ueno wrote: 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 example, nova depends on neutron configuration etc My idea is to have config server in oslo.config, and let cfg.CONF get config from the server. This way has several benefits. - We can get centralized management without modification on each projects ( nova, neutron, etc) - We can provide horizon for configuration This is bp for this proposal. https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized I'm very appreciate any comments on this. I've thought about this as well. I like the overall idea of having a config server. However, I don't like the idea of having it within oslo.config. I'd prefer oslo.config to remain a library. Also, I think it would be more complex than just having a server that provides the configs. It'll need authentication like all other services in OpenStack and perhaps even support of encryption. I like the idea of a config registry but as mentioned above, IMHO it's to live under its own project. That's all I've got for now, FF -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
Hi folks Thank you for your input. The key difference from external configuration system (Chef, puppet etc) is integration with openstack services. There are cases a process should know the config value in the other hosts. If we could have centralized config storage api, we can solve this issue. One example of such case is neuron + nova vif parameter configuration regarding to security group. The workflow is something like this. nova asks vif configuration information for neutron server. Neutron server ask configuration in neutron l2-agent on the same host of nova-compute. host1 neutron server nova-api host2 neturon l2-agent nova-compute In this case, a process should know the config value in the other hosts. Replying some questions Adding a config server would dramatically change the way that configuration management tools would interface with OpenStack services. [Jay] Since this bp is just adding new mode, we can still use existing config files. why not help to make Chef or Puppet better and cover the more OpenStack use-cases rather than add yet another competing system [Doug, Morgan] I believe this system is not competing system. The key point is we should have some standard api to access such services. As Oleg suggested, we can use sql-server, kv-store, or chef or puppet as a backend system. Best Nachi 2014/1/9 Morgan Fainberg m...@metacloud.com: I agree with Doug’s question, but also would extend the train of thought to ask why not help to make Chef or Puppet better and cover the more OpenStack use-cases rather than add yet another competing system? Cheers, Morgan On January 9, 2014 at 10:24:06, Doug Hellmann (doug.hellm...@dreamhost.com) wrote: What capabilities 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 na...@ntti3.com wrote: 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 fla...@redhat.com: On 08/01/14 17:13 -0800, Nachi Ueno wrote: 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 example, nova depends on neutron configuration etc My idea is to have config server in oslo.config, and let cfg.CONF get config from the server. This way has several benefits. - We can get centralized management without modification on each projects ( nova, neutron, etc) - We can provide horizon for configuration This is bp for this proposal. https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized I'm very appreciate any comments on this. I've thought about this as well. I like the overall idea of having a config server. However, I don't like the idea of having it within oslo.config. I'd prefer oslo.config to remain a library. Also, I think it would be more complex than just having a server that provides the configs. It'll need authentication like all other services in OpenStack and perhaps even support of encryption. I like the idea of a config registry but as mentioned above, IMHO it's to live under its own project. That's all I've got for now, FF -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
Hi Jeremy
Don't you think it is burden for operators if we should choose correct
combination of config for multiple nodes even if we have chef and
puppet?
If we have some constraint or dependency in configurations, such logic
should be in openstack source code.
We can solve this issue if we have a standard way to know the config
value of other process in the other host.
Something like this.
self.conf.host('host1').firewall_driver
Then we can have a chef/or file baed config backend code for this for example.
Best
Nachi
2014/1/9 Jeremy Hanmer jer...@dreamhost.com:
+1 to Jay. Existing tools are both better suited to the job and work
quite well in their current state. To address Nachi's first example,
there's nothing preventing a Nova node in Chef from reading Neutron's
configuration (either by using a (partial) search or storing the
necessary 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 jaypi...@gmail.com wrote:
On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:
On 08/01/14 17:13 -0800, Nachi Ueno wrote:
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 example, nova depends on neutron configuration etc
My idea is to have config server in oslo.config, and let cfg.CONF get
config from the server.
This way has several benefits.
- We can get centralized management without modification on each
projects ( nova, neutron, etc)
- We can provide horizon for configuration
This is bp for this proposal.
https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized
I'm very appreciate any comments on this.
I've thought about this as well. I like the overall idea of having a
config server. However, I don't like the idea of having it within
oslo.config. I'd prefer oslo.config to remain a library.
Also, I think it would be more complex than just having a server that
provides the configs. It'll need authentication like all other
services in OpenStack and perhaps even support of encryption.
I like the idea of a config registry but as mentioned above, IMHO it's
to live under its own project.
Hi Nati and Flavio!
So, I'm -1 on this idea, just because I think it belongs in the realm of
configuration management tooling (Chef/Puppet/Salt/Ansible/etc). Those
tools are built to manage multiple configuration files and changes in
them. Adding a config server would dramatically change the way that
configuration management tools would interface with OpenStack services.
Instead of managing the config file templates as all of the tools
currently do, the tools would need to essentially need to forego the
tried-and-true INI files and instead write a bunch of code in order to
deal with REST API set/get operations for changing configuration data.
In summary, while I agree that OpenStack services have an absolute TON
of configurability -- for good and bad -- there are ways to improve the
usability of configuration without changing the paradigm that most
configuration management tools expect. One such example is having
include.d/ support -- similar to the existing oslo.cfg module's support
for a --config-dir, but more flexible and more like what other open
source programs (like Apache) have done for years.
All the best,
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
Hi Doug
2014/1/9 Doug Hellmann doug.hellm...@dreamhost.com:
On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno na...@ntti3.com wrote:
Hi folks
Thank you for your input.
The key difference from external configuration system (Chef, puppet
etc) is integration with
openstack services.
There are cases a process should know the config value in the other hosts.
If we could have centralized config storage api, we can solve this issue.
One example of such case is neuron + nova vif parameter configuration
regarding to security group.
The workflow is something like this.
nova asks vif configuration information for neutron server.
Neutron server ask configuration in neutron l2-agent on the same host
of nova-compute.
That extra round trip does sound like a potential performance bottleneck,
but sharing the configuration data directly is not the right solution. If
the configuration setting names are shared, they become part of the
integration API between the two services. Nova should ask neutron how to
connect the VIF, and it shouldn't care how neutron decides to answer that
question. The configuration setting is an implementation detail of neutron
that shouldn't be exposed directly to nova.
I agree for nova - neutron if.
However, neutron server and neutron l2 agent configuration depends on
each other.
Running a configuration service also introduces what could be a single point
of failure for all of the other distributed services in OpenStack. An
out-of-band tool like chef or puppet doesn't result in the same sort of
situation, because the tool does not have to be online in order for the
cloud to be online.
We can choose same implementation. ( Copy information in local cache etc)
Thank you for your input, I could organize my thought.
My proposal can be split for the two bps.
[BP1] conf api for the other process
Provide standard way to know the config value in the other process in
same host or the other host.
- API Example:
conf.host('host1').firewall_driver
- Conf file baed implementaion:
config for each host will be placed in here.
/etc/project/conf.d/{hostname}/agent.conf
[BP2] Multiple backend for storing config files
Currently, we have only file based configration.
In this bp, we are extending support for config storage.
- KVS
- SQL
- Chef - Ohai
Best
Nachi
Doug
host1
neutron server
nova-api
host2
neturon l2-agent
nova-compute
In this case, a process should know the config value in the other hosts.
Replying some questions
Adding a config server would dramatically change the way that
configuration management tools would interface with OpenStack services.
[Jay]
Since this bp is just adding new mode, we can still use existing config
files.
why not help to make Chef or Puppet better and cover the more OpenStack
use-cases rather than add yet another competing system [Doug, Morgan]
I believe this system is not competing system.
The key point is we should have some standard api to access such services.
As Oleg suggested, we can use sql-server, kv-store, or chef or puppet
as a backend system.
Best
Nachi
2014/1/9 Morgan Fainberg m...@metacloud.com:
I agree with Doug’s question, but also would extend the train of thought
to
ask why not help to make Chef or Puppet better and cover the more
OpenStack
use-cases rather than add yet another competing system?
Cheers,
Morgan
On January 9, 2014 at 10:24:06, Doug Hellmann
(doug.hellm...@dreamhost.com)
wrote:
What capabilities 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 na...@ntti3.com wrote:
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 fla...@redhat.com:
On 08/01/14 17:13 -0800, Nachi Ueno wrote:
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 example, nova depends on neutron configuration etc
My idea is to have config server in oslo.config, and let cfg.CONF
get
config from the server.
This way has several benefits.
- We can get centralized management without modification on each
projects ( nova, neutron, etc)
- We can provide horizon for configuration
This is bp for this proposal.
https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized
I'm very appreciate any comments on this.
I've thought about this as well. I like the overall idea of having a
config server. However, I don't like
Re: [openstack-dev] [oslo.config] Centralized config management
Hi Doug
Thank you for your input.
2014/1/9 Doug Hellmann doug.hellm...@dreamhost.com:
On Thu, Jan 9, 2014 at 2:34 PM, Nachi Ueno na...@ntti3.com wrote:
Hi Doug
2014/1/9 Doug Hellmann doug.hellm...@dreamhost.com:
On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno na...@ntti3.com wrote:
Hi folks
Thank you for your input.
The key difference from external configuration system (Chef, puppet
etc) is integration with
openstack services.
There are cases a process should know the config value in the other
hosts.
If we could have centralized config storage api, we can solve this
issue.
One example of such case is neuron + nova vif parameter configuration
regarding to security group.
The workflow is something like this.
nova asks vif configuration information for neutron server.
Neutron server ask configuration in neutron l2-agent on the same host
of nova-compute.
That extra round trip does sound like a potential performance
bottleneck,
but sharing the configuration data directly is not the right solution.
If
the configuration setting names are shared, they become part of the
integration API between the two services. Nova should ask neutron how to
connect the VIF, and it shouldn't care how neutron decides to answer
that
question. The configuration setting is an implementation detail of
neutron
that shouldn't be exposed directly to nova.
I agree for nova - neutron if.
However, neutron server and neutron l2 agent configuration depends on
each other.
Running a configuration service also introduces what could be a single
point
of failure for all of the other distributed services in OpenStack. An
out-of-band tool like chef or puppet doesn't result in the same sort of
situation, because the tool does not have to be online in order for the
cloud to be online.
We can choose same implementation. ( Copy information in local cache etc)
Thank you for your input, I could organize my thought.
My proposal can be split for the two bps.
[BP1] conf api for the other process
Provide standard way to know the config value in the other process in
same host or the other host.
Please don't do this. It's just a bad idea to expose the configuration
settings between apps this way, because it couples the applications tightly
at a low level, instead of letting the applications have APIs for sharing
logical information at a high level. It's the difference between asking
what is the value of a specific configuration setting on a particular
hypervisor and asking how do I connect a VIF for this instance. The
latter lets you provide different answers based on context. The former
doesn't.
Essentially, A configuration is a API.
I don't think every configuration is a kind of low level
configuration (timeout etc).
Some configuration should tell how do I connect a VIF for this instance,
and we should select high level design configuration parameters.
Doug
- API Example:
conf.host('host1').firewall_driver
- Conf file baed implementaion:
config for each host will be placed in here.
/etc/project/conf.d/{hostname}/agent.conf
[BP2] Multiple backend for storing config files
Currently, we have only file based configration.
In this bp, we are extending support for config storage.
- KVS
- SQL
- Chef - Ohai
Best
Nachi
Doug
host1
neutron server
nova-api
host2
neturon l2-agent
nova-compute
In this case, a process should know the config value in the other
hosts.
Replying some questions
Adding a config server would dramatically change the way that
configuration management tools would interface with OpenStack services.
[Jay]
Since this bp is just adding new mode, we can still use existing
config
files.
why not help to make Chef or Puppet better and cover the more
OpenStack
use-cases rather than add yet another competing system [Doug, Morgan]
I believe this system is not competing system.
The key point is we should have some standard api to access such
services.
As Oleg suggested, we can use sql-server, kv-store, or chef or puppet
as a backend system.
Best
Nachi
2014/1/9 Morgan Fainberg m...@metacloud.com:
I agree with Doug’s question, but also would extend the train of
thought
to
ask why not help to make Chef or Puppet better and cover the more
OpenStack
use-cases rather than add yet another competing system?
Cheers,
Morgan
On January 9, 2014 at 10:24:06, Doug Hellmann
(doug.hellm...@dreamhost.com)
wrote:
What capabilities 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 na...@ntti3.com wrote:
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
Re: [openstack-dev] [oslo.config] Centralized config management
2014/1/9 Jeremy Hanmer jer...@dreamhost.com:
Having run openstack clusters for ~2 years, I can't say that I've ever
desired such functionality.
My proposal is adding functionalities, not removing it.
so if you are satisfied with file based configuration with chef or puppet,
this change won't affect you
How do you see these interactions defined? For instance, if I deploy
a custom driver for Neutron, does that mean I also have to patch
everything that will be talking to it (Nova, for instance) so they can
agree on compatibility?
Nova / Neutron talks with neturon api. so it should be OK because we
are talking care
backward compatibility in the REST API.
The point in my example is neutron server + neutron l2 agent sync.
Also, I know that I run what is probably a more complicated cluster
than most production clusters, but I can't think of very many
configuration options that are globally in sync across the cluster.
Hypervisors, network drivers, mysql servers, API endpoints...they all
might vary between hosts/racks/etc.
To support such heterogeneous environment is a purpose of this bp.
Configuration dependency is pain 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.. debug..
On Thu, Jan 9, 2014 at 11:08 AM, Nachi Ueno na...@ntti3.com wrote:
Hi Jeremy
Don't you think it is burden for operators if we should choose correct
combination of config for multiple nodes even if we have chef and
puppet?
If we have some constraint or dependency in configurations, such logic
should be in openstack source code.
We can solve this issue if we have a standard way to know the config
value of other process in the other host.
Something like this.
self.conf.host('host1').firewall_driver
Then we can have a chef/or file baed config backend code for this for
example.
Best
Nachi
2014/1/9 Jeremy Hanmer jer...@dreamhost.com:
+1 to Jay. Existing tools are both better suited to the job and work
quite well in their current state. To address Nachi's first example,
there's nothing preventing a Nova node in Chef from reading Neutron's
configuration (either by using a (partial) search or storing the
necessary 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 jaypi...@gmail.com wrote:
On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:
On 08/01/14 17:13 -0800, Nachi Ueno wrote:
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 example, nova depends on neutron configuration etc
My idea is to have config server in oslo.config, and let cfg.CONF get
config from the server.
This way has several benefits.
- We can get centralized management without modification on each
projects ( nova, neutron, etc)
- We can provide horizon for configuration
This is bp for this proposal.
https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized
I'm very appreciate any comments on this.
I've thought about this as well. I like the overall idea of having a
config server. However, I don't like the idea of having it within
oslo.config. I'd prefer oslo.config to remain a library.
Also, I think it would be more complex than just having a server that
provides the configs. It'll need authentication like all other
services in OpenStack and perhaps even support of encryption.
I like the idea of a config registry but as mentioned above, IMHO it's
to live under its own project.
Hi Nati and Flavio!
So, I'm -1 on this idea, just because I think it belongs in the realm of
configuration management tooling (Chef/Puppet/Salt/Ansible/etc). Those
tools are built to manage multiple configuration files and changes in
them. Adding a config server would dramatically change the way that
configuration management tools would interface with OpenStack services.
Instead of managing the config file templates as all of the tools
currently do, the tools would need to essentially need to forego the
tried-and-true INI files and instead write a bunch of code in order to
deal with REST API set/get operations for changing configuration data.
In summary, while I agree that OpenStack services have an absolute TON
of configurability -- for good and bad -- there are ways to improve the
usability of configuration without changing the paradigm that most
configuration management tools expect. One such example is having
include.d/ support -- similar to the existing
Re: [openstack-dev] [oslo.config] Centralized config management
Hi Bob
2014/1/9 Robert Kukura rkuk...@redhat.com:
On 01/09/2014 02:34 PM, Nachi Ueno wrote:
Hi Doug
2014/1/9 Doug Hellmann doug.hellm...@dreamhost.com:
On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno na...@ntti3.com wrote:
Hi folks
Thank you for your input.
The key difference from external configuration system (Chef, puppet
etc) is integration with
openstack services.
There are cases a process should know the config value in the other hosts.
If we could have centralized config storage api, we can solve this issue.
One example of such case is neuron + nova vif parameter configuration
regarding to security group.
The workflow is something like this.
nova asks vif configuration information for neutron server.
Neutron server ask configuration in neutron l2-agent on the same host
of nova-compute.
That extra round trip does sound like a potential performance bottleneck,
but sharing the configuration data directly is not the right solution. If
the configuration setting names are shared, they become part of the
integration API between the two services. Nova should ask neutron how to
connect the VIF, and it shouldn't care how neutron decides to answer that
question. The configuration setting is an implementation detail of neutron
that shouldn't be exposed directly to nova.
I agree for nova - neutron if.
However, neutron server and neutron l2 agent configuration depends on
each other.
Running a configuration service also introduces what could be a single point
of failure for all of the other distributed services in OpenStack. An
out-of-band tool like chef or puppet doesn't result in the same sort of
situation, because the tool does not have to be online in order for the
cloud to be online.
We can choose same implementation. ( Copy information in local cache etc)
Thank you for your input, I could organize my thought.
My proposal can be split for the two bps.
[BP1] conf api for the other process
Provide standard way to know the config value in the other process in
same host or the other host.
- API Example:
conf.host('host1').firewall_driver
- Conf file baed implementaion:
config for each host will be placed in here.
/etc/project/conf.d/{hostname}/agent.conf
[BP2] Multiple backend for storing config files
Currently, we have only file based configration.
In this bp, we are extending support for config storage.
- KVS
- SQL
- Chef - Ohai
I'm not opposed to making oslo.config support pluggable back ends, but I
don't think BP2 could be depended upon to satisfy a requirement for a
global view of arbitrary config information, since this wouldn't be
available if a file-based backend were selected.
We can do it even if it's a file-based backend.
Chef or puppet will copy some configuration on the sever side and agent side.
The server read agent configuration stored in the server.
As far as the neutron server getting info it needs about running L2
agents, this is currently done via the agents_db RPC, where each agent
periodically sends certain info to the server and the server stores it
in the DB for subsequent use. The same mechanism is also used for L3 and
DHCP agents, and probably for *aaS agents. Some agent config information
is included, as well as some stats, etc.. This mechanism does the job,
but could be generalized and improved a bit. But I think this flow of
information is really for specialized purposes - only a small subset of
the config info is passed, and other info is passed that doesn't come
from config.
I agree on here.
We need a generic framework to do..
- static config with server and agent
- dynamic resource information and update
- stats or liveness updates
Today, we are re-inventing these frameworks in the different processes.
My only real concern with using this current mechanism is that some of
the information (stats and liveness) is very dynamic, while other
information (config) is relatively static. Its a bit wasteful to send
all of it every couple seconds, but at least liveness (heartbeat) info
does need to be sent frequently. BP1 sounds like it could address the
static part, but I'm still not sure config file info is the only
relatively static info that might need to be shared. I think neutron can
stick with its agents_db RPC, DB, and API extension for now, and improve
it as needed.
I got it.
It looks like the community tend to don't like this idea, so it's not
good timing
to do this in generic way.
Let's work on this in neutron for now.
Doug, Jeremy , Jay, Greg
Thank you for your inputs! I'll obsolete this bp.
Nachi
-Bob
Best
Nachi
Doug
host1
neutron server
nova-api
host2
neturon l2-agent
nova-compute
In this case, a process should know the config value in the other hosts.
Replying some questions
Adding a config server would dramatically change the way that
configuration management tools would interface with OpenStack services.
[Jay]
Since this bp is just adding
Re: [openstack-dev] [oslo.config] Centralized config management
Hi Jay
2014/1/9 Jay Pipes jaypi...@gmail.com:
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 correct
combination of config for multiple nodes even if we have chef and
puppet?
It's more of a burden for operators to have to configure OpenStack in
multiple ways.
This is independent discussion with pain of dependent configuration in
multiple node.
If we have some constraint or dependency in configurations, such logic
should be in openstack source code.
Could you explain this a bit more? I generally view packages and things
like requirements.txt and setup.py [extra] sections as the canonical way
of resolving dependencies. An example here would be great.
It's package dependencies. I'm talking about configuration
dependencies or constraint.
For example, if we wanna use VLAN with neutron,
we should do proper configuration in neutron server and nova-compute
and l2-agent.
We get input such as this is a burden for operation.
Then neutron team start working on port binding extension to reduce this burden.
This extension let nova ask neutron for vif configuration, then we can remove
any redundant network configuration in nova.conf.
We can solve this issue if we have a standard way to know the config
value of other process in the other host.
Something like this.
self.conf.host('host1').firewall_driver
This is already in every configuration management system I can think of.
Yes. I agree. But we can't assess it from inside of the openstack code.
In Chef, a cookbook can call out to search (or partial search) for the
node in question and retrieve such information (called attributes in
Chef-world).
In Puppet, one would use Hiera to look up another node's configuration.
In Ansible, one would use a Dynamic Inventory.
In Salt, you'd use Salt Mine.
Then we can have a chef/or file baed config backend code for this for
example.
I actually think you're thinking about this in the reverse way to the
way operators think about things. Operators want all configuration data
managed by a singular system -- their configuration management system.
Adding a different configuration data manager into the mix is the
opposite of what most operators would like, at least, that's just in my
experience.
My point is let openstack access the single configuration management system.
Also, I wanna reduce redundant configuration in between multiple
nodes, and hopefully,
we could have some generic framework to do this.
Nachi
All the best,
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.config] Centralized config management
Hi Oleg
2014/1/9 Oleg Gelbukh ogelb...@mirantis.com:
On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno na...@ntti3.com wrote:
2014/1/9 Jeremy Hanmer jer...@dreamhost.com:
How do you see these interactions defined? For instance, if I deploy
a custom driver for Neutron, does that mean I also have to patch
everything that will be talking to it (Nova, for instance) so they can
agree on compatibility?
Nova / Neutron talks with neturon api. so it should be OK because we
are talking care
backward compatibility in the REST API.
The point in my example is neutron server + neutron l2 agent sync.
What about doing it the other way round, i.e. allow one server to query
certain configuration parameter(s) from the other via RPC? I believe I've
seen such proposal quite some time ago in Nova blueprints, but with no
actual implementation.
I agree. This is a my current choice.
--
Best regards,
Oleg Gelbukh
Also, I know that I run what is probably a more complicated cluster
than most production clusters, but I can't think of very many
configuration options that are globally in sync across the cluster.
Hypervisors, network drivers, mysql servers, API endpoints...they all
might vary between hosts/racks/etc.
To support such heterogeneous environment is a purpose of this bp.
Configuration dependency is pain 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.. debug..
On Thu, Jan 9, 2014 at 11:08 AM, Nachi Ueno na...@ntti3.com wrote:
Hi Jeremy
Don't you think it is burden for operators if we should choose correct
combination of config for multiple nodes even if we have chef and
puppet?
If we have some constraint or dependency in configurations, such logic
should be in openstack source code.
We can solve this issue if we have a standard way to know the config
value of other process in the other host.
Something like this.
self.conf.host('host1').firewall_driver
Then we can have a chef/or file baed config backend code for this for
example.
Best
Nachi
2014/1/9 Jeremy Hanmer jer...@dreamhost.com:
+1 to Jay. Existing tools are both better suited to the job and work
quite well in their current state. To address Nachi's first example,
there's nothing preventing a Nova node in Chef from reading Neutron's
configuration (either by using a (partial) search or storing the
necessary 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 jaypi...@gmail.com wrote:
On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:
On 08/01/14 17:13 -0800, Nachi Ueno wrote:
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 example, nova depends on neutron configuration etc
My idea is to have config server in oslo.config, and let cfg.CONF
get
config from the server.
This way has several benefits.
- We can get centralized management without modification on each
projects ( nova, neutron, etc)
- We can provide horizon for configuration
This is bp for this proposal.
https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized
I'm very appreciate any comments on this.
I've thought about this as well. I like the overall idea of having a
config server. However, I don't like the idea of having it within
oslo.config. I'd prefer oslo.config to remain a library.
Also, I think it would be more complex than just having a server
that
provides the configs. It'll need authentication like all other
services in OpenStack and perhaps even support of encryption.
I like the idea of a config registry but as mentioned above, IMHO
it's
to live under its own project.
Hi Nati and Flavio!
So, I'm -1 on this idea, just because I think it belongs in the realm
of
configuration management tooling (Chef/Puppet/Salt/Ansible/etc).
Those
tools are built to manage multiple configuration files and changes in
them. Adding a config server would dramatically change the way that
configuration management tools would interface with OpenStack
services.
Instead of managing the config file templates as all of the tools
currently do, the tools would need to essentially need to forego the
tried-and-true INI files and instead write a bunch of code in order
to
deal with REST API set/get operations for changing configuration
data.
In summary, while I
Re: [openstack-dev] [oslo.config] Centralized config management
2014/1/9 Doug Hellmann doug.hellm...@dreamhost.com:
On Thu, Jan 9, 2014 at 3:56 PM, Nachi Ueno na...@ntti3.com wrote:
Hi Oleg
2014/1/9 Oleg Gelbukh ogelb...@mirantis.com:
On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno na...@ntti3.com wrote:
2014/1/9 Jeremy Hanmer jer...@dreamhost.com:
How do you see these interactions defined? For instance, if I deploy
a custom driver for Neutron, does that mean I also have to patch
everything that will be talking to it (Nova, for instance) so they
can
agree on compatibility?
Nova / Neutron talks with neturon api. so it should be OK because we
are talking care
backward compatibility in the REST API.
The point in my example is neutron server + neutron l2 agent sync.
What about doing it the other way round, i.e. allow one server to query
certain configuration parameter(s) from the other via RPC? I believe
I've
seen such proposal quite some time ago in Nova blueprints, but with no
actual implementation.
I agree. This is a my current choice.
But my point is that you shouldn't be thinking about this as querying
configuration settings. The fact that a piece of information one service
needs is stored in the configuration file of another service is an
implementation detail. It might move. The name of the option could change.
The way the value is determined might change.
I agree, but may be definition of configuration is different with you.
For me, API and Configurations are all reflection from internal Models.
They are just some ways to configure these models.
If configuration is always some lower implementation parameter for you,
I would say it as Model.
So don't tie yourself to the configuration setting location and name of
another service. Ask the service the question you have, and let it provide
an answer. Make it a specific RPC call, so the input parameters can be
versioned and the response type can be versioned.
+1 for versioning,
However adding more and more rpc call get system management hard, and
let system unstable.
It make processes tightly coupled, and it make hard to debug.
We should have single storage of logical models. (nova-api for
compute, and neutron server for networking for example). Then all
service should work to realize logical models.
Nachi
Doug
--
Best regards,
Oleg Gelbukh
Also, I know that I run what is probably a more complicated cluster
than most production clusters, but I can't think of very many
configuration options that are globally in sync across the cluster.
Hypervisors, network drivers, mysql servers, API endpoints...they all
might vary between hosts/racks/etc.
To support such heterogeneous environment is a purpose of this bp.
Configuration dependency is pain 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.. debug..
On Thu, Jan 9, 2014 at 11:08 AM, Nachi Ueno na...@ntti3.com wrote:
Hi Jeremy
Don't you think it is burden for operators if we should choose
correct
combination of config for multiple nodes even if we have chef and
puppet?
If we have some constraint or dependency in configurations, such
logic
should be in openstack source code.
We can solve this issue if we have a standard way to know the config
value of other process in the other host.
Something like this.
self.conf.host('host1').firewall_driver
Then we can have a chef/or file baed config backend code for this
for
example.
Best
Nachi
2014/1/9 Jeremy Hanmer jer...@dreamhost.com:
+1 to Jay. Existing tools are both better suited to the job and
work
quite well in their current state. To address Nachi's first
example,
there's nothing preventing a Nova node in Chef from reading
Neutron's
configuration (either by using a (partial) search or storing the
necessary 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 jaypi...@gmail.com
wrote:
On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:
On 08/01/14 17:13 -0800, Nachi Ueno wrote:
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 example, nova depends on neutron configuration etc
My idea is to have config server in oslo.config, and let
cfg.CONF
get
config from the server.
This way has several benefits
[openstack-dev] [oslo.config] Centralized config management
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 example, nova depends on neutron configuration etc My idea is to have config server in oslo.config, and let cfg.CONF get config from the server. This way has several benefits. - We can get centralized management without modification on each projects ( nova, neutron, etc) - We can provide horizon for configuration This is bp for this proposal. https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized I'm very appreciate any comments on this. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada
Hi Anita Let's me join this session also. Nachi Ueno NTT i3 2014/1/5 Anita Kuno ante...@anteaya.info: 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 relatively new to OpenStack community with a strong desire to learn and contribute. Having a strong desire to participate effectively is great. The difficulty for us is that we have already indicated that we need experienced participants at the code sprint. [0] Having long periods of silence and then simply announcing you have booked your flights makes things difficult since we have been in conversation with others about this for some time. I'm not saying don't come, I am saying that this now puts myself and Mark in a position of having to explain ourselves to others regarding consistency. Mark and I will address this, though I will need to discuss this with Mark to hear his thoughts and I am unable right now since I am at a conference all week. [1] Going forward, having regular conversations about items of this nature (irc is a great tool for this) is something I would like to see happen more often. You may have seen that Arista Testing has come alive and is voting on the newly submitted neutron patches. I have been busy putting together the framework, and learning the Jenkins/Gerrit interface. Yes. Can you respond on the Remove voting until your testing structure works thread please? This enables people who wish to respond to you on this point a place to conduct the conversation. It also preserves a history of the topic so that those searching the archives have all the relevant information in one place. Now, I have shifted my focus on Neutron/networking tempest tests. I notice some of these tests are failing on my setup. I have started to dig into these with the intent to understand them. That is a great place to begin. Thank you for taking interest and pursuing test bugs. In terms of this upcoming sprint, if you folks can give some pointers that will help me get better prepared and productive, that will be appreciated. We need folks attending the sprint who are familiar with offering patches to tempest. Seeing your name in this list would be a great indicator that you are at least able to offer a patch. [3] If you are able to focus this week on getting up to speed on Tempest and the Neutron Tempest process, then your attendance at the conference may possibly be effective both for yourself and for the rest of the participants. This wiki page is probably a good place to begin. [4] The etherpad tracking the Neutron Tempest team's progress is here. [5] Familiarizing yourself with the status of the conversation during the meetings will help as well, though it isn't as important in terms of being useful at the sprint as offering a tempest patch. Neutron meeting logs can be found here. [6] Also being available in channel will go a long way to fostering the kind of interactions which are constructive now and in the future. I don't see you in channel much, it would be great to see you more. Looking forward to meeting and working with you. And I you. Let's consider this an opportunity for greater participation with Neutron and having more conversations in irc is a great way to begin. Though I am not available in -neutron this week others are, so please announce when you are ready to work and hopefully someone will be keeping an eye out for you and offer you a hand. regards.. -Sukhdev Thanks Sukhdev, Anita. [0] http://lists.openstack.org/pipermail/openstack-dev/2013-December/022918.html [1] http://eavesdrop.openstack.org/meetings/networking/2013/networking.2013-12-16-21.02.log.html timestamp 21:57:46 [2] http://lists.openstack.org/pipermail/openstack-dev/2013-December/023228.html [3] https://review.openstack.org/#/q/status:open+project:openstack/tempest,n,z [4] https://wiki.openstack.org/wiki/Neutron/TempestAPITests [5] https://etherpad.openstack.org/p/icehouse-summit-qa-neutron [6] http://eavesdrop.openstack.org/meetings/networking/2013/ On Fri, Dec 27, 2013 at 9:00 AM, Anita Kuno ante...@anteaya.info wrote: On 12/18/2013 04:17 PM, Anita Kuno wrote: Okay time for a recap. What: Neutron Tempest code sprint Where: Montreal, QC, Canada When: January 15, 16, 17 2014 Location: I am about to sign the contract for Salle du Parc at 3625 Parc avenue, a room in a residence of McGill University. Time: 9am - 5am Time: 9am - 5pm I am expecting to see the following people in Montreal in January: Mark McClain Salvatore Orlando Sean Dague Matt Trenish Jay Pipes Sukhdev Kapur Miguel Lavelle Oleg Bondarev Rossella Sblendido Emilien Macchi Sylvain Afchain Nicolas Planel Kyle Mestery Dane Leblanc Sumit Naiksatam Henry Gessau Don Kehn Carl Baldwin Justin Hammond Anita Kuno If you are on the above list and can't attend, please email me so I have an up
Re: [openstack-dev] [QA][Neutron] About paramiko's SSHException: Error reading SSH protocol banner
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 sorla...@nicira.com: Yair, The 'isolated' mode makes the tempest session more realistic by simulating a cloud with multiple networks and ports. For Neutron tests this means creating a new set of network resources for each test class. If creating distinct network resources for each tenant is the root cause of this problem, there is probably some underlying issue in neutron that needs to be addressed. I think there is a requirement to be able to run the test suite with 'full tenant isolation' and 'parallel' execution. On the other hand Toshihiro noted that SSH gets connected, and before starting with the protocol banner errors, it even says that it tries to authenticate, and the authentication fails. I don't know what to think here. I only have two hints: 1 - The SSH connection attempt starts before the VM and the floating IPs are wired by the agent. Paramiko has to wait more than a minute for a response to come from the server. Could this cause the library to fail? Can we try to ping and then SSH once the ping succeeds as test_network_basic_ops does? 2 - Is there a chance that key management might be flaky when running parallel tests? I don't think so because otherwise we should see failures even with nova-network, and that does not happen. Salvatore On 27 December 2013 08:14, IWAMOTO Toshihiro iwam...@valinux.co.jp wrote: At Fri, 27 Dec 2013 01:53:59 +0100, Salvatore Orlando wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; ISO-8859-1 (7bit)] I put together all the patches which we prepared for making parallel testing work, and ran a few times 'check experimental' on the gate to see whether it worked or not. With parallel testing, the only really troubling issue are the scenario tests which require to access a VM from a floating IP, and the new patches we've squashed together in [1] should address this issue. However, the result is that timeouts are still observed but with a different message [2]. I'm not really familiar with it, and I've never observed it in local testing. I wonder if it just happens to be the usual problem about the target host not being reachable, or if it is something specific to paramiko. Any hint would be appreciated, since from the logs is appears everything is wired properly. It seems that a TCP connection has been established but paramiko failed get data from the server in time. Does increasing paramiko timeout help? [1] https://review.openstack.org/#/c/57420/ [2] http://logs.openstack.org/20/57420/40/experimental/check-tempest-dsvm-neutron-isolated-parallel/a74bdc8/console.html#_2013-12-26_22_51_31_817 [1.2 text/html; ISO-8859-1 (quoted-printable)] [2 text/plain; us-ascii (7bit)] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron Distributed Virtual Router
I'm +1 for 'provider'. 2013/12/9 Akihiro Motoki mot...@da.jp.nec.com: 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, we assumes at least two types edge and distributed. Though edge and distributed is a type of implementations, I think they are some kind of provider. I just would like to add an option. I am open to provider vs distirbute attributes. Thanks, Akihiro (2013/12/10 7:01), Vasudevan, Swaminathan (PNB Roseville) wrote: Hi Folks, We are in the process of defining the API for the Neutron Distributed Virtual Router, and we have a question. Just wanted to get the feedback from the community before we implement and post for review. We are planning to use the “distributed” flag for the routers that are supposed to be routing traffic locally (both East West and North South). This “distributed” flag is already there in the “neutronclient” API, but currently only utilized by the “Nicira Plugin”. We would like to go ahead and use the same “distributed” flag and add an extension to the router table to accommodate the “distributed flag”. Please let us know your feedback. Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.com mailto:swaminathan.vasude...@hp.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting
+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 i...@embrane.com: +1 for 1700UTC Thursday on IRC -Original Message- From: Kyle Mestery [mailto:mest...@siliconloons.com] Sent: Tuesday, December 10, 2013 9:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting On Dec 10, 2013, at 10:45 AM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: -Original Message- From: Kyle Mestery mest...@siliconloons.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, December 10, 2013 10:48 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] Third party Neutron plugin testing meeting Last week I took an action item to organize a meeting for everyone who is doing third-party testing in Neutron for plugins, whether this is vendor or Open Source based. The idea is to share ideas around setups and any issues people hit. I'd like to set this meeting up for this week, Thursday at 1700UTC. I would also like to propose we make this a dial in meeting using the Infrastructure Conferencing bridges [1]. If this time works, I'll set something up and reply to this thread with the dial in information. +1 for the meeting time. Any particular reason for voice over IRC? We kind of decided that doing this over voice initially would be expedient, but I am fine with moving to IRC. If I don't hear objections, lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt. Also, I've started a etherpad page [2] with information. It would be good for people to add information to this etherpad as well. I've coupled this pad with information around multi-node gate testing for Neutron as well, as I suspect most of the third-party testing will require multiple nodes as well. I'll start filling out our setup. I have some questions around Third-Party Testing in particular, and look forward to this discussion. Awesome, thanks Anthony! Thanks! Kyle [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron Distributed Virtual Router
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 gong...@unitedstack.com: If distributed router is good enough, why do we still need non-distributed router? On Tue, Dec 10, 2013 at 9:04 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: I would imagine that, from the Neutron perspective, you get a single router whether or not it's distributed. I think that if a router is distributed - regardless of whether it's tenant-tenant or tenant-outside - it certainly *could* have some sort of SLA flag, but I don't think a simple 'distributed' flag is either here or there; it's not telling the tenant anything meaningful. On 10 December 2013 00:48, Mike Wilson geekinu...@gmail.com wrote: I guess the question that immediately comes to mind is, is there anyone that doesn't want a distributed router? I guess there could be someone out there that hates the idea of traffic flowing in a balanced fashion, but can't they just run a single router then? Does there really need to be some flag to disable/enable this behavior? Maybe I am oversimplifying things... you tell me. -Mike Wilson On Mon, Dec 9, 2013 at 3:01 PM, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Hi Folks, We are in the process of defining the API for the Neutron Distributed Virtual Router, and we have a question. Just wanted to get the feedback from the community before we implement and post for review. We are planning to use the “distributed” flag for the routers that are supposed to be routing traffic locally (both East West and North South). This “distributed” flag is already there in the “neutronclient” API, but currently only utilized by the “Nicira Plugin”. We would like to go ahead and use the same “distributed” flag and add an extension to the router table to accommodate the “distributed flag”. Please let us know your feedback. Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] only one subnet_id is allowed behind a router for vpnservice object
Thanks!
Commented on bp whiteboard.
2013/12/5 Yongsheng Gong gong...@unitedstack.com:
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 na...@ntti3.com wrote:
Hi Yong
Yes, to support multiple subnet is on the roadmap.
I'll definitely welcome your help :P
2013/12/5 Yongsheng Gong gong...@unitedstack.com:
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/master/neutron/extensions/vpnaas.py
RESOURCE_ATTRIBUTE_MAP = {
'vpnservices': {
'id': {'allow_post': False, 'allow_put': False,
'validate': {'type:uuid': None},
'is_visible': True,
'primary_key': True},
'tenant_id': {'allow_post': True, 'allow_put': False,
'validate': {'type:string': None},
'required_by_policy': True,
'is_visible': True},
'name': {'allow_post': True, 'allow_put': True,
'validate': {'type:string': None},
'is_visible': True, 'default': ''},
'description': {'allow_post': True, 'allow_put': True,
'validate': {'type:string': None},
'is_visible': True, 'default': ''},
'subnet_id': {'allow_post': True, 'allow_put': False,
'validate': {'type:uuid': None},
'is_visible': True},
'router_id': {'allow_post': True, 'allow_put': False,
'validate': {'type:uuid': None},
'is_visible': True},
'admin_state_up': {'allow_post': True, 'allow_put': True,
'default': True,
'convert_to': attr.convert_to_boolean,
'is_visible': True},
'status': {'allow_post': False, 'allow_put': False,
'is_visible': True}
},
with such limit, I don't think there is a way to allow other subnets
behind
the router be vpn exposed!
thoughts?
Thanks
Yong Sheng Gong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
Hi folks OK, It looks like we get consensus on separate resource way. Best Nachi 2013/12/5 Eugene Nikanorov enikano...@mirantis.com: 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 service_type extension. Thanks, Eugene. On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran stephen.g...@theguardian.com wrote: Hi, Right, sorry, I see that wasn't clear - I blame lack of coffee :) I would prefer the Revised New Model. I much prefer the ability to restore a loadbalancer from config in the event of node failure, and the ability to do basic sharing of certificates between VIPs. I think that a longer term plan may involve putting the certificates in a smarter system if we decide we want to do things like evaluate trust models, but just storing them locally for now will do most of what I think people want to do with SSL termination. Cheers, On 05/12/13 09:57, Samuel Bercovici wrote: Hi Stephen, To make sure I understand, which model is fine Basic/Simple or New. Thanks, -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Thursday, December 05, 2013 8:22 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Hi, I would be happy with this model. Yes, longer term it might be nice to have an independent certificate store so that when you need to be able to validate ssl you can, but this is a good intermediate step. Cheers, On 02/12/13 09:16, Vijay Venkatachalam wrote: LBaaS enthusiasts: Your vote on the revised model for SSL Termination? Here is a comparison between the original and revised model for SSL Termination: *** Original Basic Model that was proposed in summit *** * Certificate parameters introduced as part of VIP resource. * This model is for basic config and there will be a model introduced in future for detailed use case. * Each certificate is created for one and only one VIP. * Certificate params not stored in DB and sent directly to loadbalancer. * In case of failures, there is no way to restart the operation from details stored in DB. *** Revised New Model *** * Certificate parameters will be part of an independent certificate resource. A first-class citizen handled by LBaaS plugin. * It is a forwarding looking model and aligns with AWS for uploading server certificates. * A certificate can be reused in many VIPs. * Certificate params stored in DB. * In case of failures, parameters stored in DB will be used to restore the system. A more detailed comparison can be viewed in the following link https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVe ZISh07iGs/edit?usp=sharing -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Tool for detecting commonly misspelled words
Great tool especially for non-native guys such as me! Thanks Joe Best Nachi 2013/12/3 Sylvain Bauza sylvain.ba...@gmail.com: 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 joe.gord...@gmail.com 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 next time you want to fix a typo, instead of just fixing a single one you can go ahead and fix a whole bunch. https://github.com/lyda/misspell-check To install it: $ pip install misspellings To use it in your favorite openstack repo: $ git ls-files | grep -v locale | misspellings -f - Sample output: http://paste.openstack.org/show/54354 best, Joe ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Tool for detecting commonly misspelled words
2013/12/3 John Griffith john.griff...@solidfire.com: On Tue, Dec 3, 2013 at 11:38 AM, Russell Bryant rbry...@redhat.com 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 next time you want to fix a typo, instead of just fixing a single one you can go ahead and fix a whole bunch. https://github.com/lyda/misspell-check To install it: $ pip install misspellings To use it in your favorite openstack repo: $ git ls-files | grep -v locale | misspellings -f - Sample output: http://paste.openstack.org/show/54354 Are we going to start gating on spellcheck of code and commit messages? :-) NO please (please please please). We have enough grammar reviewers at this point already IMO and I honestly think I might puke if jenkins fails my patch because I didn't put a '.' at the end of my comment line in the code. I'd much rather see us focus on things like... I dunno... maybe having the code actually work? yeah, but may be non-voting reviews by this tool is helpful -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Tool for detecting commonly misspelled words
2013/12/3 John Griffith john.griff...@solidfire.com: On Tue, Dec 3, 2013 at 11:54 AM, Nachi Ueno na...@ntti3.com wrote: 2013/12/3 John Griffith john.griff...@solidfire.com: On Tue, Dec 3, 2013 at 11:38 AM, Russell Bryant rbry...@redhat.com 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 next time you want to fix a typo, instead of just fixing a single one you can go ahead and fix a whole bunch. https://github.com/lyda/misspell-check To install it: $ pip install misspellings To use it in your favorite openstack repo: $ git ls-files | grep -v locale | misspellings -f - Sample output: http://paste.openstack.org/show/54354 Are we going to start gating on spellcheck of code and commit messages? :-) NO please (please please please). We have enough grammar reviewers at this point already IMO and I honestly think I might puke if jenkins fails my patch because I didn't put a '.' at the end of my comment line in the code. I'd much rather see us focus on things like... I dunno... maybe having the code actually work? yeah, but may be non-voting reviews by this tool is helpful Fair enough... don't get me wrong I'm all for support of non-english contributors etc. I just think that the emphasis on grammar and punctuation in reviews has gotten a bit out of hand as of late. FWIW I've never -1'd a patch (and never would) because somebody used its rather than it's in a comment. Or they didn't end a comment (NOT a docstring) with a period. I think it's the wrong place to spend effort quite honestly. That being said, I realize people will continue to this sort of thing (it's very important to get your -1 counts in the review stats) and admittedly there is some value to spelling and grammar. I just feel that there are *real* issues and bugs that people could spend this time that would actually have some significant and real benefit. I'm obviously in the minority on this topic so I should probably just yield at this point and get on board the grammar train. May be, this is off topic. At first, I do agree the importance of such grammar error is not high. We should focus on real issues. However IMO, we should -1 for even such cases (using its) I just send patch for fixing misspells in neutron. https://review.openstack.org/#/c/59809/ There was 50 misspells. so it is may be small mistakes for one patch, but it will be growing.. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
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 between applications. so my current idea is to have a independent resource for certificates for each applications. Best Nachi 2013/12/2 Vijay Venkatachalam vijay.venkatacha...@citrix.com: LBaaS enthusiasts: Your vote on the revised model for SSL Termination? Here is a comparison between the original and revised model for SSL Termination: *** Original Basic Model that was proposed in summit *** * Certificate parameters introduced as part of VIP resource. * This model is for basic config and there will be a model introduced in future for detailed use case. * Each certificate is created for one and only one VIP. * Certificate params not stored in DB and sent directly to loadbalancer. * In case of failures, there is no way to restart the operation from details stored in DB. *** Revised New Model *** * Certificate parameters will be part of an independent certificate resource. A first-class citizen handled by LBaaS plugin. * It is a forwarding looking model and aligns with AWS for uploading server certificates. * A certificate can be reused in many VIPs. * Certificate params stored in DB. * In case of failures, parameters stored in DB will be used to restore the system. A more detailed comparison can be viewed in the following link https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVeZISh07iGs/edit?usp=sharing Thanks, Vijay V. -Original Message- From: Vijay Venkatachalam Sent: Friday, November 29, 2013 2:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first level citizen - SSL Termination To summarize: Certificate will be a first level citizen which can be reused and For certificate management nothing sophisticated is required. Can you please Vote (+1, -1)? We can move on if there is consensus around this. -Original Message- From: Stephen Gran [mailto:stephen.g...@guardian.co.uk] Sent: Wednesday, November 20, 2013 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n YTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self- signed, and is used for lots of VIPs. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e- mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___
[openstack-dev] [Neutron][Tempest] Heat template for services
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 neutron test. https://github.com/openstack/tempest/blob/master/tempest/api/orchestration/stacks/test_neutron_resources.py Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Tempest] Heat template for services
Hi Steve Thank you for your input. I agree with you. We added apache, mysql and wordpress for this review, because heat-template is a show-case for example template. I agree with you, we can start a process of simplehttpserver in meta data script for LBaaS test. Best Nachi 2013/11/26 Steve Baker sba...@redhat.com: 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://review.openstack.org/#/c/58496/1 It is great if we could get feedback from yours. This template is fine as an example template for heat-templates, but not for a tempest test. I think installing apache, mysql and wordpress is not appropriate when the aim is a functional test of LBaaS, FWaaS and VPN These should probably be 3 different scenario tests using heatclient, an separate yaml template, and written in this style: https://github.com/openstack/tempest/tree/stable/havana/tempest/scenario/orchestration For the LBaaS test, using SimpleHTTPServer[1] instead of apache would mean no packages would need to be installed (which would be slow, and risks transient errors). Each web server can return something unique, so the test can assert that the load balancer is balancing all servers. For FWaaS and VPN it would be handy if the templates required no nova servers, or servers that require only cirros, since then they can run in the standard gate jobs. FYI, here is existing heat neutron test. https://github.com/openstack/tempest/blob/master/tempest/api/orchestration/stacks/test_neutron_resources.py [1] http://docs.python.org/2/library/simplehttpserver.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] Blob in keystone v3 certificate API
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... Also we can't ensure the backward compatibilities with such free format API definitions. (1) IMO, we should not use free format attribute such as blob or arbitrary key,value pairs. (2) Should we use this API as a storage for certificate used in any openstack services? Since it is hard to provider validation on such API, I'm start thinking to have vpn certificate API in neutron. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VPNaaS questions...
Hi Paul I rebased the patch, and working on unit testing too https://review.openstack.org/#/c/41827/ 2013/10/23 Paul Michali p...@cisco.com: 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 amot...@gmail.com wrote: Hi Paul, On Wed, Oct 23, 2013 at 9:56 PM, Paul Michali p...@cisco.com wrote: Hi guys, Some questions on VPNaaS… Can we get the review reopened of the service type framework changes for VPN on the server side? I was thinking of trying to rebase that patch, based on the latest from master, but before doing so, I ran TOX on the latest master commit. TOX fails with a bunch of errors, some reporting that the system is out of memory. I have a 4GB Ubuntu 12.04 VM for this and I see it max out on memory, when TOX is run on the whole Neutron code for py27. Anyone seen this? I see this too. On 4GB Ubuntu 13.04 VM, I have over 1GB swap while running the whole test and the test slows down after swap begins…. PCM: Whew! I was worried that it was something in my setup. Any idea on a root cause/workaround? Is this happening when Jenkins runs? I have tried the current patch of service type framework, and found that client changes are needed too. I have changes ready for review, should I post them, or do we need to wait (or indicate some dependency on the server side changes)? My suggestion is to post a patch with WIP status. We can test the server side patch with CLI. It really helps us all. PCM: Thanks! I wasn't sure how to proceed as the client change is useless w/o the server change. Yeah, please push wip :) I see that there is VPN connection status and VPN service status. What is the purpose of the latter? What is the status, if the service has multiple connections in different states? I see the same. PCM: Yeah, need to understand what the desired meaning is for the service status in this context. In openswan impl, vpnservice state is the state of openswan process. ipsec-site-connection state is actual connection state. so let's say we have two site. Vpnservice will be ACTIVE and ipsec-site-connection's state will be DOWN after we setup only one site. Have you guys tried VPNaaS with Havana and the now default ML2 plugin? I got a failure on connection create, saying that it could not find get_l3_agents_hosting_routers() attribute. I haven't looked into this yet, but will try as soon as I can. I think https://bugs.launchpad.net/neutron/+bug/1238846 is same as what you encountered. I believe this bug was fixed in the final RC. Doesn't it work? PCM: Ah, I missed that bug review. I probably need to update my repo with the latest to pick this up. Thanks! Regards, PCM Thanks, Akihiro Thanks! PCM (Paul Michali) Contact info for Cisco users http://twiki.cisco.com/Main/pcm ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Disable async network allocation
Hi Phil 2013/10/21 Day, Phil philip@hp.com: 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 also rule out if there is some obscure eventlet threading issue in here). I thought it was configurable – but I don’t see anything obvious in the code to go back to the old (slower) approach of doing network allocation in-lien in the main create thread ? May I ask the meaning of async network allocation ? One of the issues I’m trying to track is Neutron occasionally creating more than one port – I suspect a retry mechanism in the httplib2 is sending the port create request multiple times if Neutron is slow to reply, resulting in Neutron processing it multiple times. Looks like only the Neutron client has chosen to use httplib2 rather that httplib – anyone got any insight here ? This is a quite interest findings. so If we use httplib, this won't happen? Sometimes of course the Neutron timeout results in the create request being re-scheduled onto another node (which can it turn generate its own set of port create requests).Its the thread behavior around how the timeout exception is handled that I’m slightly nervous of (some of the retries seem to occur after the original network thread should have terminated). I agree. The kind of unintentional retry causes issues. Thanks Phil Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron - an issue regarding what API to follow
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 amot...@gmail.com: Hi, The API document is the official one, and Wiki is used during the development. We may be better to add a note to the wiki page to avoid such confusion. I am not sure what confused you. Could you give me an example? Thanks, Akihiro 2013年10月21日月曜日 GROSZ, Maty (Maty) maty.gr...@alcatel-lucent.com: Hey *, I got a little confused with what API should we follow regarding Neutron VPN service… There is this wiki page https://wiki.openstack.org/wiki/Neutron/VPNaaS that handles VPN APIs, where as the formal Neutron API documentation, http://docs.openstack.org/api/openstack-network/2.0/content/vpnaas_ext_ops_service.html, describes different API version and URL structure. Generally, my decisions are always follow the formal API documentation. But in this case I am little confused… Can anyone help? What are the actual APIs? Thanks, Maty. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] VPNaaS questions
Hi Paul 2013/10/11 Paul Michali p...@cisco.com: 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? 2) When are you planning on reopening the review? I'm not sure it will work without rebase. I'll rebase, and test it again in next week. Anyone, I see that there is an agent.py file for VPN that has a main() and it starts up an L3 agent, specifying the VPNAgent class (in same file). 3) How does this file get invoked? IOW how does the main() get invoked? we should use neutron-vpn-agent command to run vpn-agent. This command invoke vpn agent class. It is defined setup.cnf https://github.com/openstack/neutron/blob/master/setup.cfg#L98 4) I take it we can specify multiple device drivers in the config file for the agent? Yes. Currently, for the reference device driver, the hierarchy is currently DeviceDriver [ABC] - IPsecDriver [Swan based logic] - OpenSwanDriver [one function, OpenSwan specific]. The ABC has a specific set of APIs. Wondering how to incorporate provider based device drivers. It is designed when we know only one swan based driver. so It won't fit with another device drivers. if so, You can also extend or modify DeviceDriver also. 5) Should I push up more general methods from IPsecDriver to DeviceDriver, so that they can be reused by other providers? That's woud be great 6) Should I push down the swan based methods from DeviceDriver to IPsecDriver and maybe name it SwanDeviceDriver? yes I see that vpnaas.py is an extension for VPN that defines attributes and the base plugin functions. 7) If a provider as additional attributes (can't think of any yet), how can the attribute be extended, only for that provider (or is that the wrong way to handle this)? You can extend existing extension. For VPN, there are several attributes, each with varying ranges of values allowed. This is reflected in the CLI help messages, the database (e.g. enums), and is validated (some) in the client code and in the VPN service. Chaining existing attributes may be challenging on client side. But let's discuss this with a concrete example. 8) How do we provide different limits/allowed values for attributes, for a specific provider (e.g. let's say the provider supports or doesn't support an encryption method, or doesn't support IKE v1 or v2)? Driver can throw unsupported exception. ( It is not defined yet) 9) Should the code be changed not to do any client validation, and to have generic help, so that different values could be provided, or is there a way to customize this based on provider? That's could be one way. 10) If customized, is it possible to reflect the difference in allowed values in the help strings (and client validation)? May be, server side can tell the client hey I'm supporting this set of values Then client can use it as the help string. # This change may need bp. 11) How do we handle the variation in the database (e.g. when enums specifying a fixed set of values)? Do we need to change the database to be more generic (strings and ints) or do we somehow extend the database? more than one driver will use same DB. so I'm +1 for generic db structure if it is really needed. I was wondering in general how providers can customize service features, based on their capabilities (better or worse than reference). I could create a Summit session topic on this, but wanted to know if this is something that has already been addressed or if a different architectural approach has already been defined. AFIK, That's new challenge. I think LB team and FW team is facing same issue. Best Nachi Regards, PCM (Paul Michali) MAIL p...@cisco.com IRC pcm_ (irc.freenode.net) TW @pmichali ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Extraroute and router extensions
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 nexton...@yahoo.com: Hi Rudra, Nachi. Glad to see this discussion on the mailing list! The ExtraRoute routes are fairly limited and it would be great to be able to store more complete routing information in Neutron. I've submitted a blueprint proposing expanding ExtraRoute parameters to include more information (extended-route-params). But it still has a problem where routes are stored in a list and are not indexed. So an update could be painful. Could you share what attributes would you like to see in your RIB API? Thanks! Artem P.S. I'm OpenStack newbie, looking forward to learning from and working with you! 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 need to keep backward compatibility. so, IMO, we should create Routing table extension. I'm thinking about this in the context of L3VPN (MPLS) extension. My Idea is to have a RIB API in the Neutron. For vpnv4 routes it may have RT or RDs. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] addCleanup vs. tearDown
+1 2013/10/8 Monty Taylor mord...@inaugust.com: Hey! Got a question on IRC which seemed fair game for a quick mailing list post: Q: I see both addCleanup and tearDown in nova's test suite - which one should I use for new code? A: addCleanup All new code should 100% of the time use addCleanup and not tearDown - this is because addCleanups are all guaranteed to run, even if one of them fails, whereas a failure inside of a tearDown can leave the rest of the tearDown un-executed, which can leave stale state laying around. Eventually, as we get to it, tearDown should be 100% erradicated from OpenStack. However, we don't really need more patch churn, so I recommend only working on it as you happen to be in related code. Thanks! Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Blueprint for IPAM and Policy extensions in Neutron
Hi Rudra Thanks! Some questions and comments - name and fq_name How we use name and fq_name ? IMO, we should prevent to use shorten name. - src_ports: [80-80], For API consistency, we should use similar way of the security groups http://docs.openstack.org/api/openstack-network/2.0/content/POST_createSecGroupRule__security-group-rules_security-groups-ext.html - PolicyRuleCreate Could you add more example if the action contains services. action_list: [simple_action-pass], This spec is related with service framework discussion also. so I wanna know the detail and different with service framework. it is also helpful if we could have full list of examples. Best Nachi 2013/10/7 Rudra Rugge rru...@juniper.net: Hi Nachi, I have split the spec for policy and VPN wiki served as a good reference point. Please review and provide comments: https://wiki.openstack.org/wiki/Blueprint-policy-extensions-for-neutron Thanks, Rudra On Oct 4, 2013, at 4:56 PM, Nachi Ueno na...@ntti3.com wrote: 2013/10/4 Rudra Rugge rru...@juniper.net: Hi Nachi, Inline response On 10/4/13 12:54 PM, Nachi Ueno na...@ntti3.com wrote: Hi Rudra inline responded 2013/10/4 Rudra Rugge rru...@juniper.net: Hi Nachi, Thanks for reviewing the BP. Please see inline: On 10/4/13 11:30 AM, Nachi Ueno na...@ntti3.com wrote: Hi Rudra Two comment from me (1) IPAM and Network policy extension looks like independent extension. so IPAM part and Network policy should be divided for two blueprints. [Rudra] I agree that these need to be split into two blueprints. I will create another BP. Thanks (2) The team IPAM is too general word. IMO we should use more specific word. How about SubnetGroup? [Rudra] IPAM holds more information. - All DHCP attributes for this IPAM subnet - DNS server configuration - In future address allocation schemes Actually, Neutron Subnet has dhcp, DNS, ip allocation schemes. If I understand your proposal correct, IPAM is a group of subnets for of which shares common parameters. Also, you can propose to extend existing subnet. [Rudra] Neutron subnet requires a network as I understand. IPAM info should not have such dependency. Similar to Amazon VPC model where all IPAM information can be stored even if a a network is not created. Association to networks can happen at a later time. OK I got it. However IPAM is still too general word. Don't you have any alternatives? Best Nachi Rudra (3) Network Policy Resource I would like to know more details of this api I would like to know resource definition and sample API request and response json. (This is one example https://wiki.openstack.org/wiki/Quantum/VPNaaS ) Especially, I'm interested in src-addresses, dst-addresses, action-list properties. Also, how can we express any port in your API? [Rudra] Will add the details of the resources and APIs after separating the blueprint. Thanks! Best Nachi Regards, Rudra Best Nachi 2013/10/4 Rudra Rugge rru...@juniper.net: Hi All, The link in the email was incorrect. Please follow the following link: https://blueprints.launchpad.net/neutron/+spec/ipam-policy-extensions-f or -neutron Thanks, Rudra On Oct 3, 2013, at 11:38 AM, Rudra Rugge rru...@juniper.net wrote: Hi All, A blueprint has been registered to add IPAM and Policy extensions to Neutron. Please review the blueprint and the attached specification. https://blueprints.launchpad.net/neutron/+spec/juniper-contrail-ipam-po li cy-extensions-for-neutron All comments are welcome. Thanks, Rudra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev
Re: [openstack-dev] Blueprint for IPAM and Policy extensions in Neutron
Hi Rudra Two comment from me (1) IPAM and Network policy extension looks like independent extension. so IPAM part and Network policy should be divided for two blueprints. (2) The team IPAM is too general word. IMO we should use more specific word. How about SubnetGroup? (3) Network Policy Resource I would like to know more details of this api I would like to know resource definition and sample API request and response json. (This is one example https://wiki.openstack.org/wiki/Quantum/VPNaaS ) Especially, I'm interested in src-addresses, dst-addresses, action-list properties. Also, how can we express any port in your API? Best Nachi 2013/10/4 Rudra Rugge rru...@juniper.net: Hi All, The link in the email was incorrect. Please follow the following link: https://blueprints.launchpad.net/neutron/+spec/ipam-policy-extensions-for-neutron Thanks, Rudra On Oct 3, 2013, at 11:38 AM, Rudra Rugge rru...@juniper.net wrote: Hi All, A blueprint has been registered to add IPAM and Policy extensions to Neutron. Please review the blueprint and the attached specification. https://blueprints.launchpad.net/neutron/+spec/juniper-contrail-ipam-policy-extensions-for-neutron All comments are welcome. Thanks, Rudra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Blueprint for IPAM and Policy extensions in Neutron
2013/10/4 Rudra Rugge rru...@juniper.net: Hi Nachi, Inline response On 10/4/13 12:54 PM, Nachi Ueno na...@ntti3.com wrote: Hi Rudra inline responded 2013/10/4 Rudra Rugge rru...@juniper.net: Hi Nachi, Thanks for reviewing the BP. Please see inline: On 10/4/13 11:30 AM, Nachi Ueno na...@ntti3.com wrote: Hi Rudra Two comment from me (1) IPAM and Network policy extension looks like independent extension. so IPAM part and Network policy should be divided for two blueprints. [Rudra] I agree that these need to be split into two blueprints. I will create another BP. Thanks (2) The team IPAM is too general word. IMO we should use more specific word. How about SubnetGroup? [Rudra] IPAM holds more information. - All DHCP attributes for this IPAM subnet - DNS server configuration - In future address allocation schemes Actually, Neutron Subnet has dhcp, DNS, ip allocation schemes. If I understand your proposal correct, IPAM is a group of subnets for of which shares common parameters. Also, you can propose to extend existing subnet. [Rudra] Neutron subnet requires a network as I understand. IPAM info should not have such dependency. Similar to Amazon VPC model where all IPAM information can be stored even if a a network is not created. Association to networks can happen at a later time. OK I got it. However IPAM is still too general word. Don't you have any alternatives? Best Nachi Rudra (3) Network Policy Resource I would like to know more details of this api I would like to know resource definition and sample API request and response json. (This is one example https://wiki.openstack.org/wiki/Quantum/VPNaaS ) Especially, I'm interested in src-addresses, dst-addresses, action-list properties. Also, how can we express any port in your API? [Rudra] Will add the details of the resources and APIs after separating the blueprint. Thanks! Best Nachi Regards, Rudra Best Nachi 2013/10/4 Rudra Rugge rru...@juniper.net: Hi All, The link in the email was incorrect. Please follow the following link: https://blueprints.launchpad.net/neutron/+spec/ipam-policy-extensions-f or -neutron Thanks, Rudra On Oct 3, 2013, at 11:38 AM, Rudra Rugge rru...@juniper.net wrote: Hi All, A blueprint has been registered to add IPAM and Policy extensions to Neutron. Please review the blueprint and the attached specification. https://blueprints.launchpad.net/neutron/+spec/juniper-contrail-ipam-po li cy-extensions-for-neutron All comments are welcome. Thanks, Rudra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][VPNaaS] VPNaaS team meeting
Hi Neutron VPNaaS folks In havana, IPsec site-to-site model and reference driver is merged. Let's discuss next step! :P I have created a page for this discussion. so could you add your bp or thought or workitem on this etherpad page. https://etherpad.openstack.org/NeutronVPNaaSIceHouse I have also registered a session based on this discussion. http://summit.openstack.org/cfp/details/163 I would like to discuss based on the etherpad page at the summit session. Also, I would like to have a meeting on IRC. I added a candidate date in the etherpad page, so please feel free to add your option. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [ml2] devstack now defaults to the ML2 plugin
Congrat! 2013/10/1 Kyle Mestery (kmestery) kmest...@cisco.com: Folks: Just an update regarding the change to move devstack to default to the ML2 Neutron plugin instead of the OVS plugin. The patch [1] merged yesterday. Full tempest tests were passed with this, but just a heads up for those using devstack without specifying a Neutron plugin specifically. Thanks, Kyle [1] https://review.openstack.org/#/c/47837/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer][IceHouse] Ceilometer + Kibana + ElasticSearch Integration
Hi Julien Thank you for your comment 2013/9/16 Julien Danjou jul...@danjou.info: On Fri, Sep 13 2013, Nachi Ueno wrote: Hi Nachi, That looks like a good idea, thanks for submitting. [1] We should add elastic search query api for ceilometer? or we should let user kick ElasticSearch api directory? Note that ElasticSearch has no tenant based authentication, in that case we need to integrate Keystone and ElasticSearch. (or Horizon) This should provide data retrieval too, otherwise it has much less interest. OK I'll propose adding the data retrieval api too with elastic search query. [2] Log (syslog or any application log) should be stored in Ceilometer? (or it should be new OpenStack project? ) Ceilometer already has on the roadmap events/notifications storage, ES would really fit here I think. As I've some plan to use the notification system as a logging back-end, that would probably cover part of this. Cool. Ok so I'll continue working on this on Ceilometer. Best Nachi -- Julien Danjou // Free Software hacker / independent consultant // http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer][IceHouse] Ceilometer + Kibana + ElasticSearch Integration
HI Jaesuk Thank you for your comment. I'm planning to write fluend plugin to collect log data from VM to the ceilometer. 2013/9/13 Jaesuk Ahn bluejay@gmail.com: +1 we have been researching on logstash+ es + kivana for openstack log, thinking how ceilometer can be intergrated with those. Great to here this! Although I have to think this integration more from now, for log aggregator, using logstash might be good idea here. I will keep following up on this. :) Jaesuk Ahn, Ph.D. Team Lead, Cloud Platform Dev. KT 2013. 9. 14. 오전 2:38에 Nachi Ueno na...@ntti3.com님이 작성: Hi Folks Thank you for your feedback! I'll continue this one (1) adding new storage driver (2) adding extension for elastic search query in ceilometer. (i'm still not sure how ceilometer supports extension framework yet) Monsyne Thank you for your information. I'll take a look that project. Best Nachi 2013/9/13 Monsyne Dragon mdra...@rackspace.com: Nice! Have you chatted with these folks: http://projectmeniscus.org/ ? (Openstack-related logging-as-a-service project) They list interoperation with Ceilometer as a project goal. On 9/12/13 7:06 PM, Nachi Ueno na...@ntti3.com wrote: Hi Folks Is anyone interested in Kibana + ElasticSearch Integration with ceilometer? # Note: This discussion is not for Havana. I have registered BP. (for IceHouse) https://blueprints.launchpad.net/ceilometer/+spec/elasticsearch-driver This is demo video. http://www.youtube.com/watch?v=8SmA0W0hd4Ifeature=youtu.be I wrote some sample storage driver for elastic search in ceilometer. This is WIP - https://review.openstack.org/#/c/46383/ This integration sounds cool for me, because if we can integrate then, we can use it as Log as a service. IMO, there are some discussion points. [1] We should add elastic search query api for ceilometer? or we should let user kick ElasticSearch api directory? Note that ElasticSearch has no tenant based authentication, in that case we need to integrate Keystone and ElasticSearch. (or Horizon) [2] Log (syslog or any application log) should be stored in Ceilometer? (or it should be new OpenStack project? ) Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer][IceHouse] Ceilometer + Kibana + ElasticSearch Integration
Hi Folks Is anyone interested in Kibana + ElasticSearch Integration with ceilometer? # Note: This discussion is not for Havana. I have registered BP. (for IceHouse) https://blueprints.launchpad.net/ceilometer/+spec/elasticsearch-driver This is demo video. http://www.youtube.com/watch?v=8SmA0W0hd4Ifeature=youtu.be I wrote some sample storage driver for elastic search in ceilometer. This is WIP - https://review.openstack.org/#/c/46383/ This integration sounds cool for me, because if we can integrate then, we can use it as Log as a service. IMO, there are some discussion points. [1] We should add elastic search query api for ceilometer? or we should let user kick ElasticSearch api directory? Note that ElasticSearch has no tenant based authentication, in that case we need to integrate Keystone and ElasticSearch. (or Horizon) [2] Log (syslog or any application log) should be stored in Ceilometer? (or it should be new OpenStack project? ) Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] The three API server multi-worker process patches.
Hi Folks We choose https://review.openstack.org/#/c/37131/ -- This patch to go on. We are also discussing in this patch. Best Nachi 2013/9/5 Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com: Brian, As far as I know, no consensus was reached. A problem was discovered that happens when spawning multiple processes. The mysql connection seems to go away after between 10-60 seconds in my testing causing a seemingly random API call to fail. After that, it is okay. This must be due to some interaction between forking the process and the mysql connection pool. This needs to be solved but I haven't had the time to look in to it this week. I'm not sure if the other proposal suffers from this problem. Carl On 9/4/13 3:34 PM, Brian Cline bcl...@softlayer.com wrote: Was any consensus on this ever reached? It appears both reviews are still open. I'm partial to review 37131 as it attacks the problem a more concisely, and, as mentioned, combined the efforts of the two more effective patches. I would echo Carl's sentiments that it's an easy review minus the few minor behaviors discussed on the review thread today. We feel very strongly about these making it into Havana -- being confined to a single neutron-server instance per cluster or region is a huge bottleneck--essentially the only controller process with massive CPU churn in environments with constant instance churn, or sudden large batches of new instance requests. In Grizzly, this behavior caused addresses not to be issued to some instances during boot, due to quantum-server thinking the DHCP agents timed out and were no longer available, when in reality they were just backlogged (waiting on quantum-server, it seemed). Is it realistically looking like this patch will be cut for h3? -- Brian Cline Software Engineer III, Product Innovation SoftLayer, an IBM Company 4849 Alpha Rd, Dallas, TX 75244 214.782.7876 direct | bcl...@softlayer.com -Original Message- From: Baldwin, Carl (HPCS Neutron) [mailto:carl.bald...@hp.com] Sent: Wednesday, August 28, 2013 3:04 PM To: Mark McClain Cc: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] The three API server multi-worker process patches. All, We've known for a while now that some duplication of work happened with respect to adding multiple worker processes to the neutron-server. There were a few mistakes made which led to three patches being done independently of each other. Can we settle on one and accept it? I have changed my patch at the suggestion of one of the other 2 authors, Peter Feiner, in attempt to find common ground. It now uses openstack common code and therefore it is more concise than any of the original three and should be pretty easy to review. I'll admit to some bias toward my own implementation but most importantly, I would like for one of these implementations to land and start seeing broad usage in the community earlier than later. Carl Baldwin PS Here are the two remaining patches. The third has been abandoned. https://review.openstack.org/#/c/37131/ https://review.openstack.org/#/c/36487/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neturon] VPNaaS
Hi folks We could merged VPNaaS DB and Driver and CLI for neutron. # heat support also looks like merged! This is a demo video http://www.youtube.com/watch?v=6qqCRqBwMUY This is latest how to install vpn https://wiki.openstack.org/wiki/Quantum/VPNaaS/HowToInstall The last part is Horizon support. https://review.openstack.org/#/c/34882/ so it is great if we can help test VPNaaS function and Horizon. It is also helpful if you could test it with existing network gears also. Best Nachi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
