#opendaylight-meeting: tws
Meeting started by colindixon at 17:03:14 UTC
(full logs).
Meeting summary
- agenda bashing (colindixon, 17:03:39)
- https://wiki.opendaylight.org/view/Tech_Work_Stream:Main
this is the main page for the TWS call (colindixon,
17:04:08)
- today’s agenda is covering the usage of
karaf (colindixon,
17:04:21)
- karaf hands on (colindixon, 17:07:35)
- hands-on walk-through by mlemay_ on Karaf for
ODL Helium release (Madhu,
17:07:37)
- note that this is being recorded and will be
posted (colindixon,
17:07:59)
- https://wiki.opendaylight.org/view/Runtime:Karaf_Features_Guidelines
this is the first resource you should go to to get started (colindixon,
17:08:21)
- mlemay_ is also working on an archetype which
will help (colindixon,
17:08:31)
- creating the feature pom file (colindixon, 17:09:35)
- the convention is to create a directory named :
features under the root of the repository and it is
recommended (Madhu,
17:09:38)
- start by copying the pom.xml file from the
above wiki page (it has all the the things you need, while some of
the poms floating around may not) (colindixon,
17:10:40)
- mlemay_ is demonstrating in the video by doing
this in l2switch (colindixon,
17:13:13)
- after copying you should find your parent pom
and copy it’s groupId, artifactId, and version from there
(colindixon,
17:13:54)
- you need to give this artifact a name, e.g.,
features-<project> (colindixon,
17:14:33)
- complete the description field as well
(colindixon,
17:14:42)
- creatint a features.xml file (colindixon, 17:15:10)
- after creating the pom.xml file, you should
create a features.xml file in src/main/resources (relative to the
pom.xml) (colindixon,
17:16:44)
- you should copy the projects features file xml
from the wiki page linked above (colindixon,
17:17:06)
- in the <features…> tag, change the
name=“…” block to use your project instead of whatever it’s
there (colindixon,
17:18:00)
- in the <feature…> tag, change the name to
be “odl-<project>-<feature>”, which is the naming
convention we’re using (colindixon,
17:19:22)
- at this point, you can test what you have so
far by building the pom.xml file and seeing if it works (colindixon,
17:20:17)
- filling in the <feature> block in the features.xml (colindixon, 17:21:05)
- the bundle dependencies inside of the feature
file follow the Pax-URL format (Madhu,
17:21:32)
- the simplest way to start making a feautre is
to grab a bundle using a <bundle> tag, an example is shown on
the wiki page linked above (colindixon,
17:22:53)
- at this point building it will create a .kar
file which is a repository that contains the bundles you asked
for (colindixon,
17:25:50)
- this won’t work yet (at least for l2switch)
because we haven’t expressed our dependencies yet (colindixon,
17:27:12)
- in this case, to add the the md-sal and get all
of it’s transitive feautures, we add teh md-sal feature as a
dependency in the pom.xml (colindixon,
17:27:56)
- this isn’t required, but it makes it so that
you get transitive dependencies (colindixon,
17:28:15)
- after doing this the dependency needs to be
added to the feature.xml file as well, this is done by putting
another <feature> tag inside the first, again an example is on
the above linked wiki page (colindixon,
17:29:29)
- in general, you should try to use care in
picking which features you’re dependent on so that you avoid
“pulling in the entire world" (colindixon,
17:30:40)
- in this case, we’re pulling in odl-mdsal-all to
be faster (colindixon,
17:31:59)
- wrapping up features.xml and pom.xml parts (colindixon, 17:32:56)
- Madhu points out the key point is that the the
important part here is really just filling out the few blanks in the
pom.xml, then filling in the few key lines of the
features.xml (colindixon,
17:33:31)
- after that everything that follows, including
installing features, is the same for everyone (colindixon,
17:34:03)
- installing/using features (colindixon, 17:34:23)
- the Controller project has the default
container today. It will be added to the integration project
too (Madhu,
17:34:24)
- the controller project's container is located
under (Madhu,
17:34:39)
- opendaylight/distribution/opendaylight-karaf
(Madhu,
17:34:55)
- mvn clean install of the above folder will
create a distribution*.zip file which can be unzipped (Madhu,
17:35:16)
- and run the karaf container from within the
distribution.* folder bin/karaf (Madhu,
17:35:39)
- bin/karaf will launch the karaf
container. (Madhu,
17:36:06)
- feature:list will list all the features from
the local karaf repo (Madhu,
17:36:26)
- kar:list will list all the Karaf
archives (Madhu,
17:36:39)
- feature:install will install a particular
feature. when a feature is installed it will install all the
dependent features and bundles. (Madhu,
17:37:05)
- example feature:install odl-adsal-all will
install everything that adsal provides. (Madhu,
17:37:31)
- hideyuki asks if the fact that we’re running
Karaf means that we’re running an osgi runtime as well (colindixon,
17:37:39)
- bundle:list will list every bundle that is
loaded (just like ss command in the equinox togo shell) (Madhu,
17:37:54)
- mlemay_ says, yes, and you can see the osgi
bundles with the command bundle:list (colindixon,
17:38:16)
- feature:repo-list will display the repos that
is available and provisioned (Madhu,
17:39:05)
- hideyuki asks what “repo” means here, mlemay_
says it’s a feature repository which is the the features.xml file we
defined earlier (colindixon,
17:40:25)
- feature:repo-add will add the karaf feature
repo that is created (the xml that is created as part of the project
feature) (Madhu,
17:40:26)
- once the feature-repo is added, we can use the
feature-install to install the file to the running container and
that will pull in all the dependencies as before. (colindixon,
17:42:33)
- alternatively, we can use kar:install to
install a kar file that is created on a particular project
(Madhu,
17:43:08)
- also, kar file can be simply dropped into the
"deploy" folder and it will automatically install all the features
part of the kar file (Madhu,
17:43:39)
- feature:repo-refresh command can be used to
refresh a feature at runtime and it is very useful during
development (Madhu,
17:46:35)
- use the log: command to explore more
(Madhu,
17:48:10)
- Rob Adams asks some questions about how we can
make this easier for users in the WebEx chat, Madhu provides some
answers (colindixon,
17:50:18)
- karaf CLI is a bit more feature richness like
history, command completion, etc... (Madhu,
17:50:32)
- exploring the CLI options can be useful
(Madhu,
17:50:46)
- hideyuki asks if by default log messages do not
go to the karaf cli, the answer is yeah, to get them you go to
log:display or log:tail (colindixon,
17:51:02)
- karaf container provides ability to configure
the Command-line to be used remotely using ssh. (Madhu,
17:52:14)
- the karaf cli provides ssh access by default,
which you can use to get remote access to the running
container (colindixon,
17:52:17)
- you can change the port (or even if it’s turned
on) in the config files which are located in the “etc” folder inside
the karaf distribution (colindixon,
17:52:41)
- edwarnicke points out that when you’re
installing a bundle, it won’t start unless you pass -s to that
command, e.g., bundle:install -s … (colindixon,
17:54:08)
- karaf remembers the previous session and
restarts all the features installed in the previous run, if the
karaf container is restarted (Madhu,
17:54:39)
- to clear that state, you can delete the
contents of the “data” folder (colindixon,
17:55:25)
- LuisGomez asks some questions about how to roll
this up for integration, mlemay_ responds yeah there are lots of
things we are planning there, but the first step is to get projects
making feature files (colindixon,
17:58:00)
- key take aways (colindixon, 17:58:09)
- we are asking all projects to try to get their
stuff packaged up as karaf features if at all possible (colindixon,
17:58:46)
- we are developing REST-APIs being developed to
do most of the stuffs done using the CLI. (Madhu,
17:58:59)
- please reach out to mlemay_ and others if you
need help getting started or if you get stuck (colindixon,
17:59:15)
- also developing DLUX ui to install,
etc... (Madhu,
17:59:15)
- colindixon points out that the part where you
identify what your dependencies are might be a sticking point for
people and wasn’t really covered here (colindixon,
18:01:47)
- ACTION: mlemay_ to
provide information about figuring out you dependencies (which will
likely be other features) that on a wiki page and send it out
(colindixon,
18:02:18)
Meeting ended at 18:05:20 UTC
(full logs).
Action items
- mlemay_ to provide information about figuring out you dependencies (which will likely be other features) that on a wiki page and send it out
Action items, by person
- mlemay_
- mlemay_ to provide information about figuring out you dependencies (which will likely be other features) that on a wiki page and send it out
People present (lines said)
- colindixon (64)
- Madhu (45)
- odl_meetbot (8)
- readams (7)
- mlemay_ (4)
- phrobb (0)
Generated by MeetBot 0.1.4.