Commit b13e257b authored by David Johnson's avatar David Johnson

Add some basic wfa usage documentation and feature notes.

parent 1bc93167
Pipeline #1862 passed with stage
in 2 seconds
......@@ -538,3 +538,84 @@ later.
Using Capnet
First, you'll want to create a Capnet-backed virtual network, where the
virtual network is built atop the physical Capnet network you configured
above (i.e., ``capnet-phys-``)::
neutron net-create $NETNAME --shared \
--provider:physical_network $PHYSNET --provider:network_type capnet
NETID=`neutron net-show $NETNAME | awk '/ id / {print $4}'`
neutron subnet-create $NETNAME --name $SUBNETNAME \
--allocation-pool $ALLOCPOOL --gateway $ROUTER $SUBNET
SUBNETID=`neutron subnet-show $SUBNETNAME | awk '/ id / {print $4}'`
neutron router-create $ROUTERNAME
neutron router-interface-add $ROUTERNAME $SUBNETNAME
(Obviously, change the network metadata as you like. Also, ***note***
that we create a shared virtual network so that multiple tenants can
connect at once, as described above.)
Once you have a Capnet virtual network in your OpenStack cloud, you can
begin to add VMs and Capnet workflow agents to the network. When you
create a workflow agent in Capnet, you can mark it as the "master" for
the tenant. This means it automatically receives capabilities to all
the VMs owned by that tenant and attached to the network to which the
agent is being connected. If you don't mark it as a master, it will not
receive those capabilities.
You can also mark an existing VM's port as a master workflow agent, or
reuse an existing VM as a workflow agent. If you choose this option,
though, you'll have to install the Capnet Python binding and your agent
in that VM, or similar. We haven't tested this feature, either,
although it should be supported.
If you don't use an existing VM's port as the workflow agent, when you
create the agent, a Linux network namespace will be created on your
network manager node (or whatever node you've configured with
`hosts_workflow_apps` in
``/etc/neutron/plugins/ml2/ml2_capnet_conf.ini``), and your agent
program will run in that namespace. Thus, the path to the workflow
agent program you specify must already exist on the network manager node
--- you'll have to manually install any new agents you want to run (in
the future, we may allow them to be glance images so users can upload
them, but this isn't important right now.).
***NOTE***: right now, the workflow agent will run as root --- this has
to do with the difficulty of passing CAP_NET_RAW to a non-binary forked
child on Linux --- Linux 4.3 has native support for allowing POSIX caps
to be passed to children (see ``capnet/tools/capnet-privexec.c``), but
that's too recent to count on. We'll fix it later; for now, just be
You can explore the Capnet Neutron CLI extension commands by doing::
neutron help | grep capnet
Then you can further explore each subcommand::
neutron help capnet-wfagent-create
For instance, you could create a Hadoop service workflow agent (which
receives capabilities to VMs from a user tenant who wants Hadoop
installed and configured, and configures Hadoop software and network
flows between those VMs) like this::
STENANTID=`openstack project show $STENANT | awk ' / id / {print $4}'`
neutron capnet-wfagent-create --tenant-id $STENANTID --name $WFANAME \
--master --wfapp-path /usr/bin/capnet-wfagent-service-tenant-hadoop-membrane \
(assuming you had a project named `service-0`, and that workflow agent
installed on your network manager node).
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment