Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Bigtop >> mail # dev >> Python Fork


+
Philip Herron 2013-03-27, 13:54
+
Sean Mackrory 2013-03-27, 15:26
Copy link to this message
-
Re: Python Fork
On 27/03/13 15:26, Sean Mackrory wrote:
> Overall I think I like this - thanks for doing all the work for this fork!
> It would indeed be nice to have a more sophisticated language for this.
> Some thoughts:
>
>    - If we do make a move to Python, we ought to make sure it works on
>    Python 2.4 initially, as we're still doing releases that we intend to
>    support on RHEL 5. I haven't tried the fork on RHEL 5 yet, so I'm just
>    mentioning it - don't know if there actually are any small issues.
>
>
Yeah i could try and and test against this tomorrow there are a few
things i'd have to look out for since i think i used with in there etc
which is python >= 2.5 but its not nessecary etc.

>    - do-component-build and install_.sh: I think those should remain as
>    bash scripts. Did you have any intention to the contrary?
>
Yeah this is true we should deffo keep this this is a nice way to have
the builds be the same on both deb/rpm.

>
>    - Some of the do-component-build scripts source 'bigtop.bom' to get
>    component versions in the environment. We need to make sure we still
>    generate that in a shell-friendly form.
>
Ah this is an interesting problem but if we were to output environment
variables for the child-processes of subprocess.call this might work.
Other outputting an bash friendly bom like before. There is definitely a
way to work around this. Though i am not sure what way yet :P.

>
>    - Don't know how I feel about "demoting" the tests. I've been under the
>    impression that they were still maintained (though I admit I haven't paid
>    much attention to them myself), but if they're not well maintained, I think
>    I'd rather we make a plan to give them more attention than accept their
>    unmaintained-ness.
Yeah it might be my ignorance but I�ve never got that side of bigtop to
work yet. And not sure how it works I think I put bigtop-deploy and test
under contrib mostly because it undocumented and not really that
important for the main functions of bigtop to package software.

>
> Definitely a big decision to make and there's a lot of discussion and work
> to go - but put me down for a +1.
>

And i plan to make the code a lot nicer i did this in an afternoon and i
know its probably not great yet but there is a lot of room for more
interesting use of bigtop for long-term.

Thanks for your +1. I think with some work i could try and bring it up
to scratch with trunk bigtop and see how the community finds it i think
its a necessary step in the long run even though the gcc hacker in my
likes makefiles :).

--Phil
+
Roman Shaposhnik 2013-03-27, 15:37
+
Philip Herron 2013-03-28, 15:04
+
Sean Mackrory 2013-03-28, 16:01
+
Roman Shaposhnik 2013-03-28, 16:33
+
Konstantin Boudnik 2013-03-28, 19:18
+
Roman Shaposhnik 2013-03-28, 16:29
+
Bruno Mahé 2013-03-29, 08:59
+
Bruno Mahé 2013-03-29, 08:42
+
Bruno Mahé 2013-03-29, 09:10
+
Philip Herron 2013-03-27, 15:12
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB