Date   
Re: Problem in running Edgex services

espy
 

On 6/25/19 5:58 AM, Sezal Chug wrote:

Hi,
so i was trying to run the latest version of edgex on Kubernetes. But i could run only the consul, volume and config see only . when i run the logging deployment it shows a problem.

Did you use kompose to convert the docker-compose files to k8s? I ran into exactly the same volume errors when I tried using kompose a few months back.

Regards,
/tony



This is the description for my pod
Name:               logging-78c5748598-q87qw
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               admin1/192.168.1.9
Start Time:         Tue, 25 Jun 2019 15:23:46 +0530
Labels:             io.kompose.service=logging
                    pod-template-hash=78c5748598
Annotations:        <none>
Status:             Running
IP:                 10.42.0.35
Controlled By:      ReplicaSet/logging-78c5748598
Containers:
  edgex-support-logging:
    Container ID:  containerd://af5f410195f01b2744193c24449e22334a140cb4da356f2efefd7c0e0f5a0a69
    Image:         nexus3.edgexfoundry.org:10002/docker-support-logging-go:0.7.1
    Image ID:      docker.io/edgexfoundry/docker-support-logging-go@sha256:f0b2d67554547e2dd3282f4878b57a79923cf9b5ee730e19dd5a4b42946b2ee6
    Port:          48061/TCP
    Host Port:     0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 25 Jun 2019 15:23:50 +0530
      Finished:     Tue, 25 Jun 2019 15:23:50 +0530
    Ready:          False
    Restart Count:  1
    Environment:    <none>
    Mounts:
      /consul/config from consul-config (rw)
      /consul/data from consul-data (rw)
      /data/db from db-data (rw)
      /edgex/logs from log-data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-hrf5p (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  db-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  db-data
    ReadOnly:   false
  log-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  log-data
    ReadOnly:   false
  consul-config:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  consul-config
    ReadOnly:   false
  consul-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  consul-data
    ReadOnly:   false
  default-token-hrf5p:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-hrf5p
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  18s                default-scheduler  Successfully assigned default/logging-78c5748598-q87qw to admin1
  Normal   Pulled     14s (x2 over 16s)  kubelet, admin1    Container image "nexus3.edgexfoundry.org:10002/docker-support-logging-go:0.7.1" already present on machine
  Normal   Created    13s (x2 over 15s)  kubelet, admin1    Created container edgex-support-logging
  Normal   Started    13s (x2 over 15s)  kubelet, admin1    Started container edgex-support-logging
  Warning  BackOff    11s (x2 over 12s)  kubelet, admin1    Back-off restarting failed container

please check. why is it exiting exit code 1.
the logs are below.
ERROR: 2019/06/25 09:35:02 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:03 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:04 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:05 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:06 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:07 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:08 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:09 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:10 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:11 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:12 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:13 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:14 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:15 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:16 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:17 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:18 edgex-support-logging: Service bootstrap failed!

Re: Problem in running Edgex services

James.White2@...
 

Sezal,

It appears that your services are unable to get to Consul.  I am not sure what / how you have set up your pods, etc.  If you message me privately, I can put you in touch with a member of my team that has some of EdgeX running in Kubernetes.

 

 

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

EdgeX Foundry Technical Steering Committee Vice Chairman

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 

 

 

From: EdgeX-Devel@... <EdgeX-Devel@...> On Behalf Of Sezal Chug
Sent: Tuesday, June 25, 2019 4:59 AM
To: EdgeX-Devel@...
Subject: [Edgex-devel] Problem in running Edgex services

 

[EXTERNAL EMAIL]

Hi,

so i was trying to run the latest version of edgex on Kubernetes. But i could run only the consul, volume and config see only . when i run the logging deployment it shows a problem.

This is the description for my pod

Name:               logging-78c5748598-q87qw
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               admin1/192.168.1.9
Start Time:         Tue, 25 Jun 2019 15:23:46 +0530
Labels:             io.kompose.service=logging
                    pod-template-hash=78c5748598
Annotations:        <none>
Status:             Running
IP:                 10.42.0.35
Controlled By:      ReplicaSet/logging-78c5748598
Containers:
  edgex-support-logging:
    Container ID:  containerd://af5f410195f01b2744193c24449e22334a140cb4da356f2efefd7c0e0f5a0a69
    Image:         nexus3.edgexfoundry.org:10002/docker-support-logging-go:0.7.1
    Image ID:      docker.io/edgexfoundry/docker-support-logging-go@sha256:f0b2d67554547e2dd3282f4878b57a79923cf9b5ee730e19dd5a4b42946b2ee6
    Port:          48061/TCP
    Host Port:     0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 25 Jun 2019 15:23:50 +0530
      Finished:     Tue, 25 Jun 2019 15:23:50 +0530
    Ready:          False
    Restart Count:  1
    Environment:    <none>
    Mounts:
      /consul/config from consul-config (rw)
      /consul/data from consul-data (rw)
      /data/db from db-data (rw)
      /edgex/logs from log-data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-hrf5p (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  db-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  db-data
    ReadOnly:   false
  log-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  log-data
    ReadOnly:   false
  consul-config:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  consul-config
    ReadOnly:   false
  consul-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  consul-data
    ReadOnly:   false
  default-token-hrf5p:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-hrf5p
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  18s                default-scheduler  Successfully assigned default/logging-78c5748598-q87qw to admin1
  Normal   Pulled     14s (x2 over 16s)  kubelet, admin1    Container image "nexus3.edgexfoundry.org:10002/docker-support-logging-go:0.7.1" already present on machine
  Normal   Created    13s (x2 over 15s)  kubelet, admin1    Created container edgex-support-logging
  Normal   Started    13s (x2 over 15s)  kubelet, admin1    Started container edgex-support-logging
  Warning  BackOff    11s (x2 over 12s)  kubelet, admin1    Back-off restarting failed container

 

please check. why is it exiting exit code 1.

the logs are below.

ERROR: 2019/06/25 09:35:02 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:03 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:04 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:05 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:06 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:07 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:08 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:09 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:10 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:11 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:12 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:13 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:14 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:15 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:16 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:17 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:18 edgex-support-logging: Service bootstrap failed!

 

Problem in running Edgex services

Sezal Chug <sezal17101@...>
 

Hi,
so i was trying to run the latest version of edgex on Kubernetes. But i could run only the consul, volume and config see only . when i run the logging deployment it shows a problem.
This is the description for my pod
Name:               logging-78c5748598-q87qw
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               admin1/192.168.1.9
Start Time:         Tue, 25 Jun 2019 15:23:46 +0530
Labels:             io.kompose.service=logging
                    pod-template-hash=78c5748598
Annotations:        <none>
Status:             Running
IP:                 10.42.0.35
Controlled By:      ReplicaSet/logging-78c5748598
Containers:
  edgex-support-logging:
    Container ID:  containerd://af5f410195f01b2744193c24449e22334a140cb4da356f2efefd7c0e0f5a0a69
    Image:         nexus3.edgexfoundry.org:10002/docker-support-logging-go:0.7.1
    Image ID:      docker.io/edgexfoundry/docker-support-logging-go@sha256:f0b2d67554547e2dd3282f4878b57a79923cf9b5ee730e19dd5a4b42946b2ee6
    Port:          48061/TCP
    Host Port:     0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 25 Jun 2019 15:23:50 +0530
      Finished:     Tue, 25 Jun 2019 15:23:50 +0530
    Ready:          False
    Restart Count:  1
    Environment:    <none>
    Mounts:
      /consul/config from consul-config (rw)
      /consul/data from consul-data (rw)
      /data/db from db-data (rw)
      /edgex/logs from log-data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-hrf5p (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  db-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  db-data
    ReadOnly:   false
  log-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  log-data
    ReadOnly:   false
  consul-config:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  consul-config
    ReadOnly:   false
  consul-data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  consul-data
    ReadOnly:   false
  default-token-hrf5p:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-hrf5p
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  18s                default-scheduler  Successfully assigned default/logging-78c5748598-q87qw to admin1
  Normal   Pulled     14s (x2 over 16s)  kubelet, admin1    Container image "nexus3.edgexfoundry.org:10002/docker-support-logging-go:0.7.1" already present on machine
  Normal   Created    13s (x2 over 15s)  kubelet, admin1    Created container edgex-support-logging
  Normal   Started    13s (x2 over 15s)  kubelet, admin1    Started container edgex-support-logging
  Warning  BackOff    11s (x2 over 12s)  kubelet, admin1    Back-off restarting failed container

please check. why is it exiting exit code 1.
the logs are below.
ERROR: 2019/06/25 09:35:02 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:03 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:04 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:05 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:06 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:07 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:08 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:09 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:10 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:11 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:12 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:13 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:14 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:15 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:16 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:17 connection to Consul could not be made: Put http://edgex-core-consul:8500/v1/agent/service/register: dial tcp: lookup edgex-core-consul on 10.43.0.10:53: no such host
ERROR: 2019/06/25 09:35:18 edgex-support-logging: Service bootstrap failed!

Re: edgexfoundary installation

espy
 

On 6/4/19 8:10 AM, James.White2@... wrote:

Venkat – as one alternate, EdgeX also provides Ubuntu snaps.  This is provided through the Snap store.

One minor correction, snaps are supported on any Linux distro with snapd support. So technically they're not "Ubuntu" snaps. The edgexfoundry snap has in fact been installed on Debian, Kali, and Zorin among others distros.

For more information on how to install and use the snap of EdgeX see:

https://github.com/edgexfoundry/edgex-go/blob/master/snap/README.md

If you're running any recent version of Ubuntu, installing the snap is a one-line command:

$ sudo snap install edgexfoundry

This will install from the latest/stable channel which is the Delhi release of EdgeX. If you want to experiment with the current development release "Edinburgh", you just need indicate that you want to install from the edinburgh/edge channel where daily builds are published:

$ sudo snap install edgexfoundry --channel=edinburgh/edge

Please let me know if you have any questions.

Regards,
/tony

 

Others in our community (for example Mainflux) have used other means or simple scripting to install, but that is not something we maintain as part of the community artifacts.  You might want to solicit for other alternatives through our Slack channels (edgexfoundry.slack.com).

 

Jim

 

From: EdgeX-Devel@... <EdgeX-Devel@...> On Behalf Of va00510223@...
Sent: Monday, June 3, 2019 11:53 PM
To: EdgeX-Devel@...
Subject: [Edgex-devel] edgexfoundary installation

 

[EXTERNAL EMAIL]

Hi,
Do we have any way of installing edgexfoundary without docker?? 
Please suggest.

Thanks
Venkat

Re: device-sdk in Python

James.White2@...
 

Alex,

There is no immediate plan to provide a Python DS SDK, but if there is a contribution, we would welcome the addition of alternate language SDKs (either DS or application functions SDK).

 

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

EdgeX Foundry Technical Steering Committee Vice Chairman

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 

 

 

From: EdgeX-Devel@... <EdgeX-Devel@...> On Behalf Of Alex Gonzalez
Sent: Wednesday, June 5, 2019 7:20 AM
To: EdgeX-Devel@...
Subject: [Edgex-devel] device-sdk in Python

 

[EXTERNAL EMAIL]

Hi,

Just wondering whether there is any ongoing effort for a Python device SDK.

Regards,
Alex

device-sdk in Python

Alex Gonzalez
 

Hi,

Just wondering whether there is any ongoing effort for a Python device SDK.

Regards,
Alex

Re: edgexfoundary installation

James.White2@...
 

Venkat – as one alternate, EdgeX also provides Ubuntu snaps.  This is provided through the Snap store.

 

Others in our community (for example Mainflux) have used other means or simple scripting to install, but that is not something we maintain as part of the community artifacts.  You might want to solicit for other alternatives through our Slack channels (edgexfoundry.slack.com).

 

Jim

 

From: EdgeX-Devel@... <EdgeX-Devel@...> On Behalf Of va00510223@...
Sent: Monday, June 3, 2019 11:53 PM
To: EdgeX-Devel@...
Subject: [Edgex-devel] edgexfoundary installation

 

[EXTERNAL EMAIL]

Hi,
Do we have any way of installing edgexfoundary without docker?? 
Please suggest.

Thanks
Venkat

edgexfoundary installation

va00510223@...
 

Hi,
Do we have any way of installing edgexfoundary without docker?? 
Please suggest.

Thanks
Venkat

Re: [Edgex-golang] Community Feedback Required on PRs 1348 / 1359

Goodell, Leonard <leonard.goodell@...>
 

Ian makes a good point in that in the non-docker scenarios, the configuration.toml is easily modified to specify use of Redis. So in those cases having a new command line switch is redundant.

 

I still think for the Docker scenario, the command line switch is preferred. I’d like the DB settings override be in code rather than in the Docker file. Have the switch doesn’t make it required in the non-docker scenarios. There the configuration.toml can still be modified, rather than use the switch.

 

-Lenny

 

From: EdgeX-GoLang@... <EdgeX-GoLang@...> On Behalf Of Ian Johnson
Sent: Tuesday, May 21, 2019 11:47 AM
To: Goodell, Leonard <leonard.goodell@...>
Cc: Trevor.Conn@...; EdgeX-GoLang@...; edgex-tsc-core@...; EdgeX-Devel@...
Subject: Re: [Edgex-golang] Community Feedback Required on PRs 1348 / 1359

 

Apologies for the long email, but there's a bit of background necessary to explain why I don't think it's a good idea to use this command line flag in the snap.

 

With the snap we are in a better position than Docker to use the configuration files more directly because the configuration files live on the user's host file system and not inside the container where modification is tricky. Due to this, we try to strike a nice balance in the snap between allowing the user to modify the configuration files directly and also enable using consul for more automated device management tasks. Our current plan for managing this can be read about in issue #922.

 

Basically, in the snap we want to have 2 ways to run config-seed, one automated way which runs without the overwrite flag, and one manual way which runs with the overwrite flag. This allows a developer or manual user to easily change configuration for the services by modifying the files locally on their file system directly and then run a single command to push the content of the configuration from the filesystem into Consul.

 

I don’t think the addition of this new command line option will really help the snap at all. To explain that, let me explain how using redis currently would work. If a user wants to use redis our current mechanism would be just to have the user run:

 

snap set dbtype=redisdb

 

(or they could use the snapd REST API to do the same thing)

 

That then triggers a configuration hook to run, which processes the configuration.toml files locally for redis using a tool called remarshal, then pushes that configuration into consul so that an automated configuration management system can interact with consul to get/set configuration afterwards. This has the combined benefit of allowing a local user or developer to know what and where the configuration items that are set come from. They either originated from local configuration files or from something driving consul. The “snap set” mechanism described above merely is used as a transparent external means to modify something internal to EdgeX, the configuration files and Consul. It’s not meant to store state about EdgeX configuration, just to conveniently trigger those internal changes.

 

If we now consider using the command line flag that Trevor has proposed, if we are to use that option in the snap, we now need to track internally in the snap what database was configured with the “snap set” command above, and more importantly use that config item to determine what flags to launch config-seed with (dbtype=redis -> --database=redis, etc.). This means that in the snap, EdgeX now has an external system controlling configuration of the system and someone using the snap has a third dimension for control-plane/configuration:

 

  • Configuration files
  • Consul
  • Snapd configuration items

 

Previously, the snapd configuration items were only used to track what services were on/off, which is no different to someone using docker-compose to start/stop certain services and is a natural way to track this.

 

Our intention with the snap is to minimize the extent to which the snap distribution differs from the other distribution methods, but also to add convenient features which the snap can provide that aren’t available to docker-compose and native packaging methods. While it may be slightly simpler to add this command line flag for Redis to config-seed and use it within the snap, I think that it is simpler from a user’s perspective (as well as a documentation perspective) to have all the EdgeX configuration live within EdgeX. Having configuration items live in multiple locations significantly contributes to user confusion and complexity as the software ages and so trying to minimize this from the 1.0 release is beneficial.

 

 

 

On Tue, May 21, 2019 at 11:13 AM Goodell, Leonard <leonard.goodell@...> wrote:

I prefer PR 1348 as it works for native and snaps, not just Docker. Also, I think it is more straight forward than modifying the toml file during the Docker build.

 

-Lenny

 

From: EdgeX-GoLang@... <EdgeX-GoLang@...> On Behalf Of Trevor.Conn@...
Sent: Tuesday, May 21, 2019 8:41 AM
To: EdgeX-GoLang@...; edgex-tsc-core@...; EdgeX-Devel@...
Subject: [Edgex-golang] Community Feedback Required on PRs 1348 / 1359

 

Hi all --

 

As you're aware from recent working group calls we need to develop a mechanism whereby the service configurations can be easily overridden to use Redis for the upcoming Edinburgh release. In a deployment scenario, we do not want to require an admin to go in and modify the configuration files for Redis to be enabled. It needs to be accomplished either via the Snap, docker-compose or script for automation.

 

We have two PRs for issue 1347 that seek to solve this problem. One of them is mine and I don't think it's appropriate for me to make a unilateral decision, so I'm seeking feedback from the community as to which approach should be accepted.

 

To summarize each approach:

 

1.) PR 1359 utilizes changes to the config-seed Dockerfile that creates copies of the existing service configuration.toml files. It replaces the necessary properties in the duplicated files with Redis values and then injects these into the config-seed image in a different directory. To use this, a Redis-specific docker-compose.yml would utilize the existing --cmd parameter to point at the root location of the Redis configuration files. For example: 

config-seed:
    image: edgexfoundry/docker-core-config-seed-go:0.7.1
    container_name: edgex-config-seed
    command: ["/edgex/cmd/config-seed/config-seed --profile=docker --cmd=/edgex/cmd-redis"]

 

2.) PR 1348 defines a new command line parameter on the config-seed (--database / -d) that defaults to Mongo. If the service is started with "-d=redis" then the database connectivity parameters are overridden from the existing configuration.toml files prior to population of Consul.

 

The essential differences are:

  • Definition of a new command line parameter on the config-seed versus not.
  • Assumptions about whether the config-seed should perform this function in native deployments utilizing Consul.
    • 1348 will accomplish this. 1359 will put this responsibility on the admin since it only touches the Dockerfile.

Since code freeze is on Tuesday the 28th, we need a consensus from the community rather quickly. You are welcome to provide feedback here or on either PR. If no clear preference has emerged by the time we hold the Core Working Group call this Thursday, we will make a decision then.

 

Thanks.

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

Re: [Edgex-golang] Community Feedback Required on PRs 1348 / 1359

Michael Hall
 

Is there any real benefit from making this runtime configurable rather than deploy-time configurable? We could have an edgexfoundry-redis.snap (and docker-compose-redis.yml) that would always use Redis, right from the start.

The user would have to decide which they wanted to use before deploying, but it seems like that would be the case anyway. It could also give us some insights into the demand for one backend of the other, by looking at their separate download statistics.


Michael Hall
mhall119@...
On 5/21/19 2:47 PM, Ian Johnson wrote:

Apologies for the long email, but there's a bit of background necessary to explain why I don't think it's a good idea to use this command line flag in the snap.

With the snap we are in a better position than Docker to use the configuration files more directly because the configuration files live on the user's host file system and not inside the container where modification is tricky. Due to this, we try to strike a nice balance in the snap between allowing the user to modify the configuration files directly and also enable using consul for more automated device management tasks. Our current plan for managing this can be read about in issue #922.


Basically, in the snap we want to have 2 ways to run config-seed, one automated way which runs without the overwrite flag, and one manual way which runs with the overwrite flag. This allows a developer or manual user to easily change configuration for the services by modifying the files locally on their file system directly and then run a single command to push the content of the configuration from the filesystem into Consul.


I don’t think the addition of this new command line option will really help the snap at all. To explain that, let me explain how using redis currently would work. If a user wants to use redis our current mechanism would be just to have the user run:


snap set dbtype=redisdb


(or they could use the snapd REST API to do the same thing)


That then triggers a configuration hook to run, which processes the configuration.toml files locally for redis using a tool called remarshal, then pushes that configuration into consul so that an automated configuration management system can interact with consul to get/set configuration afterwards. This has the combined benefit of allowing a local user or developer to know what and where the configuration items that are set come from. They either originated from local configuration files or from something driving consul. The “snap set” mechanism described above merely is used as a transparent external means to modify something internal to EdgeX, the configuration files and Consul. It’s not meant to store state about EdgeX configuration, just to conveniently trigger those internal changes.


If we now consider using the command line flag that Trevor has proposed, if we are to use that option in the snap, we now need to track internally in the snap what database was configured with the “snap set” command above, and more importantly use that config item to determine what flags to launch config-seed with (dbtype=redis -> --database=redis, etc.). This means that in the snap, EdgeX now has an external system controlling configuration of the system and someone using the snap has a third dimension for control-plane/configuration:


  • Configuration files

  • Consul

  • Snapd configuration items


Previously, the snapd configuration items were only used to track what services were on/off, which is no different to someone using docker-compose to start/stop certain services and is a natural way to track this.


Our intention with the snap is to minimize the extent to which the snap distribution differs from the other distribution methods, but also to add convenient features which the snap can provide that aren’t available to docker-compose and native packaging methods. While it may be slightly simpler to add this command line flag for Redis to config-seed and use it within the snap, I think that it is simpler from a user’s perspective (as well as a documentation perspective) to have all the EdgeX configuration live within EdgeX. Having configuration items live in multiple locations significantly contributes to user confusion and complexity as the software ages and so trying to minimize this from the 1.0 release is beneficial.




On Tue, May 21, 2019 at 11:13 AM Goodell, Leonard <leonard.goodell@...> wrote:

I prefer PR 1348 as it works for native and snaps, not just Docker. Also, I think it is more straight forward than modifying the toml file during the Docker build.

 

-Lenny

 

From: EdgeX-GoLang@... <EdgeX-GoLang@...> On Behalf Of Trevor.Conn@...
Sent: Tuesday, May 21, 2019 8:41 AM
To: EdgeX-GoLang@...; edgex-tsc-core@...; EdgeX-Devel@...
Subject: [Edgex-golang] Community Feedback Required on PRs 1348 / 1359

 

Hi all --

 

As you're aware from recent working group calls we need to develop a mechanism whereby the service configurations can be easily overridden to use Redis for the upcoming Edinburgh release. In a deployment scenario, we do not want to require an admin to go in and modify the configuration files for Redis to be enabled. It needs to be accomplished either via the Snap, docker-compose or script for automation.

 

We have two PRs for issue 1347 that seek to solve this problem. One of them is mine and I don't think it's appropriate for me to make a unilateral decision, so I'm seeking feedback from the community as to which approach should be accepted.

 

To summarize each approach:

 

1.) PR 1359 utilizes changes to the config-seed Dockerfile that creates copies of the existing service configuration.toml files. It replaces the necessary properties in the duplicated files with Redis values and then injects these into the config-seed image in a different directory. To use this, a Redis-specific docker-compose.yml would utilize the existing --cmd parameter to point at the root location of the Redis configuration files. For example: 

