<div dir="ltr">Hi Hongbin,<div><br></div><div>Many thanks, got it running, that was awesom... :) The problem was unsynched time. I installed chrony and it started working. </div><div><br></div><div>Now I am running into another problem; the networking of the container. The container gets started, I can shell into it through appcontainer API, it even gets the correct IP address of my private network (named priv-net) in openstack, <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">through DHCP</span>. But when I ping any address, even the address of the priv-net's gateway, it does nothing. I have following configuration</div><div><br></div><div>neutron-openvswitch-agent is running</div><div>neutron-ovs-cleanup is running<br></div><div>neutron-destroy-patch-ports is running<br></div><div>kuryr-libnetwork is running<br></div><div>docker is running<br></div><div>zun-compute is running<br></div><div><br></div><div>The eth0 network card has standard configuration of an OVSBridge.</div><div><br></div><div>When I create a new container it also creates taps and patch ports on the compute node. Now I am going to try to use kuryr script to test what happens with "bridged" and "host" networks.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Muhammad Usman Awais<br><br><br></div></div>
<br><div class="gmail_quote">On Thu, Jun 21, 2018 at 1:14 PM, Hongbin Lu <span dir="ltr"><<a href="mailto:hongbin034@gmail.com" target="_blank">hongbin034@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>HI
<span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Muhammad,</span></div><div><br></div><div>Here is the code (run in controller node) that decides whether a service is up <a href="https://github.com/openstack/zun/blob/master/zun/api/servicegroup.py" target="_blank">https://github.com/openstack/<wbr>zun/blob/master/zun/api/<wbr>servicegroup.py</a> . There are several possibilities to cause a service to be 'down':</div><div>1. The service was being 'force_down' via API (e.g. explicitly issued a command like "appcontainer service forcedown")</div><div>2. The zun compute process is not doing the heartbeat for a certain period of time (CONF.service_down_time).</div><div>3. The zun compute process is doing the heartbeat properly but the time between controller node and compute node is out of sync.</div><div><br></div><div>In before, #3 is the common pitfall that people ran into. If it is not #3, you might want to check if the zun compute process is doing the heartbeat properly. Each zun compute process is running a periodic task to update its state in DB: <a href="https://github.com/openstack/zun/blob/master/zun/servicegroup/zun_service_periodic.py" target="_blank">https://github.com/<wbr>openstack/zun/blob/master/zun/<wbr>servicegroup/zun_service_<wbr>periodic.py</a> . The call of '
<span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">report_state_up</span>
' will record this service is up in DB at current time. You might want to check if this periodic task is running properly, or if the current state is updated in the DB.<br></div><div><br></div><div>Above is my best guess. Please feel free to follow it up with me or other team members if you need further assistant for this issue.</div><div><br></div><div>Best regards,</div><div>Hongbin</div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Wed, Jun 20, 2018 at 9:14 AM Usman Awais <<a href="mailto:usman.awais@gmail.com" target="_blank">usman.awais@gmail.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><div dir="ltr">Dear Zuners,<div><br></div><div>I have installed RDO pike. I stopped openstack-nova-compute service on one of the hosts, and installed a zun-compute service. Although all the services seems to be running ok on both controller and compute but when I do </div><div><br></div><div> openstack appcontainer service list</div><div><br></div><div>It gives me following</div><div><br></div><div>+----+--------------+---------<wbr>----+-------+----------+------<wbr>-----------+------------------<wbr>---+-------------------+</div><div>| Id | Host | Binary | State | Disabled | Disabled Reason | Updated At | Availability Zone |</div><div>+----+--------------+---------<wbr>----+-------+----------+------<wbr>-----------+------------------<wbr>---+-------------------+</div><div>| 1 | node1.os.lab | zun-compute | down | False | None | 2018-06-20 13:14:31 | nova |</div><div>+----+--------------+---------<wbr>----+-------+----------+------<wbr>-----------+------------------<wbr>---+-------------------+</div><div><br></div><div>I have checked all ports in both directions they are open, including etcd ports and others. All services are running, only docker service has the warning message saying "failed to retrieve docker-runc version: exec: \"docker-runc\": executable file not found in $PATH". There is also a message at zun-compute "/usr/lib64/python2.7/site-<wbr>packages/sqlalchemy/sql/<wbr>default_comparator.py:161: SAWarning: The IN-predicate on "container.uuid" was invoked with an empty sequence. This results in a contradiction, which nonetheless can be expensive to evaluate. Consider alternative strategies for improved performance."</div><div><br></div><div>Please guide...</div><div><br></div><div>Regards,<br clear="all"><div><div class="m_1670455320156694095gmail-m_-8573622893539285047gmail_signature">Muhammad Usman Awais<br><br><br></div></div>
</div></div></div></div>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>