Hi,
I've seen some activity on #167, and a new #168 - can someone take a
look and review? Thanks!
On 14/04/2015 15:02, Bhathiya Supun wrote:
I just added https://github.com/jclouds/jclouds-labs/pull/167.
I have resolved merge conflicts and made some changes in live test of
PR#144.
Shall we merge PR#167 now?
Regards.
On 14 April 2015 at 12:54, Francesco Chicchiriccò <ilgro...@apache.org>
wrote:
Hi all,
as you might have seen, the PR #161 was merged yesterday.
How should we move forward?
Bhathiya, do you have any news?
Regards.
On 10/04/2015 10:27, Francesco Chicchiriccò wrote:
On 08/04/2015 22:58, Ignasi Barrera wrote:
I'd say the plan is to merge #161 first, to have a tested and working
implementation of the compute service.
Once that one is in, we can discuss about the convenience of changing
the current model to have a better mapping from the jclouds "node"
object to the Azure entities. Regarding this, we can not expect
everyone to read the Azure API docs, so a summary of the motivation
behind that change, an overview of the current vs the proposed model
and the pros and cons of the change would be highly appreciated.
Waiting for PR #161 to get merged, here's my view on the refactoring
proposed to have a 'better mapping from the jclouds "node" object to the
Azure entities', e.g. for the subject of Bhathiya's PR #157 (still without
a corresponding issue on JIRA, shouldn't we open it?).
Currently there is a direct match between Deployment (Azure) and Node
(JClouds), by mean of DeploymentToNodeMetadata:
https://github.com/jclouds/jclouds-labs/blob/master/
azurecompute/src/main/java/org/jclouds/azurecompute/compute/functions/
DeploymentToNodeMetadata.java
However, in Azure a deployment can contain multiple virtual machines; the
current code makes instead assumption that a deployment contains a single
virtual machine, and uses the same name for both.
For this reason Bhathiya is working for replacing
DeploymentToNodeMetadata with a new VirtualMachineToNodeMetadata, which
requires to implement the "Add Role" operation (as reported below) in order
to add "a Virtual Machine to a deployment of Virtual Machines", as reported
in
https://msdn.microsoft.com/en-us/library/azure/jj157186.aspx
Naturally, this modification has a significant impact on the live test
execution.
So, in summary:
* PRO - do not impose limitations on the way how Azure features can be
driven via JClouds, because without this change one is forced to create a
new deployment for every new virtual machine; moreover, even if I cannot
find a specific reference in the documentation, it seems that you can only
have a single deployment for deployment slot (e.g. "Production" or
"Staging") which would mean that, in order to have 2 virtual machines, you
need to have 2 distinct deployments in 2 distinct cloud services
* CON - additional work for ensuring that all live tests are still
working in this new configuration
Fabio, Bhathiya, please correct / complete.
Regarding promotion, we need to have the live tests passing (you did a
fantastic job here, so that's not going to be a problem!) and a way to
test it regularly. We have both requirements covered, so as soon as
the compute service implementation is completed, and stable we can
promote it.
Sounds good!
Regards.
On 8 April 2015 at 11:42, Bhathiya Supun <hsbath...@gmail.com> wrote:
Hi Francesco,
1. #155 (for JCLOUDS-839) - is it complete?
It does not complete issue 839. It only support
GetCloudServiceProperties
Operation. I will rebase it. Further I can work on JCLOUD-839( if no
one
working on it) .However do we need suport for all the operations? Shall
we
decide on what operations need to be supported
2. #154 (for JCLOUDS-853) - is it complete?
It is complete and I'll have to rebase.
3. #157 (no subtask of JCLOUDS-664 for this?) - is this complete? In
particular, is support for "Add Role Operation" yet to be added?
I have finished working on AddRole opertaion. However it may require
little
bit of work to rebase. I'll continue workion on that if all are agreed
with
the proposed changes.
4. #144 (for JCLOUDS-852?) - is it complete?
It is need to be rebased as well. There were few issues with live tests
when I make the PR and I have now fixed it
5. #118 - which seems to be outdated: shall we just close it?
It is outdated and I'll close it
what is required to promote the Azure Compute provider out of labs?
should we support Operations on Autoscaling? [1]
[1] - https://msdn.microsoft.com/en-us/library/azure/dn510374.aspx
On 8 April 2015 at 13:20, Francesco Chicchiriccò <ilgro...@apache.org>
wrote:
Hi all,
let's recap the situation, after a while.
Several pull requests have been merged in the meanwhile and now the
following issues are resolved:
1. JCLOUDS-837
2. JCLOUDS-838
3. JCLOUDS-841
4. JCLOUDS-842
5. JCLOUDS-846
6. JCLOUDS-849
Moreover, the following PR are needed to be merged before continuing:
1. #156 (resolving JCLOUDS-850) - which should be merge any minute now,
but requires jclouds/jclouds#724 / JCLOUDS-876
2. #161 that, besides resolving JCLOUDS-873, contains important
improvements for the live tests execution
More PRs from Bhathiya are also waiting, but might require some rebase:
1. #155 (for JCLOUDS-839) - is it complete?
2. #154 (for JCLOUDS-853) - is it complete?
3. #157 (no subtask of JCLOUDS-664 for this?) - is this complete? In
particular, is support for "Add Role Operation" yet to be added?
4. #144 (for JCLOUDS-852?) - is it complete?
5. #118 - which seems to be outdated: shall we just close it?
Any thoughts? Plans?
Side question: what is required to promote the Azure Compute provider
out
of labs?
Regards.
On 25/03/2015 10:40, Bhathiya Supun wrote:
Hi Francesco, Fabio
I have make a PR [1] with the propsed changes. With the changes we no
longer assume deployment name and Cloudservice name are equal.
VirtualMachineToNodeMetadat can be
builder.location(FluentIterable.from(locations.get()).firstMatch(
LocationPredicates.idEquals(api.getCloudServiceApi().get(from.
<http://from.name/>serviceName()).location())).orNull());
However Add Role Operation [2] should be suppported in order to
service
adapter to be complete. Now I am working on that.
Please check my PR and update me on the way you would like to proceed
[1] - https://github.com/jclouds/jclouds-labs/pull/157
[2] - https://msdn.microsoft.com/en-us/library/azure/jj157186.aspx
On 24 March 2015 at 17:25, Bhathiya Supun <hsbath...@gmail.com>
wrote:
Hi Francesco, Fabilo
@ Francsco It must be <VirtualMachine, RoleSize, OSImage, Location>.
My
bad. What I was typing!
It is mostly complete
https://github.com/hsbhathiya/jclouds-labs/commit/
cc24ecc201ff8a6740c232670be57dfc61745643
I'll be able to make the PR with in a day.
@Fabio.
Please, consider that we have to remove the assumption that
deployment
name is equal to CloudService's. This is the reason why we need
location
directly available or CloudService name instead.
Agree serviceName is an attribute in my VirtualMachine. However I
have
made the same (wrong) assumption when transforming
DeploymentsToVirtualMachines in my solution. I'll look for a
solution.
May be we can get the cloud service from the Url of deployment
https://msdn.microsoft.com/en-us/library/azure/ee460804.aspx
Url
Specifies the URL that is used to access the cloud service.For
example,
if
the service name is *MyService* you could access the access the
service
by calling: http://*MyService*.cloudapp.net
I have to check it though.
On 24 March 2015 at 16:39, Fabio Martelli <fabio.marte...@gmail.com>
wrote:
Il 24/03/2015 11:22, Francesco Chicchiriccò ha scritto:
Hi Bhathiya,
I was finally able to spend some time to dive into this issue
(JCLOUDS-853, if I am not wrong).
What is quite clear to me is that the current mapping between
Deployment
(azure domain) and NodeMetadata (jclouds domain) does not reflect
the
way
how things are organized in Azure.
In fact, after having created a cloud service (using the test code)
'ilgrosso548-virtualmachineapilivetest', the deployment and the
virtual
machine with same name (using the code from one of live tests), I
was
also
able to add a second virtual machine to the existing deployment by
POSTing
this payload [1] to this endpoint [2] (as explained in [3]).
I mostly agree with what you propose below, e.g.:
1 - Introduce VirtualMachine in domain
2 - Map DeploymentToVirtualMachines where single deployment
produces
list of virtual machines
3 - Map VirtualMachineToNodeMetadata
4 - Change AzureComputeServiceAdapter<VirtualMachine,
RoleList,OSImage,Location>"
I say "mostly" because I don't fully agree with last statement: I
would
have said instead
<VirtualMachine, RoleSize, OSImage, Location>
e.g. keeping RoleSize as class for listing hardware profiles.
Have you already started working on this? How long do you think it
would
take to you to complete?
Consider that we already have a pending PR for JCLOUDS-850 and
that a
new PR for JCLOUDS-849 should be ready by the end of this weel at
most.
Depending on timings, it might be an idea to rebase our work on
yours,
as opposite to what Fabio is proposing below.
Hi Bhathiya, as per Francesco, I got your proposal: it sounds
reasonable
with me.
You can proceed if you want but I have to ask you to take care to
make
Location/CloudService ID available to populate NodeMetadata object.
Currently, the deployment does not include the location among its
properties: in order to set-up location for a new NodeMetadata
object I
had
to retrieve this info asking for CloudService properties before.
Into the DeploymentToNodeMetadata, my temporary solution for the
location
is the following
// TODO: CloudService name is required (see JCLOUDS-849): waiting
for
JCLOUDS-853.
builder.location(FluentIterable.from(locations.get()).firstMatch(
LocationPredicates.idEquals(api.getCloudServiceApi().get(from.name
()).location())).orNull());
Please, consider that we have to remove the assumption that
deployment
name is equal to CloudService's. This is the reason why we need
location
directly available or CloudService name instead.
Please, let me have a feedback.
Regards,
F.
WDYT?
Regards.
[1] https://paste.apache.org/gQoV
[2] https://management.core.windows.net/d6769fbe-4649-
453f-8435-c07f0cc0709d/services/hostedservices/ilgrosso548-
virtualmachineapilivetest/deployments/ilgrosso548-
virtualmachineapilivetest/roles
[3] https://msdn.microsoft.com/en-us/library/azure/jj157186.aspx
On 20/03/2015 17:35, Bhathiya Supun wrote:
Hi Fabio,
I can wait till the PR of issue [1] and rebase my work on it. I
just
need
to make sure we get compute abstraction to azure compute
mapping right.I think sooner we make the decision better. It'll be
great if
someone from MS Open Tech can look into this issue?
[1] - https://issues.apache.org/jira/browse/JCLOUDS-849
Thanks
On 20 March 2015 at 19:53, Fabio Martelli <
fabio.marte...@gmail.com>
wrote:
Il 19/03/2015 18:32, Bhathiya Supun ha scritto:
Hi devs,
I like to bring back this[1] discussion related to
AzureComputeServcieAdapter implementation.
"As far as I understand RoleInstance represents a node in azure
API.
However RoleInstance to NodeMetadata would be bit problematic as
Azure
RoleInstance represenation not consist of some important data
Main issue I see in the current mapping of Deployment to Node
is the
assumption that deployment always consist of single a
roleinststace.
My suggestion is to
1 - Introduce VirtualMachine in domain
2 - Map DeploymentToVirtualMachines where single deployment
produces
list
of virtual machines
3 - Map VirtualMachineToNodeMetadata
4 - Change AzureComputeServiceAdapter<VirtualMachine,
RoleList,OSImage,
Location> "
I can make a PR with suggested changes if we can agree on this.
However
these substasks 9,10 in jira would directly conflict with the
change.Any
thoughts on this?
[1] - https://github.com/jclouds/jclouds-labs/pull/135#
discussion_r25013853
[2] - https://issues.apache.org/jira/browse/JCLOUDS-664
Hi Bhathiya, personally I cannot evaluate the overall impact
of
the
suggested changes.
Even though I have no particular issue with them I have to ask
you to
wait
for [1]:
* I see a lot of conflicts between our work and yours;
* the work on this issue will be a strong check for every
future
change.
We are currently working on [1] and we should be able to submit
the
new PR
at the beginning of the next week.
WDYT?
Kind regards,
F.
[1] https://issues.apache.org/jira/browse/JCLOUDS-849
On 4 March 2015 at 19:36, Bhathiya Supun <hsbath...@gmail.com
wrote:
Hi,
It is great to see this moving forwad.
I would note down tasks I have finished upto now (but yet to
make
PR)
1 - Add Role Operation Support [1]
2 - Get Cloud Service Properties Support [2]
This is already supported in feature Api.But improved to
capture
all
the
data returned by the operation
3 - Fix issues in Create Virtual Machine Deployment Operation
[3]
allowing different combinations of DeploymentParams
[1] - https://msdn.microsoft.com/en-
us/library/azure/jj157186.aspx
[2] - https://msdn.microsoft.com/en-
us/library/azure/ee460806.aspx
[3] - https://msdn.microsoft.com/en-
us/library/azure/jj157194.aspx
On 4 March 2015 at 19:02, Francesco Chicchiriccò <
ilgro...@apache.org>
wrote:
Hi,
FYI we were finally able to fix the live test execution, and
created PR
#147
Now we are examining the Azure Service Management REST API
Reference at
https://msdn.microsoft.com/en-us/library/ee460799.aspx
to identify anything missing (also considering PR #144 as said
below) in
order to create subtasks of JCLOUDS-664 as agreed.
Any idea about timings for merging #144 and #147?
Thanks for your support.
Regards.
On 02/03/2015 12:58, Bhathiya Supun wrote:
Hi Francesco,
I added PR 144 supporting virtual machine image operations
in
feature
Api
[1].
[1] https://msdn.microsoft.com/en-
us/library/azure/dn499771.aspx
On 2 March 2015 at 16:42, Francesco Chicchiriccò <
ilgro...@apache.org>
wrote:
On 28/02/2015 08:12, Ignasi Barrera wrote:
You can subscribe to the jclouds "notifications" list
to get
all
emails
from jira and github comments. Everyting ends up in a ML.
Thanks Ignasi, just subscribed.
Let's use the subtasks to coordinate the
development.
Thanks guys!
Fine: we'll keep you updated here about our current
activities
(e.g.
making the live test suite succeeding) - which I hope will
end
up
soon
with
a pull request.
I have also seen another pull request on Azure provider
(#144):
any
background on this?
Regards.
El 27/02/2015 17:16, "Francesco Chicchiriccò" <
ilgro...@apache.org
escribió:
On 27/02/2015 17:09, Andrea Turli wrote:
Francesco,
thanks again for you interest!
Yes, #135 has been merged few hours ago. I've also
update
https://issues.apache.org/jira/browse/JCLOUDS-664 to
track
some
subtasks
identified in #135
Hi Andrea,
that's cool: do you know where JIRA notifications are
sent,
at
least
when
issues get created?
Thanks.
Regards.
On Fri, Feb 27, 2015 at 5:02 PM Ross Gardler (MS
OPEN
TECH) <
ross.gard...@microsoft.com> wrote:
Set up a GitHub user for this kid and subscribe
ot to
the
project?
Sent from my Windows Phone
________________________________
From: Francesco Chicchiriccò<mailto:ilgro...@apache.org
Sent: 2/27/2015 7:54 AM
To: dev@jclouds.apache.org<mailto:
dev@jclouds.apache.org>
Subject: Re: Working on Azure compute provider
Hi there!
Looks like PR 135 was merged today:
https://github.com/jclouds/jclouds-labs/pull/135#
issuecomment-76381931
That's good: we will re-base our work on updated
jclouds-labs
master
branch and move forward (still having troubles with live
tests,
but
making some progresses).
Can we move here at dev@ discussions like the one
above or
at
least
ask
infra to setup some sort of github PR mirroring?
It would help keeping track of ongoing development
efforts
(you
know,
"If it didn't happen on a mailing list, it didn't
happen"...).
What about opening residual issues as we've been
discussing
below?
Thanks!
Regards.
On 24/02/2015 15:45, Ignasi Barrera wrote:
Sure. I'll have a look at it later today and
merge it
if
everything
looks good. Let's move forward!
On 24 February 2015 at 15:40, Francesco Chicchiriccò
<ilgro...@apache.org> wrote:
On 24/02/2015 15:25, Andrea Turli wrote:
Francesco,
thanks for your update and for your effort!
I think #135 is almost ready to be merged, I think
we are
waiting to
close
the main pending discussion on
https://github.com/jclouds/jclouds-labs/pull/135#
discussion-
diff-24976668
What about merging #135 as is and moving the
discussion
mentioned
above
into
a new JIRA issue (linked to or as subtask of)
JCLOUDS-664?
I like both the idea of splitting JCLOUDS-164
in
multiple
subtasks
or
simply create a new set of JIRA ISSUES to improve
Azure
compute
implmentation.
Anything goes to me, good!
Regards.
On Tue Feb 24 2015 at 2:16:54 PM Francesco
Chicchiriccò
<ilgro...@apache.org>
wrote:
Hi all,
a quick update on ours (Fabio's and mine)
current
activities.
First of all, we are basing our work on PR #135
rather
than
jclouds-labs' master, since the former contains a
whole
set of
fixes
and
new features, and is in turn based on the
latter.
About this, is anyone able to provide a sneak
peek on
expected
actual
merge timeframe? From the e-mail below it seems
quite
soon.
We are currently trying to make all live tests
succeeding
with
an
actual
Azure instance: this is the initial main
purpose of
our
contribution,
and will constitute the ground of our first pull
request.
(Incidentally, I remember that there are free MSDN
subscriptions
available - including Azure - for ASF committers; see
https://svn.apache.org/repos/
private/committers/donated-
licenses/msdn-license-grants.txt
for details)
The intention is then to move from there by
identifying
some
subtasks
of
JCLOUDS-664 for each specific item.
WDYT?
Regards.
On 20/02/2015 10:45, Francesco Chicchiriccò wrote:
On 20/02/2015 10:13, Andrea Turli wrote:
Hi Francesco,
thanks for your interest in jclouds!
Azure Compute implementation is under the spot
these
days
and
we
are
working hard to improve it.
You may be aware of [1] and moreover there are
currently a
couple
of
pending PRs which are providing an initial
implementation of
the
AzureComputeServiceAdapter [2]
Hi Andrea, I am aware of course of the
recent
"Azure SDK
Vs
REST"
discussion, and I also know that at the end the
REST
option
was
preferred.
As [2] will be soon merged, I think we
could wait
for
#135
and
then
rebase
your #137 on it, if it is still needed.
WDYT?
This sounds reasonable: I think we should
coordinate our
work
(even
by
opening some subtasks of JCLOUDS-664) in order
to
avoid
latency
and
being as much effective as possible.
How would do you see this?
Feel free to join IRC #jclouds to discuss
better
next
steps!
I'm already there :-)
Regards.
[1]: http://www.mail-archive.com/
dev@jclouds.apache.org/
msg05877.
html
[2]: https://github.com/jclouds/
jclouds-labs/pull/135
On Fri Feb 20 2015 at 10:03:45 AM Francesco
Chicchiriccò
<ilgro...@apache.org> wrote:
Hi JClouds community,
I am interested in contributing to the Azure compute
provider
with
target of completing its implementation, as part
of
Eduard's
team
with a
focus on Azure.
Is there anyone actively working on this [1]?
I see as initial directions to implement methods
in
[2] and
to
change
the deprecated implementations in [3]: am I
missing
something?
I have prepared a first pull request [4] which
fixes
some
troubles
I've
found with live (e.g. against an actual Azure
subscription)
test
execution.
WDYT?
Regards.
[1] https://issues.apache.org/
jira/browse/JCLOUDS-664
[2] https://github.com/jclouds/
jclouds-labs/blob/master/
azurecompute/src/main/java/org/jclouds/azurecompute/
compute/
AzureComputeServiceAdapter.java
[3] https://github.com/jclouds/
jclouds-labs/blob/master/
azurecompute/src/main/java/org/jclouds/azurecompute/
config/
AzureComputeHttpApiModule.java
[4] https://github.com/jclouds/
jclouds-labs/pull/137
--
--
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