config-seed:
    image: edgexfoundry/docker-core-config-seed-go:0.7.1
    container_name: edgex-config-seed
    command: ["/edgex/cmd/config-seed/config-seed --profile=docker --cmd=/edgex/cmd-redis"]

 

2.) PR 1348 defines a new command line parameter on the config-seed (--database / -d) that defaults to Mongo. If the service is started with "-d=redis" then the database connectivity parameters are overridden from the existing configuration.toml files prior to population of Consul.

 

The essential differences are:

  • Definition of a new command line parameter on the config-seed versus not.
  • Assumptions about whether the config-seed should perform this function in native deployments utilizing Consul.
    • 1348 will accomplish this. 1359 will put this responsibility on the admin since it only touches the Dockerfile.

Since code freeze is on Tuesday the 28th, we need a consensus from the community rather quickly. You are welcome to provide feedback here or on either PR. If no clear preference has emerged by the time we hold the Core Working Group call this Thursday, we will make a decision then.

 

Thanks.

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

Re: [Edgex-golang] Community Feedback Required on PRs 1348 / 1359

Ian Johnson
 

Apologies for the long email, but there's a bit of background necessary to explain why I don't think it's a good idea to use this command line flag in the snap.


With the snap we are in a better position than Docker to use the configuration files more directly because the configuration files live on the user's host file system and not inside the container where modification is tricky. Due to this, we try to strike a nice balance in the snap between allowing the user to modify the configuration files directly and also enable using consul for more automated device management tasks. Our current plan for managing this can be read about in issue #922.


