Re: [ovs-dev] [OVN][RAFT] Follower refusing new entries from leader
Hi,Han Hope to receive your reply. Thanks, Yun 在 2019-11-28 16:17:07，"taoyunupt" 写道： Hi,Han Another question. NO COMPACT. If restart a follower , leader sender some entries during the break time, when it has started, if it also happend to this problem? What is the difference between simply restart and COMPACT with restart ? Thanks, Yun 在 2019-11-28 13:58:36，"taoyunupt" 写道： Hi,Han Thanks for your reply. I think maybe we can disconnect the failed follower from the Haproxy then synchronize the date, after all completed, reconnect it to Haproxy again. But I do not know how to synchronize actually. It is just my naive idea. Do you have some suggestion about how to fix this problem. If not very completed, I wii have a try. Thanks Yun 在 2019-11-28 11:47:55，"Han Zhou" 写道： On Wed, Nov 27, 2019 at 7:22 PM taoyunupt wrote: > > Hi, > My OVN cluster has 3 OVN-northd nodes, They are proxied by Haproxy with a > VIP. Recently, I restart OVN cluster frequently. One of the members report > the logs below. > After read the code and paper of RAFT, it seems normal process ,If the > follower does not find an entry in its log with the same index and term, then > it refuses the new entries. > I think it's reasonable to refuse. But, as we could not control Haproxy > or some proxy maybe, so it will happen error when an session assignate to the > failed follower. > > Does have some means or ways to solve this problem. Maybe we can kick off > the failed follower or disconnect it from the haproxy then synchronize the > date ? Hope to hear your suggestion. > > > 2019-11-27T14:22:17.060Z|00240|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > 2019-11-27T14:22:17.064Z|00241|raft|ERR|Dropped 34 log messages in last 12 > seconds (most recently, 0 seconds ago) due to excessive rate > 2019-11-27T14:22:17.064Z|00242|raft|ERR|internal error: deferred append_reply > message completed but not ready to send because message index 14890 is past > last synced index 0: a2b2 append_reply "mismatch past end of log": term=1103 > log_end=14891 result="inconsistency" > 2019-11-27T14:22:17.402Z|00243|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > > > [root@ovn1 ~]# ovs-appctl -t /var/run/openvswitch/ovnsb_db.ctl > cluster/status OVN_Southbound > a2b2 > Name: OVN_Southbound > Cluster ID: 4c54 (4c546513-77e3-4602-b211-2e200014ad79) > Server ID: a2b2 (a2b2a9c5-cf58-4724-8421-88fd5ca5d94d) > Address: tcp:10.254.8.209:6644 > Status: cluster member > Role: leader > Term: 1103 > Leader: self > Vote: self > > Log: [42052, 51009] > Entries not yet committed: 0 > Entries not yet applied: 0 > Connections: ->beaf ->9a33 <-9a33 <-beaf > Servers: > a2b2 (a2b2 at tcp:10.254.8.209:6644) (self) next_index=15199 > match_index=51008 > beaf (beaf at tcp:10.254.8.208:6644) next_index=51009 match_index=0 > 9a33 (9a33 at tcp:10.254.8.210:6644) next_index=51009 match_index=51008 > I think it is a bug. I noticed that this problem happens when the cluster is restarted after DB compaction. I mentioned it in one of the test cases: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L252 I also mentioned another problem related to compaction: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L239 I was planning to debug these but didn't get the time yet. I will try to find some time next week (it would be great if you could figure it out and submit patches). Thanks, Han ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] ofctrl_check_and_add_flow: Replace the actions of an existing flow if actions have changed.
From: Numan Siddique
If ofctrl_check_and_add_flow(F') is called where flow F' has match-actions (M,
A2)
and if there already exists a flow F with match-actions (M, A1) in the desired
flow
table, then this function doesn't update the existing flow F with new actions
actions A2.
This patch fixes it. Presently we don't see any issues because of this
behaviour.
But it's better to fix it.
Signed-off-by: Numan Siddique
---
controller/ofctrl.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/controller/ofctrl.c b/controller/ofctrl.c
index 10edd84fb..5a174da48 100644
--- a/controller/ofctrl.c
+++ b/controller/ofctrl.c
@@ -667,14 +667,23 @@ ofctrl_check_and_add_flow(struct ovn_desired_flow_table
*flow_table,
ovn_flow_log(f, "ofctrl_add_flow");
-if (ovn_flow_lookup(&flow_table->match_flow_table, f, true)) {
-if (log_duplicate_flow) {
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
-if (!VLOG_DROP_DBG(&rl)) {
-char *s = ovn_flow_to_string(f);
-VLOG_DBG("dropping duplicate flow: %s", s);
-free(s);
+struct ovn_flow *existing_f =
+ovn_flow_lookup(&flow_table->match_flow_table, f, true);
+if (existing_f) {
+if (ofpacts_equal(f->ofpacts, f->ofpacts_len,
+ existing_f->ofpacts, existing_f->ofpacts_len)) {
+if (log_duplicate_flow) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
+if (!VLOG_DROP_DBG(&rl)) {
+char *s = ovn_flow_to_string(f);
+VLOG_DBG("dropping duplicate flow: %s", s);
+free(s);
+}
}
+} else {
+free(existing_f->ofpacts);
+existing_f->ofpacts = xmemdup(f->ofpacts, f->ofpacts_len);
+existing_f->ofpacts_len = f->ofpacts_len;
}
ovn_flow_destroy(f);
return;
--
2.23.0
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto: fix stack-buffer-overflow
On Fri, Nov 29, 2019 at 11:44 AM Linhaifeng wrote: > > Should use flow->actions not &flow->actions. > > here is ASAN report: > = > ==57189==ERROR: AddressSanitizer: stack-buffer-overflow on address > 0x428fa0e8 at pc 0x7f61a520 bp 0x428f9420 sp 0x428f9498 READ > of size 196 at 0x428fa0e8 thread T150 (revalidator22) > #0 0x7f61a51f in __interceptor_memcpy (/lib64/libasan.so.4+0xa251f) > #1 0xd26a3b2b in ofpbuf_put lib/ofpbuf.c:426 > #2 0xd26a30cb in ofpbuf_clone_data_with_headroom lib/ofpbuf.c:248 > #3 0xd26a2e77 in ofpbuf_clone_with_headroom lib/ofpbuf.c:218 > #4 0xd26a2dc3 in ofpbuf_clone lib/ofpbuf.c:208 > #5 0xd23e3993 in ukey_set_actions ofproto/ofproto-dpif-upcall.c:1640 > #6 0xd23e3f03 in ukey_create__ ofproto/ofproto-dpif-upcall.c:1696 > #7 0xd23e553f in ukey_create_from_dpif_flow > ofproto/ofproto-dpif-upcall.c:1806 > #8 0xd23e65fb in ukey_acquire ofproto/ofproto-dpif-upcall.c:1984 > #9 0xd23eb583 in revalidate ofproto/ofproto-dpif-upcall.c:2625 > #10 0xd23dee5f in udpif_revalidator ofproto/ofproto-dpif-upcall.c:1076 > #11 0xd26b84ef in ovsthread_wrapper lib/ovs-thread.c:708 > #12 0x7e74a8bb in start_thread (/lib64/libpthread.so.0+0x78bb) > #13 0x7e0665cb in thread_start (/lib64/libc.so.6+0xd55cb) > > Address 0x428fa0e8 is located in stack of thread T150 (revalidator22) at > offset 328 in frame > #0 0xd23e4cab in ukey_create_from_dpif_flow > ofproto/ofproto-dpif-upcall.c:1762 > > This frame has 4 object(s): > [32, 96) 'actions' > [128, 192) 'buf' > [224, 328) 'full_flow' > [384, 2432) 'stub' <== Memory access at offset 328 partially underflows > this variable > HINT: this may be a false positive if your program uses some custom stack > unwind mechanism or swapcontext > (longjmp and C++ exceptions *are* supported) Thread T150 > (revalidator22) created by T0 here: > #0 0x7f5b0f7f in __interceptor_pthread_create > (/lib64/libasan.so.4+0x38f7f) > #1 0xd26b891f in ovs_thread_create lib/ovs-thread.c:792 > #2 0xd23dc62f in udpif_start_threads ofproto/ofproto-dpif-upcall.c:639 > #3 0xd23daf87 in ofproto_set_flow_table > ofproto/ofproto-dpif-upcall.c:446 > #4 0xd230ff7f in dpdk_evs_cfg_set vswitchd/bridge.c:1134 > #5 0xd2310097 in bridge_reconfigure vswitchd/bridge.c:1148 > #6 0xd23279d7 in bridge_run vswitchd/bridge.c:3944 > #7 0xd23365a3 in main vswitchd/ovs-vswitchd.c:240 > #8 0x7dfb1adf in __libc_start_main (/lib64/libc.so.6+0x20adf) > #9 0xd230a3d3 > (/usr/sbin/ovs-vswitchd-2.7.0-1.1.RC5.001.asan+0x26f3d3) > > SUMMARY: AddressSanitizer: stack-buffer-overflow > (/lib64/libasan.so.4+0xa251f) in __interceptor_memcpy Shadow bytes around the > buggy address: > 0x200fe851f3c0: 00 00 00 00 f1 f1 f1 f1 f8 f2 f2 f2 00 00 00 00 > 0x200fe851f3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x200fe851f3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x200fe851f3f0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 > 0x200fe851f400: f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 > =>0x200fe851f410: 00 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 > 0x200fe851f420: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 > 0x200fe851f430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x200fe851f440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x200fe851f450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x200fe851f460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte > legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user:f7 > Container overflow: fc > Array cookie:ac > Intra object redzone:bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone:cb > ==57189==ABORTING > > Signed-off-by: Linhaifeng Acked-by: Numan Siddique Numan > --- > ofproto/ofproto-dpif-upcall.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c > index dc30824771..c2fc527a31 100644 > --- a/ofproto/ofproto-dpif-upcall.c > +++ b/ofproto/ofproto-dpif-upcall.c > @@ -1796,7 +1796,7 @@ ukey_create_from_dpif_flow(const struct udpif *udpif, > } > > reval_seq = seq_read(udpif->reval_seq) - 1; /* Ensure revalidation. */ > -ofpbuf_use_const(&actions, &flow->actions, flow->actions_len); > +ofpbuf_use_const(&actions, flow->action
Re: [ovs-dev] [PATCH] dpif-netdev: Use netdev-offload API for port lookup while offloading.
Hi Ilya,
The first two RFC series are confirmed. They require the third RFC series to
enable user space vport offloading.
1. https://patchwork.ozlabs.org/project/openvswitch/list/?series=143209
("netdev-offload: Prerequisites of vport offloading via DPDK")
2. https://patchwork.ozlabs.org/project/openvswitch/list/?series=144559
("dpif-netdev: Use netdev-offload API for port lookup while offloading.")
3. https://patchwork.ozlabs.org/project/openvswitch/list/?series=144826
("[ovs-dev,RFC,v1] netdev-dpdk: Add flow_api support for netdev vports")
Can you please merge all the three series into one patch set?
Then we will be able to test it and send our feedback.
Regards,
Ophir
> -Original Message-
> From: Ilya Maximets
> Sent: Friday, November 22, 2019 5:42 PM
> To: ovs-dev@openvswitch.org
> Cc: Ophir Munk ; Roni Bar Yanai
> ; Eli Britstein ; Ian Stokes
> ; Ilya Maximets
> Subject: [PATCH] dpif-netdev: Use netdev-offload API for port lookup while
> offloading.
>
> Currently, while offloading, userspace datapath tries to lookup netdev in a
> local port list of the datapath interface instance. However, there is no
> guarantee that these netdevs are the same netdevs that netdev-offload
> module operates with and, as a result, there is no any guarantee that these
> netdev instances has initialized flow API.
>
> dpif-netdev should request ports from the netdev-offload module as
> intended by flow offloading API in a same way as dpif-netlink does.
> This will also give us performance benefits because we don't need to hold
> global port mutex anymore.
>
> We're not noticing any significant issues with current code, but it will
> become
> a serious issue in the future, e.g. with offloading for virtual tunneling
> ports.
>
> Reported-by: Ophir Munk
> Fixes: 241bad15d99a ("dpif-netdev: associate flow with a mark id")
> Signed-off-by: Ilya Maximets
> ---
> lib/dpif-netdev.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index 5142bad1d..885a4df36
> 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -2266,15 +2266,14 @@ mark_to_flow_disassociate(struct
> dp_netdev_pmd_thread *pmd,
> * remove the flow from hardware and free the mark.
> */
> if (flow_mark_has_no_ref(mark)) {
> -struct dp_netdev_port *port;
> +struct netdev *port;
> odp_port_t in_port = flow->flow.in_port.odp_port;
>
> -ovs_mutex_lock(&pmd->dp->port_mutex);
> -port = dp_netdev_lookup_port(pmd->dp, in_port);
> +port = netdev_ports_get(in_port, pmd->dp->dpif->dpif_class);
> if (port) {
> -ret = netdev_flow_del(port->netdev, &flow->mega_ufid, NULL);
> +ret = netdev_flow_del(port, &flow->mega_ufid, NULL);
> +netdev_close(port);
> }
> -ovs_mutex_unlock(&pmd->dp->port_mutex);
>
> flow_mark_free(mark);
> VLOG_DBG("Freed flow mark %u\n", mark); @@ -2372,12 +2371,12 @@
> dp_netdev_flow_offload_del(struct dp_flow_offload_item *offload) static
> int dp_netdev_flow_offload_put(struct dp_flow_offload_item *offload) {
> -struct dp_netdev_port *port;
> struct dp_netdev_pmd_thread *pmd = offload->pmd;
> struct dp_netdev_flow *flow = offload->flow;
> odp_port_t in_port = flow->flow.in_port.odp_port;
> bool modification = offload->op ==
> DP_NETDEV_FLOW_OFFLOAD_OP_MOD;
> struct offload_info info;
> +struct netdev *port;
> uint32_t mark;
> int ret;
>
> @@ -2411,17 +2410,16 @@ dp_netdev_flow_offload_put(struct
> dp_flow_offload_item *offload)
> }
> info.flow_mark = mark;
>
> -ovs_mutex_lock(&pmd->dp->port_mutex);
> -port = dp_netdev_lookup_port(pmd->dp, in_port);
> -if (!port || netdev_vport_is_vport_class(port->netdev->netdev_class)) {
> -ovs_mutex_unlock(&pmd->dp->port_mutex);
> +port = netdev_ports_get(in_port, pmd->dp->dpif->dpif_class);
> +if (!port || netdev_vport_is_vport_class(port->netdev_class)) {
> +netdev_close(port);
> goto err_free;
> }
> -ret = netdev_flow_put(port->netdev, &offload->match,
> +ret = netdev_flow_put(port, &offload->match,
>CONST_CAST(struct nlattr *, offload->actions),
>offload->actions_len, &flow->mega_ufid, &info,
>NULL);
> -ovs_mutex_unlock(&pmd->dp->port_mutex);
> +netdev_close(port);
>
> if (ret) {
> goto err_free;
> --
> 2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] ipf question
>
>
> -- Forwarded message -
> From: Li,Rongqing
> Date: Thu, Nov 28, 2019 at 12:17 AM
> Subject: 答复: ipf question
> To: Darrell Ball
> Cc: ovs dev
>
>
> It does not work for me
>
>
>
> Normal it should like below
>
>
>
>
> But when the size is 5,
>
>
>
>
> 50% is loss
>
>
>
>
>
>
> Thanks
>
>
>
> -RongQing
>
Hi Li,Rongqing
This is what I see
ping -s 5 -q -c 20 -i 0.1 -w 2
20 packets transmitted, 17 received, 15% packet loss, time 0ms
Note that all fragments for a given packet do not arrive into OVS in
sequence but are interleaved with other packet fragments,
hence > 1 packet's fragments are waiting to be sent back out from ipf when
the test ends, so this result is about what I expect.
A couple things to watch for in your testing:
1/ Make sure you are not filling up the maximum fragments stored (which is
for DOS protection)
This might lead to long RTT until these are flushed out; otherwise you have
something
else going on in the src or dest VMs reassembly
.
i..e. check
ovs-appctl dpctl/ipf-get-status
these fields:
max num frags (v4/v6):
num frag:
2/ Watch for datapath flows being revalidated out due to inactivity and
setup again; packets for
a stream are not normally spaced 1 sec apart, so revalidation may kick in;
use short '-i'; see above
New flows will change the recirc id and we are now doing strict checking
for resume flows.
Thanks Darrell
>
>
> *发件人:* Darrell Ball [mailto:dlu...@gmail.com]
> *发送时间:* 2019年11月26日 10:38
> *收件人:* Li,Rongqing
> *抄送:* ovs dev
> *主题:* Re: ipf question
>
>
>
> Thanks Li,Rongqing
>
>
>
> On Mon, Nov 18, 2019 at 9:35 PM Li,Rongqing wrote:
>
> Thanks, Darrell
>
>
>
> I can try to test it
>
>
>
> thanks !; can you try this 2 patch series ?
>
>
>
> dball@ubuntu:~/openvswitch/ovs$ cat
> outgoing2/0001-dp-packet-Cache-batch-action-list-in-batch.patch
> From 80436fb57a54ecfd532e99086dbb0e5142415070 Mon Sep 17 00:00:00 2001
> From: Darrell Ball
> Date: Sun, 24 Nov 2019 17:29:07 -0800
> Subject: [patch v1 1/2] dp-packet: Cache batch action list in batch.
> To: d...@openvswitch.org
>
> Cache the batch action list in the batch itself. This will be
> used in a subsequent patch.
>
> Signed-off-by: Darrell Ball
> ---
> lib/dp-packet.h | 27 ++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/lib/dp-packet.h b/lib/dp-packet.h
> index 14f0897..77df801 100644
> --- a/lib/dp-packet.h
> +++ b/lib/dp-packet.h
> @@ -775,9 +775,11 @@ enum { NETDEV_MAX_BURST = 32 }; /* Maximum number
> packets in a batch. */
>
> struct dp_packet_batch {
> size_t count;
> +size_t actions_len;
> +const struct nlattr *actions;
> +struct dp_packet *packets[NETDEV_MAX_BURST];
> bool trunc; /* true if the batch needs truncate. */
> bool do_not_steal; /* Indicate that the packets should not be stolen.
> */
> -struct dp_packet *packets[NETDEV_MAX_BURST];
> };
>
> static inline void
> @@ -786,6 +788,8 @@ dp_packet_batch_init(struct dp_packet_batch *batch)
> batch->count = 0;
> batch->trunc = false;
> batch->do_not_steal = false;
> +batch->actions = NULL;
> +batch->actions_len = 0;
> }
>
> static inline void
> @@ -930,6 +934,27 @@ dp_packet_batch_reset_cutlen(struct dp_packet_batch
> *batch)
> }
> }
>
> +static inline void
> +dp_packet_batch_set_action_ctx(struct dp_packet_batch *batch,
> + const struct nlattr *actions,
> + size_t actions_len)
> +{
> +batch->actions = actions;
> +batch->actions_len = actions_len;
> +}
> +
> +static inline const struct nlattr *
> +dp_packet_batch_get_actions(struct dp_packet_batch *batch)
> +{
> +return batch->actions;
> +}
> +
> +static inline size_t
> +dp_packet_batch_get_action_len(struct dp_packet_batch *batch)
> +{
> +return batch->actions_len;
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> --
> 1.9.1
>
>
>
> dball@ubuntu:~/openvswitch/ovs$ cat
> outgoing2/0002-ipf-Resume-fragments-in-same-action-list.patch
> From 4aefd4e791f9d7b6ef916e41136cb59e6020bb22 Mon Sep 17 00:00:00 2001
> From: Darrell Ball
> Date: Sun, 24 Nov 2019 17:33:58 -0800
> Subject: [patch v1 2/2] ipf: Resume fragments in same action list.
> To: d...@openvswitch.org
>
> Once fragments are reassembled and go through conntrack, the fragments
> need to resume processing in the same action list. There is a
> semantic requirement that the list have, at most, one conntrack action,
> so this specifies the resume point in the list as well. A memcmp is
> used to compare pre and post processing lists as padding is zeroed out,
> therefore having predictable values.
>
> Signed-off-by: Darrell Ball
> ---
> lib/dpif-netdev.c | 1 +
> lib/ipf.c | 49 -
> 2 files changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 5142bad..3ddca5b 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -
[ovs-dev] Planes de carrera y sucesión
Buen día El cupo del curso está por llenarse y quise aprovechar la oportunidad de hacerte una última invitación: •Nombre: CDMX: Planes de carrera y sucesión •¿Cuándo?: Viernes 06 de Diciembre •Formato: Presencial. •Instructor: Lyz Escalante •Lugar: En Vivo desde su computadora Desarrollaremos planes de carrera y sucesión que aseguren el funcionamiento óptimo de una empresa. Proporcionaremos las herramientas más importantes y de vanguardia que se están utilizando para medir la satisfacción de los clientes y que nos ayudarán a centrar la estrategia de nuestra organización en las necesidades de nuestro cliente. Si el tema del curso no se apega a tus necesidades podemos ayudarte con cursos privados personalizados en línea o presenciales. Solicita informes sin compromiso. En este curso participan empresas de todo el país y nuestro instructor es un experto en el tema que puede atender directamente las dudas y comentarios de tu equipo de trabajo. Solicita información respondiendo a este correo con la Planes, junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: Números de Atención: (045) 55 15 54 66 30 - (045) 55 85 56 72 93 - (045) 55 30 16 70 85 Qué tengas un gran día. Saludos. Si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas @innovalearn.net ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Talento humano de diferentes niveles
11 de Diciembre | Horario de 10:00 a 17:00 hrs. | (hora del centro de México) - Contratación eficiente de mandos operativos y medios - Una empresa puede tener las mejores instalaciones, los mejores instrumentos de trabajo, incluso, lo mejores directivos, pero le haría falta un elemento esencial: la fuerza laboral aquellas personas ue día a día hacen realidad los objetivos estratégicos de una organización, ponen en marcha los planes a través de acciones concretas, es decir, están en la operación. ¿Qué aprenderás?: - El participante conocerá el panorama actual del reclutamiento y contratación dentro de las organizaciones. - El participante conocerá las herramientas de reclutamiento y selección másutilizadas para los puestos operativos y mandos medios. - El participante conocerá las tendencias de Recursos Humanos 3.0, así como parala Gestión del personal. - El participante obtendrá herramientas prácticas para trabajar la incorporación de talento humano de diferentes niveles. Solicita información respondiendo a este correo con la palabra Operativosn los siguientes datos: Nombre: Correo electrónico: Número telefónico: Dirigido a: Ejecutivos, jefes, gerentes y directores de RRHH, Administración, Desarrollo Humano o toda área relacionada con el manejo de personal. Profesionales y empresarios con personal a su cargo. Números de Atención: (045) 55 15 54 66 30 - (045) 55 85567293 - (045) 5530167085 En caso de que haya recibido este correo sin haberlo solicitado o si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas@ innovalearn.net ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
