<div dir="ltr"><div style><span style="color:rgb(0,0,0);font-family:arial,sans-serif">Thanks Shake,</span></div><div style><span style="color:rgb(0,0,0);font-family:arial,sans-serif"><br></span></div><div style><span style="color:rgb(0,0,0);font-family:arial,sans-serif">Turned out to be a problem with this :</span></div>
<div style><span style="color:rgb(0,0,0);font-family:arial,sans-serif"><br></span></div><div style><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> bridge name bridge id STP enabled interfaces</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> br-eth2 8000.000cfc01f473 no eth2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif"><br></span></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">Removing eth2 from br-eth2 fixes this. The quantum agent subsequently plumbs eth2 onto the other bridge</span></div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif"><br></span></div><div><div><font color="#000000" face="arial, sans-serif">brq3c2d19b3-fa 8000.000cfc01f473 no eth2</font></div>
<div><font color="#000000" face="arial, sans-serif"> tap72b8463c-6f</font></div><div><font color="#000000" face="arial, sans-serif"> tapa6c9775d-df</font></div>
<div><font color="#000000" face="arial, sans-serif"> tapadbf1b11-e9</font></div><div><font color="#000000" face="arial, sans-serif"> tapc6c54b78-87</font></div>
<div><font color="#000000" face="arial, sans-serif"> tapcf424b48-54</font></div><div><font color="#000000" face="arial, sans-serif"> tapdb58671d-bd</font></div>
<div><font color="#000000" face="arial, sans-serif"> tapdb661e2b-ff</font></div><div><font color="#000000" face="arial, sans-serif"> tapfbe88e01-78</font></div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif"><br></div></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif">Regards,</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif">Prashanth</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif"><br></span></div><font color="#000000" face="arial, sans-serif">Hi Prashanth</font><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<br><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">whether can share your netwrok interface setting /etc/netwrok/interface.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">I am not sure the setting .</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">physical_interface_mappings = physnet2:eth2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">what I need to setting in eth2?</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">On Wed, Apr 17, 2013 at 11:38 PM, Prashanth Prahalad <</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<a href="mailto:prashanth.prahal@gmail.com" style="text-decoration:none;font-family:arial,sans-serif">prashanth.prahal@gmail.com</a><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> wrote:</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> Hi Folks,</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> I'm setting up quantum with linux bridge. I might have configured this</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> incorrectly and looking for some help on what could be going on.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> This is my quantum.conf and linuxbridge_conf.ini - which tries to setup</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> the linux bridge over eth2.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> [DEFAULT]</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> auth_strategy = keystone</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> allow_overlapping_ips = True</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> policy_file = /etc/quantum/policy.json</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> debug = True</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> verbose = True</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> service_plugins =</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> quantum.plugins.services.</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">agent_loadbalancer.plugin.</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">LoadBalancerPlugin</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> core_plugin =</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> quantum.plugins.linuxbridge.</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">lb_quantum_plugin.</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">LinuxBridgePluginV2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> rabbit_password = openstack</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> rabbit_host = localhost</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> rpc_backend = quantum.openstack.common.rpc.</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">impl_kombu</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> state_path = /opt/stack/data/quantum</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> debug = True</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> verbose = True</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> lock_path = $state_path/lock</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> log_file = quantum.log</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> log_dir = /var/log/quantum</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> bind_host = 0.0.0.0</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> bind_port = 9696</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> <......></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> linuxbridge_conf.ini</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> [VLANS]</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tenant_network_type = vlan</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> network_vlan_ranges = physnet2:1000:2999</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> [DATABASE]</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> sql_connection = mysql://root:openstack@</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">localhost</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> /quantum_linux_bridge?charset=</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">utf8</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> reconnect_interval = 2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> [LINUX_BRIDGE]</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> physical_interface_mappings = physnet2:eth2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> [AGENT]</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> root_helper = sudo /usr/local/bin/quantum-</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">rootwrap</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> /etc/quantum/rootwrap.conf</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> polling_interval = 2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> [SECURITYGROUP]</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> firewall_driver =</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> quantum.agent.linux.iptables_</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">firewall.</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">IptablesFirewallDriver</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> But when the VM is booted up, it comes up over brq3c2d19b3-fa instead of</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> br-eth2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> bridge name bridge id STP enabled interfaces</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> br-eth2 8000.000cfc01f473 no eth2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> brq057a0be8-e9 8000.96f0115f0c03 no</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tapa0dcbf6a-73</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> brq34f87736-91 8000.32245b5d90b7 no</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tap22c7ffb1-9f</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tap874fecfb-ac</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> brq3c2d19b3-fa 8000.3a84ed127b7a no</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tapadbf1b11-e9</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tapc6c54b78-87</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tapcf424b48-54</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tapdb58671d-bd</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> tapdb661e2b-ff</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> Here's a list of commands :</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> quantum net-create sharednet1 --shared --provider:network_type=flat -</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> provider:physical_network=</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">physnet2</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> quantum subnet-create sharednet1 </span><a href="http://30.0.0.0/24" target="_blank" style="text-decoration:none;font-family:arial,sans-serif">30.0.0.0/24</a><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> +-----------------------------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">---------+------------+-------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">------------------------------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">-----------------+</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> | id | name | subnets</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> |</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> +-----------------------------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">---------+------------+-------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">------------------------------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">-----------------+</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> | 057a0be8-e9f9-4e23-a97b-</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">08d2bdb67ad2 | public |</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> 92b32336-76d2-4fa3-a5eb-</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">e1a4b76c648c </span><a href="http://172.24.4.224/28" target="_blank" style="text-decoration:none;font-family:arial,sans-serif">172.24.4.224/28</a><span style="color:rgb(0,0,0);font-family:arial,sans-serif"> |</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> | 34f87736-91d6-4f00-ad11-</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">fe39e76638ce | private |</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> f315bfd5-5f8a-4fa4-bca2-</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">0814998cf8d5 </span><a href="http://10.0.0.0/24" target="_blank" style="text-decoration:none;font-family:arial,sans-serif">10.0.0.0/24</a><span style="color:rgb(0,0,0);font-family:arial,sans-serif"> |</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> | 3c2d19b3-fa72-4bcb-916b-</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">8d54e0e879b1 | sharednet1 |</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> 4691c3ca-b769-4454-9997-</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">1b4dd851d602 </span><a href="http://30.0.0.0/24" target="_blank" style="text-decoration:none;font-family:arial,sans-serif">30.0.0.0/24</a><span style="color:rgb(0,0,0);font-family:arial,sans-serif"> |</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> +-----------------------------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">---------+------------+-------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">------------------------------</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">-----------------+</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> nova boot --image cirros --flavor m1.tiny --nic</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> net-id=3c2d19b3-fa72-4bcb-</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif">916b-8d54e0e879b1 --key-name test my_first_server</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> Anything I'm missing ?</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">> Thanks !</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif">> Prashanth</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif"><span style="color:rgb(0,0,0);font-family:arial,sans-serif">></span><br style="color:rgb(0,0,0);font-family:arial,sans-serif">
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 18, 2013 at 5:00 AM, <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Sachin Thakkar)<br>
2. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Alan Kavanagh)<br>
3. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Ian Wells)<br>
4. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Yi Yang)<br>
5. AUTO: Dietmar Noll/Germany/IBM is out of the office<br>
(returning 24.04.2013) (Dietmar Noll)<br>
6. vms come up on a different bridge.. (Prashanth Prahalad)<br>
7. Source for the Swift API spec? (Pete Zaitcev)<br>
8. Re: [Heat] TOSCA, CAMP, CloudFormation, ??? (Angus Salkeld)<br>
9. Re: Source for the Swift API spec? (Adrian Smith)<br>
10. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Nachi Ueno)<br>
11. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Vasudevan, Swaminathan (PNB Roseville))<br>
12. Re: [Heat] Future Vision for Heat (Steven Hardy)<br>
13. Re: [Heat] Future Vision for Heat (Steven Hardy)<br>
14. Re: [Heat] Future Vision for Heat (Steven Hardy)<br>
15. Re: Source for the Swift API spec? (Anne Gentle)<br>
16. Heat/DSL2 (Alex Heneveld)<br>
17. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(<a href="mailto:fank@vmware.com">fank@vmware.com</a>)<br>
18. Re: Heat/DSL2 (Tripp, Travis S)<br>
19. Re: [Heat] Future Vision for Heat (Zane Bitter)<br>
20. Re: [Heat] Future Vision for Heat (Zane Bitter)<br>
21. Re: Heat/DSL2 (Duncan Johnston Watt)<br>
22. Re: [Heat] Future Vision for Heat (Adrian Otto)<br>
23. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Nachi Ueno)<br>
24. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Alan Kavanagh)<br>
25. Re: [Quantum] Quantum VPN: Update from today's discussion<br>
(Nachi Ueno)<br>
26. Workflow as a service: Convection (Roshan)<br>
27. AUTO: Avishay Traeger is out of the office (returning<br>
05/12/2013) (Avishay Traeger)<br>
28. Re: vms come up on a different bridge.. (Shake Chen)<br>
29. [Quantum] Quantum VPN discussion (Nachi Ueno)<br>
30. Re: [Heat] Future Vision for Heat (Joshua Harlow)<br>
31. passwords in logs --security related (Bhandaru, Malini K)<br>
32. Re: [Heat] Future Vision for Heat (Adrian Otto)<br>
33. Re: passwords in logs --security related (Matt Van Winkle)<br>
34. Re: passwords in logs --security related (Matt Van Winkle)<br>
35. [Cinder] Raised exception in utils.execute (Yann Fouillat)<br>
36. Re: [Heat] Future Vision for Heat (Adrian Otto)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 17 Apr 2013 06:58:51 -0700 (PDT)<br>
From: Sachin Thakkar <<a href="mailto:sthakkar@vmware.com">sthakkar@vmware.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID:<br>
<23962145.1899.1366207131452.JavaMail.sthakkar@sthakkar-mbair.local><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I definitely agree with point (1) from Yi below. There are so many flavors and intricacies to VPNs that it would be to our advantage to decouple as much as possible.<br>
<br>
For (2), my understanding is that the quantum VPN could be either. Is your comment to add this explicit role in addition to the state fields?<br>
<br>
Sachin<br>
<br>
----- Original Message -----<br>
<br>
From: "Yi Yang" <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Sent: Wednesday, April 17, 2013 12:42:35 AM<br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's discussion<br>
<br>
A couple of quick comments:<br>
<br>
1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,<br>
as the former adopts a server-client model while the latter doesn't.<br>
<br>
2. One thing missed in these use cases, except in use case 3, is the<br>
"role" -- does the quantum VPN act as a server or a client?<br>
<br>
Yi<br>
<br>
<br>
<br>
On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
> Hi folks<br>
><br>
> Thank you for joining today's discussion.<br>
> Based on today's discussion, we updated the slide.<br>
><br>
> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135</a><br>
><br>
> Changes<br>
> - Simplify use case<br>
> removed any router references because it deals with implementation<br>
> - Simplify Generic VPNService model<br>
> removed any router references because it deals with service insertion<br>
> - Update attributes of generic VPN Service<br>
> Layer2 or Layer3 mode etc<br>
><br>
> Tommorows' discussion is<br>
> 5:20 at OpenStack Networking room<br>
> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g</a><br>
><br>
> Thanks!<br>
> Nachi<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/b30d0488/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/b30d0488/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 17 Apr 2013 14:13:31 +0000<br>
From: Alan Kavanagh <<a href="mailto:alan.kavanagh@ericsson.com">alan.kavanagh@ericsson.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID:<br>
<<a href="mailto:C977B257ADF8814C8EB4FB66BB9D0C2E0AB2C4@eusaamb109.ericsson.se">C977B257ADF8814C8EB4FB66BB9D0C2E0AB2C4@eusaamb109.ericsson.se</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Absolutely Yi. So I think the Use Case Scenario that is being addressed dictates what the VPN type or collection of suitable VPN types that can be used.<br>
<br>
For point 2, lets touch on that at the VPN session today ;-)<br>
<br>
Alan<br>
<br>
-----Original Message-----<br>
From: Yi Yang [mailto:<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>]<br>
Sent: April-17-13 3:43 AM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's discussion<br>
<br>
A couple of quick comments:<br>
<br>
1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases, as the former adopts a server-client model while the latter doesn't.<br>
<br>
2. One thing missed in these use cases, except in use case 3, is the "role" -- does the quantum VPN act as a server or a client?<br>
<br>
Yi<br>
<br>
<br>
<br>
On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
> Hi folks<br>
><br>
> Thank you for joining today's discussion.<br>
> Based on today's discussion, we updated the slide.<br>
><br>
> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7</a><br>
> B6MKbzFyk73tI/edit#slide=id.gd23898b7_135<br>
><br>
> Changes<br>
> - Simplify use case<br>
> removed any router references because it deals with implementation<br>
> - Simplify Generic VPNService model<br>
> removed any router references because it deals with service<br>
> insertion<br>
> - Update attributes of generic VPN Service<br>
> Layer2 or Layer3 mode etc<br>
><br>
> Tommorows' discussion is<br>
> 5:20 at OpenStack Networking room<br>
> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335ac" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335ac</a><br>
> c8a78ff61c#.UW3p1SvC82g<br>
><br>
> Thanks!<br>
> Nachi<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 17 Apr 2013 07:27:29 -0700<br>
From: Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID:<br>
<CAPoubz5bjOormU9FkGDN=TKh5oiY+3Hqm6mY8drru=iKKWZL=<a href="mailto:w@mail.gmail.com">w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On 17 April 2013 00:42, Yi Yang <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>> wrote:<br>
<br>
> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,<br>
> as the former adopts a server-client model while the latter doesn't.<br>
><br>
<br>
Thirded. There are any number of VPNs where the VPN is set up by some form<br>
of mutual agreement - no negotiation, no connection, merely one end sending<br>
packets in an agreed format and simultaneously agreeing to process incoming<br>
ones.<br>
<br>
The categorisations I would choose are:<br>
<br>
1. VPN by mutual agreement (and where the connection cannot, typically, be<br>
rejected) - this would include MPLS, GRE, l2tpv3 and VLANs<br>
2. VPN where we provide one set of credentials to the far end, the VPN must<br>
be activated and may drop and be reactivated, and the connection is<br>
authorised or rejected on those credentials<br>
3. VPN where we're an endpoint with (possibly) many sets of credentials and<br>
we authorise incoming connections.<br>
<br>
(2) and (3) would presumably be the same set of protocols and include<br>
openvpn, ipsec and friends.<br>
<br>
I'm not sure that that covers all the cases, so please chime in with your<br>
counterexamples.<br>
<br>
--<br>
Ian.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/dbc0bf1e/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/dbc0bf1e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 17 Apr 2013 10:38:56 -0400<br>
From: Yi Yang <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID: <<a href="mailto:516EB400.20904@gmail.com">516EB400.20904@gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
<br>
While quantum VPN can serve as either client or server or both, there<br>
are big difference on requirements -- for example, a SSL VPN server<br>
needs to have an address pool, which is not required for clients.<br>
<br>
IMO, we need to first differentiate these use cases (server vs. client)<br>
before we decide what state fields should be covered.<br>
<br>
Yi<br>
<br>
On 4/17/13 9:58 AM, Sachin Thakkar wrote:<br>
> I definitely agree with point (1) from Yi below. There are so many<br>
> flavors and intricacies to VPNs that it would be to our advantage to<br>
> decouple as much as possible.<br>
><br>
> For (2), my understanding is that the quantum VPN could be either. Is<br>
> your comment to add this explicit role in addition to the state fields?<br>
><br>
> Sachin<br>
><br>
> ------------------------------------------------------------------------<br>
> *From: *"Yi Yang" <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
> *To: *"OpenStack Development Mailing List"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> *Sent: *Wednesday, April 17, 2013 12:42:35 AM<br>
> *Subject: *Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
> today's discussion<br>
><br>
> A couple of quick comments:<br>
><br>
> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,<br>
> as the former adopts a server-client model while the latter doesn't.<br>
><br>
> 2. One thing missed in these use cases, except in use case 3, is the<br>
> "role" -- does the quantum VPN act as a server or a client?<br>
><br>
> Yi<br>
><br>
><br>
><br>
> On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
> > Hi folks<br>
> ><br>
> > Thank you for joining today's discussion.<br>
> > Based on today's discussion, we updated the slide.<br>
> ><br>
> ><br>
> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135</a><br>
> ><br>
> > Changes<br>
> > - Simplify use case<br>
> > removed any router references because it deals with implementation<br>
> > - Simplify Generic VPNService model<br>
> > removed any router references because it deals with service insertion<br>
> > - Update attributes of generic VPN Service<br>
> > Layer2 or Layer3 mode etc<br>
> ><br>
> > Tommorows' discussion is<br>
> > 5:20 at OpenStack Networking room<br>
> ><br>
> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g</a><br>
> ><br>
> > Thanks!<br>
> > Nachi<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/70ac7937/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/70ac7937/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 17 Apr 2013 17:13:22 +0200<br>
From: Dietmar Noll <<a href="mailto:DNOLL@de.ibm.com">DNOLL@de.ibm.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] AUTO: Dietmar Noll/Germany/IBM is out of the<br>
office (returning 24.04.2013)<br>
Message-ID:<br>
<<a href="mailto:OFE28CE9B2.1B2C3038-ONC1257B50.00539F54-C1257B50.00539F54@de.ibm.com">OFE28CE9B2.1B2C3038-ONC1257B50.00539F54-C1257B50.00539F54@de.ibm.com</a>><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
<br>
I am out of the office until 24.04.2013.<br>
<br>
I am out of the office traveling and will only have limited access to<br>
e-mails.<br>
I will respond as soon as possible.<br>
For TPC/VSC related topics, please contact Sumant Padbidri<br>
For other urgent topics, please contact Horst Zisgen.<br>
<br>
<br>
Note: This is an automated response to your message "OpenStack-dev Digest,<br>
Vol 12, Issue 21" sent on 17/04/2013 14:00:02.<br>
<br>
This is the only notification you will receive while this person is away.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 17 Apr 2013 08:38:01 -0700<br>
From: Prashanth Prahalad <<a href="mailto:prashanth.prahal@gmail.com">prashanth.prahal@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] vms come up on a different bridge..<br>
Message-ID:<br>
<CADghgozytDB=<a href="mailto:6rqA1iPS40ywp9k-EBPkg5L%2BRb5p2uwGxEvpKA@mail.gmail.com">6rqA1iPS40ywp9k-EBPkg5L+Rb5p2uwGxEvpKA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi Folks,<br>
<br>
I'm setting up quantum with linux bridge. I might have configured this<br>
incorrectly and looking for some help on what could be going on.<br>
<br>
This is my quantum.conf and linuxbridge_conf.ini - which tries to setup<br>
the linux bridge over eth2.<br>
<br>
[DEFAULT]<br>
auth_strategy = keystone<br>
allow_overlapping_ips = True<br>
policy_file = /etc/quantum/policy.json<br>
debug = True<br>
verbose = True<br>
service_plugins =<br>
quantum.plugins.services.agent_loadbalancer.plugin.LoadBalancerPlugin<br>
core_plugin =<br>
quantum.plugins.linuxbridge.lb_quantum_plugin.LinuxBridgePluginV2<br>
rabbit_password = openstack<br>
rabbit_host = localhost<br>
rpc_backend = quantum.openstack.common.rpc.impl_kombu<br>
state_path = /opt/stack/data/quantum<br>
debug = True<br>
verbose = True<br>
lock_path = $state_path/lock<br>
log_file = quantum.log<br>
log_dir = /var/log/quantum<br>
bind_host = 0.0.0.0<br>
bind_port = 9696<br>
<......><br>
<br>
linuxbridge_conf.ini<br>
<br>
[VLANS]<br>
tenant_network_type = vlan<br>
network_vlan_ranges = physnet2:1000:2999<br>
[DATABASE]<br>
sql_connection = mysql://root:openstack@localhost<br>
/quantum_linux_bridge?charset=utf8<br>
reconnect_interval = 2<br>
[LINUX_BRIDGE]<br>
physical_interface_mappings = physnet2:eth2<br>
[AGENT]<br>
root_helper = sudo /usr/local/bin/quantum-rootwrap<br>
/etc/quantum/rootwrap.conf<br>
polling_interval = 2<br>
[SECURITYGROUP]<br>
firewall_driver =<br>
quantum.agent.linux.iptables_firewall.IptablesFirewallDriver<br>
<br>
But when the VM is booted up, it comes up over brq3c2d19b3-fa instead of<br>
br-eth2<br>
<br>
bridge name bridge id STP enabled interfaces<br>
br-eth2 8000.000cfc01f473 no eth2<br>
brq057a0be8-e9 8000.96f0115f0c03 no<br>
tapa0dcbf6a-73<br>
brq34f87736-91 8000.32245b5d90b7 no<br>
tap22c7ffb1-9f<br>
<br>
tap874fecfb-ac<br>
brq3c2d19b3-fa 8000.3a84ed127b7a no<br>
tapadbf1b11-e9<br>
<br>
tapc6c54b78-87<br>
<br>
tapcf424b48-54<br>
<br>
tapdb58671d-bd<br>
<br>
tapdb661e2b-ff<br>
<br>
Here's a list of commands :<br>
<br>
quantum net-create sharednet1 --shared --provider:network_type=flat -<br>
provider:physical_network=physnet2<br>
quantum subnet-create sharednet1 <a href="http://30.0.0.0/24" target="_blank">30.0.0.0/24</a><br>
<br>
+--------------------------------------+------------+------------------------------------------------------+<br>
| id | name | subnets<br>
|<br>
+--------------------------------------+------------+------------------------------------------------------+<br>
| 057a0be8-e9f9-4e23-a97b-08d2bdb67ad2 | public |<br>
92b32336-76d2-4fa3-a5eb-e1a4b76c648c <a href="http://172.24.4.224/28" target="_blank">172.24.4.224/28</a> |<br>
| 34f87736-91d6-4f00-ad11-fe39e76638ce | private |<br>
f315bfd5-5f8a-4fa4-bca2-0814998cf8d5 <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> |<br>
| 3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 | sharednet1 |<br>
4691c3ca-b769-4454-9997-1b4dd851d602 <a href="http://30.0.0.0/24" target="_blank">30.0.0.0/24</a> |<br>
+--------------------------------------+------------+------------------------------------------------------+<br>
<br>
nova boot --image cirros --flavor m1.tiny --nic<br>
net-id=3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 --key-name test my_first_server<br>
<br>
Anything I'm missing ?<br>
<br>
Thanks !<br>
Prashanth<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/fd87c076/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/fd87c076/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 17 Apr 2013 11:26:16 -0600<br>
From: Pete Zaitcev <<a href="mailto:zaitcev@redhat.com">zaitcev@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Source for the Swift API spec?<br>
Message-ID: <20130417112616.72cd8bed@lembas.zaitcev.lan><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
Just curious after Anne joined a breakfast table and talked about helping<br>
with the docs: where is the source of the Swift API spec? I'm talking<br>
about this:<br>
<a href="http://docs.openstack.org/api/openstack-object-storage/1.0/content/" target="_blank">http://docs.openstack.org/api/openstack-object-storage/1.0/content/</a><br>
<br>
I have manuals repo cloned, but apparently it's not there.<br>
(this - git://<a href="http://github.com/openstack/openstack-manuals.git" target="_blank">github.com/openstack/openstack-manuals.git</a>)<br>
<br>
Obviously it's not in doc/source/ of Swift repo either. But it has to<br>
be _somewhere_, right?<br>
<br>
-- Pete<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Wed, 17 Apr 2013 10:56:12 -0700<br>
From: Angus Salkeld <<a href="mailto:asalkeld@redhat.com">asalkeld@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???<br>
Message-ID: <<a href="mailto:20130417175612.GB4100@redhat.com">20130417175612.GB4100@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 15/04/13 14:39 -0700, Alex Heneveld wrote:<br>
><br>
>I have refactored and expanded the "vocabulary" (@asalked's madness<br>
>guide) now at:<br>
><br>
> <a href="https://wiki.openstack.org/wiki/Heat/Vocabulary" target="_blank">https://wiki.openstack.org/wiki/Heat/Vocabulary</a><br>
<br>
Thanks Alex.<br>
<br>
-Angus<br>
><br>
>--A<br>
><br>
><br>
>On 12/04/2013 15:36, Adrian Otto wrote:<br>
>>Clint,<br>
>><br>
>>On Apr 12, 2013, at 2:22 PM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
>> wrote:<br>
>><br>
>>>On 2013-04-12 08:45, Adrian Otto wrote:<br>
>>>>This proposal will utilize the existing Heat agent. We currently use<br>
>>>>SSH keypair injection on the API call to the Cloud Servers API to<br>
>>>>bootstrap compute nodes in the simple case. The idea is to leave that<br>
>>>>open to handle whatever the system Provider modules want to<br>
>>>>instrument. Please recognize that we want this DSL to work regardless<br>
>>>>of what the underlying hardware/cloud infrastructure is. It can work<br>
>>>>on your laptop with vagrant, with OpenStack, with a public cloud? that<br>
>>>>should not matter. The vendor specific implementations all go into the<br>
>>>>Provider plug-ins. The idea is to enable decentralized implementation<br>
>>>>of vendor-specific systems, and centralized sharing of best practices<br>
>>>>for application deployment. Imagine an OpenStack community repo of<br>
>>>>Heat Blueprints where everyone can publish their best practices.<br>
>>>So what I think you're saying is, Heat would have some intrinsic providers for compute, object storage, block storage, etc. Users would somehow be able to define their own providers inside compute servers via an API, which could then be referenced directly in the DSL? So if I want memcached, I write a provider definition for it, and somehow deliver it into the compute node and notify Heat of its presence?<br>
>>><br>
>>>The spec is really unclear on how providers are defined (or I'm just overloaded with specs and can't comprehend it), but I am actually pretty excited to see a system that allows users to reference and manage compute-hosted things at the same level as "under the cloud" resources.<br>
>>Yes, you've got the idea. In the case of memcached, you might just want to build that up from compute instances, so you might not even involve a provider for that, it could simply be specified as a Component. That's not any different from what Heat can already do today. Here is another use case where Providers can make a lot of sense:<br>
>><br>
>>Goal: Deploy my app on my chosen OpenStack based public cloud, using Heat for Dev/Test. For Production, deploy to my private OpenStack cloud.<br>
>><br>
>>Scenario: My app depends on a MySQL database. My public cloud provider has a hosted "mysql" service that is offered through a Provider plug-in. It's there automatically because my cloud hosting company put it there. I deploy, and finish my testing on the public cloud. I want to go to production now.<br>
>><br>
>>Solution: The Provider gives you a way to abstract the different cloud implementations. I establish an equivalent Provider on my private OpenStack cloud using RedDwarf. I set up a Provider that offers "mysql" in my private cloud. Now the same setup works on both clouds, even though the API for my local "mysql" service may actually differ from the database provisioning API in the public cloud. Now I deploy on my "production" Environment in my private cloud, and it works!<br>
>><br>
>>Not to blow your mind too much, but in the use case above, we assume that each cloud has its own hosted Heat service that speaks the Open API+DSL. You could also use one of the Heat services, and *not* the other. You define two Environments. One is for "dev/test" and uses Providers on the public cloud. The other is for "production", and it uses Providers on the private cloud. Now you can just decide where stuff gets provisioned by selecting the appropriate Environment. You might decide to just use the hosted Heat service from your public cloud, even when you are deploying into your private cloud.<br>
>><br>
>>If that makes sense, you can take that idea a step further, and actually set up Environments that mix both public and private cloud infrastructure. Maybe you use provider A for your mission critical (persistent, HA) Components, and provider B for nightly batch processing jobs. Same Environment. Arbitrary number of clouds.<br>
>><br>
>>Without a concept like Providers, application portability between public and private clouds can get a bit more convoluted. You may end up doing things like constructing the "mysql" service on top of compute nodes using Components for sake of portability, but this can cause you to sacrifice performance using a general purpose compute instances you find in a typical nova compute service, rather than the more performance tuned hosted database service your public cloud service may offer you.<br>
>><br>
>>Cheers,<br>
>><br>
>>Adrian<br>
>><br>
>><br>
>>_______________________________________________<br>
>>OpenStack-dev mailing list<br>
>><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Wed, 17 Apr 2013 19:04:10 +0100<br>
From: Adrian Smith <<a href="mailto:adrian_f_smith@dell.com">adrian_f_smith@dell.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Source for the Swift API spec?<br>
Message-ID:<br>
<<a href="mailto:CAKgbHu29F0VH0CzkswMaJZaaqPxjSRnZP0y6JsX7C90Pwz6Reg@mail.gmail.com">CAKgbHu29F0VH0CzkswMaJZaaqPxjSRnZP0y6JsX7C90Pwz6Reg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
I think this it the repo Pete, <a href="https://github.com/openstack/object-api" target="_blank">https://github.com/openstack/object-api</a><br>
<br>
Adrian<br>
<br>
On 17 April 2013 18:26, Pete Zaitcev <<a href="mailto:zaitcev@redhat.com">zaitcev@redhat.com</a>> wrote:<br>
> Just curious after Anne joined a breakfast table and talked about helping<br>
> with the docs: where is the source of the Swift API spec? I'm talking<br>
> about this:<br>
> <a href="http://docs.openstack.org/api/openstack-object-storage/1.0/content/" target="_blank">http://docs.openstack.org/api/openstack-object-storage/1.0/content/</a><br>
><br>
> I have manuals repo cloned, but apparently it's not there.<br>
> (this - git://<a href="http://github.com/openstack/openstack-manuals.git" target="_blank">github.com/openstack/openstack-manuals.git</a>)<br>
><br>
> Obviously it's not in doc/source/ of Swift repo either. But it has to<br>
> be _somewhere_, right?<br>
><br>
> -- Pete<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Wed, 17 Apr 2013 11:42:38 -0700<br>
From: Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID:<br>
<<a href="mailto:CABJepwjM-pK4wNk7EmHPgspuCjBOMZJvFKAmXgqaGw49pR0A5A@mail.gmail.com">CABJepwjM-pK4wNk7EmHPgspuCjBOMZJvFKAmXgqaGw49pR0A5A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi folks<br>
<br>
May be, there are many ways to categorize use cases.<br>
<br>
We agreed we will model VPN as a Service instance (VPNService).<br>
If we define new service, the service can support any kind of VPNs (L2, L3)<br>
What's we need to be discussed is attributes of Generalize VPN Service<br>
Models if we can have generic vpn service models.<br>
<br>
I added vpn map for slide 13 ( This may help this discussion)<br>
<a href="https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310" target="_blank">https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310</a><br>
<br>
This is current proposed attributes.<br>
<br>
1. id<br>
2. name<br>
3. tenant_id<br>
4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... )<br>
5. insertion_mode<br>
6. mode = l2 | l3 ?<br>
<br>
I believe there is no need to discussion about 1-4.<br>
5 is needed to use service insertion.<br>
( Prevent routed service insertion of which didn't support it)<br>
<br>
6. Mode<br>
I'm not sure how to use this attribute, so I'm very appreciate if<br>
someone would add<br>
the motivation on the slide<br>
<br>
Thanks<br>
Nachi<br>
<br>
2013/4/17 Yi Yang <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>>:<br>
> While quantum VPN can serve as either client or server or both, there are<br>
> big difference on requirements -- for example, a SSL VPN server needs to<br>
> have an address pool, which is not required for clients.<br>
><br>
> IMO, we need to first differentiate these use cases (server vs. client)<br>
> before we decide what state fields should be covered.<br>
><br>
> Yi<br>
><br>
><br>
> On 4/17/13 9:58 AM, Sachin Thakkar wrote:<br>
><br>
> I definitely agree with point (1) from Yi below. There are so many flavors<br>
> and intricacies to VPNs that it would be to our advantage to decouple as<br>
> much as possible.<br>
><br>
> For (2), my understanding is that the quantum VPN could be either. Is your<br>
> comment to add this explicit role in addition to the state fields?<br>
><br>
> Sachin<br>
><br>
> ________________________________<br>
> From: "Yi Yang" <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
> To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Wednesday, April 17, 2013 12:42:35 AM<br>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's<br>
> discussion<br>
><br>
> A couple of quick comments:<br>
><br>
> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,<br>
> as the former adopts a server-client model while the latter doesn't.<br>
><br>
> 2. One thing missed in these use cases, except in use case 3, is the<br>
> "role" -- does the quantum VPN act as a server or a client?<br>
><br>
> Yi<br>
><br>
><br>
><br>
> On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
>> Hi folks<br>
>><br>
>> Thank you for joining today's discussion.<br>
>> Based on today's discussion, we updated the slide.<br>
>><br>
>><br>
>> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135</a><br>
>><br>
>> Changes<br>
>> - Simplify use case<br>
>> removed any router references because it deals with implementation<br>
>> - Simplify Generic VPNService model<br>
>> removed any router references because it deals with service insertion<br>
>> - Update attributes of generic VPN Service<br>
>> Layer2 or Layer3 mode etc<br>
>><br>
>> Tommorows' discussion is<br>
>> 5:20 at OpenStack Networking room<br>
>><br>
>> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g</a><br>
>><br>
>> Thanks!<br>
>> Nachi<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Wed, 17 Apr 2013 18:52:49 +0000<br>
From: "Vasudevan, Swaminathan (PNB Roseville)"<br>
<<a href="mailto:swaminathan.vasudevan@hp.com">swaminathan.vasudevan@hp.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID:<br>
<<a href="mailto:4094DC7712AF5D488899847517A3C5B0649E62EB@G9W0342.americas.hpqcorp.net">4094DC7712AF5D488899847517A3C5B0649E62EB@G9W0342.americas.hpqcorp.net</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi Nachi,<br>
I also added a slide 9, that gives a high level data model for all the vpn service types.<br>
Thanks<br>
Swami<br>
<br>
-----Original Message-----<br>
From: Nachi Ueno [mailto:<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>]<br>
Sent: Wednesday, April 17, 2013 11:43 AM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's discussion<br>
<br>
Hi folks<br>
<br>
May be, there are many ways to categorize use cases.<br>
<br>
We agreed we will model VPN as a Service instance (VPNService).<br>
If we define new service, the service can support any kind of VPNs (L2, L3) What's we need to be discussed is attributes of Generalize VPN Service Models if we can have generic vpn service models.<br>
<br>
I added vpn map for slide 13 ( This may help this discussion)<br>
<a href="https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310" target="_blank">https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310</a><br>
<br>
This is current proposed attributes.<br>
<br>
1. id<br>
2. name<br>
3. tenant_id<br>
4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... ) 5. insertion_mode 6. mode = l2 | l3 ?<br>
<br>
I believe there is no need to discussion about 1-4.<br>
5 is needed to use service insertion.<br>
( Prevent routed service insertion of which didn't support it)<br>
<br>
6. Mode<br>
I'm not sure how to use this attribute, so I'm very appreciate if someone would add the motivation on the slide<br>
<br>
Thanks<br>
Nachi<br>
<br>
2013/4/17 Yi Yang <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>>:<br>
> While quantum VPN can serve as either client or server or both, there<br>
> are big difference on requirements -- for example, a SSL VPN server<br>
> needs to have an address pool, which is not required for clients.<br>
><br>
> IMO, we need to first differentiate these use cases (server vs.<br>
> client) before we decide what state fields should be covered.<br>
><br>
> Yi<br>
><br>
><br>
> On 4/17/13 9:58 AM, Sachin Thakkar wrote:<br>
><br>
> I definitely agree with point (1) from Yi below. There are so many<br>
> flavors and intricacies to VPNs that it would be to our advantage to<br>
> decouple as much as possible.<br>
><br>
> For (2), my understanding is that the quantum VPN could be either. Is<br>
> your comment to add this explicit role in addition to the state fields?<br>
><br>
> Sachin<br>
><br>
> ________________________________<br>
> From: "Yi Yang" <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
> To: "OpenStack Development Mailing List"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Wednesday, April 17, 2013 12:42:35 AM<br>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
> today's discussion<br>
><br>
> A couple of quick comments:<br>
><br>
> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN<br>
> cases, as the former adopts a server-client model while the latter doesn't.<br>
><br>
> 2. One thing missed in these use cases, except in use case 3, is the<br>
> "role" -- does the quantum VPN act as a server or a client?<br>
><br>
> Yi<br>
><br>
><br>
><br>
> On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
>> Hi folks<br>
>><br>
>> Thank you for joining today's discussion.<br>
>> Based on today's discussion, we updated the slide.<br>
>><br>
>><br>
>> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn</a><br>
>> 7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135<br>
>><br>
>> Changes<br>
>> - Simplify use case<br>
>> removed any router references because it deals with<br>
>> implementation<br>
>> - Simplify Generic VPNService model<br>
>> removed any router references because it deals with service<br>
>> insertion<br>
>> - Update attributes of generic VPN Service<br>
>> Layer2 or Layer3 mode etc<br>
>><br>
>> Tommorows' discussion is<br>
>> 5:20 at OpenStack Networking room<br>
>><br>
>> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335a" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335a</a><br>
>> cc8a78ff61c#.UW3p1SvC82g<br>
>><br>
>> Thanks!<br>
>> Nachi<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Wed, 17 Apr 2013 19:54:17 +0100<br>
From: Steven Hardy <<a href="mailto:shardy@redhat.com">shardy@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:20130417185416.GD11493@t430slt.redhat.com">20130417185416.GD11493@t430slt.redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi Adrian,<br>
<br>
Thanks for taking the time to do this, definitely provides a good starting<br>
point for further discussion and captures many of the concepts mentioned<br>
during the sessions on Monday.<br>
<br>
On Tue, Apr 16, 2013 at 08:56:23AM +0000, Adrian Otto wrote:<br>
> Heaters,<br>
><br>
> I attended the various sessions at the Design Summit today in Portland, and assembled as many of the ideas for future planning as I could. For the benefit of those who are not attending, or who were not in these sessions, I created this Wiki page to express what I think is an early consensus on where we could take things. Let's tweak this if it's not a good direction.<br>
><br>
> <a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
<br>
Thanks for taking the time to do this, definitely provides a good starting<br>
point for further discussion and captures many of the concepts mentioned<br>
during the sessions on Monday.<br>
<br>
I think your diagram represents a possible long-term view of how the<br>
architecture could develop, but obviously there are many components there<br>
which do not currently exist, or which are currently part of the heat core<br>
orchestration engine.<br>
<br>
I think it may be useful to look at the initial modifications required to<br>
support the new "superset DSL", and I'll try to get a diagram up later with<br>
my view of what is required to do this, but in summary:<br>
<br>
- The model interpreter can be in heat-engine, as the first thing which<br>
processes the template during template-driven lifecycle operations<br>
(create/update) - this is separate from the current "parser" logic, so we<br>
can incrementally modify the underlying parser logic and interpreter<br>
logic in-step.<br>
<br>
- The API layer can be unmodified<br>
<br>
- Translations to/from formats other than our current CFN-compatible format<br>
and the new "Native DSL" (or "HOT" - Heat Openstack Template as was<br>
suggested on Monday :D) are performed outside of heat - IMO we only want<br>
to care about the superset DSL inside heat, and we don't want the<br>
complexity of the stacked API's, multiple model interpreter plugins etc (at<br>
least initially)<br>
<br>
- Scheduler/parser logic remains in the heat-engine (this should not ever<br>
be moved into the API in your diagram IMO)<br>
<br>
> Keith will be doing an Unconference session on the Workflow Service idea? I believe on Wednesday afternoon.<br>
<br>
This definitely sounds interesting, and I'm interested in further<br>
discussing this idea, see you there!<br>
<br>
Steve<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Wed, 17 Apr 2013 19:55:06 +0100<br>
From: Steven Hardy <<a href="mailto:shardy@redhat.com">shardy@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:20130417185504.GE11493@t430slt.redhat.com">20130417185504.GE11493@t430slt.redhat.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Tue, Apr 16, 2013 at 04:13:06PM +0200, Thomas Spatzier wrote:<br>
> Hi Adrian,<br>
><br>
> thanks for taking writing this up to capture yesterday's discussions.<br>
> I don't fully understand what the difference or overlap of the Model<br>
> Interpreter inside the main blue box and the Model Interpreter in the green<br>
> box is. My understanding was that a Model Interpreter would be something<br>
> that translates an external format (such as CFN, TOSCA, whatever) to the<br>
> core Heat DSL. And then there would be one component which looks at the<br>
> common DSL model to derive the deployment plan (I think somebody said this<br>
> is what the "parser" does today).<br>
> I think having to partly re-implement the interpreter (in the sense of<br>
> compiling a concrete deployment plan directly) for various external formats<br>
> could be complicated.<br>
<br>
I agree, which is why I propose keeping the mult-format translation outside<br>
of heat (layered above the API, or some scripts which do format conversion)<br>
<br>
The "parser" is really our internal terminology, but for the purposes of<br>
the discussion, the parser is the thing which converts the native template<br>
format into resource definitions and a dependency-graph we can process<br>
<br>
Steve<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Wed, 17 Apr 2013 19:56:04 +0100<br>
From: Steven Hardy <<a href="mailto:shardy@redhat.com">shardy@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:20130417185603.GF11493@t430slt.redhat.com">20130417185603.GF11493@t430slt.redhat.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Tue, Apr 16, 2013 at 01:37:15PM -0700, Alex Heneveld wrote:<br>
><br>
> very useful summary. thanks adrian for this and thanks all for the<br>
> great discussion yesterday. a few comments:<br>
><br>
> (1) @doug, @thomas: +1. while it would be possible for external<br>
> servers to understand different models and call REST using a native<br>
> dsl, it should also be possible to support multiple model<br>
> interpreters as part of the big blue box. that would seem better<br>
> for the "legacy" CFN :) and the new DSL (eg YAML) and/or possibly<br>
> TOSCA XML (or a lite version thereof!).<br>
<br>
As mentioned elsewhere, I don't think supporting multiple model<br>
interpreters internally will be helpful in the short/medium term, the<br>
maintenance burden will be too high IMO. We should concentrate on<br>
definining a superset language which is expressive enough that other<br>
formats people require can be trivially converted either at, or ideally<br>
above the API level.<br>
<br>
><br>
> (2) should the workflow service and the scheduler be more closely<br>
> integrated, or even the same? feels like whatever heat does for its<br>
> orchestration would want the same task management, scheduling,<br>
> locking, etc that imperative plans/workflow included as part of a<br>
> heat blueprint would want.<br>
><br>
> (3) @debojyoti: +1. i'd really like to see support for nested /<br>
> hierarchical components or typed relationships. this gives a nice<br>
> solution to services/tiers/pools/autoscaling-groups going up one<br>
> level but you could go higher too. it makes it composable which<br>
> becomes very powerful (one of the best features of TOSCA imho). i<br>
> look forward to the curvature talk (and a visio-style gui for<br>
> heat!!).<br>
<br>
Note we do already support nested/composed stacks - is there some other<br>
concept or functionality you'd like to see in addition to this?<br>
<br>
> finally -- (4) -- is there any interest in continuing the discussion<br>
> while so many of us are here?<br>
><br>
> i have heard rumours of extra rooms available for the asking.<br>
<br>
I'll see if I can find some meeting space - main challenge is everyone has<br>
pretty packed schedules with all the other sessions that are going on.<br>
<br>
I'd definitely like to spend some time white-boarding this and making sure<br>
we have the vocabulary and concept-mapping side of things agreed.<br>
<br>
Steve<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Wed, 17 Apr 2013 12:32:32 -0700<br>
From: Anne Gentle <<a href="mailto:annegentle@justwriteclick.com">annegentle@justwriteclick.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Source for the Swift API spec?<br>
Message-ID: <<a href="mailto:032DADF2-2ED5-42BB-9BD0-63AE0A5C349F@justwriteclick.com">032DADF2-2ED5-42BB-9BD0-63AE0A5C349F@justwriteclick.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Yes, that is correct.<br>
<br>
Anne Gentle<br>
Content Stacker<br>
<a href="mailto:anne@openstack.org">anne@openstack.org</a><br>
<br>
<br>
On Apr 17, 2013, at 11:04 AM, Adrian Smith <<a href="mailto:adrian_f_smith@dell.com">adrian_f_smith@dell.com</a>> wrote:<br>
<br>
> I think this it the repo Pete, <a href="https://github.com/openstack/object-api" target="_blank">https://github.com/openstack/object-api</a><br>
><br>
> Adrian<br>
><br>
> On 17 April 2013 18:26, Pete Zaitcev <<a href="mailto:zaitcev@redhat.com">zaitcev@redhat.com</a>> wrote:<br>
>> Just curious after Anne joined a breakfast table and talked about helping<br>
>> with the docs: where is the source of the Swift API spec? I'm talking<br>
>> about this:<br>
>> <a href="http://docs.openstack.org/api/openstack-object-storage/1.0/content/" target="_blank">http://docs.openstack.org/api/openstack-object-storage/1.0/content/</a><br>
>><br>
>> I have manuals repo cloned, but apparently it's not there.<br>
>> (this - git://<a href="http://github.com/openstack/openstack-manuals.git" target="_blank">github.com/openstack/openstack-manuals.git</a>)<br>
>><br>
>> Obviously it's not in doc/source/ of Swift repo either. But it has to<br>
>> be _somewhere_, right?<br>
>><br>
>> -- Pete<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Wed, 17 Apr 2013 12:56:23 -0700<br>
From: Alex Heneveld <<a href="mailto:alex.heneveld@cloudsoftcorp.com">alex.heneveld@cloudsoftcorp.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Heat/DSL2<br>
Message-ID: <516EFE67.5010800@CloudsoftCorp.com><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
<br>
I've been working through the Heat/DSL [1] idea, trying to whittle it<br>
down to an even simpler model, suitable as an abstraction atop<br>
CloudFormation as well as TOSCA and CAMP. And like [1] trying to make<br>
it easy for mortals to read and write.<br>
<br>
The current state is at Heat/DSL2 [2], with a rough python parser<br>
implementation (not connected to Heat yet) at [3].<br>
<br>
I'll be around today and tomorrow so if anyone would like to discuss F2F<br>
or on IRC (alexheneveld) please shout.<br>
<br>
Also note there are some related lightning talks starting soon and an<br>
unconference tomorrow at 2.20pm.<br>
<br>
Best<br>
Alex<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Heat/DSL" target="_blank">https://wiki.openstack.org/wiki/Heat/DSL</a><br>
[2] <a href="https://wiki.openstack.org/wiki/Heat/DSL2" target="_blank">https://wiki.openstack.org/wiki/Heat/DSL2</a><br>
[3] <a href="https://github.com/sjcorbett/heat-camp-yaml" target="_blank">https://github.com/sjcorbett/heat-camp-yaml</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Wed, 17 Apr 2013 13:27:22 -0700 (PDT)<br>
From: <a href="mailto:fank@vmware.com">fank@vmware.com</a><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID: <<a href="mailto:955208200.4190562.1366230442506.JavaMail.root@vmware.com">955208200.4190562.1366230442506.JavaMail.root@vmware.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi Nachi,<br>
<br>
I'm not sure how "insertion_mode" could be any useful for plugins if it only indicate the mode as routed/out-of-path/floating insertion.<br>
<br>
For example, we need to associated it with a router if it is routed insertion (and we have an extension for associating a service with a router id: <a href="https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion" target="_blank">https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion</a>).<br>
<br>
What we need for out-of-path insertion and floating insertion? A network/subnet id?<br>
<br>
-Kaiwei<br>
<br>
----- Original Message -----<br>
From: "Nachi Ueno" <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Sent: Wednesday, April 17, 2013 11:42:38 AM<br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's discussion<br>
<br>
Hi folks<br>
<br>
May be, there are many ways to categorize use cases.<br>
<br>
We agreed we will model VPN as a Service instance (VPNService).<br>
If we define new service, the service can support any kind of VPNs (L2, L3)<br>
What's we need to be discussed is attributes of Generalize VPN Service<br>
Models if we can have generic vpn service models.<br>
<br>
I added vpn map for slide 13 ( This may help this discussion)<br>
<a href="https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310" target="_blank">https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310</a><br>
<br>
This is current proposed attributes.<br>
<br>
1. id<br>
2. name<br>
3. tenant_id<br>
4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... )<br>
5. insertion_mode<br>
6. mode = l2 | l3 ?<br>
<br>
I believe there is no need to discussion about 1-4.<br>
5 is needed to use service insertion.<br>
( Prevent routed service insertion of which didn't support it)<br>
<br>
6. Mode<br>
I'm not sure how to use this attribute, so I'm very appreciate if<br>
someone would add<br>
the motivation on the slide<br>
<br>
Thanks<br>
Nachi<br>
<br>
2013/4/17 Yi Yang <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>>:<br>
> While quantum VPN can serve as either client or server or both, there are<br>
> big difference on requirements -- for example, a SSL VPN server needs to<br>
> have an address pool, which is not required for clients.<br>
><br>
> IMO, we need to first differentiate these use cases (server vs. client)<br>
> before we decide what state fields should be covered.<br>
><br>
> Yi<br>
><br>
><br>
> On 4/17/13 9:58 AM, Sachin Thakkar wrote:<br>
><br>
> I definitely agree with point (1) from Yi below. There are so many flavors<br>
> and intricacies to VPNs that it would be to our advantage to decouple as<br>
> much as possible.<br>
><br>
> For (2), my understanding is that the quantum VPN could be either. Is your<br>
> comment to add this explicit role in addition to the state fields?<br>
><br>
> Sachin<br>
><br>
> ________________________________<br>
> From: "Yi Yang" <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
> To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Wednesday, April 17, 2013 12:42:35 AM<br>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's<br>
> discussion<br>
><br>
> A couple of quick comments:<br>
><br>
> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,<br>
> as the former adopts a server-client model while the latter doesn't.<br>
><br>
> 2. One thing missed in these use cases, except in use case 3, is the<br>
> "role" -- does the quantum VPN act as a server or a client?<br>
><br>
> Yi<br>
><br>
><br>
><br>
> On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
>> Hi folks<br>
>><br>
>> Thank you for joining today's discussion.<br>
>> Based on today's discussion, we updated the slide.<br>
>><br>
>><br>
>> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135</a><br>
>><br>
>> Changes<br>
>> - Simplify use case<br>
>> removed any router references because it deals with implementation<br>
>> - Simplify Generic VPNService model<br>
>> removed any router references because it deals with service insertion<br>
>> - Update attributes of generic VPN Service<br>
>> Layer2 or Layer3 mode etc<br>
>><br>
>> Tommorows' discussion is<br>
>> 5:20 at OpenStack Networking room<br>
>><br>
>> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g</a><br>
>><br>
>> Thanks!<br>
>> Nachi<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Wed, 17 Apr 2013 21:37:28 +0000<br>
From: "Tripp, Travis S" <<a href="mailto:travis.tripp@hp.com">travis.tripp@hp.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Heat/DSL2<br>
Message-ID:<br>
<<a href="mailto:AD38C991545E8641B21449D96872D72E36BC6512@G9W0343.americas.hpqcorp.net">AD38C991545E8641B21449D96872D72E36BC6512@G9W0343.americas.hpqcorp.net</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Alex,<br>
<br>
When are the lightning talks?<br>
<br>
Travis<br>
<br>
-----Original Message-----<br>
From: Alex Heneveld [mailto:<a href="mailto:alex.heneveld@cloudsoftcorp.com">alex.heneveld@cloudsoftcorp.com</a>]<br>
Sent: Wednesday, April 17, 2013 12:56 PM<br>
To: OpenStack Development Mailing List<br>
Subject: [openstack-dev] Heat/DSL2<br>
<br>
<br>
I've been working through the Heat/DSL [1] idea, trying to whittle it down to an even simpler model, suitable as an abstraction atop CloudFormation as well as TOSCA and CAMP. And like [1] trying to make it easy for mortals to read and write.<br>
<br>
The current state is at Heat/DSL2 [2], with a rough python parser implementation (not connected to Heat yet) at [3].<br>
<br>
I'll be around today and tomorrow so if anyone would like to discuss F2F or on IRC (alexheneveld) please shout.<br>
<br>
Also note there are some related lightning talks starting soon and an unconference tomorrow at 2.20pm.<br>
<br>
Best<br>
Alex<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Heat/DSL" target="_blank">https://wiki.openstack.org/wiki/Heat/DSL</a><br>
[2] <a href="https://wiki.openstack.org/wiki/Heat/DSL2" target="_blank">https://wiki.openstack.org/wiki/Heat/DSL2</a><br>
[3] <a href="https://github.com/sjcorbett/heat-camp-yaml" target="_blank">https://github.com/sjcorbett/heat-camp-yaml</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Wed, 17 Apr 2013 14:47:43 -0700<br>
From: Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:516F187F.8060309@redhat.com">516F187F.8060309@redhat.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
Thanks Adrian!<br>
<br>
We should probably make it clear for those who can't be at Summit that<br>
this is not intended to be a record of the design summit discussions.<br>
I'd describe this as a snapshot of Adrian's evolving vision for Heat,<br>
taken after the design summit sessions. In particular, I think it<br>
reflects a couple of misconceptions about the current architecture of<br>
Heat, and it also contains some stuff that hasn't been discussed at all<br>
at Summit (e.g. the CEP part... btw my initial reaction to this is that<br>
it should probably talk to Ceilometer rather than the Autoscaling service).<br>
<br>
That said, there certainly *is* consensus that we want to evolve Heat<br>
toward being able to orchestrate whole applications rather than just<br>
services. We'll be doing further work throughout the week and<br>
subsequently on the mailing list to refine some of these architectural<br>
ideas, and we're looking forward to working with Adrian and his team at<br>
Rackspace to make it happen :)<br>
<br>
cheers,<br>
Zane.<br>
<br>
On 16/04/13 01:56, Adrian Otto wrote:<br>
> Heaters,<br>
><br>
> I attended the various sessions at the Design Summit today in Portland, and assembled as many of the ideas for future planning as I could. For the benefit of those who are not attending, or who were not in these sessions, I created this Wiki page to express what I think is an early consensus on where we could take things. Let's tweak this if it's not a good direction.<br>
><br>
> <a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
><br>
> Keith will be doing an Unconference session on the Workflow Service idea? I believe on Wednesday afternoon.<br>
><br>
> Thanks,<br>
><br>
> Adrian<br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Wed, 17 Apr 2013 14:53:48 -0700<br>
From: Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:516F19EC.8040201@redhat.com">516F19EC.8040201@redhat.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 16/04/13 09:05, Thomas Spatzier wrote:<br>
> Hi Adrian,<br>
><br>
> Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>> wrote on 16.04.2013 17:24:56:<br>
>> From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
>> To: OpenStack Development Mailing List<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
>> Date: 16.04.2013 17:26<br>
>> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
>><br>
>> Thanks Thomas. Good point.<br>
>><br>
>> In that case, wwe could just consider the one within the blue area<br>
>> to have the label "Parser" and that should clarify matters. I'm<br>
>> happy to make tweaks to clarify it.<br>
><br>
> Maybe we can also come up with a better term than "parser". Would be<br>
> interested what the Heat core team thinks.<br>
<br>
For historical reasons, "parser" is the name of the module that<br>
essentially runs the Heat orchestration engine. It's a terrible name<br>
that doesn't really reflect what it actually does, so I'm definitely in<br>
favour of changing it.<br>
<br>
This diagram is also showing it in the wrong place, so we have some more<br>
work to do to figure out some better terminology and get everyone on the<br>
same page.<br>
<br>
cheers,<br>
Zane.<br>
<br>
><br>
> Regards,<br>
> Thomas<br>
><br>
>><br>
>> Adrian<br>
>><br>
>><br>
>> -----Original message-----<br>
>> From: Thomas Spatzier <<a href="mailto:thomas.spatzier@de.ibm.com">thomas.spatzier@de.ibm.com</a>><br>
>> To: OpenStack Development Mailing List<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Sent: Tue, Apr 16, 2013 14:22:07 GMT+00:00<br>
>> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
><br>
>> Hi Adrian,<br>
>><br>
>> thanks for taking writing this up to capture yesterday's discussions.<br>
>> I don't fully understand what the difference or overlap of the Model<br>
>> Interpreter inside the main blue box and the Model Interpreter in the<br>
> green<br>
>> box is. My understanding was that a Model Interpreter would be something<br>
>> that translates an external format (such as CFN, TOSCA, whatever) to the<br>
>> core Heat DSL. And then there would be one component which looks at the<br>
>> common DSL model to derive the deployment plan (I think somebody said<br>
> this<br>
>> is what the "parser" does today).<br>
>> I think having to partly re-implement the interpreter (in the sense of<br>
>> compiling a concrete deployment plan directly) for various external<br>
> formats<br>
>> could be complicated.<br>
>><br>
>> Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>> wrote on 16.04.2013 10:56:23:<br>
>><br>
>>> From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
>>> To: OpenStack Development Mailing List<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
>>> Date: 16.04.2013 10:57<br>
>>> Subject: [openstack-dev] [Heat] Future Vision for Heat<br>
>>><br>
>>> Heaters,<br>
>>><br>
>>> I attended the various sessions at the Design Summit today in<br>
>>> Portland, and assembled as many of the ideas for future planning as<br>
>>> I could. For the benefit of those who are not attending, or who<br>
>>> were not in these sessions, I created this Wiki page to express what<br>
>>> I think is an early consensus on where we could take things. Let's<br>
>>> tweak this if it's not a good direction.<br>
>>><br>
>>> <a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
>>><br>
>>> Keith will be doing an Unconference session on the Workflow Service<br>
>>> idea? I believe on Wednesday afternoon.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Adrian<br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Wed, 17 Apr 2013 15:13:55 -0700<br>
From: Duncan Johnston Watt <<a href="mailto:duncan.johnstonwatt@cloudsoftcorp.com">duncan.johnstonwatt@cloudsoftcorp.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Heat/DSL2<br>
Message-ID:<br>
<CABoR60Ljx6yTkdAsEzaJPEkpf8rb4wqwn-2FM-uY=<a href="mailto:y%2B4w8zGQQ@mail.gmail.com">y+4w8zGQQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Travis<br>
<br>
Hi. The lightning talks happened over lunchtime today.<br>
<br>
However there is an unconference session led by Alex covering this material<br>
at 2.20PM Thursday in A104.<br>
<br>
Because there was a glitch with the AV during one of the lightning talks<br>
(Adrian Otto/Anish Karmarker's talk on OASIS CAMP) this will be repeated at<br>
the start of the unconference session.<br>
<br>
Best<br>
<br>
Duncan<br>
<br>
On 17 April 2013 14:37, Tripp, Travis S <<a href="mailto:travis.tripp@hp.com">travis.tripp@hp.com</a>> wrote:<br>
<br>
> Alex,<br>
><br>
> When are the lightning talks?<br>
><br>
> Travis<br>
><br>
> -----Original Message-----<br>
> From: Alex Heneveld [mailto:<a href="mailto:alex.heneveld@cloudsoftcorp.com">alex.heneveld@cloudsoftcorp.com</a>]<br>
> Sent: Wednesday, April 17, 2013 12:56 PM<br>
> To: OpenStack Development Mailing List<br>
> Subject: [openstack-dev] Heat/DSL2<br>
><br>
><br>
> I've been working through the Heat/DSL [1] idea, trying to whittle it down<br>
> to an even simpler model, suitable as an abstraction atop CloudFormation as<br>
> well as TOSCA and CAMP. And like [1] trying to make it easy for mortals to<br>
> read and write.<br>
><br>
> The current state is at Heat/DSL2 [2], with a rough python parser<br>
> implementation (not connected to Heat yet) at [3].<br>
><br>
> I'll be around today and tomorrow so if anyone would like to discuss F2F<br>
> or on IRC (alexheneveld) please shout.<br>
><br>
> Also note there are some related lightning talks starting soon and an<br>
> unconference tomorrow at 2.20pm.<br>
><br>
> Best<br>
> Alex<br>
><br>
> [1] <a href="https://wiki.openstack.org/wiki/Heat/DSL" target="_blank">https://wiki.openstack.org/wiki/Heat/DSL</a><br>
> [2] <a href="https://wiki.openstack.org/wiki/Heat/DSL2" target="_blank">https://wiki.openstack.org/wiki/Heat/DSL2</a><br>
> [3] <a href="https://github.com/sjcorbett/heat-camp-yaml" target="_blank">https://github.com/sjcorbett/heat-camp-yaml</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Duncan Johnston-Watt<br>
CEO | Cloudsoft Corporation<br>
<br>
Twitter | @duncanjw<br>
Mobile | +44 777 190 2653<br>
Skype | duncan_johnstonwatt<br>
Linkedin | <a href="http://www.linkedin.com/in/duncanjohnstonwatt" target="_blank">www.linkedin.com/in/duncanjohnstonwatt</a><br>
<br>
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.<br>
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP<br>
<br>
This e-mail message is confidential and for use by the addressee only. If<br>
the message is received by anyone other than the addressee, please return<br>
the message to the sender by replying to it and then delete the message<br>
from your computer. Internet e-mails are not necessarily secure. Cloudsoft<br>
Corporation Limited does not accept responsibility for changes made to this<br>
message after it was sent.<br>
<br>
Whilst all reasonable care has been taken to avoid the transmission of<br>
viruses, it is the responsibility of the recipient to ensure that the<br>
onward transmission, opening or use of this message and any attachments<br>
will not adversely affect its systems or data. No responsibility is<br>
accepted by Cloudsoft Corporation Limited in this regard and the recipient<br>
should carry out such virus and other checks as it considers appropriate.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/a526a13a/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/a526a13a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Wed, 17 Apr 2013 23:10:18 +0000<br>
From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:2DDA2627-6224-441D-BEDD-784000AC3D1E@rackspace.com">2DDA2627-6224-441D-BEDD-784000AC3D1E@rackspace.com</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
Zane,<br>
<br>
On Apr 17, 2013, at 2:47 PM, Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>><br>
wrote:<br>
<br>
> Thanks Adrian!<br>
><br>
> We should probably make it clear for those who can't be at Summit that this is not intended to be a record of the design summit discussions. I'd describe this as a snapshot of Adrian's evolving vision for Heat, taken after the design summit sessions.<br>
<br>
Good suggestion. I'll tune the text at the top of that wiki post to reflect that. I'd like to continue tweaking on this to give us something to aim toward. We absolutely will iterate toward it, and will start with something less ambitious. As we zero in to that, I'm happy to document that direction as well.<br>
<br>
> In particular, I think it reflects a couple of misconceptions about the current architecture of Heat, and it also contains some stuff that hasn't been discussed at all at Summit (e.g. the CEP part... btw my initial reaction to this is that it should probably talk to Ceilometer rather than the Autoscaling service).<br>
<br>
Yes, is that something we can talk about today or tomorrow while we are still together?<br>
<br>
> That said, there certainly *is* consensus that we want to evolve Heat toward being able to orchestrate whole applications rather than just services. We'll be doing further work throughout the week and subsequently on the mailing list to refine some of these architectural ideas, and we're looking forward to working with Adrian and his team at Rackspace to make it happen :)<br>
<br>
Thanks. I'd like to complement the whole Heat team. The collaborative spirit I have experienced while working with you has been terrific.<br>
<br>
Cheers,<br>
<br>
Adrian<br>
<br>
> cheers,<br>
> Zane.<br>
><br>
> On 16/04/13 01:56, Adrian Otto wrote:<br>
>> Heaters,<br>
>><br>
>> I attended the various sessions at the Design Summit today in Portland, and assembled as many of the ideas for future planning as I could. For the benefit of those who are not attending, or who were not in these sessions, I created this Wiki page to express what I think is an early consensus on where we could take things. Let's tweak this if it's not a good direction.<br>
>><br>
>> <a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
>><br>
>> Keith will be doing an Unconference session on the Workflow Service idea? I believe on Wednesday afternoon.<br>
>><br>
>> Thanks,<br>
>><br>
>> Adrian<br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Wed, 17 Apr 2013 16:14:52 -0700<br>
From: Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID:<br>
<<a href="mailto:CABJepwjnXRTAy7_urYSnwZNuzVW79qToWRp8YeVTLFUrZh-dxQ@mail.gmail.com">CABJepwjnXRTAy7_urYSnwZNuzVW79qToWRp8YeVTLFUrZh-dxQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi Kaiwei<br>
<br>
Thank you for your comment.<br>
It depends on the each VPNService sub class.<br>
Some L2VPNService may have network_id and association with out-of-path<br>
insertion mode.<br>
(This part is also not implemented)<br>
For some L3 VPN may support routed insertion mode, and the subclass of<br>
VPNService will have router_id (or port_id).<br>
<br>
The use of insertion mode is input value checking when we insert it.<br>
<br>
Thanks<br>
Nachi<br>
<br>
<br>
<br>
2013/4/17 <<a href="mailto:fank@vmware.com">fank@vmware.com</a>>:<br>
> Hi Nachi,<br>
><br>
> I'm not sure how "insertion_mode" could be any useful for plugins if it only indicate the mode as routed/out-of-path/floating insertion.<br>
><br>
> For example, we need to associated it with a router if it is routed insertion (and we have an extension for associating a service with a router id: <a href="https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion" target="_blank">https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion</a>).<br>
><br>
> What we need for out-of-path insertion and floating insertion? A network/subnet id?<br>
><br>
> -Kaiwei<br>
><br>
> ----- Original Message -----<br>
> From: "Nachi Ueno" <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
> To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Wednesday, April 17, 2013 11:42:38 AM<br>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's discussion<br>
><br>
> Hi folks<br>
><br>
> May be, there are many ways to categorize use cases.<br>
><br>
> We agreed we will model VPN as a Service instance (VPNService).<br>
> If we define new service, the service can support any kind of VPNs (L2, L3)<br>
> What's we need to be discussed is attributes of Generalize VPN Service<br>
> Models if we can have generic vpn service models.<br>
><br>
> I added vpn map for slide 13 ( This may help this discussion)<br>
> <a href="https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310" target="_blank">https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310</a><br>
><br>
> This is current proposed attributes.<br>
><br>
> 1. id<br>
> 2. name<br>
> 3. tenant_id<br>
> 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... )<br>
> 5. insertion_mode<br>
> 6. mode = l2 | l3 ?<br>
><br>
> I believe there is no need to discussion about 1-4.<br>
> 5 is needed to use service insertion.<br>
> ( Prevent routed service insertion of which didn't support it)<br>
><br>
> 6. Mode<br>
> I'm not sure how to use this attribute, so I'm very appreciate if<br>
> someone would add<br>
> the motivation on the slide<br>
><br>
> Thanks<br>
> Nachi<br>
><br>
> 2013/4/17 Yi Yang <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>>:<br>
>> While quantum VPN can serve as either client or server or both, there are<br>
>> big difference on requirements -- for example, a SSL VPN server needs to<br>
>> have an address pool, which is not required for clients.<br>
>><br>
>> IMO, we need to first differentiate these use cases (server vs. client)<br>
>> before we decide what state fields should be covered.<br>
>><br>
>> Yi<br>
>><br>
>><br>
>> On 4/17/13 9:58 AM, Sachin Thakkar wrote:<br>
>><br>
>> I definitely agree with point (1) from Yi below. There are so many flavors<br>
>> and intricacies to VPNs that it would be to our advantage to decouple as<br>
>> much as possible.<br>
>><br>
>> For (2), my understanding is that the quantum VPN could be either. Is your<br>
>> comment to add this explicit role in addition to the state fields?<br>
>><br>
>> Sachin<br>
>><br>
>> ________________________________<br>
>> From: "Yi Yang" <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Sent: Wednesday, April 17, 2013 12:42:35 AM<br>
>> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's<br>
>> discussion<br>
>><br>
>> A couple of quick comments:<br>
>><br>
>> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,<br>
>> as the former adopts a server-client model while the latter doesn't.<br>
>><br>
>> 2. One thing missed in these use cases, except in use case 3, is the<br>
>> "role" -- does the quantum VPN act as a server or a client?<br>
>><br>
>> Yi<br>
>><br>
>><br>
>><br>
>> On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
>>> Hi folks<br>
>>><br>
>>> Thank you for joining today's discussion.<br>
>>> Based on today's discussion, we updated the slide.<br>
>>><br>
>>><br>
>>> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135</a><br>
>>><br>
>>> Changes<br>
>>> - Simplify use case<br>
>>> removed any router references because it deals with implementation<br>
>>> - Simplify Generic VPNService model<br>
>>> removed any router references because it deals with service insertion<br>
>>> - Update attributes of generic VPN Service<br>
>>> Layer2 or Layer3 mode etc<br>
>>><br>
>>> Tommorows' discussion is<br>
>>> 5:20 at OpenStack Networking room<br>
>>><br>
>>> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g</a><br>
>>><br>
>>> Thanks!<br>
>>> Nachi<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Wed, 17 Apr 2013 23:40:34 +0000<br>
From: Alan Kavanagh <<a href="mailto:alan.kavanagh@ericsson.com">alan.kavanagh@ericsson.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID:<br>
<<a href="mailto:C977B257ADF8814C8EB4FB66BB9D0C2E0AB758@eusaamb109.ericsson.se">C977B257ADF8814C8EB4FB66BB9D0C2E0AB758@eusaamb109.ericsson.se</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi Nachi<br>
<br>
I think we have some big fundamental issues here. You may not require an insertion mode for some L2VPN types, depending on the service you want the L2VPN to offer. Yi also brings a really good point that I feel we are not reflecting and showing on routing, we should decouple routing completely from the VPN Service. Also you have two Router types, one to advertise the VPN Tunnel End Point Upstream for reachability and one if "you want dynamic routing" for a tenant network (for example) from one network site to another through the VPN Tunnel.<br>
<br>
I feel we are mixing a lot of these fundamental concepts and topics.<br>
<br>
Alan<br>
<br>
-----Original Message-----<br>
From: Nachi Ueno [mailto:<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>]<br>
Sent: April-17-13 7:15 PM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's discussion<br>
<br>
Hi Kaiwei<br>
<br>
Thank you for your comment.<br>
It depends on the each VPNService sub class.<br>
Some L2VPNService may have network_id and association with out-of-path insertion mode.<br>
(This part is also not implemented)<br>
For some L3 VPN may support routed insertion mode, and the subclass of VPNService will have router_id (or port_id).<br>
<br>
The use of insertion mode is input value checking when we insert it.<br>
<br>
Thanks<br>
Nachi<br>
<br>
<br>
<br>
2013/4/17 <<a href="mailto:fank@vmware.com">fank@vmware.com</a>>:<br>
> Hi Nachi,<br>
><br>
> I'm not sure how "insertion_mode" could be any useful for plugins if it only indicate the mode as routed/out-of-path/floating insertion.<br>
><br>
> For example, we need to associated it with a router if it is routed insertion (and we have an extension for associating a service with a router id: <a href="https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion" target="_blank">https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion</a>).<br>
><br>
> What we need for out-of-path insertion and floating insertion? A network/subnet id?<br>
><br>
> -Kaiwei<br>
><br>
> ----- Original Message -----<br>
> From: "Nachi Ueno" <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
> To: "OpenStack Development Mailing List"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Wednesday, April 17, 2013 11:42:38 AM<br>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
> today's discussion<br>
><br>
> Hi folks<br>
><br>
> May be, there are many ways to categorize use cases.<br>
><br>
> We agreed we will model VPN as a Service instance (VPNService).<br>
> If we define new service, the service can support any kind of VPNs<br>
> (L2, L3) What's we need to be discussed is attributes of Generalize<br>
> VPN Service Models if we can have generic vpn service models.<br>
><br>
> I added vpn map for slide 13 ( This may help this discussion)<br>
> <a href="https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c4" target="_blank">https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c4</a><br>
> 7iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310<br>
><br>
> This is current proposed attributes.<br>
><br>
> 1. id<br>
> 2. name<br>
> 3. tenant_id<br>
> 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... ) 5. insertion_mode<br>
> 6. mode = l2 | l3 ?<br>
><br>
> I believe there is no need to discussion about 1-4.<br>
> 5 is needed to use service insertion.<br>
> ( Prevent routed service insertion of which didn't support it)<br>
><br>
> 6. Mode<br>
> I'm not sure how to use this attribute, so I'm very appreciate if<br>
> someone would add the motivation on the slide<br>
><br>
> Thanks<br>
> Nachi<br>
><br>
> 2013/4/17 Yi Yang <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>>:<br>
>> While quantum VPN can serve as either client or server or both, there<br>
>> are big difference on requirements -- for example, a SSL VPN server<br>
>> needs to have an address pool, which is not required for clients.<br>
>><br>
>> IMO, we need to first differentiate these use cases (server vs.<br>
>> client) before we decide what state fields should be covered.<br>
>><br>
>> Yi<br>
>><br>
>><br>
>> On 4/17/13 9:58 AM, Sachin Thakkar wrote:<br>
>><br>
>> I definitely agree with point (1) from Yi below. There are so many<br>
>> flavors and intricacies to VPNs that it would be to our advantage to<br>
>> decouple as much as possible.<br>
>><br>
>> For (2), my understanding is that the quantum VPN could be either. Is<br>
>> your comment to add this explicit role in addition to the state fields?<br>
>><br>
>> Sachin<br>
>><br>
>> ________________________________<br>
>> From: "Yi Yang" <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Sent: Wednesday, April 17, 2013 12:42:35 AM<br>
>> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
>> today's discussion<br>
>><br>
>> A couple of quick comments:<br>
>><br>
>> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN<br>
>> cases, as the former adopts a server-client model while the latter doesn't.<br>
>><br>
>> 2. One thing missed in these use cases, except in use case 3, is the<br>
>> "role" -- does the quantum VPN act as a server or a client?<br>
>><br>
>> Yi<br>
>><br>
>><br>
>><br>
>> On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
>>> Hi folks<br>
>>><br>
>>> Thank you for joining today's discussion.<br>
>>> Based on today's discussion, we updated the slide.<br>
>>><br>
>>><br>
>>> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZ" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZ</a><br>
>>> n7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135<br>
>>><br>
>>> Changes<br>
>>> - Simplify use case<br>
>>> removed any router references because it deals with<br>
>>> implementation<br>
>>> - Simplify Generic VPNService model<br>
>>> removed any router references because it deals with service<br>
>>> insertion<br>
>>> - Update attributes of generic VPN Service<br>
>>> Layer2 or Layer3 mode etc<br>
>>><br>
>>> Tommorows' discussion is<br>
>>> 5:20 at OpenStack Networking room<br>
>>><br>
>>> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335</a><br>
>>> acc8a78ff61c#.UW3p1SvC82g<br>
>>><br>
>>> Thanks!<br>
>>> Nachi<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Wed, 17 Apr 2013 17:02:19 -0700<br>
From: Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
today's discussion<br>
Message-ID:<br>
<CABJepwi0DnmgpGy3FT3L=_K3i6utyuw9CU8_XML2FUAEfang=<a href="mailto:g@mail.gmail.com">g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi Alan<br>
<br>
It makes sence. so now, I'm +1 for removing insertion_mode.<br>
<br>
<br>
2013/4/17 Alan Kavanagh <<a href="mailto:alan.kavanagh@ericsson.com">alan.kavanagh@ericsson.com</a>>:<br>
> Hi Nachi<br>
><br>
> I think we have some big fundamental issues here. You may not require an insertion mode for some L2VPN types, depending on the service you want the L2VPN to offer. Yi also brings a really good point that I feel we are not reflecting and showing on routing, we should decouple routing completely from the VPN Service. Also you have two Router types, one to advertise the VPN Tunnel End Point Upstream for reachability and one if "you want dynamic routing" for a tenant network (for example) from one network site to another through the VPN Tunnel.<br>
><br>
> I feel we are mixing a lot of these fundamental concepts and topics.<br>
><br>
> Alan<br>
><br>
> -----Original Message-----<br>
> From: Nachi Ueno [mailto:<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>]<br>
> Sent: April-17-13 7:15 PM<br>
> To: OpenStack Development Mailing List<br>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's discussion<br>
><br>
> Hi Kaiwei<br>
><br>
> Thank you for your comment.<br>
> It depends on the each VPNService sub class.<br>
> Some L2VPNService may have network_id and association with out-of-path insertion mode.<br>
> (This part is also not implemented)<br>
> For some L3 VPN may support routed insertion mode, and the subclass of VPNService will have router_id (or port_id).<br>
><br>
> The use of insertion mode is input value checking when we insert it.<br>
><br>
> Thanks<br>
> Nachi<br>
><br>
><br>
><br>
> 2013/4/17 <<a href="mailto:fank@vmware.com">fank@vmware.com</a>>:<br>
>> Hi Nachi,<br>
>><br>
>> I'm not sure how "insertion_mode" could be any useful for plugins if it only indicate the mode as routed/out-of-path/floating insertion.<br>
>><br>
>> For example, we need to associated it with a router if it is routed insertion (and we have an extension for associating a service with a router id: <a href="https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion" target="_blank">https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion</a>).<br>
>><br>
>> What we need for out-of-path insertion and floating insertion? A network/subnet id?<br>
>><br>
>> -Kaiwei<br>
>><br>
>> ----- Original Message -----<br>
>> From: "Nachi Ueno" <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
>> To: "OpenStack Development Mailing List"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Sent: Wednesday, April 17, 2013 11:42:38 AM<br>
>> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
>> today's discussion<br>
>><br>
>> Hi folks<br>
>><br>
>> May be, there are many ways to categorize use cases.<br>
>><br>
>> We agreed we will model VPN as a Service instance (VPNService).<br>
>> If we define new service, the service can support any kind of VPNs<br>
>> (L2, L3) What's we need to be discussed is attributes of Generalize<br>
>> VPN Service Models if we can have generic vpn service models.<br>
>><br>
>> I added vpn map for slide 13 ( This may help this discussion)<br>
>> <a href="https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c4" target="_blank">https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c4</a><br>
>> 7iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310<br>
>><br>
>> This is current proposed attributes.<br>
>><br>
>> 1. id<br>
>> 2. name<br>
>> 3. tenant_id<br>
>> 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... ) 5. insertion_mode<br>
>> 6. mode = l2 | l3 ?<br>
>><br>
>> I believe there is no need to discussion about 1-4.<br>
>> 5 is needed to use service insertion.<br>
>> ( Prevent routed service insertion of which didn't support it)<br>
>><br>
>> 6. Mode<br>
>> I'm not sure how to use this attribute, so I'm very appreciate if<br>
>> someone would add the motivation on the slide<br>
>><br>
>> Thanks<br>
>> Nachi<br>
>><br>
>> 2013/4/17 Yi Yang <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>>:<br>
>>> While quantum VPN can serve as either client or server or both, there<br>
>>> are big difference on requirements -- for example, a SSL VPN server<br>
>>> needs to have an address pool, which is not required for clients.<br>
>>><br>
>>> IMO, we need to first differentiate these use cases (server vs.<br>
>>> client) before we decide what state fields should be covered.<br>
>>><br>
>>> Yi<br>
>>><br>
>>><br>
>>> On 4/17/13 9:58 AM, Sachin Thakkar wrote:<br>
>>><br>
>>> I definitely agree with point (1) from Yi below. There are so many<br>
>>> flavors and intricacies to VPNs that it would be to our advantage to<br>
>>> decouple as much as possible.<br>
>>><br>
>>> For (2), my understanding is that the quantum VPN could be either. Is<br>
>>> your comment to add this explicit role in addition to the state fields?<br>
>>><br>
>>> Sachin<br>
>>><br>
>>> ________________________________<br>
>>> From: "Yi Yang" <<a href="mailto:yyos1999@gmail.com">yyos1999@gmail.com</a>><br>
>>> To: "OpenStack Development Mailing List"<br>
>>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>>> Sent: Wednesday, April 17, 2013 12:42:35 AM<br>
>>> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from<br>
>>> today's discussion<br>
>>><br>
>>> A couple of quick comments:<br>
>>><br>
>>> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN<br>
>>> cases, as the former adopts a server-client model while the latter doesn't.<br>
>>><br>
>>> 2. One thing missed in these use cases, except in use case 3, is the<br>
>>> "role" -- does the quantum VPN act as a server or a client?<br>
>>><br>
>>> Yi<br>
>>><br>
>>><br>
>>><br>
>>> On 4/16/13 8:16 PM, Nachi Ueno wrote:<br>
>>>> Hi folks<br>
>>>><br>
>>>> Thank you for joining today's discussion.<br>
>>>> Based on today's discussion, we updated the slide.<br>
>>>><br>
>>>><br>
>>>> <a href="https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZ" target="_blank">https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZ</a><br>
>>>> n7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135<br>
>>>><br>
>>>> Changes<br>
>>>> - Simplify use case<br>
>>>> removed any router references because it deals with<br>
>>>> implementation<br>
>>>> - Simplify Generic VPNService model<br>
>>>> removed any router references because it deals with service<br>
>>>> insertion<br>
>>>> - Update attributes of generic VPN Service<br>
>>>> Layer2 or Layer3 mode etc<br>
>>>><br>
>>>> Tommorows' discussion is<br>
>>>> 5:20 at OpenStack Networking room<br>
>>>><br>
>>>> <a href="http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335" target="_blank">http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335</a><br>
>>>> acc8a78ff61c#.UW3p1SvC82g<br>
>>>><br>
>>>> Thanks!<br>
>>>> Nachi<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Wed, 17 Apr 2013 17:16:31 -0700<br>
From: Roshan <<a href="mailto:roshanagr@gmail.com">roshanagr@gmail.com</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Workflow as a service: Convection<br>
Message-ID: <<a href="mailto:D8BE48D3-70FC-4912-ADFA-DF384AEE4730@gmail.com">D8BE48D3-70FC-4912-ADFA-DF384AEE4730@gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Here are the etherpad notes from today 's session on workflow. Feel free to add/ modify what I missed<br>
<br>
<a href="https://etherpad.openstack.org/Convection" target="_blank">https://etherpad.openstack.org/Convection</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/b5ecd1d8/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/b5ecd1d8/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Thu, 18 Apr 2013 04:02:29 +0300<br>
From: Avishay Traeger <<a href="mailto:AVISHAY@il.ibm.com">AVISHAY@il.ibm.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] AUTO: Avishay Traeger is out of the office<br>
(returning 05/12/2013)<br>
Message-ID:<br>
<<a href="mailto:OF776DC00D.EB3946DF-ONC2257B51.0005B8AE-C2257B51.0005B8AE@il.ibm.com">OF776DC00D.EB3946DF-ONC2257B51.0005B8AE-C2257B51.0005B8AE@il.ibm.com</a>><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
<br>
I am out of the office until 05/12/2013.<br>
<br>
For technical issues regarding the Storwize/SVC Cinder driver, please<br>
contact: Jie Ping Wu <<a href="mailto:wujp@cn.ibm.com">wujp@cn.ibm.com</a>>, Li Min Liu <<a href="mailto:liminliu@cn.ibm.com">liminliu@cn.ibm.com</a>>,<br>
Ronen Kat <<a href="mailto:ronenkat@il.ibm.com">ronenkat@il.ibm.com</a>><br>
For all other issue, please contact my manager, Dalit Naor<br>
<<a href="mailto:dalit@il.ibm.com">dalit@il.ibm.com</a>><br>
<br>
<br>
Note: This is an automated response to your message "Re: [openstack-dev]<br>
Heat/DSL2" sent on 18/04/2013 0:37:28.<br>
<br>
This is the only notification you will receive while this person is away.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Thu, 18 Apr 2013 10:36:00 +0800<br>
From: Shake Chen <<a href="mailto:shake.chen@gmail.com">shake.chen@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] vms come up on a different bridge..<br>
Message-ID:<br>
<CAO__-NbXdvhV20L_0vamg_aGpECf06ypdY-j=<a href="mailto:5a6zhq27a1cAg@mail.gmail.com">5a6zhq27a1cAg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Prashanth<br>
<br>
whether can share your netwrok interface setting /etc/netwrok/interface.<br>
<br>
I am not sure the setting .<br>
<br>
physical_interface_mappings = physnet2:eth2<br>
<br>
<br>
what I need to setting in eth2?<br>
<br>
<br>
On Wed, Apr 17, 2013 at 11:38 PM, Prashanth Prahalad <<br>
<a href="mailto:prashanth.prahal@gmail.com">prashanth.prahal@gmail.com</a>> wrote:<br>
<br>
> Hi Folks,<br>
><br>
> I'm setting up quantum with linux bridge. I might have configured this<br>
> incorrectly and looking for some help on what could be going on.<br>
><br>
> This is my quantum.conf and linuxbridge_conf.ini - which tries to setup<br>
> the linux bridge over eth2.<br>
><br>
> [DEFAULT]<br>
> auth_strategy = keystone<br>
> allow_overlapping_ips = True<br>
> policy_file = /etc/quantum/policy.json<br>
> debug = True<br>
> verbose = True<br>
> service_plugins =<br>
> quantum.plugins.services.agent_loadbalancer.plugin.LoadBalancerPlugin<br>
> core_plugin =<br>
> quantum.plugins.linuxbridge.lb_quantum_plugin.LinuxBridgePluginV2<br>
> rabbit_password = openstack<br>
> rabbit_host = localhost<br>
> rpc_backend = quantum.openstack.common.rpc.impl_kombu<br>
> state_path = /opt/stack/data/quantum<br>
> debug = True<br>
> verbose = True<br>
> lock_path = $state_path/lock<br>
> log_file = quantum.log<br>
> log_dir = /var/log/quantum<br>
> bind_host = 0.0.0.0<br>
> bind_port = 9696<br>
> <......><br>
><br>
> linuxbridge_conf.ini<br>
><br>
> [VLANS]<br>
> tenant_network_type = vlan<br>
> network_vlan_ranges = physnet2:1000:2999<br>
> [DATABASE]<br>
> sql_connection = mysql://root:openstack@localhost<br>
> /quantum_linux_bridge?charset=utf8<br>
> reconnect_interval = 2<br>
> [LINUX_BRIDGE]<br>
> physical_interface_mappings = physnet2:eth2<br>
> [AGENT]<br>
> root_helper = sudo /usr/local/bin/quantum-rootwrap<br>
> /etc/quantum/rootwrap.conf<br>
> polling_interval = 2<br>
> [SECURITYGROUP]<br>
> firewall_driver =<br>
> quantum.agent.linux.iptables_firewall.IptablesFirewallDriver<br>
><br>
> But when the VM is booted up, it comes up over brq3c2d19b3-fa instead of<br>
> br-eth2<br>
><br>
> bridge name bridge id STP enabled interfaces<br>
> br-eth2 8000.000cfc01f473 no eth2<br>
> brq057a0be8-e9 8000.96f0115f0c03 no<br>
> tapa0dcbf6a-73<br>
> brq34f87736-91 8000.32245b5d90b7 no<br>
> tap22c7ffb1-9f<br>
><br>
> tap874fecfb-ac<br>
> brq3c2d19b3-fa 8000.3a84ed127b7a no<br>
> tapadbf1b11-e9<br>
><br>
> tapc6c54b78-87<br>
><br>
> tapcf424b48-54<br>
><br>
> tapdb58671d-bd<br>
><br>
> tapdb661e2b-ff<br>
><br>
> Here's a list of commands :<br>
><br>
> quantum net-create sharednet1 --shared --provider:network_type=flat -<br>
> provider:physical_network=physnet2<br>
> quantum subnet-create sharednet1 <a href="http://30.0.0.0/24" target="_blank">30.0.0.0/24</a><br>
><br>
><br>
> +--------------------------------------+------------+------------------------------------------------------+<br>
> | id | name | subnets<br>
> |<br>
><br>
> +--------------------------------------+------------+------------------------------------------------------+<br>
> | 057a0be8-e9f9-4e23-a97b-08d2bdb67ad2 | public |<br>
> 92b32336-76d2-4fa3-a5eb-e1a4b76c648c <a href="http://172.24.4.224/28" target="_blank">172.24.4.224/28</a> |<br>
> | 34f87736-91d6-4f00-ad11-fe39e76638ce | private |<br>
> f315bfd5-5f8a-4fa4-bca2-0814998cf8d5 <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> |<br>
> | 3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 | sharednet1 |<br>
> 4691c3ca-b769-4454-9997-1b4dd851d602 <a href="http://30.0.0.0/24" target="_blank">30.0.0.0/24</a> |<br>
><br>
> +--------------------------------------+------------+------------------------------------------------------+<br>
><br>
> nova boot --image cirros --flavor m1.tiny --nic<br>
> net-id=3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 --key-name test my_first_server<br>
><br>
> Anything I'm missing ?<br>
><br>
> Thanks !<br>
> Prashanth<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
<br>
<br>
--<br>
Shake Chen<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/bb6ebd36/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/bb6ebd36/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Wed, 17 Apr 2013 21:53:18 -0700<br>
From: Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Quantum] Quantum VPN discussion<br>
Message-ID:<br>
<CABJepwhOF7pLwJfuwk9=t=<a href="mailto:YD5ZCUSosrQi2hdZDAZuDk5b8CHw@mail.gmail.com">YD5ZCUSosrQi2hdZDAZuDk5b8CHw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
HI folks<br>
<br>
Thank you for your joining today's Quantum VPN discussion.<br>
<br>
- We will add more detailed usecases<br>
- remove insertion from GeneralVPNService<br>
- continue discussion for needs of mode (l2 or l3) attribute of<br>
GeneralVPNService<br>
-- The opinion for removing mode<br>
GeneralVPNService has type attribute, so type can also express l2 or l3.<br>
For example, l2.l2tp l3.bgpmpls kind of thing can be used.<br>
if there are no strong support for using mode, we will remote the attribute<br>
- At first, we will focus on nova-parity SSL-VPN support ( Swami or<br>
Sachin will work on this)<br>
Write ssl-vpn usecase<br>
Write API spec<br>
discuss it<br>
- milestone could be<br>
general model -> H1<br>
ssl-vpn -> H1/H2<br>
the others -> H2/H3<br>
<br>
Thanks!<br>
Nachi<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Thu, 18 Apr 2013 05:37:02 +0000<br>
From: Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:CD94D2C5.3A5A9%25harlowja@yahoo-inc.com">CD94D2C5.3A5A9%harlowja@yahoo-inc.com</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
I'd be very interested in having 'Scheduler & Workflow Service' part there<br>
be a library.<br>
<br>
Pretty much every application is a workflow in some way, and using said<br>
library in nova for the orc work there would be very neat.<br>
<br>
As long as it doesn't change the use-case that heat desires of course (or<br>
overload that use-case and make everything complex when it doesn't need to<br>
be)...<br>
<br>
It would be very neat to use those 2 services as a library, where I can<br>
submit arbitrary code to (the state transitions that nova does) and have<br>
it handle calling those states, coordinating, rolling back (or at least<br>
calling a method to rollback, since rollback is usually very specific to<br>
what has occurred). Basically submitting jobs, but not via a DSL/CEP (or<br>
the like), not via a model interpreter, but directly via code. Is there<br>
any documentation on how heat handles task resumption (if 1 engine fails,<br>
another should be able to continue the work), how are said engines made HA<br>
and reliable...<br>
<br>
Such a engine library would make sense as the core 'engine' for a lot of<br>
the openstack core projects imho.<br>
<br>
Thoughts?<br>
<br>
On 4/17/13 2:47 PM, "Zane Bitter" <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br>
<br>
>Thanks Adrian!<br>
><br>
>We should probably make it clear for those who can't be at Summit that<br>
>this is not intended to be a record of the design summit discussions.<br>
>I'd describe this as a snapshot of Adrian's evolving vision for Heat,<br>
>taken after the design summit sessions. In particular, I think it<br>
>reflects a couple of misconceptions about the current architecture of<br>
>Heat, and it also contains some stuff that hasn't been discussed at all<br>
>at Summit (e.g. the CEP part... btw my initial reaction to this is that<br>
>it should probably talk to Ceilometer rather than the Autoscaling<br>
>service).<br>
><br>
>That said, there certainly *is* consensus that we want to evolve Heat<br>
>toward being able to orchestrate whole applications rather than just<br>
>services. We'll be doing further work throughout the week and<br>
>subsequently on the mailing list to refine some of these architectural<br>
>ideas, and we're looking forward to working with Adrian and his team at<br>
>Rackspace to make it happen :)<br>
><br>
>cheers,<br>
>Zane.<br>
><br>
>On 16/04/13 01:56, Adrian Otto wrote:<br>
>> Heaters,<br>
>><br>
>> I attended the various sessions at the Design Summit today in Portland,<br>
>>and assembled as many of the ideas for future planning as I could. For<br>
>>the benefit of those who are not attending, or who were not in these<br>
>>sessions, I created this Wiki page to express what I think is an early<br>
>>consensus on where we could take things. Let's tweak this if it's not a<br>
>>good direction.<br>
>><br>
>> <a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
>><br>
>> Keith will be doing an Unconference session on the Workflow Service<br>
>>idea? I believe on Wednesday afternoon.<br>
>><br>
>> Thanks,<br>
>><br>
>> Adrian<br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Thu, 18 Apr 2013 06:48:57 +0000<br>
From: "Bhandaru, Malini K" <<a href="mailto:malini.k.bhandaru@intel.com">malini.k.bhandaru@intel.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] passwords in logs --security related<br>
Message-ID:<br>
<<a href="mailto:EE6FFF4F6C34C84C8C98DD2414EEA47E53C42372@ORSMSX154.amr.corp.intel.com">EE6FFF4F6C34C84C8C98DD2414EEA47E53C42372@ORSMSX154.amr.corp.intel.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hello All!<br>
<br>
David Geng is addressing a case of password logging in keystone. Do we handle any passwords in other openstack<br>
components and log them? Might they benefit from David moving his fix into Oslo as a log filter (a nice suggestion from Guang-yee).<br>
Please weigh in. If yes, what is expected the string pattern?<br>
<br>
<a href="https://review.openstack.org/#/c/26487/" target="_blank">https://review.openstack.org/#/c/26487/</a><br>
<br>
<br>
Regards<br>
Malini<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/33bcf398/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/33bcf398/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Thu, 18 Apr 2013 07:19:52 +0000<br>
From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:3FF04A18-D419-448B-A5D0-E2812C98F7F2@rackspace.com">3FF04A18-D419-448B-A5D0-E2812C98F7F2@rackspace.com</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
Joshua,<br>
<br>
On Apr 17, 2013, at 10:37 PM, Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>> wrote:<br>
<br>
> I'd be very interested in having 'Scheduler & Workflow Service' part there<br>
> be a library.<br>
><br>
> Pretty much every application is a workflow in some way, and using said<br>
> library in nova for the orc work there would be very neat.<br>
<br>
We had an unconference session today when we discussed this concept:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Convection" target="_blank">https://wiki.openstack.org/wiki/Convection</a><br>
<br>
The idea is that this could start as a library in Heat, and then be moved to Oslo upon achievement of a reasonable level of maturity.<br>
<br>
> As long as it doesn't change the use-case that heat desires of course (or<br>
> overload that use-case and make everything complex when it doesn't need to<br>
> be)?<br>
<br>
It should actually simplify Heat.<br>
<br>
> It would be very neat to use those 2 services as a library, where I can<br>
> submit arbitrary code to (the state transitions that nova does) and have<br>
> it handle calling those states, coordinating, rolling back (or at least<br>
> calling a method to rollback, since rollback is usually very specific to<br>
> what has occurred). Basically submitting jobs, but not via a DSL/CEP (or<br>
> the like), not via a model interpreter, but directly via code. Is there<br>
> any documentation on how heat handles task resumption (if 1 engine fails,<br>
> another should be able to continue the work), how are said engines made HA<br>
> and reliable?<br>
<br>
At the very least, we should expect a solution that will allow you to submit a callback in some form (possibly a web hook, or a function) so that you can act upon state transitions in the workflow. There are ways to deal with rollback. Chances are that a rather simple early implementation would shift that to the client, but there are way to deal with it in the service too.<br>
<br>
> Such a engine library would make sense as the core 'engine' for a lot of<br>
> the openstack core projects imho.<br>
<br>
Yes, if the vision is achieved, you would use Heat for Orchestration purposes, and Convection for simple task executions. The first use case for Convection would be a task that has a start, a sequence of tasks, followed by a termination. This could be very useful in Nova when you care about kicking off a workflow and be able to get a callback upon completion of the job/task.<br>
<br>
For jobs that would benefit from parallel execution and coordination of multiple tasks, you would use Heat as an Orchestration instrument, which would in turn use multiple workflows.<br>
<br>
> Thoughts?<br>
<br>
The first implementation is likely to be library within the Heat project that the Heat engine uses. Next, an Oslo library, and then a standalone service with a REST API that uses the Oslo library for general purpose uses from applications outside Openstack, perhaps those deployed by Heat, etc. This gives us the opportunity to offer the service in an fault tolerant HA configuration for use cases that require reliable workflow execution. If you are interested in contributing, I urge you to connect with Keith Bray <<a href="mailto:keith.bray@racksopace.com">keith.bray@racksopace.com</a>> to coordinate efforts.<br>
<br>
Cheers,<br>
<br>
Adrian<br>
<br>
><br>
> On 4/17/13 2:47 PM, "Zane Bitter" <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br>
><br>
>> Thanks Adrian!<br>
>><br>
>> We should probably make it clear for those who can't be at Summit that<br>
>> this is not intended to be a record of the design summit discussions.<br>
>> I'd describe this as a snapshot of Adrian's evolving vision for Heat,<br>
>> taken after the design summit sessions. In particular, I think it<br>
>> reflects a couple of misconceptions about the current architecture of<br>
>> Heat, and it also contains some stuff that hasn't been discussed at all<br>
>> at Summit (e.g. the CEP part... btw my initial reaction to this is that<br>
>> it should probably talk to Ceilometer rather than the Autoscaling<br>
>> service).<br>
>><br>
>> That said, there certainly *is* consensus that we want to evolve Heat<br>
>> toward being able to orchestrate whole applications rather than just<br>
>> services. We'll be doing further work throughout the week and<br>
>> subsequently on the mailing list to refine some of these architectural<br>
>> ideas, and we're looking forward to working with Adrian and his team at<br>
>> Rackspace to make it happen :)<br>
>><br>
>> cheers,<br>
>> Zane.<br>
>><br>
>> On 16/04/13 01:56, Adrian Otto wrote:<br>
>>> Heaters,<br>
>>><br>
>>> I attended the various sessions at the Design Summit today in Portland,<br>
>>> and assembled as many of the ideas for future planning as I could. For<br>
>>> the benefit of those who are not attending, or who were not in these<br>
>>> sessions, I created this Wiki page to express what I think is an early<br>
>>> consensus on where we could take things. Let's tweak this if it's not a<br>
>>> good direction.<br>
>>><br>
>>> <a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
>>><br>
>>> Keith will be doing an Unconference session on the Workflow Service<br>
>>> idea? I believe on Wednesday afternoon.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Adrian<br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 33<br>
Date: Thu, 18 Apr 2013 08:47:10 +0000<br>
From: Matt Van Winkle <<a href="mailto:mvanwink@rackspace.com">mvanwink@rackspace.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] passwords in logs --security related<br>
Message-ID: <<a href="mailto:BB3E33C3-8295-40D7-B4D0-135643F20E9E@rackspace.com">BB3E33C3-8295-40D7-B4D0-135643F20E9E@rackspace.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Honestly, no passwords should be logged anywhere. We need to be able to expose logs in a way that doesn't provide a feat platform for non-privileged users to script athentication against<br>
<br>
Sent from my iPhone<br>
<br>
On Apr 17, 2013, at 11:58 PM, "Bhandaru, Malini K" <<a href="mailto:malini.k.bhandaru@intel.com">malini.k.bhandaru@intel.com</a><mailto:<a href="mailto:malini.k.bhandaru@intel.com">malini.k.bhandaru@intel.com</a>>> wrote:<br>
<br>
Hello All!<br>
<br>
David Geng is addressing a case of password logging in keystone. Do we handle any passwords in other openstack<br>
components and log them? Might they benefit from David moving his fix into Oslo as a log filter (a nice suggestion from Guang-yee).<br>
Please weigh in. If yes, what is expected the string pattern?<br>
<br>
<a href="https://review.openstack.org/#/c/26487/" target="_blank">https://review.openstack.org/#/c/26487/</a><br>
<br>
<br>
Regards<br>
Malini<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/33f54f3d/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/33f54f3d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 34<br>
Date: Thu, 18 Apr 2013 08:50:15 +0000<br>
From: Matt Van Winkle <<a href="mailto:mvanwink@rackspace.com">mvanwink@rackspace.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] passwords in logs --security related<br>
Message-ID: <<a href="mailto:B3D315D8-2914-4E1F-9CBF-EE4FAD9A8DE5@rackspace.com">B3D315D8-2914-4E1F-9CBF-EE4FAD9A8DE5@rackspace.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Summit + late night + big thumbs = fail<br>
<br>
<br>
<br>
Sent from my iPhone<br>
<br>
On Apr 18, 2013, at 1:47 AM, "Matt Van Winkle" <<a href="mailto:mvanwink@rackspace.com">mvanwink@rackspace.com</a><mailto:<a href="mailto:mvanwink@rackspace.com">mvanwink@rackspace.com</a>>> wrote:<br>
<br>
Honestly, no passwords should be logged anywhere. We need to be able to expose logs in a way that doesn't provide a feat platform for non-privileged users to script athentication against<br>
<br>
Sent from my iPhone<br>
<br>
On Apr 17, 2013, at 11:58 PM, "Bhandaru, Malini K" <<a href="mailto:malini.k.bhandaru@intel.com">malini.k.bhandaru@intel.com</a><mailto:<a href="mailto:malini.k.bhandaru@intel.com">malini.k.bhandaru@intel.com</a>>> wrote:<br>
<br>
Hello All!<br>
<br>
David Geng is addressing a case of password logging in keystone. Do we handle any passwords in other openstack<br>
components and log them? Might they benefit from David moving his fix into Oslo as a log filter (a nice suggestion from Guang-yee).<br>
Please weigh in. If yes, what is expected the string pattern?<br>
<br>
<a href="https://review.openstack.org/#/c/26487/" target="_blank">https://review.openstack.org/#/c/26487/</a><br>
<br>
<br>
Regards<br>
Malini<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/64188223/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/64188223/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Thu, 18 Apr 2013 11:00:50 +0200<br>
From: Yann Fouillat <<a href="mailto:yann.fouillat.ext@makina-corpus.com">yann.fouillat.ext@makina-corpus.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Cinder] Raised exception in utils.execute<br>
Message-ID: <<a href="mailto:516FB642.10902@makina-corpus.com">516FB642.10902@makina-corpus.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hello,<br>
<br>
I had the same problem as<br>
<a href="https://lists.launchpad.net/openstack/msg20619.html" target="_blank">https://lists.launchpad.net/openstack/msg20619.html</a>. For information,<br>
here is the traceback of my error:<br>
<br>
=====================================================================<br>
Traceback (most recent call last):<br>
File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 224,<br>
in _start_child<br>
self._child_process(wrap.server)<br>
File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 201,<br>
in _child_process<br>
launcher.run_server(server)<br>
File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 95,<br>
in run_server<br>
server.start()<br>
File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 342,<br>
in start<br>
self.manager.init_host()<br>
File "/usr/lib/python2.7/dist-packages/cinder/volume/manager.py",<br>
line 149, in init_host<br>
self.driver.ensure_export(ctxt, volume)<br>
File<br>
"/usr/lib/python2.7/dist-packages/cinder/volume/drivers/lvm.py", line<br>
388, in ensure_export<br>
old_name=old_name)<br>
File "/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py", line<br>
225, in create_iscsi_target<br>
self._new_target(name, tid, **kwargs)<br>
File "/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py", line<br>
284, in _new_target<br>
**kwargs)<br>
File "/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py", line<br>
73, in _run<br>
self._execute(self._cmd, *args, run_as_root=True, **kwargs)<br>
File "/usr/lib/python2.7/dist-packages/cinder/utils.py", line 145,<br>
in execute<br>
'to utils.execute: %r') % kwargs)<br>
Error: Got unknown keyword args to utils.execute: {'old_name': None}<br>
=====================================================================<br>
<br>
I am not sure how to reproduce this behaviour. For info, I followed<br>
this guide to install OpenStack:<br>
<a href="https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_MultiNode/OpenStack_Grizzly_Install_Guide.rst" target="_blank">https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_MultiNode/OpenStack_Grizzly_Install_Guide.rst</a>.<br>
Maybe adding a volume in horizon and then restarting cinder-volume is<br>
enough to reproduce it.<br>
<br>
I figured out that the correction of this bug:<br>
<a href="https://bugs.launchpad.net/cinder/+bug/1065702" target="_blank">https://bugs.launchpad.net/cinder/+bug/1065702</a> added an entry to<br>
kwargs which will last until utils.execute is called, in which an<br>
exception will be raised because old_name is not an expected parameter:<br>
<br>
=====================================================================<br>
if len(kwargs):<br>
raise exception.Error(_('Got unknown keyword args '<br>
<br>
'to utils.execute: %r') % kwargs)<br>
=====================================================================<br>
<br>
So, my question is the following: is this exception really necessary ?<br>
kwargs is not used afterwards. Isn't logging a warning enough ? It<br>
would prevent this kind of unexpected behaviour withouwor<br>
t having to sanitize kwargs before each call of utils.execute.<br>
<br>
However, if there is really a reason to raise this exception, I'll be<br>
curious to know it.<br>
<br>
Regards,<br>
<br>
Yann<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.12 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iQEcBAEBAgAGBQJRb7ZCAAoJEO1YhKM5jgEdOqgIALH3UWKK3oN1Pq9tTqPbNZ17<br>
8F+8xID3DDDetIIIYvwaMuJ6ZMudjQXVXNYSkl9QH4s11qOawl72nxrQEgXdMkVE<br>
1W2a+YttaVVDCwmw8yb4ikvL9tsuXu/P6xMkCASkUJ/f9UfSrxgr+6ElXCBEjIN0<br>
gtxxGTWYKfu94SSUVP8GLoOr4Vz7+DWmVf0qDG2fo8ZEV2Lz9HkWtkeJYQo3vre6<br>
fbJEI9WSiN55ajEB0suzH76yrWNnECNa90Xg5GTZuWOfEReA8D9ZBGfC5pjhvx8z<br>
nUs010B7X+5fKd5GA5VxotS1cg0eyLDdp55ZAE/zZh2eFyZvRKOtTMXV95pFeqU=<br>
=UaX0<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 36<br>
Date: Thu, 18 Apr 2013 09:10:04 +0000<br>
From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
Message-ID: <<a href="mailto:D3206B2D-D31B-42B4-A371-FB39A5BA4AB4@rackspace.com">D3206B2D-D31B-42B4-A371-FB39A5BA4AB4@rackspace.com</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
I have further refined the Vision Wiki page in accordance with further feedback from the core team. This is a shorter term vision that more closely matches what we will evolve toward in the short therm.<br>
<br>
<a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
<br>
On Apr 17, 2013, at 2:53 PM, Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br>
<br>
> On 16/04/13 09:05, Thomas Spatzier wrote:<br>
>> Hi Adrian,<br>
>><br>
>> Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>> wrote on 16.04.2013 17:24:56:<br>
>>> From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
>>> To: OpenStack Development Mailing List<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
>>> Date: 16.04.2013 17:26<br>
>>> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
>>><br>
>>> Thanks Thomas. Good point.<br>
>>><br>
>>> In that case, wwe could just consider the one within the blue area<br>
>>> to have the label "Parser" and that should clarify matters. I'm<br>
>>> happy to make tweaks to clarify it.<br>
>><br>
>> Maybe we can also come up with a better term than "parser". Would be<br>
>> interested what the Heat core team thinks.<br>
><br>
> For historical reasons, "parser" is the name of the module that essentially runs the Heat orchestration engine. It's a terrible name that doesn't really reflect what it actually does, so I'm definitely in favour of changing it.<br>
><br>
> This diagram is also showing it in the wrong place, so we have some more work to do to figure out some better terminology and get everyone on the same page.<br>
><br>
> cheers,<br>
> Zane.<br>
><br>
>><br>
>> Regards,<br>
>> Thomas<br>
>><br>
>>><br>
>>> Adrian<br>
>>><br>
>>><br>
>>> -----Original message-----<br>
>>> From: Thomas Spatzier <<a href="mailto:thomas.spatzier@de.ibm.com">thomas.spatzier@de.ibm.com</a>><br>
>>> To: OpenStack Development Mailing List<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>>> Sent: Tue, Apr 16, 2013 14:22:07 GMT+00:00<br>
>>> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat<br>
>><br>
>>> Hi Adrian,<br>
>>><br>
>>> thanks for taking writing this up to capture yesterday's discussions.<br>
>>> I don't fully understand what the difference or overlap of the Model<br>
>>> Interpreter inside the main blue box and the Model Interpreter in the<br>
>> green<br>
>>> box is. My understanding was that a Model Interpreter would be something<br>
>>> that translates an external format (such as CFN, TOSCA, whatever) to the<br>
>>> core Heat DSL. And then there would be one component which looks at the<br>
>>> common DSL model to derive the deployment plan (I think somebody said<br>
>> this<br>
>>> is what the "parser" does today).<br>
>>> I think having to partly re-implement the interpreter (in the sense of<br>
>>> compiling a concrete deployment plan directly) for various external<br>
>> formats<br>
>>> could be complicated.<br>
>>><br>
>>> Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>> wrote on 16.04.2013 10:56:23:<br>
>>><br>
>>>> From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
>>>> To: OpenStack Development Mailing List<br>
>>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
>>>> Date: 16.04.2013 10:57<br>
>>>> Subject: [openstack-dev] [Heat] Future Vision for Heat<br>
>>>><br>
>>>> Heaters,<br>
>>>><br>
>>>> I attended the various sessions at the Design Summit today in<br>
>>>> Portland, and assembled as many of the ideas for future planning as<br>
>>>> I could. For the benefit of those who are not attending, or who<br>
>>>> were not in these sessions, I created this Wiki page to express what<br>
>>>> I think is an early consensus on where we could take things. Let's<br>
>>>> tweak this if it's not a good direction.<br>
>>>><br>
>>>> <a href="https://wiki.openstack.org/wiki/Heat/Vision" target="_blank">https://wiki.openstack.org/wiki/Heat/Vision</a><br>
>>>><br>
>>>> Keith will be doing an Unconference session on the Workflow Service<br>
>>>> idea? I believe on Wednesday afternoon.<br>
>>>><br>
>>>> Thanks,<br>
>>>><br>
>>>> Adrian<br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 12, Issue 22<br>
*********************************************<br>
</blockquote></div><br></div></div>