Hi Anjana,
On Wed, Aug 7, 2013 at 12:25 AM, Anjana Fernando <[email protected]> wrote: > Hi Harshana, > > On Tue, Aug 6, 2013 at 9:17 PM, Harshana Martin <[email protected]> wrote: > >> Hi Anjana, >> >> >> On Tue, Aug 6, 2013 at 1:36 AM, Anjana Fernando <[email protected]> wrote: >> >>> Hi, >>> >>> The only issue is, the user experience is not consistent for the user, >>> when some artifacts are deployed from the CAR and when otherwise directly >>> deployed from a wizard or some upload method from the web console. Where >>> suddenly the edit/delete functionality is not available for some of the >>> artifacts. >>> >> >> So I do not agree with this argument! >> >> Task of the management console is to support management task not the >> development task. >> >> Current management console has development capability (which is wrong) >> does not mean we will continue to support development tasks via Management >> console. It's good to have such capability for quick demo purpose but real >> development work will not happen on Management console. >> > > That's the problem .. that's where I said, the user experience is not > consistent, development capability in management console is wrong or > whatever, we currently have that at the moment, that is what I pointed out. > In that case, we should remove all dev stuff from management console > altogether, and come to the pure approach, that would be the ideal case. > Yes. >From tooling perspective of the platform that is where we are heading. But in order to do that first we need all those development capabilities in the Mgt Console to be available in Dev Studio. But the problem is we are not there yet but we are certainly making progress. But we do not need to make the same mistake we did in the past by including these Dev Capabilities in to Mgt Console and specially messing with CAR files from Mgt console should not be supported. Thanks and Regards, Harshana > But what we are currently going to do now is something in the middle. > Anyways, I just pointed out the issue in the suggested approach applying it > to the current way we have stuff. > > >> >> >> Anyways, if that is the policy we are going to stick to, that is also >>> fine. So now we just need a clear API to get these information into see, if >>> the deployed artifact we have now came from a CAR or directly deployed, so >>> we can change the other functionality accordingly. >>> >> >> Please use Application Admin service for that. >> > > OK, great. Ayashkantha please note, use the above service and do the > needful to change the BAM toolbox deployment suitably. > > Cheers, > Anjana. > > >> >> Thanks and Regards, >> Harshana >> >>> >>> Cheers, >>> Anjana. >>> >>> >>> On Tue, Aug 6, 2013 at 1:54 PM, Srinath Perera <[email protected]> wrote: >>> >>>> I also prefer not to let user edit artifacts in a car via the admin >>>> console .. or at least keep it that way for start. >>>> >>>> Lets see what others think. >>>> >>>> --Srinath >>>> >>>> >>>> On Tue, Aug 6, 2013 at 1:47 PM, Harshana Martin <[email protected]>wrote: >>>> >>>>> Hi Srinath, >>>>> >>>>> >>>>> On Tuesday, August 6, 2013, Srinath Perera wrote: >>>>> >>>>>> Hi Ayashkantha, >>>>>> >>>>>> Yes, you are right. >>>>>> >>>>>> Harshna, IMO these are the requirements >>>>>> >>>>>> 1) When someone deploy a car, we directly deploy artifacts in the >>>>>> carbon by calling deployers without copying them to file system >>>>>> >>>>> >>>>> Correct! >>>>> >>>>>> 2) Either we should not let users edit artifacts come via car, or >>>>>> update the underline car file when the update is done. >>>>>> >>>>> >>>>> I'm strongly -1 for involving Carbon server for manipulating CAR files >>>>> in the runtime since IMO server is trying to do something out side of its >>>>> scope and it could lead us to unnecessary complexities in terms of >>>>> persistence, application governance,etc. >>>>> >>>>> If a car file is required o be updated, it is the task of the >>>>> developer/Dev ops person to package it using Dev Studio or Maven and >>>>> redeploy the new CAR file. >>>>> >>>>> We have already decided in a previous meeting we do not let users to >>>>> manipulate artifacts deployed via CAR. For example delete should be >>>>> disabled for artifacts deployed via CAR. >>>>> >>>>> These UI Level chanes has to be done for Carbon 4,2.0. >>>>> >>>>>> >>>>>> To do this, each artifact has to keep track where it came from (which >>>>>> car). >>>>>> >>>>>> How much of these do we have? I will schedule an review to discuss >>>>>> this. >>>>>> >>>>> >>>>> We already have admin services to do this. Application Admin is >>>>> performing it. >>>>> >>>>> This admin service is used to populate the C-App dashboard. So there >>>>> is nothing to implement in terms of tracking the C-App artifacts source. >>>>> >>>>> Only missing features at this point is the ability to limit/disable >>>>> the Ui for certain operations on the artifacts deployed via C-Apps. >>>>> >>>>> Thanks and Regards, >>>>> Harshana >>>>> >>>>>> >>>>>> --Srinath >>>>>> >>>>>> >>>>>> On Tue, Aug 6, 2013 at 11:52 AM, Ayashkantha Ramasinghe < >>>>>> [email protected]> wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> The problem we have is, even though we can undeploy the artifacts >>>>>> deployed by a car using UI, if that is not being removed from the car >>>>>> file, >>>>>> the artifact is being redeployed while restarting the server. So, what we >>>>>> need to do is to check where the artifact came from and remove it from >>>>>> there too. if the artifact is a manually deployed, then we need to remove >>>>>> it from the file system, if the artifact is automatically deployed, then >>>>>> we >>>>>> need to remove it from car file. >>>>>> >>>>>> This problem should be there in all products which supports cApp >>>>>> deployment(I checked in ESB too) and this is fundamentally wrong, because >>>>>> repacking the car manually is not the solution. The artifact being >>>>>> deleted >>>>>> by the user from UI and the server being restarted cause to bring back >>>>>> the >>>>>> changes, I guess, that is not a good design. >>>>>> >>>>>> WDYT???? >>>>>> >>>>>> >>>>>> >>>>>> Thank you, >>>>>> -Ayashkantha Ramasinghe >>>>>> -Software Engineer >>>>>> -Tel: +94 777 487 669 >>>>>> >>>>>> >>>>>> On Mon, Aug 5, 2013 at 9:13 AM, Anjana Fernando <[email protected]>wrote: >>>>>> >>>>>> Hi Harshana, >>>>>> >>>>>> That is not exactly what I asked for. The metadata, we need it to >>>>>> know where the target artifact came from, either from a specific CAR file >>>>>> or from the deployment directory of its own. We need this information >>>>>> from >>>>>> some API, for example, if a data service is edited, where I should save >>>>>> it >>>>>> to (actually in BAM toolboxes we wont have that requirement). And also, >>>>>> re-packing is basically the action the application has to do when someone >>>>>> edits something as I mentioned now, and merging it back to the CAR. And >>>>>> also, how the delete action is to be implemented. >>>>>> >>>>>> Basically, can you show me a place this functionality is already >>>>>> properly implemented, so we can use that as a reference. >>>>>> >>>>>> Cheers, >>>>>> Anjana. >>>>>> >>>>>> >>>>>> On Mon, Aug 5, 2013 at 8:48 AM, Harshana Martin <[email protected]>wrote: >>>>>> >>>>>> Hi Anjana, >>>>>> >>>>>> >>>>>> On Sun, Aug 4, 2013 at 7:27 PM, Anjana Fernando <[email protected]>wrote: >>>>>> >>>>>> Hi Harshana, >>>>>> >>>>>> On Fri, Aug 2, 2013 at 10:40 PM, Harshana Martin >>>>>> <[email protected]>wrote: >>>>>> >>>>>> >>>>>> OK, yeah, but the thing is, is this already done by others? .. as in >>>>>> .. we have to keep this metadata somewhere to say where it came from, to >>>>>> use it when we are editing/updating an artifact, and there needs to be >>>>>> some >>>>>> utilities to re-pack the car file and all. >>>>>> >>>>>> >>>>>> Metadata related CAR file and its artifacts are already being >>>>>> maintained in the Registry. >>>>>> >>>>>> >>>>>> I see, can you please point to the APIs that can be used to get these >>>>>> information and to re-pack the CAR files and so on. And, is there any >>>>>> other >>>>>> place we can use as a reference? .. >>>>>> >>>>>> >>>>>> Matadata management in the registry is done by the C-App deployer. As >>>>>> a C-App BAM artifact deployer developer you do not need to change >>>>>> anything >>>>>> in there. >>>>>> >>>>>> Re-Packaging of CAR file has to be done by the Person who developed >>>>>> the CAR file means if you are the person who want to deploy the Toolbo >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Harshana Martin >>>>> Associate Technical Lead >>>>> WSO2 Inc. : http://wso2.com >>>>> >>>>> Mobile: +94 775 998 115 >>>>> Profile: https://www.google.com/profiles/harshana05 >>>>> Blog: http://harshana05.blogspot.com >>>>> Twitter: http://twitter.com/harshana05 >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> ============================ >>>> Srinath Perera, Ph.D. >>>> Director, Research, WSO2 Inc. >>>> Visiting Faculty, University of Moratuwa >>>> Member, Apache Software Foundation >>>> Research Scientist, Lanka Software Foundation >>>> Blog: http://srinathsview.blogspot.com/ >>>> Photos: http://www.flickr.com/photos/hemapani/ >>>> Phone: 0772360902 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Anjana Fernando* >>> Technical Lead >>> WSO2 Inc. | http://wso2.com >>> lean . enterprise . middleware >>> >> >> >> >> -- >> >> Harshana Martin >> Associate Technical Lead >> WSO2 Inc. : http://wso2.com >> >> Mobile: +94 775 998 115 >> Profile: https://www.google.com/profiles/harshana05 >> Blog: http://harshana05.blogspot.com >> Twitter: http://twitter.com/harshana05 >> >> > > > -- > *Anjana Fernando* > Technical Lead > WSO2 Inc. | http://wso2.com > lean . enterprise . middleware > -- Harshana Martin Associate Technical Lead WSO2 Inc. : http://wso2.com Mobile: +94 775 998 115 Profile: https://www.google.com/profiles/harshana05 Blog: http://harshana05.blogspot.com Twitter: http://twitter.com/harshana05
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
