FAQ
I am getting this error after trying to import a Java Design job into a
workflow.

[17/Nov/2012 00:50:17 +0000] middleware INFO Processing exception:
list index out of range: Traceback (most recent call last):
File
"/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
line 100, in get_response
response = callback(request, *callback_args, **callback_kwargs)
File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75, in
decorate
return view_func(request, *args, **kwargs)
File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 268, in
edit_workflow
graph = workflow.gen_graph(actions_formset.forms, **graph_options)
File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
gen_graph
return django_mako.render_to_string(template, {'nodes':
self.get_hierarchy(), 'index': index})
File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
get_hierarchy
return self.get_hierarchy_rec(node) + [[Kill.objects.get(name='kill',
workflow=node.workflow)],
File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
get_hierarchy_rec
return [node] + self.get_hierarchy_rec(child)
File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
get_hierarchy_rec
return [node] + self.get_hierarchy_rec(child)
File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
get_hierarchy_rec
return [node] + self.get_hierarchy_rec(child)
File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
get_hierarchy_rec
child = Link.objects.filter(parent=node).exclude(name__in=['related',
'kill'])[0].child
File
"/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
line 189, in __getitem__
return list(qs)[0]
IndexError: list index out of range

Can anybody help? I don't want to create the workflow from scratch again.

Thanks,
Ben

Search Discussions

  • Abraham Elmahrek at Nov 17, 2012 at 1:16 am
    Hey,

    Can you provide me with a data export? (/usr/share/hue/build/env/bin/hue
    dumpdata oozie).

    -Abe
    On 11/16/12 4:55 PM, bkim@adconion.com wrote:
    I am getting this error after trying to import a Java Design job into
    a workflow.

    [17/Nov/2012 00:50:17 +0000] middleware INFO Processing exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75,
    in decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line
    268, in edit_workflow
    graph = workflow.gen_graph(actions_formset.forms, **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) +
    [[Kill.objects.get(name='kill', workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child =
    Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    Can anybody help? I don't want to create the workflow from scratch again.

    Thanks,
    Ben
  • Benjamin Kim at Nov 17, 2012 at 1:38 am
    Hi Abe,

    Which log files do you need specifically?

    Thanks,
    Ben

    On Friday, November 16, 2012 5:16:03 PM UTC-8, abe wrote:

    Hey,

    Can you provide me with a data export? (/usr/share/hue/build/env/bin/hue
    dumpdata oozie).

    -Abe
    On 11/16/12 4:55 PM, bk...@adconion.com <javascript:> wrote:
    I am getting this error after trying to import a Java Design job into
    a workflow.

    [17/Nov/2012 00:50:17 +0000] middleware INFO Processing exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75,
    in decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line
    268, in edit_workflow
    graph = workflow.gen_graph(actions_formset.forms, **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) +
    [[Kill.objects.get(name='kill', workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child =
    Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    Can anybody help? I don't want to create the workflow from scratch again.
    Thanks,
    Ben
  • Abraham Elmahrek at Nov 17, 2012 at 1:43 am
    Hey Benjamin,

    I just need a datadump. The command I provided in parenthesis should work!

    -Abe
    On 11/16/12 5:38 PM, Benjamin Kim wrote:
    Hi Abe,

    Which log files do you need specifically?

    Thanks,
    Ben


    On Friday, November 16, 2012 5:16:03 PM UTC-8, abe wrote:

    Hey,

    Can you provide me with a data export?
    (/usr/share/hue/build/env/bin/hue
    dumpdata oozie).

    -Abe
    On 11/16/12 4:55 PM, bk...@adconion.com <javascript:> wrote:
    I am getting this error after trying to import a Java Design job into
    a workflow.

    [17/Nov/2012 00:50:17 +0000] middleware INFO Processing
    exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75,
    in decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line
    268, in edit_workflow
    graph = workflow.gen_graph(actions_formset.forms,
    **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) +
    [[Kill.objects.get(name='kill', workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child =
    Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    Can anybody help? I don't want to create the workflow from
    scratch again.
    Thanks,
    Ben
  • Benjamin Kim at Nov 17, 2012 at 1:56 am
    Hi Abe,

    Does it output the data to a file somewhere? I ran the command, and nothing
    but "[]" came back.

    Thanks,
    Ben
    On Friday, November 16, 2012 5:43:07 PM UTC-8, abe wrote:

    Hey Benjamin,

    I just need a datadump. The command I provided in parenthesis should work!

    -Abe

    On 11/16/12 5:38 PM, Benjamin Kim wrote:

    Hi Abe,

    Which log files do you need specifically?

    Thanks,
    Ben

    On Friday, November 16, 2012 5:16:03 PM UTC-8, abe wrote:

    Hey,

    Can you provide me with a data export? (/usr/share/hue/build/env/bin/hue
    dumpdata oozie).

    -Abe
    On 11/16/12 4:55 PM, bk...@adconion.com wrote:
    I am getting this error after trying to import a Java Design job into
    a workflow.

    [17/Nov/2012 00:50:17 +0000] middleware INFO Processing exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75,
    in decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line
    268, in edit_workflow
    graph = workflow.gen_graph(actions_formset.forms, **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) +
    [[Kill.objects.get(name='kill', workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child =
    Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    Can anybody help? I don't want to create the workflow from scratch again.
    Thanks,
    Ben
  • Abraham Elmahrek at Nov 17, 2012 at 2:05 am
    Hey Benjamin,

    It looks like your database is empty?? Did you save the workflow??

    -Abe
    On 11/16/12 5:50 PM, Benjamin Kim wrote:
    Hi Abe,

    Does it output the data to a file somewhere? I ran the command, and
    nothing but "[]" came back.

    Thanks,
    Ben

    On Friday, November 16, 2012 5:43:07 PM UTC-8, abe wrote:

    Hey Benjamin,

    I just need a datadump. The command I provided in parenthesis
    should work!

    -Abe
    On 11/16/12 5:38 PM, Benjamin Kim wrote:
    Hi Abe,

    Which log files do you need specifically?

    Thanks,
    Ben


    On Friday, November 16, 2012 5:16:03 PM UTC-8, abe wrote:

    Hey,

    Can you provide me with a data export?
    (/usr/share/hue/build/env/bin/hue
    dumpdata oozie).

    -Abe
    On 11/16/12 4:55 PM, bk...@adconion.com wrote:
    I am getting this error after trying to import a Java
    Design job into
    a workflow.

    [17/Nov/2012 00:50:17 +0000] middleware INFO Processing
    exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args,
    **callback_kwargs)
    File
    "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75,
    in decorate
    return view_func(request, *args, **kwargs)
    File
    "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line
    268, in edit_workflow
    graph = workflow.gen_graph(actions_formset.forms,
    **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py",
    line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py",
    line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) +
    [[Kill.objects.get(name='kill', workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py",
    line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py",
    line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py",
    line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py",
    line 557, in
    get_hierarchy_rec
    child =
    Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    Can anybody help? I don't want to create the workflow from
    scratch again.
    Thanks,
    Ben
  • Benjamin Kim at Nov 17, 2012 at 2:20 am
    Abe,

    I have 8 example workflows plus the 1 that I created. I tried creating
    another one from scratch and got the same error when I tried to edit it.
    But when I copy an existing example workflow and modify that, I don't have
    any problems.

    It's the "IndexError: list of index out of range" that I keep seeing in the
    runcpserver.log. I see the "Server Error (500)" on the Hue webpage.

    Thanks,
    Ben
    On Friday, November 16, 2012 6:05:25 PM UTC-8, abe wrote:

    Hey Benjamin,

    It looks like your database is empty?? Did you save the workflow??

    -Abe

    On 11/16/12 5:50 PM, Benjamin Kim wrote:

    Hi Abe,

    Does it output the data to a file somewhere? I ran the command, and
    nothing but "[]" came back.

    Thanks,
    Ben
    On Friday, November 16, 2012 5:43:07 PM UTC-8, abe wrote:

    Hey Benjamin,

    I just need a datadump. The command I provided in parenthesis should work!

    -Abe

    On 11/16/12 5:38 PM, Benjamin Kim wrote:

    Hi Abe,

    Which log files do you need specifically?

    Thanks,
    Ben

    On Friday, November 16, 2012 5:16:03 PM UTC-8, abe wrote:

    Hey,

    Can you provide me with a data export? (/usr/share/hue/build/env/bin/hue
    dumpdata oozie).

    -Abe
    On 11/16/12 4:55 PM, bk...@adconion.com wrote:
    I am getting this error after trying to import a Java Design job into
    a workflow.

    [17/Nov/2012 00:50:17 +0000] middleware INFO Processing exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75,
    in decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line
    268, in edit_workflow
    graph = workflow.gen_graph(actions_formset.forms, **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) +
    [[Kill.objects.get(name='kill', workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child =
    Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    Can anybody help? I don't want to create the workflow from scratch again.
    Thanks,
    Ben
  • Abraham Elmahrek at Nov 19, 2012 at 2:26 am
    Hey Benjamin,

    What does the workflow you're making look like? That error is indicative of
    a malformed workflow.

    -Abe
    On Fri, Nov 16, 2012 at 6:20 PM, Benjamin Kim wrote:

    Abe,

    I have 8 example workflows plus the 1 that I created. I tried creating
    another one from scratch and got the same error when I tried to edit it.
    But when I copy an existing example workflow and modify that, I don't have
    any problems.

    It's the "IndexError: list of index out of range" that I keep seeing in
    the runcpserver.log. I see the "Server Error (500)" on the Hue webpage.

    Thanks,
    Ben

    On Friday, November 16, 2012 6:05:25 PM UTC-8, abe wrote:

    Hey Benjamin,

    It looks like your database is empty?? Did you save the workflow??

    -Abe

    On 11/16/12 5:50 PM, Benjamin Kim wrote:

    Hi Abe,

    Does it output the data to a file somewhere? I ran the command, and
    nothing but "[]" came back.

    Thanks,
    Ben
    On Friday, November 16, 2012 5:43:07 PM UTC-8, abe wrote:

    Hey Benjamin,

    I just need a datadump. The command I provided in parenthesis should
    work!

    -Abe

    On 11/16/12 5:38 PM, Benjamin Kim wrote:

    Hi Abe,

    Which log files do you need specifically?

    Thanks,
    Ben

    On Friday, November 16, 2012 5:16:03 PM UTC-8, abe wrote:

    Hey,

    Can you provide me with a data export? (/usr/share/hue/build/env/bin/**hue

    dumpdata oozie).

    -Abe
    On 11/16/12 4:55 PM, bk...@adconion.com wrote:
    I am getting this error after trying to import a Java Design job into
    a workflow.

    [17/Nov/2012 00:50:17 +0000] middleware INFO Processing exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/**python2.6/site-packages/**
    Django-1.2.3-py2.6.egg/django/**core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/**src/oozie/views/editor.py", line 75,
    in decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/**src/oozie/views/editor.py", line
    268, in edit_workflow
    graph = workflow.gen_graph(actions_**formset.forms,
    **graph_options)
    File "/usr/share/hue/apps/oozie/**src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(**template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/**src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) +
    [[Kill.objects.get(name='kill'**, workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/**src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/**src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/**src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/**src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child =
    Link.objects.filter(parent=**node).exclude(name__in=['**related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/**python2.6/site-packages/**
    Django-1.2.3-py2.6.egg/django/**db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    Can anybody help? I don't want to create the workflow from scratch again.
    Thanks,
    Ben
  • Benjamin Kim at Nov 19, 2012 at 4:16 am
    Hi,

    I created a copy of the DistCp example workflow and tried to import a mapreduce task I created in the job designer. That's when I got the Server Error (500) in Hue and the IndexError: index out of range in the runcpserver.log. So, I created a brand new workflow from scratch and added a DistCp task and saved it. When I tried to edit it after closing it, I got the same errors again.

    Does this help?

    Thanks,
    Ben
  • Abraham Elmahrek at Nov 19, 2012 at 8:17 pm
    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe
    On 11/18/12 8:16 PM, Benjamin Kim wrote:
    Hi,

    I created a copy of the DistCp example workflow and tried to import a mapreduce task I created in the job designer. That's when I got the Server Error (500) in Hue and the IndexError: index out of range in the runcpserver.log. So, I created a brand new workflow from scratch and added a DistCp task and saved it. When I tried to edit it after closing it, I got the same errors again.

    Does this help?

    Thanks,
    Ben
  • Romain Rigaux at Nov 19, 2012 at 7:32 pm
    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for me.
    Are you sure even this is broken or should we look into the import from Job
    Designer?

    Romain
    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek wrote:

    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to import a
    mapreduce task I created in the job designer. That's when I got the Server
    Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Benjamin Kim at Nov 19, 2012 at 7:58 pm
    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a DistCp task
    to it. It broke. I have no problems when modifying a copy of an example
    workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for me.
    Are you sure even this is broken or should we look into the import from Job
    Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek <a...@cloudera.com<javascript:>
    wrote:
    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to import a
    mapreduce task I created in the job designer. That's when I got the Server
    Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Abraham Elmahrek at Nov 20, 2012 at 12:32 am
    With the exact same error? I just tried this exact case with MySQL and
    it worked.

    The test workflow only had the DistCP action?
    On 11/19/12 11:50 AM, Benjamin Kim wrote:
    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a DistCp
    task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben

    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked
    for me. Are you sure even this is broken or should we look into
    the import from Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek
    <a...@cloudera.com <javascript:>> wrote:

    Did you try to create the workflow from scratch after you
    copied the example? Does the example still exist?

    -Abe


    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried
    to import a mapreduce task I created in the job designer.
    That's when I got the Server Error (500) in Hue and the
    IndexError: index out of range in the runcpserver.log. So,
    I created a brand new workflow from scratch and added a
    DistCp task and saved it. When I tried to edit it after
    closing it, I got the same errors again.

    Does this help?

    Thanks,
    Ben

  • Benjamin Kim at Nov 20, 2012 at 12:42 am
    Yes, the same error and same action. I also get the same error when add an
    LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL and it
    worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a DistCp
    task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for me.
    Are you sure even this is broken or should we look into the import from Job
    Designer?

    Romain
    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek wrote:

    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to import a
    mapreduce task I created in the job designer. That's when I got the Server
    Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Abraham Elmahrek at Nov 20, 2012 at 12:54 am
    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all
    the examples. Could you please provide me with your hue.ini? I need to
    know what your database data looks like.
    On 11/19/12 4:42 PM, Benjamin Kim wrote:
    Yes, the same error and same action. I also get the same error when
    add an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL
    and it worked.

    The test workflow only had the DistCP action?
    On 11/19/12 11:50 AM, Benjamin Kim wrote:
    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a
    DistCp task to it. It broke. I have no problems when modifying a
    copy of an example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben

    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it
    worked for me. Are you sure even this is broken or should we
    look into the import from Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek
    wrote:

    Did you try to create the workflow from scratch after you
    copied the example? Does the example still exist?

    -Abe


    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and
    tried to import a mapreduce task I created in the job
    designer. That's when I got the Server Error (500) in
    Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow
    from scratch and added a DistCp task and saved it.
    When I tried to edit it after closing it, I got the
    same errors again.

    Does this help?

    Thanks,
    Ben

  • Benjamin Kim at Nov 20, 2012 at 1:01 am
    I am using Cloudera Manager 4.1. Does this complicate things? How do I get
    the hue.ini using CM? I hear that the hue.ini is overriden by it. Maybe
    that's why I don't get anything back from the data dump?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is purely
    the lack of existence of a node. I don't fully understand how the dumpdata
    command didn't give you any thing when there was in fact all the examples.
    Could you please provide me with your hue.ini? I need to know what your
    database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when add an
    LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL and
    it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a DistCp
    task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for me.
    Are you sure even this is broken or should we look into the import from Job
    Designer?

    Romain
    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek wrote:

    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to import a
    mapreduce task I created in the job designer. That's when I got the Server
    Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Romain Rigaux at Nov 20, 2012 at 1:17 am
    In CM I think it is under /var/run/cloudera-scm-agent/process... but yes it
    is not picked-up by the 'hue' command (the command is using the original
    hue.ini which is probably not pointing to the DB). Probably modifying
    /etc/hue/hue.ini
    to point to the same DB would make the 'hue dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess that the
    Distcp Action is not the culprit: is any new workflow not working with any
    new action crashing?

    Romain

    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim wrote:

    I am using Cloudera Manager 4.1. Does this complicate things? How do I get
    the hue.ini using CM? I hear that the hue.ini is overriden by it. Maybe
    that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all the
    examples. Could you please provide me with your hue.ini? I need to know
    what your database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when add
    an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL and
    it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a DistCp
    task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for
    me. Are you sure even this is broken or should we look into the import from
    Job Designer?

    Romain
    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek wrote:

    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to import a
    mapreduce task I created in the job designer. That's when I got the Server
    Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Benjamin Kim at Nov 20, 2012 at 1:46 am
    Romain,

    I just created a bunch of workflows with DistCp actions with no problems
    only if I leave the erroneous workflow from earlier there. Then, I went
    ahead and deleted all the test workflows including the erroneous workflow.
    This leaves just the example workflows and the first workflow that I
    created a while back. This one has no problems. Now, creating a new
    workflow from scratch and copying an example workflow gets me the same
    errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and deleting them. I am
    getting intermittent errors. But, after I create and leave the erroneous
    workflow, it works fine afterwards. I can create and copy workflows with no
    issues. I even tried deleting the erroneous workflow, and the workflows
    created afterwards work fine. If I delete all the workflows again like
    before. The same pattern emerges.

    It looks like having an erroneous workflow present will make all following
    workflows go through. Then, I can delete it later.

    Thanks,
    Ben
    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain Rigaux wrote:

    In CM I think it is under /var/run/cloudera-scm-agent/process... but yes
    it is not picked-up by the 'hue' command (the command is using the original
    hue.ini which is probably not pointing to the DB). Probably modifying /etc/hue/hue.ini
    to point to the same DB would make the 'hue dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess that
    the Distcp Action is not the culprit: is any new workflow not working with
    any new action crashing?

    Romain


    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim <bbui...@gmail.com<javascript:>
    wrote:
    I am using Cloudera Manager 4.1. Does this complicate things? How do I
    get the hue.ini using CM? I hear that the hue.ini is overriden by it. Maybe
    that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all the
    examples. Could you please provide me with your hue.ini? I need to know
    what your database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when add
    an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL and
    it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a DistCp
    task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for
    me. Are you sure even this is broken or should we look into the import from
    Job Designer?

    Romain
    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek wrote:

    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to import
    a mapreduce task I created in the job designer. That's when I got the
    Server Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Romain Rigaux at Nov 20, 2012 at 6:46 am
    This is very weird. It seems that the DB objects are not consistent. Is
    your MySql engine InnoDb? (and so enforce the foreign keys?)

    Another problem is that maybe the workflow names in the
    workspace/deployment directories on the HDFS are conflicting?

    [oozie]
    remote_data_dir /user/hue/oozie/workspaces


    Romain
    On Mon, Nov 19, 2012 at 5:46 PM, Benjamin Kim wrote:

    Romain,

    I just created a bunch of workflows with DistCp actions with no problems
    only if I leave the erroneous workflow from earlier there. Then, I went
    ahead and deleted all the test workflows including the erroneous workflow.
    This leaves just the example workflows and the first workflow that I
    created a while back. This one has no problems. Now, creating a new
    workflow from scratch and copying an example workflow gets me the same
    errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and deleting them. I am
    getting intermittent errors. But, after I create and leave the erroneous
    workflow, it works fine afterwards. I can create and copy workflows with no
    issues. I even tried deleting the erroneous workflow, and the workflows
    created afterwards work fine. If I delete all the workflows again like
    before. The same pattern emerges.

    It looks like having an erroneous workflow present will make all following
    workflows go through. Then, I can delete it later.

    Thanks,
    Ben

    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain Rigaux wrote:

    In CM I think it is under /var/run/cloudera-scm-agent/**process... but
    yes it is not picked-up by the 'hue' command (the command is using the
    original hue.ini which is probably not pointing to the DB). Probably
    modifying /etc/hue/hue.ini to point to the same DB would make the 'hue
    dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess that
    the Distcp Action is not the culprit: is any new workflow not working with
    any new action crashing?

    Romain

    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim wrote:

    I am using Cloudera Manager 4.1. Does this complicate things? How do I
    get the hue.ini using CM? I hear that the hue.ini is overriden by it. Maybe
    that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all the
    examples. Could you please provide me with your hue.ini? I need to know
    what your database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when add
    an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL
    and it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a DistCp
    task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for
    me. Are you sure even this is broken or should we look into the import from
    Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek <a...@cloudera.com
    wrote:
    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to import
    a mapreduce task I created in the job designer. That's when I got the
    Server Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Benjamin Kim at Nov 20, 2012 at 2:26 pm
    Hi Romain,

    We are using MySql 5.1 which is pre-InnoDB. We were using 5.5, but ran into problems with the foreign key and the DB in general. Cloudera recently updated their documentation for it, but we decided to stick with 5.1.

    I was creating the workflows without designating any deployment directory so I assume that it created them in /user/hue/oozie/workspaces. I will check for straggling folders and try creating the same workflow if there are any to check for name collision.

    Thanks,
    Ben
    On Nov 19, 2012, at 10:46 PM, Romain Rigaux wrote:

    This is very weird. It seems that the DB objects are not consistent. Is your MySql engine InnoDb? (and so enforce the foreign keys?)

    Another problem is that maybe the workflow names in the workspace/deployment directories on the HDFS are conflicting?

    [oozie]
    remote_data_dir /user/hue/oozie/workspaces


    Romain
    On Mon, Nov 19, 2012 at 5:46 PM, Benjamin Kim wrote:
    Romain,

    I just created a bunch of workflows with DistCp actions with no problems only if I leave the erroneous workflow from earlier there. Then, I went ahead and deleted all the test workflows including the erroneous workflow. This leaves just the example workflows and the first workflow that I created a while back. This one has no problems. Now, creating a new workflow from scratch and copying an example workflow gets me the same errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and deleting them. I am getting intermittent errors. But, after I create and leave the erroneous workflow, it works fine afterwards. I can create and copy workflows with no issues. I even tried deleting the erroneous workflow, and the workflows created afterwards work fine. If I delete all the workflows again like before. The same pattern emerges.

    It looks like having an erroneous workflow present will make all following workflows go through. Then, I can delete it later.

    Thanks,
    Ben

    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain Rigaux wrote:
    In CM I think it is under /var/run/cloudera-scm-agent/process... but yes it is not picked-up by the 'hue' command (the command is using the original hue.ini which is probably not pointing to the DB). Probably modifying /etc/hue/hue.ini to point to the same DB would make the 'hue dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess that the Distcp Action is not the culprit: is any new workflow not working with any new action crashing?

    Romain

    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim wrote:
    I am using Cloudera Manager 4.1. Does this complicate things? How do I get the hue.ini using CM? I hear that the hue.ini is overriden by it. Maybe that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is purely the lack of existence of a node. I don't fully understand how the dumpdata command didn't give you any thing when there was in fact all the examples. Could you please provide me with your hue.ini? I need to know what your database data looks like.
    On 11/19/12 4:42 PM, Benjamin Kim wrote:
    Yes, the same error and same action. I also get the same error when add an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL and it worked.

    The test workflow only had the DistCP action?
    On 11/19/12 11:50 AM, Benjamin Kim wrote:
    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a DistCp task to it. It broke. I have no problems when modifying a copy of an example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for me. Are you sure even this is broken or should we look into the import from Job Designer?

    Romain
    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek wrote:
    Did you try to create the workflow from scratch after you copied the example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:
    Hi,

    I created a copy of the DistCp example workflow and tried to import a mapreduce task I created in the job designer. That's when I got the Server Error (500) in Hue and the IndexError: index out of range in the runcpserver.log. So, I created a brand new workflow from scratch and added a DistCp task and saved it. When I tried to edit it after closing it, I got the same errors again.

    Does this help?

    Thanks,
    Ben
  • Benjamin Kim at Nov 20, 2012 at 4:42 pm
    Romain,

    I think the folders in the workspace were the problem. When copying an
    example workflow, it creates a folder with _<username>_-oozie-## to store
    it. Then, I changed the deployment directory advanced property to another
    location. This leaves an orphaned folder behind. Even when creating a
    workflow from scratch, if I don't designate a deployment directory in the
    advanced properties from the get go, it creates a folder in workspaces for
    you. If I do change it later, then it will leave an orphan folder too. It
    looks like a usage issue. If I were to designate any deployment directory
    for any workflow, I will have to make sure that there are no orphaned
    folders left behind.

    What are your thoughts?

    Thanks,
    Ben
    On Monday, November 19, 2012 10:46:25 PM UTC-8, Romain Rigaux wrote:

    This is very weird. It seems that the DB objects are not consistent. Is
    your MySql engine InnoDb? (and so enforce the foreign keys?)

    Another problem is that maybe the workflow names in the
    workspace/deployment directories on the HDFS are conflicting?

    [oozie]
    remote_data_dir /user/hue/oozie/workspaces


    Romain

    On Mon, Nov 19, 2012 at 5:46 PM, Benjamin Kim <bbui...@gmail.com<javascript:>
    wrote:
    Romain,

    I just created a bunch of workflows with DistCp actions with no problems
    only if I leave the erroneous workflow from earlier there. Then, I went
    ahead and deleted all the test workflows including the erroneous workflow.
    This leaves just the example workflows and the first workflow that I
    created a while back. This one has no problems. Now, creating a new
    workflow from scratch and copying an example workflow gets me the same
    errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and deleting them. I am
    getting intermittent errors. But, after I create and leave the erroneous
    workflow, it works fine afterwards. I can create and copy workflows with no
    issues. I even tried deleting the erroneous workflow, and the workflows
    created afterwards work fine. If I delete all the workflows again like
    before. The same pattern emerges.

    It looks like having an erroneous workflow present will make all
    following workflows go through. Then, I can delete it later.

    Thanks,
    Ben

    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain Rigaux wrote:

    In CM I think it is under /var/run/cloudera-scm-agent/**process... but
    yes it is not picked-up by the 'hue' command (the command is using the
    original hue.ini which is probably not pointing to the DB). Probably
    modifying /etc/hue/hue.ini to point to the same DB would make the 'hue
    dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess that
    the Distcp Action is not the culprit: is any new workflow not working with
    any new action crashing?

    Romain

    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim wrote:

    I am using Cloudera Manager 4.1. Does this complicate things? How do I
    get the hue.ini using CM? I hear that the hue.ini is overriden by it. Maybe
    that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all the
    examples. Could you please provide me with your hue.ini? I need to know
    what your database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when
    add an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL
    and it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a
    DistCp task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked for
    me. Are you sure even this is broken or should we look into the import from
    Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek <
    a...@cloudera.com> wrote:
    Did you try to create the workflow from scratch after you copied
    the example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to
    import a mapreduce task I created in the job designer. That's when I got
    the Server Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Romain Rigaux at Nov 21, 2012 at 1:37 am
    That's probably the problem indeed. If you edit a workflow and change its
    HDFS workspace but do not move the HDFS directory it will linger around and
    might conflict if the workflow is deleted and later a new one is created.

    I created https://issues.cloudera.org/browse/HUE-929 in order to:

    1. add a move workspace action when editing a workflow
    2. changing the logic of the default generated workspace names in order
    to avoid any conflicts later


    In the meantime, if a workflow directory is changed, the underlying HDFS
    directory should be either move to the new path or deleted.

    BTW, InnoDb will be fully supported without workaround in the Hue in the
    next release.

    Romain
    On Tue, Nov 20, 2012 at 8:36 AM, Benjamin Kim wrote:

    Romain,

    I think the folders in the workspace were the problem. When copying an
    example workflow, it creates a folder with _<username>_-oozie-## to store
    it. Then, I changed the deployment directory advanced property to another
    location. This leaves an orphaned folder behind. Even when creating a
    workflow from scratch, if I don't designate a deployment directory in the
    advanced properties from the get go, it creates a folder in workspaces for
    you. If I do change it later, then it will leave an orphan folder too. It
    looks like a usage issue. If I were to designate any deployment directory
    for any workflow, I will have to make sure that there are no orphaned
    folders left behind.

    What are your thoughts?

    Thanks,
    Ben

    On Monday, November 19, 2012 10:46:25 PM UTC-8, Romain Rigaux wrote:

    This is very weird. It seems that the DB objects are not consistent. Is
    your MySql engine InnoDb? (and so enforce the foreign keys?)

    Another problem is that maybe the workflow names in the
    workspace/deployment directories on the HDFS are conflicting?

    [oozie]
    remote_data_dir /user/hue/oozie/workspaces


    Romain
    On Mon, Nov 19, 2012 at 5:46 PM, Benjamin Kim wrote:

    Romain,

    I just created a bunch of workflows with DistCp actions with no problems
    only if I leave the erroneous workflow from earlier there. Then, I went
    ahead and deleted all the test workflows including the erroneous workflow.
    This leaves just the example workflows and the first workflow that I
    created a while back. This one has no problems. Now, creating a new
    workflow from scratch and copying an example workflow gets me the same
    errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and deleting them. I am
    getting intermittent errors. But, after I create and leave the erroneous
    workflow, it works fine afterwards. I can create and copy workflows with no
    issues. I even tried deleting the erroneous workflow, and the workflows
    created afterwards work fine. If I delete all the workflows again like
    before. The same pattern emerges.

    It looks like having an erroneous workflow present will make all
    following workflows go through. Then, I can delete it later.

    Thanks,
    Ben

    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain Rigaux wrote:

    In CM I think it is under /var/run/cloudera-scm-agent/**pr**ocess...
    but yes it is not picked-up by the 'hue' command (the command is using the
    original hue.ini which is probably not pointing to the DB). Probably
    modifying /etc/hue/hue.ini to point to the same DB would make the 'hue
    dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess that
    the Distcp Action is not the culprit: is any new workflow not working with
    any new action crashing?

    Romain

    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim wrote:

    I am using Cloudera Manager 4.1. Does this complicate things? How do I
    get the hue.ini using CM? I hear that the hue.ini is overriden by it. Maybe
    that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all the
    examples. Could you please provide me with your hue.ini? I need to know
    what your database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when
    add an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL
    and it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a
    DistCp task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben
    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked
    for me. Are you sure even this is broken or should we look into the import
    from Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek <
    a...@cloudera.com> wrote:
    Did you try to create the workflow from scratch after you copied
    the example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to
    import a mapreduce task I created in the job designer. That's when I got
    the Server Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Benjamin Kim at Nov 21, 2012 at 1:48 am
    Romain,

    Thanks for all your help.

    Holiday Cheers,
    Ben
    On Tuesday, November 20, 2012 5:37:47 PM UTC-8, Romain Rigaux wrote:

    That's probably the problem indeed. If you edit a workflow and change its
    HDFS workspace but do not move the HDFS directory it will linger around and
    might conflict if the workflow is deleted and later a new one is created.

    I created https://issues.cloudera.org/browse/HUE-929 in order to:

    1. add a move workspace action when editing a workflow
    2. changing the logic of the default generated workspace names in
    order to avoid any conflicts later


    In the meantime, if a workflow directory is changed, the underlying HDFS
    directory should be either move to the new path or deleted.

    BTW, InnoDb will be fully supported without workaround in the Hue in the
    next release.

    Romain
    On Tue, Nov 20, 2012 at 8:36 AM, Benjamin Kim <bbui...@gmail.com<javascript:>
    wrote:
    Romain,

    I think the folders in the workspace were the problem. When copying an
    example workflow, it creates a folder with _<username>_-oozie-## to store
    it. Then, I changed the deployment directory advanced property to another
    location. This leaves an orphaned folder behind. Even when creating a
    workflow from scratch, if I don't designate a deployment directory in the
    advanced properties from the get go, it creates a folder in workspaces for
    you. If I do change it later, then it will leave an orphan folder too. It
    looks like a usage issue. If I were to designate any deployment directory
    for any workflow, I will have to make sure that there are no orphaned
    folders left behind.

    What are your thoughts?

    Thanks,
    Ben

    On Monday, November 19, 2012 10:46:25 PM UTC-8, Romain Rigaux wrote:

    This is very weird. It seems that the DB objects are not consistent. Is
    your MySql engine InnoDb? (and so enforce the foreign keys?)

    Another problem is that maybe the workflow names in the
    workspace/deployment directories on the HDFS are conflicting?

    [oozie]
    remote_data_dir /user/hue/oozie/workspaces


    Romain
    On Mon, Nov 19, 2012 at 5:46 PM, Benjamin Kim wrote:

    Romain,

    I just created a bunch of workflows with DistCp actions with no
    problems only if I leave the erroneous workflow from earlier there. Then, I
    went ahead and deleted all the test workflows including the erroneous
    workflow. This leaves just the example workflows and the first workflow
    that I created a while back. This one has no problems. Now, creating a new
    workflow from scratch and copying an example workflow gets me the same
    errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and deleting them. I am
    getting intermittent errors. But, after I create and leave the erroneous
    workflow, it works fine afterwards. I can create and copy workflows with no
    issues. I even tried deleting the erroneous workflow, and the workflows
    created afterwards work fine. If I delete all the workflows again like
    before. The same pattern emerges.

    It looks like having an erroneous workflow present will make all
    following workflows go through. Then, I can delete it later.

    Thanks,
    Ben

    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain Rigaux wrote:

    In CM I think it is under /var/run/cloudera-scm-agent/**pr**ocess...
    but yes it is not picked-up by the 'hue' command (the command is using the
    original hue.ini which is probably not pointing to the DB). Probably
    modifying /etc/hue/hue.ini to point to the same DB would make the
    'hue dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess
    that the Distcp Action is not the culprit: is any new workflow not working
    with any new action crashing?

    Romain

    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim wrote:

    I am using Cloudera Manager 4.1. Does this complicate things? How do
    I get the hue.ini using CM? I hear that the hue.ini is overriden by it.
    Maybe that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all the
    examples. Could you please provide me with your hue.ini? I need to know
    what your database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when
    add an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL
    and it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a
    DistCp task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben

    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux
    wrote:
    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked
    for me. Are you sure even this is broken or should we look into the import
    from Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek <
    a...@cloudera.com> wrote:
    Did you try to create the workflow from scratch after you copied
    the example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to
    import a mapreduce task I created in the job designer. That's when I got
    the Server Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Benjamin Kim at Dec 3, 2012 at 10:05 pm
    Hi Romain,

    I'm getting the error again. I am starting from scratch. There are no
    workflow examples so it's all empty. Both
    /user/hue/oozie/{workspaces,deployments} directories are empty. I am trying
    to create full workflows using DistCp, Hive, and Shell actions, and I keep
    getting Server Error (500). By looking in the runcpserver.log, I get this
    error.

    [03/Dec/2012 21:59:10 +0000] middleware INFO Processing exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75, in
    decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 268, in
    edit_workflow
    graph = workflow.gen_graph(actions_formset.forms, **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) + [[Kill.objects.get(name='kill',
    workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child = Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    This one is perplexing because previously it was the orphan folders causing
    the problems.

    Thanks,
    Ben
    On Tuesday, November 20, 2012 5:37:47 PM UTC-8, Romain Rigaux wrote:

    That's probably the problem indeed. If you edit a workflow and change its
    HDFS workspace but do not move the HDFS directory it will linger around and
    might conflict if the workflow is deleted and later a new one is created.

    I created https://issues.cloudera.org/browse/HUE-929 in order to:

    1. add a move workspace action when editing a workflow
    2. changing the logic of the default generated workspace names in
    order to avoid any conflicts later


    In the meantime, if a workflow directory is changed, the underlying HDFS
    directory should be either move to the new path or deleted.

    BTW, InnoDb will be fully supported without workaround in the Hue in the
    next release.

    Romain
    On Tue, Nov 20, 2012 at 8:36 AM, Benjamin Kim <bbui...@gmail.com<javascript:>
    wrote:
    Romain,

    I think the folders in the workspace were the problem. When copying an
    example workflow, it creates a folder with _<username>_-oozie-## to store
    it. Then, I changed the deployment directory advanced property to another
    location. This leaves an orphaned folder behind. Even when creating a
    workflow from scratch, if I don't designate a deployment directory in the
    advanced properties from the get go, it creates a folder in workspaces for
    you. If I do change it later, then it will leave an orphan folder too. It
    looks like a usage issue. If I were to designate any deployment directory
    for any workflow, I will have to make sure that there are no orphaned
    folders left behind.

    What are your thoughts?

    Thanks,
    Ben

    On Monday, November 19, 2012 10:46:25 PM UTC-8, Romain Rigaux wrote:

    This is very weird. It seems that the DB objects are not consistent. Is
    your MySql engine InnoDb? (and so enforce the foreign keys?)

    Another problem is that maybe the workflow names in the
    workspace/deployment directories on the HDFS are conflicting?

    [oozie]
    remote_data_dir /user/hue/oozie/workspaces


    Romain
    On Mon, Nov 19, 2012 at 5:46 PM, Benjamin Kim wrote:

    Romain,

    I just created a bunch of workflows with DistCp actions with no
    problems only if I leave the erroneous workflow from earlier there. Then, I
    went ahead and deleted all the test workflows including the erroneous
    workflow. This leaves just the example workflows and the first workflow
    that I created a while back. This one has no problems. Now, creating a new
    workflow from scratch and copying an example workflow gets me the same
    errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and deleting them. I am
    getting intermittent errors. But, after I create and leave the erroneous
    workflow, it works fine afterwards. I can create and copy workflows with no
    issues. I even tried deleting the erroneous workflow, and the workflows
    created afterwards work fine. If I delete all the workflows again like
    before. The same pattern emerges.

    It looks like having an erroneous workflow present will make all
    following workflows go through. Then, I can delete it later.

    Thanks,
    Ben

    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain Rigaux wrote:

    In CM I think it is under /var/run/cloudera-scm-agent/**pr**ocess...
    but yes it is not picked-up by the 'hue' command (the command is using the
    original hue.ini which is probably not pointing to the DB). Probably
    modifying /etc/hue/hue.ini to point to the same DB would make the
    'hue dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess
    that the Distcp Action is not the culprit: is any new workflow not working
    with any new action crashing?

    Romain

    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim wrote:

    I am using Cloudera Manager 4.1. Does this complicate things? How do
    I get the hue.ini using CM? I hear that the hue.ini is overriden by it.
    Maybe that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all the
    examples. Could you please provide me with your hue.ini? I need to know
    what your database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when
    add an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with MySQL
    and it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a
    DistCp task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben

    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux
    wrote:
    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked
    for me. Are you sure even this is broken or should we look into the import
    from Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek <
    a...@cloudera.com> wrote:
    Did you try to create the workflow from scratch after you copied
    the example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to
    import a mapreduce task I created in the job designer. That's when I got
    the Server Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Abraham Elmahrek at Dec 4, 2012 at 12:14 am
    Hey Benjamin,

    I tried creating a basic workflow: Distcp -> Hive -> Shell. I don't get
    this error when I try to edit the workflow again.

    Could you provide me with the exact workflow structure?

    -Abe
    On 12/3/12 2:05 PM, Benjamin Kim wrote:
    Hi Romain,

    I'm getting the error again. I am starting from scratch. There are no
    workflow examples so it's all empty. Both
    /user/hue/oozie/{workspaces,deployments} directories are empty. I am
    trying to create full workflows using DistCp, Hive, and Shell actions,
    and I keep getting Server Error (500). By looking in the
    runcpserver.log, I get this error.

    [03/Dec/2012 21:59:10 +0000] middleware INFO Processing exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75,
    in decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line
    268, in edit_workflow
    graph = workflow.gen_graph(actions_formset.forms, **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) +
    [[Kill.objects.get(name='kill', workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child =
    Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    This one is perplexing because previously it was the orphan folders
    causing the problems.

    Thanks,
    Ben

    On Tuesday, November 20, 2012 5:37:47 PM UTC-8, Romain Rigaux wrote:

    That's probably the problem indeed. If you edit a workflow and
    change its HDFS workspace but do not move the HDFS directory it
    will linger around and might conflict if the workflow is deleted
    and later a new one is created.

    I created https://issues.cloudera.org/browse/HUE-929
    <https://issues.cloudera.org/browse/HUE-929> in order to:

    1. add a move workspace action when editing a workflow
    2. changing the logic of the default generated workspace names in
    order to avoid any conflicts later


    In the meantime, if a workflow directory is changed, the
    underlying HDFS directory should be either move to the new path or
    deleted.

    BTW, InnoDb will be fully supported without workaround in the Hue
    in the next release.

    Romain

    On Tue, Nov 20, 2012 at 8:36 AM, Benjamin Kim <bbui...@gmail.com
    <javascript:>> wrote:

    Romain,

    I think the folders in the workspace were the problem. When
    copying an example workflow, it creates a folder with
    _<username>_-oozie-## to store it. Then, I changed the
    deployment directory advanced property to another location.
    This leaves an orphaned folder behind. Even when creating a
    workflow from scratch, if I don't designate a deployment
    directory in the advanced properties from the get go, it
    creates a folder in workspaces for you. If I do change it
    later, then it will leave an orphan folder too. It looks like
    a usage issue. If I were to designate any deployment directory
    for any workflow, I will have to make sure that there are no
    orphaned folders left behind.

    What are your thoughts?

    Thanks,
    Ben


    On Monday, November 19, 2012 10:46:25 PM UTC-8, Romain Rigaux
    wrote:

    This is very weird. It seems that the DB objects are not
    consistent. Is your MySql engine InnoDb? (and so enforce
    the foreign keys?)

    Another problem is that maybe the workflow names in the
    workspace/deployment directories on the HDFS are conflicting?

    [oozie]
    remote_data_dir /user/hue/oozie/workspaces


    Romain

    On Mon, Nov 19, 2012 at 5:46 PM, Benjamin Kim
    wrote:

    Romain,

    I just created a bunch of workflows with DistCp
    actions with no problems only if I leave the erroneous
    workflow from earlier there. Then, I went ahead and
    deleted all the test workflows including the erroneous
    workflow. This leaves just the example workflows and
    the first workflow that I created a while back. This
    one has no problems. Now, creating a new workflow from
    scratch and copying an example workflow gets me the
    same errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and
    deleting them. I am getting intermittent errors. But,
    after I create and leave the erroneous workflow, it
    works fine afterwards. I can create and copy workflows
    with no issues. I even tried deleting the erroneous
    workflow, and the workflows created afterwards work
    fine. If I delete all the workflows again like before.
    The same pattern emerges.

    It looks like having an erroneous workflow present
    will make all following workflows go through. Then, I
    can delete it later.

    Thanks,
    Ben


    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain
    Rigaux wrote:

    In CM I think it is under
    /var/run/cloudera-scm-agent/process... but yes it
    is not picked-up by the 'hue' command (the command
    is using the original hue.ini which is probably
    not pointing to the DB). Probably modifying
    /etc/hue/hue.ini to point to the same DB would
    make the 'hue dumpdata oozie' work.

    However, the problem might be related to the users
    in Hue. I guess that the Distcp Action is not the
    culprit: is any new workflow not working with any
    new action crashing?

    Romain


    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim
    wrote:

    I am using Cloudera Manager 4.1. Does this
    complicate things? How do I get the hue.ini
    using CM? I hear that the hue.ini is overriden
    by it. Maybe that's why I don't get anything
    back from the data dump?

    Thanks,
    Ben


    On Monday, November 19, 2012 4:54:22 PM UTC-8,
    abe wrote:

    Those two errors should not be related.
    The get_hierarchy error is purely the lack
    of existence of a node. I don't fully
    understand how the dumpdata command didn't
    give you any thing when there was in fact
    all the examples. Could you please provide
    me with your hue.ini? I need to know what
    your database data looks like.
    On 11/19/12 4:42 PM, Benjamin Kim wrote:
    Yes, the same error and same action. I
    also get the same error when add an LDAP
    user that does not exist. Could it be
    related?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:25:15 PM
    UTC-8, abe wrote:

    With the exact same error? I just
    tried this exact case with MySQL and
    it worked.

    The test workflow only had the DistCP
    action?
    On 11/19/12 11:50 AM, Benjamin Kim wrote:
    Yes, I'm on CDH4.1.2. I just create
    a Test workflow and added a DistCp
    task to it. It broke. I have no
    problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the
    backend for both Hue and Oozie.

    Thanks,
    Ben

    On Monday, November 19, 2012
    11:32:31 AM UTC-8, Romain Rigaux wrote:

    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and
    added a DistCp action and it
    worked for me. Are you sure even
    this is broken or should we look
    into the import from Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20
    AM, Abraham Elmahrek
    wrote:

    Did you try to create the
    workflow from scratch after
    you copied the example? Does
    the example still exist?

    -Abe


    On 11/18/12 8:16 PM,
    Benjamin Kim wrote:

    Hi,

    I created a copy of the
    DistCp example workflow
    and tried to import a
    mapreduce task I created
    in the job designer.
    That's when I got the
    Server Error (500) in
    Hue and the IndexError:
    index out of range in
    the runcpserver.log. So,
    I created a brand new
    workflow from scratch
    and added a DistCp task
    and saved it. When I
    tried to edit it after
    closing it, I got the
    same errors again.

    Does this help?

    Thanks,
    Ben


  • Benjamin Kim at Dec 4, 2012 at 12:37 am
    Abe,

    Here are the steps I used to create it.

    1. Create the workflow Test
    2. Under advanced properties, I set the deployment directory to a folder in
    /user/hue/oozie/deployments/test
    3. Save it
    4. Under properties, I add oozie properties for the workflow to use such as
    source and destination file directories for DistCp to use
    5. Add DistCp and name it DistCp-S3 since I'm getting data from S3
    6. Fill in the arguments: -i, -update, ${source}, ${destination}
    7. Save it
    8. Add Hive
    9. Name it Hive-Partition
    10. Put the path to the script
    11. Add parameters: datepart=${datepart}, datepath=${datepath}, hour=${hour}
    12. Add job properties for hive metastore, jdbc mysql url, jdbc mysql
    driver, mysql db username, mysql db password
    13. Set the oozie.hive.defaults to the path for hive-site.xml
    14. Set the job-xml to the path for hive-site.xml
    15. Save it
    16. Add Shell
    17. Name it Shell-Impala
    18. Put impala-shell as the command
    19. Fill in the arguments: -i impala-test1:21000, -q "refresh"
    20. Save it
    21. Server Error (500)

    By the way, Romain just committed code so I Hive job-xml field will take my
    hive-site.xml file. I will not need to add the Hive job properties anymore
    hopefully. Also, the Shell command to run the Impala refresh does not work
    in a test workflow with it only. It keeps on telling me that it only takes
    one argument to CONNECT.

    FYI. I have given up entirely. I kept trying multiple times and variations
    of creating this same workflow and now I can't create a workflow at all
    without the error. I can't even add a single step without a problem. I just
    went to a shell script for the time being just to keep the data flowing.

    Thanks,
    Ben
    On Monday, December 3, 2012 4:14:04 PM UTC-8, abe wrote:

    Hey Benjamin,

    I tried creating a basic workflow: Distcp -> Hive -> Shell. I don't get
    this error when I try to edit the workflow again.

    Could you provide me with the exact workflow structure?

    -Abe

    On 12/3/12 2:05 PM, Benjamin Kim wrote:

    Hi Romain,

    I'm getting the error again. I am starting from scratch. There are no
    workflow examples so it's all empty. Both
    /user/hue/oozie/{workspaces,deployments} directories are empty. I am trying
    to create full workflows using DistCp, Hive, and Shell actions, and I keep
    getting Server Error (500). By looking in the runcpserver.log, I get this
    error.

    [03/Dec/2012 21:59:10 +0000] middleware INFO Processing exception:
    list index out of range: Traceback (most recent call last):
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py",
    line 100, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 75, in
    decorate
    return view_func(request, *args, **kwargs)
    File "/usr/share/hue/apps/oozie/src/oozie/views/editor.py", line 268, in
    edit_workflow
    graph = workflow.gen_graph(actions_formset.forms, **graph_options)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 562, in
    gen_graph
    return django_mako.render_to_string(template, {'nodes':
    self.get_hierarchy(), 'index': index})
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 534, in
    get_hierarchy
    return self.get_hierarchy_rec(node) + [[Kill.objects.get(name='kill',
    workflow=node.workflow)],
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 558, in
    get_hierarchy_rec
    return [node] + self.get_hierarchy_rec(child)
    File "/usr/share/hue/apps/oozie/src/oozie/models.py", line 557, in
    get_hierarchy_rec
    child = Link.objects.filter(parent=node).exclude(name__in=['related',
    'kill'])[0].child
    File
    "/usr/share/hue/build/env/lib/python2.6/site-packages/Django-1.2.3-py2.6.egg/django/db/models/query.py",
    line 189, in __getitem__
    return list(qs)[0]
    IndexError: list index out of range

    This one is perplexing because previously it was the orphan folders
    causing the problems.

    Thanks,
    Ben
    On Tuesday, November 20, 2012 5:37:47 PM UTC-8, Romain Rigaux wrote:

    That's probably the problem indeed. If you edit a workflow and change its
    HDFS workspace but do not move the HDFS directory it will linger around and
    might conflict if the workflow is deleted and later a new one is created.

    I created https://issues.cloudera.org/browse/HUE-929 in order to:

    1. add a move workspace action when editing a workflow
    2. changing the logic of the default generated workspace names in
    order to avoid any conflicts later


    In the meantime, if a workflow directory is changed, the underlying HDFS
    directory should be either move to the new path or deleted.

    BTW, InnoDb will be fully supported without workaround in the Hue in the
    next release.

    Romain
    On Tue, Nov 20, 2012 at 8:36 AM, Benjamin Kim wrote:

    Romain,

    I think the folders in the workspace were the problem. When copying an
    example workflow, it creates a folder with _<username>_-oozie-## to store
    it. Then, I changed the deployment directory advanced property to another
    location. This leaves an orphaned folder behind. Even when creating a
    workflow from scratch, if I don't designate a deployment directory in the
    advanced properties from the get go, it creates a folder in workspaces for
    you. If I do change it later, then it will leave an orphan folder too. It
    looks like a usage issue. If I were to designate any deployment directory
    for any workflow, I will have to make sure that there are no orphaned
    folders left behind.

    What are your thoughts?

    Thanks,
    Ben

    On Monday, November 19, 2012 10:46:25 PM UTC-8, Romain Rigaux wrote:

    This is very weird. It seems that the DB objects are not consistent. Is
    your MySql engine InnoDb? (and so enforce the foreign keys?)

    Another problem is that maybe the workflow names in the
    workspace/deployment directories on the HDFS are conflicting?

    [oozie]
    remote_data_dir /user/hue/oozie/workspaces


    Romain
    On Mon, Nov 19, 2012 at 5:46 PM, Benjamin Kim wrote:

    Romain,

    I just created a bunch of workflows with DistCp actions with no
    problems only if I leave the erroneous workflow from earlier there. Then, I
    went ahead and deleted all the test workflows including the erroneous
    workflow. This leaves just the example workflows and the first workflow
    that I created a while back. This one has no problems. Now, creating a new
    workflow from scratch and copying an example workflow gets me the same
    errors.

    Now, let's try again from the beginning.

    I created a workflow from both scratch and copy and deleting them. I
    am getting intermittent errors. But, after I create and leave the erroneous
    workflow, it works fine afterwards. I can create and copy workflows with no
    issues. I even tried deleting the erroneous workflow, and the workflows
    created afterwards work fine. If I delete all the workflows again like
    before. The same pattern emerges.

    It looks like having an erroneous workflow present will make all
    following workflows go through. Then, I can delete it later.

    Thanks,
    Ben

    On Monday, November 19, 2012 5:17:20 PM UTC-8, Romain Rigaux wrote:

    In CM I think it is under /var/run/cloudera-scm-agent/process... but
    yes it is not picked-up by the 'hue' command (the command is using the
    original hue.ini which is probably not pointing to the DB). Probably
    modifying /etc/hue/hue.ini to point to the same DB would make the
    'hue dumpdata oozie' work.

    However, the problem might be related to the users in Hue. I guess
    that the Distcp Action is not the culprit: is any new workflow not working
    with any new action crashing?

    Romain

    On Mon, Nov 19, 2012 at 5:01 PM, Benjamin Kim wrote:

    I am using Cloudera Manager 4.1. Does this complicate things? How do
    I get the hue.ini using CM? I hear that the hue.ini is overriden by it.
    Maybe that's why I don't get anything back from the data dump?

    Thanks,
    Ben

    On Monday, November 19, 2012 4:54:22 PM UTC-8, abe wrote:

    Those two errors should not be related. The get_hierarchy error is
    purely the lack of existence of a node. I don't fully understand how the
    dumpdata command didn't give you any thing when there was in fact all the
    examples. Could you please provide me with your hue.ini? I need to know
    what your database data looks like.

    On 11/19/12 4:42 PM, Benjamin Kim wrote:

    Yes, the same error and same action. I also get the same error when
    add an LDAP user that does not exist. Could it be related?

    Thanks,
    Ben
    On Monday, November 19, 2012 4:25:15 PM UTC-8, abe wrote:

    With the exact same error? I just tried this exact case with
    MySQL and it worked.

    The test workflow only had the DistCP action?

    On 11/19/12 11:50 AM, Benjamin Kim wrote:

    Yes, I'm on CDH4.1.2. I just create a Test workflow and added a
    DistCp task to it. It broke. I have no problems when modifying a copy of an
    example workflow.

    FYI. I'm using MySQL 5.1 as the backend for both Hue and Oozie.

    Thanks,
    Ben

    On Monday, November 19, 2012 11:32:31 AM UTC-8, Romain Rigaux
    wrote:
    Hi Ben,

    Are you still on CDH4.1.2?

    I created a new workflow and added a DistCp action and it worked
    for me. Are you sure even this is broken or should we look into the import
    from Job Designer?

    Romain

    On Mon, Nov 19, 2012 at 11:20 AM, Abraham Elmahrek <
    a...@cloudera.com> wrote:
    Did you try to create the workflow from scratch after you copied
    the example? Does the example still exist?

    -Abe

    On 11/18/12 8:16 PM, Benjamin Kim wrote:

    Hi,

    I created a copy of the DistCp example workflow and tried to
    import a mapreduce task I created in the job designer. That's when I got
    the Server Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.

    Does this help?

    Thanks,
    Ben
  • Abraham Elmahrek at Dec 4, 2012 at 1:03 am
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so I
    can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Abraham Elmahrek at Dec 4, 2012 at 1:06 am
    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 1:23 am
    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Abraham Elmahrek at Dec 4, 2012 at 1:47 am
    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine
    a lot of your pain is sourced from that.

    -Abe
    On 12/3/12 5:23 PM, Benjamin Kim wrote:
    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben

    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 2:01 am
    Abe,

    I forgot to mention that we are using CDH4.1.2. Cloudera Manager is at
    4.1.0, and Hue is at 2.1.0.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine a
    lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 2:03 am
    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine a
    lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Abraham Elmahrek at Dec 4, 2012 at 2:04 am
    Innodb or myisam?
    On 12/3/12 6:03 PM, Benjamin Kim wrote:
    And mysql 5.1.17.

    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug
    fixes that went into that release with regards to the Oozie
    editor. I imagine a lot of your pain is sourced from that.

    -Abe
    On 12/3/12 5:23 PM, Benjamin Kim wrote:
    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben

    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any
    commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a
    data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata >
    /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 2:09 am
    I checked a couple tables. It's MyISAM.
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine a
    lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 6:09 pm
    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize just the
    hue.oozie tables? I tried to reinstall the examples, but they seem to be
    broken too. I looked at some of the files in the example directories, and
    they are incomplete or missing.

    Thanks,
    Ben
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine a
    lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Abraham Elmahrek at Dec 4, 2012 at 7:20 pm
    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should be
    able to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!
    On 12/4/12 10:09 AM, Benjamin Kim wrote:
    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize just
    the hue.oozie tables? I tried to reinstall the examples, but they seem
    to be broken too. I looked at some of the files in the example
    directories, and they are incomplete or missing.

    Thanks,
    Ben

    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?
    On 12/3/12 6:03 PM, Benjamin Kim wrote:
    And mysql 5.1.17.

    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of
    bug fixes that went into that release with regards to the
    Oozie editor. I imagine a lot of your pain is sourced from that.

    -Abe
    On 12/3/12 5:23 PM, Benjamin Kim wrote:
    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben

    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick
    any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give
    me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata >
    /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 7:28 pm
    Thanks, Abe.

    I'll give it shot.

    Cheers,
    Ben
    On Tuesday, December 4, 2012 11:20:21 AM UTC-8, abe wrote:

    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should be able
    to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!

    On 12/4/12 10:09 AM, Benjamin Kim wrote:

    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize just
    the hue.oozie tables? I tried to reinstall the examples, but they seem to
    be broken too. I looked at some of the files in the example directories,
    and they are incomplete or missing.

    Thanks,
    Ben
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine a
    lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 8:03 pm
    Hi Abe,

    I emptied all the tables. The /user/hue/oozie/{workspaces,deployments}
    directories are empty too. It seems to be working. I recreated the workflow
    and copied it for another data integration. No problems popped up. I did 2
    things different. I created a coordinator, but this time I didn't. I
    pointed the deployment folder to be in the deployments directory, but this
    time I left them in the workspaces folder. I don't know if this has
    anything to do with it.

    Thanks,
    Ben
    On Tuesday, December 4, 2012 11:20:21 AM UTC-8, abe wrote:

    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should be able
    to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!

    On 12/4/12 10:09 AM, Benjamin Kim wrote:

    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize just
    the hue.oozie tables? I tried to reinstall the examples, but they seem to
    be broken too. I looked at some of the files in the example directories,
    and they are incomplete or missing.

    Thanks,
    Ben
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine a
    lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Abraham Elmahrek at Dec 4, 2012 at 9:26 pm
    Hey Ben,

    Just to be clear, it is working now?
    On 12/4/12 12:03 PM, Benjamin Kim wrote:
    Hi Abe,

    I emptied all the tables. The /user/hue/oozie/{workspaces,deployments}
    directories are empty too. It seems to be working. I recreated the
    workflow and copied it for another data integration. No problems
    popped up. I did 2 things different. I created a coordinator, but this
    time I didn't. I pointed the deployment folder to be in the
    deployments directory, but this time I left them in the workspaces
    folder. I don't know if this has anything to do with it.

    Thanks,
    Ben

    On Tuesday, December 4, 2012 11:20:21 AM UTC-8, abe wrote:

    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should
    be able to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!
    On 12/4/12 10:09 AM, Benjamin Kim wrote:
    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize
    just the hue.oozie tables? I tried to reinstall the examples, but
    they seem to be broken too. I looked at some of the files in the
    example directories, and they are incomplete or missing.

    Thanks,
    Ben

    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?
    On 12/3/12 6:03 PM, Benjamin Kim wrote:
    And mysql 5.1.17.

    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a
    bunch of bug fixes that went into that release with
    regards to the Oozie editor. I imagine a lot of your
    pain is sourced from that.

    -Abe
    On 12/3/12 5:23 PM, Benjamin Kim wrote:
    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben

    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry
    pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you
    give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata >
    /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 9:43 pm
    Yes, it's working now. Just the shell action for the Impala refresh returns
    an error. But the Impala refresh is working.

    Thanks,
    Ben
    On Tuesday, December 4, 2012 1:26:22 PM UTC-8, abe wrote:

    Hey Ben,

    Just to be clear, it is working now?

    On 12/4/12 12:03 PM, Benjamin Kim wrote:

    Hi Abe,

    I emptied all the tables. The /user/hue/oozie/{workspaces,deployments}
    directories are empty too. It seems to be working. I recreated the workflow
    and copied it for another data integration. No problems popped up. I did 2
    things different. I created a coordinator, but this time I didn't. I
    pointed the deployment folder to be in the deployments directory, but this
    time I left them in the workspaces folder. I don't know if this has
    anything to do with it.

    Thanks,
    Ben
    On Tuesday, December 4, 2012 11:20:21 AM UTC-8, abe wrote:

    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should be
    able to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!

    On 12/4/12 10:09 AM, Benjamin Kim wrote:

    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize just
    the hue.oozie tables? I tried to reinstall the examples, but they seem to
    be broken too. I looked at some of the files in the example directories,
    and they are incomplete or missing.

    Thanks,
    Ben
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine a
    lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 4, 2012 at 9:56 pm
    Nevermind. The Impala refresh is not working. I don't know why. It's not a
    major issue since I can do it manually.
    On Tuesday, December 4, 2012 1:26:22 PM UTC-8, abe wrote:

    Hey Ben,

    Just to be clear, it is working now?

    On 12/4/12 12:03 PM, Benjamin Kim wrote:

    Hi Abe,

    I emptied all the tables. The /user/hue/oozie/{workspaces,deployments}
    directories are empty too. It seems to be working. I recreated the workflow
    and copied it for another data integration. No problems popped up. I did 2
    things different. I created a coordinator, but this time I didn't. I
    pointed the deployment folder to be in the deployments directory, but this
    time I left them in the workspaces folder. I don't know if this has
    anything to do with it.

    Thanks,
    Ben
    On Tuesday, December 4, 2012 11:20:21 AM UTC-8, abe wrote:

    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should be
    able to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!

    On 12/4/12 10:09 AM, Benjamin Kim wrote:

    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize just
    the hue.oozie tables? I tried to reinstall the examples, but they seem to
    be broken too. I looked at some of the files in the example directories,
    and they are incomplete or missing.

    Thanks,
    Ben
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug fixes
    that went into that release with regards to the Oozie editor. I imagine a
    lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Romain Rigaux at Dec 7, 2012 at 5:03 am
    What error do you get? I tried a shell command and it worked for me.

    Command should be: impala-shell or full path to the command
    Args should be:

    - -i
    - dn3:21000
    - -q
    - "refresh"

    Romain
    On Tue, Dec 4, 2012 at 1:56 PM, Benjamin Kim wrote:

    Nevermind. The Impala refresh is not working. I don't know why. It's not a
    major issue since I can do it manually.

    On Tuesday, December 4, 2012 1:26:22 PM UTC-8, abe wrote:

    Hey Ben,

    Just to be clear, it is working now?

    On 12/4/12 12:03 PM, Benjamin Kim wrote:

    Hi Abe,

    I emptied all the tables. The /user/hue/oozie/{workspaces,**deployments}
    directories are empty too. It seems to be working. I recreated the workflow
    and copied it for another data integration. No problems popped up. I did 2
    things different. I created a coordinator, but this time I didn't. I
    pointed the deployment folder to be in the deployments directory, but this
    time I left them in the workspaces folder. I don't know if this has
    anything to do with it.

    Thanks,
    Ben
    On Tuesday, December 4, 2012 11:20:21 AM UTC-8, abe wrote:

    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should be
    able to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!

    On 12/4/12 10:09 AM, Benjamin Kim wrote:

    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize just
    the hue.oozie tables? I tried to reinstall the examples, but they seem to
    be broken too. I looked at some of the files in the example directories,
    and they are incomplete or missing.

    Thanks,
    Ben
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug
    fixes that went into that release with regards to the Oozie editor. I
    imagine a lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/**hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 7, 2012 at 5:32 am
    Hi Romain,

    It was something like, "output CONNECT takes only one argument for host". I'm paraphrasing trying to recall it. But, I have not tried it your way. I put the arguments like this:
    -i dn3:21000
    -q "refresh"

    I'll put each part as their own entry.

    Thanks,
    Ben
  • Benjamin Kim at Dec 7, 2012 at 4:39 pm
    Hi Romain,

    Bad news. I still keep getting the Server Error (500). I find that if I
    just keep copying/creating workflows eventually it will work. I, then,
    afterward delete the bad ones. It's annoying, but it works.

    Thanks,
    Ben
    On Thursday, December 6, 2012 9:03:14 PM UTC-8, Romain Rigaux wrote:

    What error do you get? I tried a shell command and it worked for me.

    Command should be: impala-shell or full path to the command
    Args should be:

    - -i
    - dn3:21000
    - -q
    - "refresh"

    Romain

    On Tue, Dec 4, 2012 at 1:56 PM, Benjamin Kim <bbui...@gmail.com<javascript:>
    wrote:
    Nevermind. The Impala refresh is not working. I don't know why. It's not
    a major issue since I can do it manually.

    On Tuesday, December 4, 2012 1:26:22 PM UTC-8, abe wrote:

    Hey Ben,

    Just to be clear, it is working now?

    On 12/4/12 12:03 PM, Benjamin Kim wrote:

    Hi Abe,

    I emptied all the tables. The /user/hue/oozie/{workspaces,**deployments}
    directories are empty too. It seems to be working. I recreated the workflow
    and copied it for another data integration. No problems popped up. I did 2
    things different. I created a coordinator, but this time I didn't. I
    pointed the deployment folder to be in the deployments directory, but this
    time I left them in the workspaces folder. I don't know if this has
    anything to do with it.

    Thanks,
    Ben
    On Tuesday, December 4, 2012 11:20:21 AM UTC-8, abe wrote:

    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should be
    able to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!

    On 12/4/12 10:09 AM, Benjamin Kim wrote:

    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize
    just the hue.oozie tables? I tried to reinstall the examples, but they seem
    to be broken too. I looked at some of the files in the example directories,
    and they are incomplete or missing.

    Thanks,
    Ben
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug
    fixes that went into that release with regards to the Oozie editor. I
    imagine a lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/**hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Romain Rigaux at Dec 7, 2012 at 6:08 pm
    Hi Ben,

    This is very probably related to #2 in
    https://issues.cloudera.org/browse/HUE-929

    Romain
    On Fri, Dec 7, 2012 at 8:39 AM, Benjamin Kim wrote:

    Hi Romain,

    Bad news. I still keep getting the Server Error (500). I find that if I
    just keep copying/creating workflows eventually it will work. I, then,
    afterward delete the bad ones. It's annoying, but it works.

    Thanks,
    Ben

    On Thursday, December 6, 2012 9:03:14 PM UTC-8, Romain Rigaux wrote:

    What error do you get? I tried a shell command and it worked for me.

    Command should be: impala-shell or full path to the command
    Args should be:

    - -i
    - dn3:21000
    - -q
    - "refresh"

    Romain
    On Tue, Dec 4, 2012 at 1:56 PM, Benjamin Kim wrote:

    Nevermind. The Impala refresh is not working. I don't know why. It's not
    a major issue since I can do it manually.

    On Tuesday, December 4, 2012 1:26:22 PM UTC-8, abe wrote:

    Hey Ben,

    Just to be clear, it is working now?

    On 12/4/12 12:03 PM, Benjamin Kim wrote:

    Hi Abe,

    I emptied all the tables. The /user/hue/oozie/{workspaces,**de**ployments}
    directories are empty too. It seems to be working. I recreated the workflow
    and copied it for another data integration. No problems popped up. I did 2
    things different. I created a coordinator, but this time I didn't. I
    pointed the deployment folder to be in the deployments directory, but this
    time I left them in the workspaces folder. I don't know if this has
    anything to do with it.

    Thanks,
    Ben
    On Tuesday, December 4, 2012 11:20:21 AM UTC-8, abe wrote:

    Hey Ben,

    When you first install Hue, the oozie tables are empty. You should be
    able to simply empty all tables prefixed with oozie_*.

    Remember to backup all your data!

    On 12/4/12 10:09 AM, Benjamin Kim wrote:

    Hi Abe,

    What would be your recommendation? Is there a way to reinitialize
    just the hue.oozie tables? I tried to reinstall the examples, but they seem
    to be broken too. I looked at some of the files in the example directories,
    and they are incomplete or missing.

    Thanks,
    Ben
    On Monday, December 3, 2012 6:04:10 PM UTC-8, abe wrote:

    Innodb or myisam?

    On 12/3/12 6:03 PM, Benjamin Kim wrote:

    And mysql 5.1.17.
    On Monday, December 3, 2012 5:47:50 PM UTC-8, abe wrote:

    I did receive it.

    It may be wise to upgrade to CDH 4.1.2. There were a bunch of bug
    fixes that went into that release with regards to the Oozie editor. I
    imagine a lot of your pain is sourced from that.

    -Abe

    On 12/3/12 5:23 PM, Benjamin Kim wrote:

    Abe,

    I sent it to you with my reply from my work email.

    Hope you get it.

    Thanks,
    Ben
    On Monday, December 3, 2012 5:06:08 PM UTC-8, abe wrote:

    Also,

    What version of Hue are you running? Did you cherry pick any
    commits
    from master or any manual edition to the code?

    -Abe
    On 12/3/12 5:03 PM, Abraham Elmahrek wrote:
    Yikes,

    Okay I can't reproduce this apparently. Can you give me a data dump so
    I can try to reproduce it with your data? Use
    "/usr/share/hue/build/env/bin/****hue dumpdata > /tmp/data.json" and email
    it over.
    On 12/3/12 4:37 PM, Benjamin Kim wrote:
    -i impala-test1:21000, -q "refresh"
  • Benjamin Kim at Dec 7, 2012 at 6:13 pm
    Romain,

    I would agree. It's sounds like that might be it.

    Cheers,
    Ben
  • Benjamin Kim at Dec 4, 2012 at 8:23 pm
    Hi Abe,

    Have you tried the shell action to running the Impala refresh command? It gives me an error.

    impala-shell -i dn3:21000 -q "refresh"

    Just curious,
    Ben
  • Benjamin Kim at Nov 19, 2012 at 7:49 pm
    The example still exists after creating the copy. I modified the copy, and
    it's still working. But, I created a Test workflow and added a DistCp task,
    and that broke it. It seems to work when I copy an example.
    On Monday, November 19, 2012 11:20:37 AM UTC-8, abe wrote:

    Did you try to create the workflow from scratch after you copied the
    example? Does the example still exist?

    -Abe
    On 11/18/12 8:16 PM, Benjamin Kim wrote:
    Hi,

    I created a copy of the DistCp example workflow and tried to import a
    mapreduce task I created in the job designer. That's when I got the Server
    Error (500) in Hue and the IndexError: index out of range in the
    runcpserver.log. So, I created a brand new workflow from scratch and added
    a DistCp task and saved it. When I tried to edit it after closing it, I got
    the same errors again.
    Does this help?

    Thanks,
    Ben

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouphue-user @
categorieshadoop
postedNov 17, '12 at 12:56a
activeDec 7, '12 at 6:13p
posts48
users4
websitecloudera.com
irc#hadoop

People

Translate

site design / logo © 2022 Grokbase