Re: Networking Components for Deltacloud OpenStack Driver

2013-06-19 Thread mar...@redhat.com
On 17/06/13 19:10, Tooley, Christopher Tooley (STL) - contr wrote:
 On 17/06/13 15:36, Tooley, Christopher Tooley (STL) - contr wrote:
 My apologies for the poor formatting and forgotten reference:

 great timing on the request! Someone put in a feature request for the
 OpenStack driver a couple weeks ago - tracked at [1] - that was
 specifically for Elastic IPs and Security Groups. As you'll see on that
 ticket I started the work of implementing this on the ruby-openstack
 rubygem side 

 Perfect, I'm looking at the fog/openstack/requests/network directory [ct1] 
 and seeing what I need in that rubygem, is that what you're talking about?

 
 actually - as you may have found out already if you've seen the pull
 request I referenced - the Deltacloud OpenStack driver uses the
 ruby-openstack rubygem [1] to talk to the OpenStack services.
 
 Is there a reason that it's built on ruby-openstack instead of fog which 
 seems to drive some of the other providers? Especially as the the fog client 
 seems to already support a large portion of this stuff.
 


well you raise a valid point. Historically we used ruby-openstack
because we liked the idea of a single gem that is dedicated to all
OpenStack services. The core Deltacloud devs ended up maintaining this
rubygem and we built it out based on the needs of the Deltacloud
OpenStack driver making releases as necessary.


Indeed we already import fog for the Google (Storage only) driver and
the Terremark driver. Perhaps now is the time to move the code over to
Fog - but that will require some dedicated effort to make sure nothing
breaks in the process,

marios



Re: Networking Components for Deltacloud OpenStack Driver

2013-06-17 Thread mar...@redhat.com
On 14/06/13 22:21, Tooley, Christopher Tooley (STL) - contr wrote:
 Our ideal solution to our cloud platform has become to use Deltacloud to 
 front-end our virtualization platforms. One of those platforms we will be 
 relying heavily on is OpenStack. I see that Deltacloud will make API calls to 
 EC2 for Load Balancers, IP Addresses and Firewalls. All of those things seem 
 to be supported in OpenStack's Quantum API so I was hoping to avoid writing 
 directly to OpenStack when Deltacloud supports it.
 
 Is there any work being done to move that forward? If so, where? If not, any 
 pointers on where to start would help.
 

Hi Chris:

great timing on the request! Someone put in a feature request for the
OpenStack driver a couple weeks ago - tracked at [1] - that was
specifically for Elastic IPs and Security Groups. As you'll see on that
ticket I started the work of implementing this on the ruby-openstack
rubygem side [2]. I'm waiting for some comments from the issue
requestor/proposer before moving forward - any input you have in that
respect will be helpful.

I haven't followed Quantum API development of late - however looking at
the v2 API [3] I can't see any support for IPs, Addresses or Load
Balancers. Are you sure they are part of Quantum or rather are they
extensions to Nova? In any case - I think for at least 2 of the things
you mention - Firewall and IP Addresses the currently open ticket at [1]
may be of interest for you. Please monitor progress on that and any
contributions you can make (especially testing of submitted code) will
help move this forward. For the Load Balancers it's probably a good idea
to open a new ticket in JIRA to request this or even for yourself to
contribute code to - though please bear in mind that you need to sign
the Apache ICLA [4] if you haven't already done that.


 It appears that Deltacloud traffic is really dropping off based on the number 
 of messages per month to the mailing list. Am I looking at the wrong list, 
 catching the community at a bad time, or is the project losing that much in 
 terms of people's available time?

To add to what Dies said - I think this email [5] will explain the
situation somewhat.

 
 I'm hoping that soon I'll be able to contribute if that is seen as a valuable 
 thing.

absolutely! Welcome to the project ;)

all the best, marios

[1] https://issues.apache.org/jira/browse/DTACLOUD-563
[2] https://github.com/ruby-openstack/ruby-openstack/pull/28
[3] http://docs.openstack.org/api/openstack-network/2.0/content/
[4] http://www.apache.org/licenses/icla.txt
[5]
http://mail-archives.apache.org/mod_mbox/deltacloud-dev/201305.mbox/%3C518D0F79.4000901%40redhat.com%3E




 
 Chris Tooley
 
 



RE: Networking Components for Deltacloud OpenStack Driver

2013-06-17 Thread Tooley, Christopher Tooley (STL) - contr
great timing on the request! Someone put in a feature request for the
OpenStack driver a couple weeks ago - tracked at [1] - that was
specifically for Elastic IPs and Security Groups. As you'll see on that
ticket I started the work of implementing this on the ruby-openstack
rubygem side 

Perfect, I'm looking at the fog/openstack/requests/network directory [ct1] and 
seeing what I need in that rubygem, is that what you're talking about?

I haven't followed Quantum API development of late - however looking at
the v2 API [3] I can't see any support for IPs, Addresses or Load
Balancers. Are you sure they are part of Quantum or rather are they
extensions to Nova?

According the comments in the commit messages, this is hitting the Quantum API. 
This could be a relatively new version of the API however, I'm not sure.