Basically, in the snap we want to have 2 ways to run config-seed, one automated way which runs without the overwrite flag, and one manual way which runs with the overwrite flag. This allows a developer or manual user to easily change configuration for the services by modifying the files locally on their file system directly and then run a single command to push the content of the configuration from the filesystem into Consul.


I don’t think the addition of this new command line option will really help the snap at all. To explain that, let me explain how using redis currently would work. If a user wants to use redis our current mechanism would be just to have the user run:


snap set dbtype=redisdb


(or they could use the snapd REST API to do the same thing)


That then triggers a configuration hook to run, which processes the configuration.toml files locally for redis using a tool called remarshal, then pushes that configuration into consul so that an automated configuration management system can interact with consul to get/set configuration afterwards. This has the combined benefit of allowing a local user or developer to know what and where the configuration items that are set come from. They either originated from local configuration files or from something driving consul. The “snap set” mechanism described above merely is used as a transparent external means to modify something internal to EdgeX, the configuration files and Consul. It’s not meant to store state about EdgeX configuration, just to conveniently trigger those internal changes.


If we now consider using the command line flag that Trevor has proposed, if we are to use that option in the snap, we now need to track internally in the snap what database was configured with the “snap set” command above, and more importantly use that config item to determine what flags to launch config-seed with (dbtype=redis -> --database=redis, etc.). This means that in the snap, EdgeX now has an external system controlling configuration of the system and someone using the snap has a third dimension for control-plane/configuration:


  • Configuration files

  • Consul

  • Snapd configuration items


