On Sat, Jan 3, 2015 at 7:59 AM, Imesh Gunaratne wrote:
> One of the problems we have here is that, the previous logic has used the
> Cluster ID to fetch the connected subscriptions on Instance Started event.
> However now it is not possible to do the same with Cluster ID, instead
> Instance Start
One of the problems we have here is that, the previous logic has used the
Cluster ID to fetch the connected subscriptions on Instance Started event.
However now it is not possible to do the same with Cluster ID, instead
Instance Started event need to include the Application ID.
On Sat, Jan 3, 2015
Thanks Lakmal! Now SM does not have subscription/repo information, we might
need to get them from Autoscaler. Yes I think we still have not implemented
any functionality for MT cartridges. Will introduce this with the signup
process.
Thanks
On Sat, Jan 3, 2015 at 7:45 AM, Lakmal Warusawithana
wr
But this is required by the multi tenants scenario also. In single tenant
wait to get git repo info (SM will send after receiving instance start,
IIRC) and do the clone at first time. In the MT, when we signup for the MT,
we should send these info. IMO, we should fixed the flow, but SM should
handl
As it looks like we have taken this long path to send repository
information to the instance because we needed to send the encrypted
password and secret separately.
I think we need to preserve this and fix Instance Status listener logic.
On Fri, Jan 2, 2015 at 9:52 PM, Imesh Gunaratne wrote:
>
Hi Devs,
This is regarding $subject. In the latest codebase git clone does not work
in agent.
I did some investigations on this logic and found that it has worked
earlier when cartridge subscriptions were managed by Stratos Manager (SM).
When an Instance Started event is received by SM, it query
Hi,
Anyone using 4-vm-setup?
When I list machines from master, it is listing only the master node, not
minions.
core@master ~ $ fleetctl list-machines
MACHINEIPMETADATA
58b1a902...172.17.8.100-
And when I list minions from master, it is listing only the master node,
not
It is already implemented and was working fine.
https://git-wip-us.apache.org/repos/asf?p=stratos.git;a=tree;f=components/org.apache.stratos.python.cartridge.agent/cartridgeagent/cartridgeagent/modules/artifactmgt;h=b0376c57220d2ca577c7b383d8a1461b80b18e5c;hb=HEAD
Thanks.
On Fri, Jan 2, 2015 at
What do you mean?? Its there since M3
On Fri, Jan 2, 2015 at 6:25 PM, Imesh Gunaratne wrote:
> Seems like we have not written logic in agent to checkout artifacts from
> GIT repository.
>
> On Fri, Jan 2, 2015 at 6:08 PM, Imesh Gunaratne wrote:
>
>> I have now fixed the issue of accessing the s
Seems like we have not written logic in agent to checkout artifacts from
GIT repository.
On Fri, Jan 2, 2015 at 6:08 PM, Imesh Gunaratne wrote:
> I have now fixed the issue of accessing the service via the host machine
> (http://kubernetes-master-ip:port/) and pushed changes to master branch.
>
I have now fixed the issue of accessing the service via the host machine
(http://kubernetes-master-ip:port/) and pushed changes to master branch.
Now I see a problem when a public GIT repo url is given without specifying
credentials. I'm currently looking into this.
Thanks
On Fri, Jan 2, 2015 at
I have now resolved the health statistics publishing issue in agent:
- There were several topology event parsers which were not properly updated
with the latest changes. As a result those were raising errors. I have now
fixed them.
- Agent's logic which waits until CEP port is active was not visib
12 matches
Mail list logo