In any case - I think for at least 2 of the things
you mention - Firewall and IP Addresses the currently open ticket at [1]
may be of interest for you. Please monitor progress on that and any
contributions you can make (especially testing of submitted code) will
help move this forward. For the Load Balancers it's probably a good idea
to open a new ticket in JIRA to request this or even for yourself to
contribute code to - though please bear in mind that you need to sign
the Apache ICLA [4] if you haven't already done that.

They are definitely of interested. I'll try to pull your branch and take a look 
around this week (hopefully tonight).

 It appears that Deltacloud traffic is really dropping off based on the number 
 of messages per month to the mailing list. Am I looking at the wrong list, 
 catching the community at a bad time, or is the project losing that much in 
 terms of people's available time?

To add to what Dies said - I think this email [5] will explain the
situation somewhat.

Thank you, that was kind of what I'd determined as well. It appears that the 
inevitable convergence is starting. Deltacloud offers something I've not seen 
in anything else and is the reason we really like it.


RE: Networking Components for Deltacloud OpenStack Driver

2013-06-17 Thread Tooley, Christopher Tooley (STL) - contr
My apologies for the poor formatting and forgotten reference:

 great timing on the request! Someone put in a feature request for the
 OpenStack driver a couple weeks ago - tracked at [1] - that was
 specifically for Elastic IPs and Security Groups. As you'll see on that
 ticket I started the work of implementing this on the ruby-openstack
 rubygem side 

Perfect, I'm looking at the fog/openstack/requests/network directory [ct1] and 
seeing what I need in that rubygem, is that what you're talking about?

 I haven't followed Quantum API development of late - however looking at
 the v2 API [3] I can't see any support for IPs, Addresses or Load
 Balancers. Are you sure they are part of Quantum or rather are they
 extensions to Nova?

According the comments in the commit messages, this is hitting the Quantum API. 
This could be a relatively new version of the API however, I'm not sure.

 In any case - I think for at least 2 of the things
 you mention - Firewall and IP Addresses the currently open ticket at [1]
 may be of interest for you. Please monitor progress on that and any
 contributions you can make (especially testing of submitted code) will
 help move this forward. For the Load Balancers it's probably a good idea
 to open a new ticket in JIRA to request this or even for yourself to
 contribute code to - though please bear in mind that you need to sign
 the Apache ICLA [4] if you haven't already done that.

They are definitely of interested. I'll try to pull your branch and take a look 
around this week (hopefully tonight).

 It appears that Deltacloud traffic is really dropping off based on the 
 number of messages per month to the mailing list. Am I looking at the wrong 
 list, catching the community at a bad time, or is the project losing that 
 much in terms of people's available time?

 To add to what Dies said - I think this email [5] will explain the
 situation somewhat.

Thank you, that was kind of what I'd determined as well. It appears that the 
inevitable convergence is starting. Deltacloud offers something I've not seen 
in anything else and is the reason we really like it.

[ct1] 
https://github.com/rackspace/fog/tree/master/lib/fog/openstack/requests/network


Re: Networking Components for Deltacloud OpenStack Driver

2013-06-17 Thread mar...@redhat.com
On 17/06/13 15:36, Tooley, Christopher Tooley (STL) - contr wrote:
 My apologies for the poor formatting and forgotten reference:
 
 great timing on the request! Someone put in a feature request for the
 OpenStack driver a couple weeks ago - tracked at [1] - that was
 specifically for Elastic IPs and Security Groups. As you'll see on that
 ticket I started the work of implementing this on the ruby-openstack
 rubygem side 
 
 Perfect, I'm looking at the fog/openstack/requests/network directory [ct1] 
 and seeing what I need in that rubygem, is that what you're talking about?
 

actually - as you may have found out already if you've seen the pull
request I referenced - the Deltacloud OpenStack driver uses the
ruby-openstack rubygem [1] to talk to the OpenStack services.


 I haven't followed Quantum API development of late - however looking at
 the v2 API [3] I can't see any support for IPs, Addresses or Load
 Balancers. Are you sure they are part of Quantum or rather are they
 extensions to Nova?
 
 According the comments in the commit messages, this is hitting the Quantum 
 API. This could be a relatively new version of the API however, I'm not sure.
 
 In any case - I think for at least 2 of the things
 you mention - Firewall and IP Addresses the currently open ticket at [1]
 may be of interest for you. Please monitor progress on that and any
 contributions you can make (especially testing of submitted code) will
 help move this forward. For the Load Balancers it's probably a good idea
 to open a new ticket in JIRA to request this or even for yourself to
 contribute code to - though please bear in mind that you need to sign
 the Apache ICLA [4] if you haven't already done that.
 
 They are definitely of interested. I'll try to pull your branch and take a 
 look around this week (hopefully tonight).
 
 It appears that Deltacloud traffic is really dropping off based on the 
 number of messages per month to the mailing list. Am I looking at the wrong 
 list, catching the community at a bad time, or is the project losing that 
 much in terms of people's available time?
 
 To add to what Dies said - I think this email [5] will explain the
 situation somewhat.
 
 Thank you, that was kind of what I'd determined as well. It appears that the 
 inevitable convergence is starting. Deltacloud offers something I've not seen 
 in anything else and is the reason we really like it.

good to hear,

thanks, marios


[1] https://github.com/ruby-openstack/ruby-openstack

 
 [ct1] 
 https://github.com/rackspace/fog/tree/master/lib/fog/openstack/requests/network
 



RE: Networking Components for Deltacloud OpenStack Driver

2013-06-17 Thread Tooley, Christopher Tooley (STL) - contr
On 17/06/13 15:36, Tooley, Christopher Tooley (STL) - contr wrote:
 My apologies for the poor formatting and forgotten reference:
 
 great timing on the request! Someone put in a feature request for the
 OpenStack driver a couple weeks ago - tracked at [1] - that was
 specifically for Elastic IPs and Security Groups. As you'll see on that
 ticket I started the work of implementing this on the ruby-openstack
 rubygem side 
 
 Perfect, I'm looking at the fog/openstack/requests/network directory [ct1] 
 and seeing what I need in that rubygem, is that what you're talking about?
 

actually - as you may have found out already if you've seen the pull
request I referenced - the Deltacloud OpenStack driver uses the
ruby-openstack rubygem [1] to talk to the OpenStack services.

Is there a reason that it's built on ruby-openstack instead of fog which seems 
to drive some of the other providers? Especially as the the fog client seems to 
already support a large portion of this stuff.


RE: Networking Components for Deltacloud OpenStack Driver

2013-06-14 Thread Koper, Dies
Hi Chris,

Your contribution would be much appreciated!

I believe addresses, load balancers and firewalls are implemented by at
least the ec2 and fgcp drivers.
I assume you're more familiar with the related ec2 APIs so my suggestion
would be to look at the ec2 driver's code[1] and copy [2] and modify it
to work with openstack's API. Once you have it working, or are stuck and
want us to have a look at your code, you can send us your changes for
review [3].
I usually grep all drivers to learn different strategies of implementing
a collection when I work on adding one to a driver.

 It appears that Deltacloud traffic is really dropping off based on the
 number of messages per month to the mailing list. Am I looking at the
 wrong list, catching the community at a bad time, or is the project
losing
 that much in terms of people's available time?

This is the right mailing list.
There are a few reasons for the recent decline compared to the six
months before that.
Chronologically:
Aug/Sep last year the DMTF's CIMI API specification was released and
we've been working hard on Deltacloud's CIMI front-end to implement this
specification. Red Hat and Fujitsu participated in the CIMI
interoperability testing events in Dec [4] and April, so lots of
development and discussions towards those events.
Although we're currently working towards the next CIMI testing event in
July, most of the coding has been done so not much discussion on the
mailing list required.
The spike in February was probably because of the network API that was
added to the Deltacloud API. A lot of people were involved in that to
ensure the common API would cover all cloud providers.
On top of the completion of the above, in May there were two
developments that caused a further drop in e-mails:
We used to send our patches to the mailing list for review but since May
most of us are using github PRs so patches and review comments don't go
to the mailing list anymore.
Finally, Red Hat has had a number of developers working fulltime on
Deltacloud for a number of years and now that Deltacloud has reached
maturity it decided to scale back its sponsorship [5], so they're
working on it part-time now.

[1]
https://github.com/deltacloud/deltacloud-core/blob/master/server/lib/del
tacloud/drivers/ec2/ec2_driver.rb#L768
[2] http://deltacloud.apache.org/getting-sources.html
[3] http://deltacloud.apache.org/how-to-contribute.html
[4]
http://www.dmtf.org/content/dmtf-hold-plugfest-cloud-infrastructure-mana
gement-interface-cimi
[5]
http://mail-archives.apache.org/mod_mbox/deltacloud-dev/201305.mbox/%3C5
18d0f79.4000...@redhat.com%3E

Regards,
Dies Koper


 -Original Message-
 From: Tooley, Christopher Tooley (STL) - contr
 [mailto:ctool...@express-scripts.com]
 Sent: Saturday, 15 June 2013 5:22 AM
 To: dev@deltacloud.apache.org
 Subject: Networking Components for Deltacloud OpenStack Driver
 
 Our ideal solution to our cloud platform has become to use Deltacloud
 to front-end our virtualization platforms. One of those platforms we
will
 be relying heavily on is OpenStack. I see that Deltacloud will make
API
 calls to EC2 for Load Balancers, IP Addresses and Firewalls. All of
those
 things seem to be supported in OpenStack's Quantum API so I was hoping
 to avoid writing directly to OpenStack when Deltacloud supports it.
 
 Is there any work being done to move that forward? If so, where? If
not,
 any pointers on where to start would help.
 
 It appears that Deltacloud traffic is really dropping off based on the
 number of messages per month to the mailing list. Am I looking at the
 wrong list, catching the community at a bad time, or is the project
losing
 that much in terms of people's available time?
 
 I'm hoping that soon I'll be able to contribute if that is seen as a
 valuable thing.
 
 Chris Tooley