Previously, the snapd configuration items were only used to track what services were on/off, which is no different to someone using docker-compose to start/stop certain services and is a natural way to track this.


Our intention with the snap is to minimize the extent to which the snap distribution differs from the other distribution methods, but also to add convenient features which the snap can provide that aren’t available to docker-compose and native packaging methods. While it may be slightly simpler to add this command line flag for Redis to config-seed and use it within the snap, I think that it is simpler from a user’s perspective (as well as a documentation perspective) to have all the EdgeX configuration live within EdgeX. Having configuration items live in multiple locations significantly contributes to user confusion and complexity as the software ages and so trying to minimize this from the 1.0 release is beneficial.




On Tue, May 21, 2019 at 11:13 AM Goodell, Leonard <leonard.goodell@...> wrote:

I prefer PR 1348 as it works for native and snaps, not just Docker. Also, I think it is more straight forward than modifying the toml file during the Docker build.

 

-Lenny

 

From: EdgeX-GoLang@... <EdgeX-GoLang@...> On Behalf Of Trevor.Conn@...
Sent: Tuesday, May 21, 2019 8:41 AM
To: EdgeX-GoLang@...; edgex-tsc-core@...; EdgeX-Devel@...
Subject: [Edgex-golang] Community Feedback Required on PRs 1348 / 1359

 

Hi all --

 

As you're aware from recent working group calls we need to develop a mechanism whereby the service configurations can be easily overridden to use Redis for the upcoming Edinburgh release. In a deployment scenario, we do not want to require an admin to go in and modify the configuration files for Redis to be enabled. It needs to be accomplished either via the Snap, docker-compose or script for automation.

 

We have two PRs for issue 1347 that seek to solve this problem. One of them is mine and I don't think it's appropriate for me to make a unilateral decision, so I'm seeking feedback from the community as to which approach should be accepted.

 

To summarize each approach:

 

1.) PR 1359 utilizes changes to the config-seed Dockerfile that creates copies of the existing service configuration.toml files. It replaces the necessary properties in the duplicated files with Redis values and then injects these into the config-seed image in a different directory. To use this, a Redis-specific docker-compose.yml would utilize the existing --cmd parameter to point at the root location of the Redis configuration files. For example: 

config-seed:
    image: edgexfoundry/docker-core-config-seed-go:0.7.1
    container_name: edgex-config-seed
    command: ["/edgex/cmd/config-seed/config-seed --profile=docker --cmd=/edgex/cmd-redis"]

 

2.) PR 1348 defines a new command line parameter on the config-seed (--database / -d) that defaults to Mongo. If the service is started with "-d=redis" then the database connectivity parameters are overridden from the existing configuration.toml files prior to population of Consul.

 

The essential differences are:

  • Definition of a new command line parameter on the config-seed versus not.
  • Assumptions about whether the config-seed should perform this function in native deployments utilizing Consul.
    • 1348 will accomplish this. 1359 will put this responsibility on the admin since it only touches the Dockerfile.

Since code freeze is on Tuesday the 28th, we need a consensus from the community rather quickly. You are welcome to provide feedback here or on either PR. If no clear preference has emerged by the time we hold the Core Working Group call this Thursday, we will make a decision then.

 

Thanks.

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

Re: Community Feedback Required on PRs 1348 / 1359

Goodell, Leonard <leonard.goodell@...>
 

I prefer PR 1348 as it works for native and snaps, not just Docker. Also, I think it is more straight forward than modifying the toml file during the Docker build.

 

-Lenny

 

From: EdgeX-GoLang@... <EdgeX-GoLang@...> On Behalf Of Trevor.Conn@...
Sent: Tuesday, May 21, 2019 8:41 AM
To: EdgeX-GoLang@...; edgex-tsc-core@...; EdgeX-Devel@...
Subject: [Edgex-golang] Community Feedback Required on PRs 1348 / 1359

 

Hi all --

 

As you're aware from recent working group calls we need to develop a mechanism whereby the service configurations can be easily overridden to use Redis for the upcoming Edinburgh release. In a deployment scenario, we do not want to require an admin to go in and modify the configuration files for Redis to be enabled. It needs to be accomplished either via the Snap, docker-compose or script for automation.

 

