I have now fixed this issue by moving artifact repository password
encryption logic to stratos manager service clients. Application key was
needed by this logic hence application was read.
Please take a pull and build again.
Thanks
On Sat, Jan 10, 2015 at 10:12 PM, Imesh Gunaratne wrote:
> As
As I found this problem occurs as follows:
- When an application is deployed, Autoscaler publishes Application Created
event.
- Soon after Autoscaler makes a call to Stratos Manager to add an
Application SignUp.
- At this point Stratos Manager has not received the Application Created
event.
- As a
Thanks Imesh.
On Fri, Jan 9, 2015 at 11:52 PM, Imesh Gunaratne wrote:
> Hi Lahiru,
>
> No, there shouldn't be any impact on single-tenant applications from the
> above implementation. Will investigate and see what's causing this.
>
> Thanks
>
> On Fri, Jan 9, 2015 at 11:47 PM, Lahiru Sandaruwan
Hi Lahiru,
No, there shouldn't be any impact on single-tenant applications from the
above implementation. Will investigate and see what's causing this.
Thanks
On Fri, Jan 9, 2015 at 11:47 PM, Lahiru Sandaruwan wrote:
> Hi Imesh,
>
> It seems my single tenant app[1] is failing. Do i need to cha
Hi Imesh,
It seems my single tenant app[1] is failing. Do i need to change it?
Error is at [2].
Thanks.
[1]
https://github.com/rekathiru/grouping-samples/tree/master/dependency_scaling/sample_groups
[2]
[2015-01-09 23:33:27,758] INFO
{org.apache.stratos.autoscaler.services.impl.AutoScalerSer
Hi Devs,
I have now completed Application SignUp functionality for Multi-Tenant
applications and pushed changes to master branch.
This is how it works:
- There is no application signup support for single-tenant applications,
it's only available for multi-tenant applications.
- For single-tenant a
I have now completed the initial version of Application SignUp support for
multi-tenant applications. Changes were pushed to master branch. Now I'm
working on fixing the logic which notify ADC to send Artifact Update event
on Git updates.
Please find latest sample artifacts here:
https://github.co
Thing is all other sunscribleInfo used in AS and only repo info used in SM.
In the single tenant, all these come to AS when deploying the application
and we need to pass subscribleInfo to SM for ADC usage. MT scenario
subscribleInfo comes to SM. If consider all scenario, IMO this is a good
move.
O
On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne wrote:
> Following is the current definition of Subscribable Info in an application:
>
> {
>"applicationId":"single-cartridge-app",
>"alias":"single-cartridge-app",
>"components":{
> "cartridges":[
> {
> "type
Following is the current definition of Subscribable Info in an application:
{
"applicationId":"single-cartridge-app",
"alias":"single-cartridge-app",
"components":{
"cartridges":[
{
"type":"php",
"cartridgeMin":1,
"cartridgeMax":10,
+1 for the design Lakmal!
Will store subscribable information in SM and expose a service to manage
them. For single tenant applications will make a call from Autoscaler to SM
to register subscribable information. For Multi-Tenant applications will
expose a REST API method to signup.
Thanks
On Mo
IMO we can handle it without major refactor. We can have property in
application to define whether single tenant or MT. MT applications are only
create and deploy by Super tenant. If MT application deployed, we can
expose a API, to get subscribe info when signup to the MT application by
tenant.
Fu
Hi Devs,
At present with service grouping functionality an application can have only
one subscription. This subscription may include multiple subscribable
information blocks for multiple cartridges.
To support Multi-Tenant applications which may include Multi-Tenant
cartridges we should be able t
13 matches
Mail list logo
