Hi, I am working on milestone3 PR[1]. I have updated the pom mapping to the Phoenix parent pom. I will write the launching script in Phoenix bin. I'm progressing on making the web app standalone. As I'm progressing through the task list I will tick them.
Let me know if I missed anything on the task list. Thanks. [1] https://github.com/apache/phoenix/pull/96 On Fri, Jul 3, 2015 at 8:41 AM, Ayola Jayamaha <[email protected]> wrote: > Hi Nick, > > I have created a pull request [1]. After going through the steps that you > have given and the resources I was able to create it with no conflicts and > it is giving a green button. So I think it is fine. If there is some > mistake please let me know. > Step 1 has been done. Updating the pom files are yet to be done. > > Thanks. > > [1] https://github.com/apache/phoenix/pull/96 > > On Fri, Jul 3, 2015 at 12:46 AM, Ayola Jayamaha <[email protected]> > wrote: > >> Thanks James and Nick for Quick reply. >> >> On Fri, Jul 3, 2015 at 12:05 AM, Nick Dimiduk <[email protected]> >> wrote: >> >>> * 1. Work from a fork of Phoenix, not your own project.* >>>> Yes I know the git work flow some far. And I can get a fork from >>>> Phoenix and do my implementation there(branch). >>>> >>> >>> Great! >>> >>> I have created the milestone 3 branch(Phoenix 4.4 Hbase 9.8) and I have >>>> sent the pull request and it is not completed (pom file is not pointing to >>>> the Phoenix parent pom still). If I have done any mistake please let me >>>> know. >>>> >>>> [1] https://github.com/apache/phoenix/pull/95 >>>> >>> >>> Yikes, this needs some git-hygeine. Your PR should contain only your >>> changes. Please rebase your changes on top of the existing branch. >>> Something like the following commands should suffice (assuming you have >>> github.com/apache/phoenix as origin): >>> >>> $ git remote update >>> $ git checkout nishanis-branch >>> $ git rebase origin/4.4-HBase-0.98 >>> >>> I will try to follow them. and try to fix it >> >> That should give you just your commits at the HEAD, and you can base your >>> PR from that. We can walk through this with a screen share if you'd like, I >>> have time today and tomorrow. >>> >> Thanks, If I was not able. I will share screen and get the help tomorrow >> >> >>> There's a pretty good description of rebase: >>> http://www.git-tower.com/blog/understanding-rebase-merge-in-git/ >>> >>> * 2. Web service that is launched with a python script from bin.* >>>> I will add a new folder in root level of Phoenix(4.4.0 9.8Hbase) called >>>> (tracingwebapp). And when you run the build from root level(need to update >>>> the root pom of Phoenix) or build from the folder level tracingwebapp and >>>> it will build the war file. So I will add a launching script to the bin of >>>> Phoenix to start the war file. Is it fine? >>>> >>> >>> We'll need it integrated into Phoenix's build, so that `mvn clean >>> package` from the Phoenix root will also build your code and run your >>> tests. Phoenix is a "multi-module" project, which means it consists of >>> multiple independent components. We're going to add tracingwebapp as a new >>> component. You can see how the pom.xml file in the root of the project >>> defines a list of modules. tracingwebapp will be added to that list. >>> >> Think looking on the other pom file in Phoenix. I can make it. >> >>> >>> There's a text-book example of multi-module projects: >>> http://books.sonatype.com/mvnex-book/reference/multimodule.html >>> >>> * 3. The tracing tools queries the real tracing table for spans.* >>>> I have written a Java code to to read the tracing data of Phoenix and >>>> adding it to a text file. It is not added to Jetty yet. I would be needing >>>> help to communicate from Java to Javascript. >>>> >>> >>> Excellent! We can start working on that once you have steps (1) and (2) >>> pulled together. >>> >>> * 4. The UI renders those spans.* >>>> Yes there will be issues when integrating. At the moment I have sent a >>>> PR. I'm not sure I did it correctly. >>>> >>> >>> I'm not sure which PR you mean, do you have a link? >>> >> That I have shared in above >> [1] https://github.com/apache/phoenix/pull/95 >> >> steps that I followed >> 1. Got the fork from Apache >> 2. Make a new branch ' milestone 3' [2] on 4.4-HBase-0.98 >> >> [2] https://github.com/AyolaJayamaha/phoenix/tree/milestone-3 >> >> >> >>> >>> After the mid-term communicate from Java to Javascript will be the first >>>> part. These changes will be done on the PR. >>>> >>> >>> During development, it's better to work from a personal branch (which >>> can be public on your own public github repository) instead of PR's. We can >>> collaborate there -- you can push commits to it, we can comment on them, >>> you can push fixes, squishing history and so on. Once your branch is in >>> good shape, you rebase it onto the latest community changes and then >>> publish your PR. We can practice this workflow after you've completed (1) >>> anove. >>> >> ok >> >>> >>> On Wed, Jul 1, 2015 at 10:28 PM, James Taylor <[email protected]> >>>> wrote: >>>> >>>>> I second what Nick said - we need to be driving the UI directly from >>>>> Phoenix queries against the trace table. I think with #3, one valuable >>>>> output will be a series of Phoenix queries that provide insight into >>>>> understanding the performance of a query. >>>>> >>>>> Unfortunately, what you've done so far isn't helping Phoenix. This >>>>> needs to be fixed quickly, or we've failed in my mind. >>>>> >>>>> Are you working full-time on this, Nishani? >>>>> >>>>> Thanks, >>>>> James >>>>> >>>>> >>>>> >>>>> On Tue, Jun 30, 2015 at 12:16 PM, Nick Dimiduk <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Nishani, >>>>>> >>>>>> I'm glad to see your self-modivation and continued progress. UI >>>>>> development is not my strength, and I like how you've interacted with the >>>>>> community to solicit feedback through your prototyping stages. One thing >>>>>> we >>>>>> are concerned about is your project coming to a point where it's ready to >>>>>> be committed back to Phoenix. I think it would be a real shame for you >>>>>> and >>>>>> for Apache if your work is not merged into the project. >>>>>> >>>>>> Let's make a firm plan for getting your work committed and running in >>>>>> production. We may need to cut scope from your milestone 2 objectives in >>>>>> order to meet this goal, but that's just fine -- this is how software >>>>>> gets >>>>>> built in industry. >>>>>> >>>>>> So, what will you need to get a PR merged into Phoenix? From looking >>>>>> through your branch, the following are the top objectives. We can dive >>>>>> into >>>>>> them one-by-one. >>>>>> >>>>>> * 1. Work from a fork of Phoenix, not your own project.* >>>>>> >>>>>> This may require you learning some more git; I don't know your skill >>>>>> level with this tool. It also will interrupt your development workflow >>>>>> for >>>>>> a little while as you become comfortable working with Phoenix from source >>>>>> instead of the 4.4.0 release artifact. >>>>>> >>>>>> * 2. Web service that is launched with a python script from bin.* >>>>>> >>>>>> We're going to need to create a new module in the Phoenix build for >>>>>> your jetty service, that way it's built as part of Phoenix. We'll also >>>>>> need >>>>>> to add a launch script to Phoenix's bin directory because mvn run is not >>>>>> acceptable production deployments. >>>>>> >>>>>> * 3. The tracing tools queries the real tracing table for spans.* >>>>>> >>>>>> There's no reason to merge a tool that's querying over sample data. >>>>>> You have the jetty service for hosting the JavaScript application, so you >>>>>> already have a place for Java code that interacts with Phoenix. You're >>>>>> going to need a span query API to communicate from JavaScript to Java; >>>>>> you >>>>>> already have the bones of this API in the mocked span data structures you >>>>>> use for your demos. >>>>>> >>>>>> * 4. The UI renders those spans.* >>>>>> >>>>>> This part's easy; you already have good progress on the UI. I >>>>>> explicitly mention it because it's a requirement for committable code and >>>>>> there's always new bugs when integrating systems. Expect to make some >>>>>> tweaks here once you get some real behind the queries. >>>>>> >>>>>> This is a lot of work, some of it you may not be comfortable with, >>>>>> but I think you can do it. The community is here to help you -- I'm here >>>>>> to >>>>>> help you. >>>>>> >>>>>> Getting your JavaScript app wired up and showing real tracing table >>>>>> data is the MOST IMPORTANT thing right now. Once you have that, we can >>>>>> start improving it with displaying user's SQL instead of trace IDs and so >>>>>> on. I highly recommend you focus on 1-4 above; we'll resume milestone 2 >>>>>> objectives once your initial work is committed. >>>>>> >>>>>> As always, I'm available by email, Skype, IM, G+; whatever is >>>>>> convenient for you. Let's get your work out there, committed and into >>>>>> production so that Phoenix users have access to this new, powerful tool >>>>>> you're building! Let's also get your name into the Phoenix commit >>>>>> history :) >>>>>> >>>>>> -n >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> Nishani Jayamaha >>>> http://ayolajayamaha.blogspot.com/ >>>> >>>> >>>> >>> >> >> >> -- >> Best Regards, >> Nishani Jayamaha >> http://ayolajayamaha.blogspot.com/ >> >> >> > > > -- > Best Regards, > Nishani Jayamaha > http://ayolajayamaha.blogspot.com/ > > > -- Best Regards, Nishani Jayamaha http://ayolajayamaha.blogspot.com/