We have two PRs for issue 1347 that seek to solve this problem. One of them is mine and I don't think it's appropriate for me to make a unilateral decision, so I'm seeking feedback from the community as to which approach should be accepted.

 

To summarize each approach:

 

1.) PR 1359 utilizes changes to the config-seed Dockerfile that creates copies of the existing service configuration.toml files. It replaces the necessary properties in the duplicated files with Redis values and then injects these into the config-seed image in a different directory. To use this, a Redis-specific docker-compose.yml would utilize the existing --cmd parameter to point at the root location of the Redis configuration files. For example: 

config-seed:
    image: edgexfoundry/docker-core-config-seed-go:0.7.1
    container_name: edgex-config-seed
    command: ["/edgex/cmd/config-seed/config-seed --profile=docker --cmd=/edgex/cmd-redis"]

 

2.) PR 1348 defines a new command line parameter on the config-seed (--database / -d) that defaults to Mongo. If the service is started with "-d=redis" then the database connectivity parameters are overridden from the existing configuration.toml files prior to population of Consul.

 

The essential differences are:

  • Definition of a new command line parameter on the config-seed versus not.
  • Assumptions about whether the config-seed should perform this function in native deployments utilizing Consul.
    • 1348 will accomplish this. 1359 will put this responsibility on the admin since it only touches the Dockerfile.

Since code freeze is on Tuesday the 28th, we need a consensus from the community rather quickly. You are welcome to provide feedback here or on either PR. If no clear preference has emerged by the time we hold the Core Working Group call this Thursday, we will make a decision then.

 

Thanks.

 

Trevor Conn
Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

Community Feedback Required on PRs 1348 / 1359

Trevor.Conn@...
 

Hi all --


As you're aware from recent working group calls we need to develop a mechanism whereby the service configurations can be easily overridden to use Redis for the upcoming Edinburgh release. In a deployment scenario, we do not want to require an admin to go in and modify the configuration files for Redis to be enabled. It needs to be accomplished either via the Snap, docker-compose or script for automation.


We have two PRs for issue 1347 that seek to solve this problem. One of them is mine and I don't think it's appropriate for me to make a unilateral decision, so I'm seeking feedback from the community as to which approach should be accepted.


To summarize each approach:


1.) PR 1359 utilizes changes to the config-seed Dockerfile that creates copies of the existing service configuration.toml files. It replaces the necessary properties in the duplicated files with Redis values and then injects these into the config-seed image in a different directory. To use this, a Redis-specific docker-compose.yml would utilize the existing --cmd parameter to point at the root location of the Redis configuration files. For example: 

config-seed:
    image: edgexfoundry/docker-core-config-seed-go:0.7.1
    container_name: edgex-config-seed
    command: ["/edgex/cmd/config-seed/config-seed --profile=docker --cmd=/edgex/cmd-redis"]


2.) PR 1348 defines a new command line parameter on the config-seed (--database / -d) that defaults to Mongo. If the service is started with "-d=redis" then the database connectivity parameters are overridden from the existing configuration.toml files prior to population of Consul.


The essential differences are:

  • Definition of a new command line parameter on the config-seed versus not.
  • Assumptions about whether the config-seed should perform this function in native deployments utilizing Consul.
    • 1348 will accomplish this. 1359 will put this responsibility on the admin since it only touches the Dockerfile.
Since code freeze is on Tuesday the 28th, we need a consensus from the community rather quickly. You are welcome to provide feedback here or on either PR. If no clear preference has emerged by the time we hold the Core Working Group call this Thursday, we will make a decision then.


Thanks.


Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Trevor_Conn@...
Round Rock, TX  USA

Decision Notice Core APIs

Trevor.Conn@...
 

Hi all – I wanted to make you aware of some decisions we made this morning in the Core WG call. This is in regard to changes to the core-command and core-metadata APIs that will be made prior to the Edinburgh code freeze. There are more details and context in today’s notes which have been posted here:

https://wiki.edgexfoundry.org/display/FA/Core+Working+Group

 

In short, the accepted changes are as follows. The rationale is provided in the document above. If you fore-see a problem with this or have a legitimate use case that would be adversely affected by the removal of a given endpoint, please speak up ASAP.

 

Core-command

Removal of the following endpoints

PUT /device/{id} (Used to set admin/operating State on device)

                •Duplicate with the following metadata routes

                                oPUT /device/{id}/adminstate/{adminState}

                                oPUT /device/{id}/opstate/{opState}

PUT /device/name/{name}(Used to set admin/operating State on device)

                •Duplicate with the following metadata routes

                                oPUT /device/name/{name}/adminstate/{adminState}

                                oPUT /device/name/{name}/opstate/{opState}

 

Core-metadata

Removal of the following endpoints

POST & PUT /command (adds or updates a command)

DELETE /command/id/{id}(deletes a command by its ID)

These endpoints today have no real effect because whenever we return a list of commands for a device, those commands come from the DeviceProfile and not the Commands collection.

 

Trevor Conn

Technical Staff Engineer

Core Working Group Chair of EdgeX Foundry

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA

 

Re: State of UI

James.White2@...
 

The VMWare team recently started cleaning it up for the Edinburgh release. Both, I am told, will be ready by freeze date.

-----Original Message-----
From: Drasko DRASKOVIC <drasko@...>
Sent: Tuesday, April 23, 2019 3:08 AM
To: White2, James
Cc: edgex-devel@...
Subject: Re: [Edgex-devel] State of UI


[EXTERNAL EMAIL]

Hi Jim,

On Tue, Apr 23, 2019 at 1:39 AM <James.White2@...> wrote:

Yes - VMWare is working to update the ui-go.
Do you have any info when this one will be released?

IoTech is updating this one: https://github.com/edgexfoundry/edgex-ui-clojure.
Last commit 5 months ago, looks like abandoned project to me.


One in holding is older version of the ui-go.
I tried this one, and it looks to me like it is not functional - last commit 8 months ago. Moreover, we 2 of those in holding, so it looks like a mess to me. ONe should be definitely removed, because it is confusing. Other should be either updated or removed.

Best regards,
Drasko DRASKOVIC
Mainflux CEO
EdgeX Foundry TSC member

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: State of UI

Drasko DRASKOVIC
 

Hi Jim,

On Tue, Apr 23, 2019 at 1:39 AM <James.White2@...> wrote:

Yes - VMWare is working to update the ui-go.
Do you have any info when this one will be released?

IoTech is updating this one: https://github.com/edgexfoundry/edgex-ui-clojure.
Last commit 5 months ago, looks like abandoned project to me.


One in holding is older version of the ui-go.
I tried this one, and it looks to me like it is not functional - last
commit 8 months ago. Moreover, we 2 of those in holding, so it looks
like a mess to me. ONe should be definitely removed, because it is
confusing. Other should be either updated or removed.

Best regards,
Drasko DRASKOVIC
Mainflux CEO
EdgeX Foundry TSC member

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: State of UI

James.White2@...
 

Yes - VMWare is working to update the ui-go. IoTech is updating this one: https://github.com/edgexfoundry/edgex-ui-clojure.

One in holding is older version of the ui-go.

-----Original Message-----
From: EdgeX-Devel@... <EdgeX-Devel@...> On Behalf Of Drasko DRASKOVIC
Sent: Monday, April 22, 2019 6:27 PM
To: edgex-devel@...
Subject: [Edgex-devel] State of UI


[EXTERNAL EMAIL]

Hello,
what is he state of EdgeX UI?

I can see one here:
https://github.com/edgexfoundry-holding/edgex-ui-go and another one
here: https://github.com/edgexfoundry-holding/edgex-ui

Is there someone working on UI?

Best regards,
Drasko DRASKOVIC
Mainflux CEO
EdgeX Foundry TSC member

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

State of UI

Drasko DRASKOVIC
 

Hello,
what is he state of EdgeX UI?

I can see one here:
https://github.com/edgexfoundry-holding/edgex-ui-go and another one
here: https://github.com/edgexfoundry-holding/edgex-ui

Is there someone working on UI?

Best regards,
Drasko DRASKOVIC
Mainflux CEO
EdgeX Foundry TSC member

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Re: 2019 EdgeX Foundry Awards

Michael Hall
 

Reminder to everyone that the call for nominations for the 2019 EdgeX Foundry Awards ends tomorrow, so please get all of your nominations (you can nominate as many people as you like) in soon!

Thank you

On 3/21/19 5:01 PM, Michael Hall wrote:

Greetings everyone,

We have opened up nominations for our 2019 EdgeX Foundry Awards. We will be accepting nominations for the next two weeks, closing at the end of day on April 3rd. The nomination process is open to everyone, whether you're from a member company or not. Anybody can be nominated, and anybody can make a nomination. I encourage you all to participate to give recognition to your fellow contributors.

Nominations can be make for the following two award categories:

Innovation Award:  The Innovation Award recognizes individuals who have contributed (contributing back to open source) the most innovative solution to the open source EdgeX project over the past year.

Contribution Award:  The Contribution Award recognizes individuals who have contributed leadership and helped EdgeX Foundry advance and continue momentum in the past year. This includes individuals who have led work groups, special projects, and/or contributed large amounts of code, bug fixes, marketing material, documentation, or otherwise significantly advanced the efforts of EdgeX with their drive and leadership. 

You will be asked to briefly explain your reasons for the nomination, and you may provide links to the work of that person to support your reasons.

After all nominations are in, the TSC will vote on each and the top two nominees from each category will be presented with a trophy at one of our upcoming in person events!

The nomination form is here: https://goo.gl/forms/cNYbuthMPheiv5s22

Please reach out to me via email or Slack is you have any trouble filling it our or questions about the process.

-- 
Michael Hall
Contractor, The Linux Foundation
-- 
Michael Hall
Contractor, The Linux Foundation

RPi 4

Drasko DRASKOVIC
 

https://www.mickmake.com/post/the-raspberry-pi-4-has-landed-a-sneak-peak-prototype-review/amp?__twitter_impression=true

BR,
Drasko DRASKOVIC
Mainflux CEO
EdgeX Foundry TSC member

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic