Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Amit Gandhi]

OpenCDN is an abandoned project, although there have been a few attempts at 
creating one called “OpenCDN”.

As far as the we can tell (Poppy Team), there is currently no viable Open 
source CDN’s available.  If there is we would be happy to add it as a supported 
driver.

Also, even if the CDN software itself was open, the true value of a CDN comes 
from the distributed global network of servers it offers and its performance to 
serve requests.  Not just the features/API offered.

Poppy intends to be an abstraction API over the various CDNs available.  We do 
not want to be in the business of building a CDN itself.


Amit.



On Feb 16, 2016, at 12:22 PM, Doug Hellmann 
mailto:d...@doughellmann.com>> wrote:

Excerpts from Sean M. Collins's message of 2016-02-16 07:15:34 +:
Thomas Goirand wrote:
Oh, that, and ... not using CassandraDB. And yes, this thread is a good
place to have this topic. I'm not sure who replied to me this thread
wasn't the place to discuss it: I respectfully disagree, since it's
another major blocker, IMO as important, if not more, as using a free
software CDN solution.

Let's handle the policy implications discussed in this thread before we
dive into the "don't use this component that I dislike" bikeshed.
Reading the thread, it appears that we've made good progress on building
consensus towards having Poppy consider an open source CDN as the
"reference implementation" (to use some Neutron parlance).

Then we can bikeshed about how good/bad the components used in the
reference implementation are. Later. The point being, there is an open
source solution that will be used to flesh out a true vendor-neutral API
(as I understand Mike Perez's position, and agree with!).

Is there? I thought the point was OpenCDN isn't actually usable. Maybe
someone from the Poppy team can provide more details about that.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [poppy] Nominate Sriram Madupasi Vasudevan for Poppy (CDN) to Core

[Amit Gandhi]

I have received a majority vote for Sriram, and would like to congratulate 
Sriram for being elevated to Core status on Poppy.

Amit.


From: Malini Kamalambal 
mailto:malini.kamalam...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 21, 2015 at 8:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [poppy] Nominate Sriram Madupasi Vasudevan for 
Poppy (CDN) to Core

+2

From: Amit Gandhi mailto:amit.gan...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 21, 2015 at 5:20 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [poppy] Nominate Sriram Madupasi Vasudevan for Poppy 
(CDN) to Core

All,

I would like to nominate Sriram Madupasi Vasudevan (thesriram) [1] to Core for 
Poppy (CDN) [2].

Sriram has worked on the project for the past 12 months, and has been 
instrumental in building out various features and resolving bugs for the team.

Please respond with your votes.

Thanks
Amit.

[1] http://stackalytics.com/?release=all&project_type=stackforge&module=poppy
[2] http://www.poppycdn.org
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [poppy] Nominate Tony Tan for Poppy (CDN) Core

[Amit Gandhi]

I have received a majority vote for Tony, and would like to congratulate Tony 
Tan for being elevated to Core status on Poppy.

Amit.


From: Malini Kamalambal 
mailto:malini.kamalam...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 21, 2015 at 8:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [poppy] Nominate Tony Tan for Poppy (CDN) Core

+2

From: Amit Gandhi mailto:amit.gan...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, September 21, 2015 at 5:22 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [poppy] Nominate Tony Tan for Poppy (CDN) Core

All,

I would like to nominate Tony Tan (tonytan4ever) [1] to Core for Poppy (CDN) 
[2].

Tony has worked on the project for the past 12 months, and has been 
instrumental in building out various features and resolving bugs for the team.  
He has written the majority of the Akamai driver and has been working hard to 
bring SSL integration to the workflow.

Please respond with your votes.

Thanks
Amit.

[1] http://stackalytics.com/?release=all&project_type=stackforge&module=poppy
[2] http://www.poppycdn.org
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [poppy] Nominate Tony Tan for Poppy (CDN) Core

[Amit Gandhi]

All,

I would like to nominate Tony Tan (tonytan4ever) [1] to Core for Poppy (CDN) 
[2].

Tony has worked on the project for the past 12 months, and has been 
instrumental in building out various features and resolving bugs for the team.  
He has written the majority of the Akamai driver and has been working hard to 
bring SSL integration to the workflow.

Please respond with your votes.

Thanks
Amit.

[1] http://stackalytics.com/?release=all&project_type=stackforge&module=poppy
[2] http://www.poppycdn.org
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [poppy] Nominate Sriram Madupasi Vasudevan for Poppy (CDN) to Core

[Amit Gandhi]

All,

I would like to nominate Sriram Madupasi Vasudevan (thesriram) [1] to Core for 
Poppy (CDN) [2].

Sriram has worked on the project for the past 12 months, and has been 
instrumental in building out various features and resolving bugs for the team.

Please respond with your votes.

Thanks
Amit.

[1] http://stackalytics.com/?release=all&project_type=stackforge&module=poppy
[2] http://www.poppycdn.org
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-*client] py33 jobs seem to be failing

[Amit Gandhi]

Is there an ETA for this fix?

Thanks
Amit.


> On Dec 17, 2014, at 3:38 PM, Jeremy Stanley  wrote:
> 
> On 2014-12-17 11:09:59 -0500 (-0500), Steve Martinelli wrote:
> [...]
>> The stack trace leads me to believe that docutils or sphinx is the
>> culprit, but neither has released a new version in the time the
>> bug has been around, so I'm not sure what the root cause of the
>> problem is.
> 
> It's an unforeseen interaction between new PBR changes to support
> Setuptools 8 and the way docutils supports Py3K by running 2to3
> during installation (entrypoint scanning causes pre-translated
> docutils to be loaded into the execution space through the egg-info
> writer PBR grew to be able to record Git SHA details outside of
> version strings). A solution is currently being developed.
> -- 
> Jeremy Stanley
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] Analysis of current API design

[Amit Gandhi]

How do the allocation of the service types in the service catalog get created.

For example, looking at the link provided below for service catalogs [1], you 
have with Rackspace a service type of rax:queues (which is running zaqar).  
However in devstack, zaqar is listed as “messaging”.  FWIW i think the 
rackspace entry came before the devstack entry, but there is now an 
inconsistency.

How do new openstack related projects (that are not incubated/graduated) appear 
in the service catalog with a consistent service type name that can be used 
across providers with the confidence it refers to the same set of api's?  Is it 
just an assumption, or do we need a catalogue somewhere listing what each 
service type is associated with?  Does adding it to Devstack pretty much stake 
claim to the service type?

Thanks
Amit.





[1] 
https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog

> On Dec 18, 2014, at 11:19 PM, Everett Toews  
> wrote:
> 
> Hi All,
> 
> At the recent API WG meeting [1] we discussed the need for more analysis of 
> current API design.
> 
> We need to get better at doing analysis of current API design as part of our 
> guideline proposals. We are not creating these guidelines in a vacuum. The 
> current design should be analyzed and taken into account.
> 
> Naturally the type of analysis will vary from guideline to guideline but 
> backing your proposals with some kind of analysis will only make them better. 
> Let’s take some examples.
> 
> 1. Anne Gentle and I want to improve the consistency of service catalogs 
> across cloud providers both public and private. This is going to require the 
> analysis of many providers and we’ve got a start on it here [2]. Hopefully a 
> guideline for the service catalog should fall out of the analysis of the many 
> providers.
> 
> 2. There’s a guideline for metadata up for review [3]. I wasn’t aware of all 
> of the places where the concept of metadata is used in OpenStack so I did 
> some analysis [4]. I found that the representation was pretty consistent but 
> how metadata was CRUDed wasn’t as consistent. I hope that information can 
> help the review along.
> 
> 3. This Guideline for collection resources' representation structures [5] 
> basically codifies in a guideline what was found in the analysis. Good stuff 
> and it has definitely helped the review along.
> 
> For more information about analysis of current API design see #1 of How to 
> Contribute [5]
> 
> Any thoughts or feedback on the above?
> 
> Thanks,
> Everett
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-12-18-16.00.log.html
> [2] 
> https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
> [3] https://review.openstack.org/#/c/141229/
> [4] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Metadata
> [5] https://review.openstack.org/#/c/133660/
> [6] https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api] Usage of the PATCH verb

[Amit Gandhi]

Hi

We are currently using PATCH in the Poppy API to update existing resources.  
However, we have recently had some discussions on how this should have been 
implemented.

I would like to get the advise of the Openstack Community and the API working 
group on how PATCH semantics should work.

The following RFC documents [1][2] (and a blog post [3]) advise the using PATCH 
as the following:


2.1.  A Simple PATCH Example


   PATCH /file.txt HTTP/1.1
   Host: www.example.com<http://www.example.com>
   Content-Type: application/example
   If-Match: "e0023aa4e"
   Content-Length: 100


[
{ "op": "test", "path": "/a/b/c", "value": "foo" },
{ "op": "remove", "path": "/a/b/c" },
{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]



Basically, the changes consist of an operation, the path in the json object to 
modify, and the new value.


The way we currently have it implemented is to submit just the changes, and the 
server applies the change to the resource.  This means passing entire lists to 
change etc.

I would like to hear some feedback from others on how PATCH should be 
implemented.

Thanks

Amit Gandhi
- Rackspace



[1] https://tools.ietf.org/html/rfc5789
[2] http://tools.ietf.org/html/rfc6902
[3] http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [poppy] Kilo-2 Priorities

[Amit Gandhi]

Thanks everyone who attended the weekly meeting yesterday.

Great job in delivering on the kilo-1 deliverables for Poppy CDN.  
https://launchpad.net/poppy/+milestone/kilo-1

We were able to be dev complete the following items:
- The ability to configure a service containing domains, origins, caching 
rules, and restrictions with a CDN provider
- The ability to purge content from a CDN provider
- The ability to define flavors
- The ability to check the health of the system
- The following Transport drivers - Pecan
- The following Storage drivers - Cassandra
- The following DNS drivers - Rackspace Cloud DNS
- The following CDN providers - Akamai, Fastly, MaxCDN, Amazon CloudFront


As we move focus on to the Kilo-2 milestone,  lets put emphasis around testing, 
bug fixing, refactoring, and making the work done up to now reliable and well 
tested, before we move on to the next set of major features.

I have updated the kilo-2 milestone deliverables to reflect these goals. 
https://launchpad.net/poppy/+milestone/kilo-2

Thanks

Amit Gandhi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

[Amit Gandhi]

Agreed it helps with billing.  It also allows the customer to make a
choice based on the features offered in a flavor.  At the end of the day,
the API works the same way regardless of the flavor selected.  The flavor
selection merely gives the customer the experience they are looking for.

I see flavors working this way:
Nova - choosing a flavor that represents the type of compute power you
need.  Many combinations could exist.
Zaqar - choosing a flavor that represents the type of messaging you need
(performance, durability, ha, or any combinations of them)
Poppy - choosing a flavor that represents the type of cdn you need
(performance, regionality, cost, or any combination of them)

…and so on…


Within each ‘feature’ there could be multiple options.

Hence I struggle to see how ‘features’ could be exposed directly by the
api’s if that only limits it to one driver of each feature (i.e. There
could be multiple drivers that meet the performance feature for example).

The flavor concept allows operators to package together some of these
features, and offer it to customers - who can then select that flavor via
the API.

In terms of inter-operable clouds, since the API functionality works the
same regardless of flavor, I don’t think it breaks interoperability.

Since operators can define their flavor names themselves and what drives
those flavors, then there is work on the dev to refer to the new flavor at
the new operator’s cloud.  But inverting that argument - will every cloud
operator always offer the same flavors?  Will some operators prefer to
offer certain flavors only?  How do you define flavors (or their features)
in a generic way that allows for the gray area’s in between, and multiple
permutations of the same benefit?

I am curious to explore the idea of not using flavors and replacing the
concept with something more generic (with concrete examples with some of
the existing API’s).  It sounds great to me, I just can’t (at this time)
think of how it would work.


Thanks.
Amit.







On 11/17/14, 5:38 PM, "Ed Leafe"  wrote:

>On Nov 17, 2014, at 3:46 PM, Amit Gandhi 
>wrote:
>> 
>> I can see where this makes a lot of sense in API¹s such as Nova¹s where
>> flavors represent some combination of memory, disk, and cpu performance.
>
>For Nova, flavors emerged more as a billing convenience than anything
>technical regarding creating a VM with certain characteristics.
>
>> In the case of CDN, the flavor represents a list of CDN providers.
>> 
>> So... you could have a flavor representing a region of the world
>> (America¹s) consisting of one or more CDN providers with a strong
>>presence
>> in those regions.
>> Or a flavor could represent performance or features offered (number of
>> edge nodes, speed, etc).  And it is up to the operator to define those
>> flavors and assign one or more appropriate CDN providers to those
>>flavors.
>
>Again, this seems like the sort of packaging you would need to charge
>customers for different levels of service, and not something that you
>would need to make a working CDN API.
>
>
>-- Ed Leafe
>
>
>
>
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

[Amit Gandhi]

I can see where this makes a lot of sense in API¹s such as Nova¹s where
flavors represent some combination of memory, disk, and cpu performance.

In the case of CDN, the flavor represents a list of CDN providers.

So... you could have a flavor representing a region of the world
(America¹s) consisting of one or more CDN providers with a strong presence
in those regions.
Or a flavor could represent performance or features offered (number of
edge nodes, speed, etc).  And it is up to the operator to define those
flavors and assign one or more appropriate CDN providers to those flavors.

Im not sure decomposing the flavor in this context makes as much sense.


Amit.


On 11/17/14, 3:18 PM, "Jay Pipes"  wrote:

>I personally do not think that a "flavor" should be stored in the base
>resource. The "flavor" should instead be decomposed into its composite
>pieces (the specification for the CDN creation) and those pieces stored
>in the database.
>
>That way, you don't inherit the terrible problem that Nova has where
>you're never really able to delete a flavor because some instance
>somewhere may still be referring to it. If, in Nova, we decomposed the
>flavor into all of its requisite pieces -- requested resource amounts,
>requested "extra specs" capabilities, requested NUMA topology, etc -- we
>wouldn't have this problem at all.
>
>So, therefore my advice would be to not do any of the above and don't
>have anything other than a "CDN type" or "CDN template" object that is
>just deconstructed into the requested capabilities and resources of the
>to-be-created CDN object and send along those things instead of
>referring to some "flavor" thing.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [poppy] Proposal to add Malini Kamalambal (malini) as a Core Reviewer

[Amit Gandhi]

I am pleased to announce that Malini Kamalambal as been promoted to Core for 
Poppy.

Thanks
Amit.

From: Amit Gandhi mailto:amit.gan...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, October 24, 2014 at 2:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [poppy] Proposal to add Malini Kamalambal (malini) as 
a Core Reviewer

Hi folks,

I’d like to propose adding Malini Kamalambal (malini) as a core reviewer on the 
Poppy team. She has been contributing regularly since the start of Poppy, and 
has proven to be a careful reviewer with good judgment.  She also brings a lot 
of insight into Openstack best practices from her experience working on Zaqar, 
where she also is a Core Reviewer.

All Poppy ATC’s, please respond with a +1 or –1.

Thanks

Amit Gandhi
@amitgandhinz
Poppy PTL


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [poppy] Proposal to add Malini Kamalambal (malini) as a Core Reviewer

[Amit Gandhi]

Hi folks,

I’d like to propose adding Malini Kamalambal (malini) as a core reviewer on the 
Poppy team. She has been contributing regularly since the start of Poppy, and 
has proven to be a careful reviewer with good judgment.  She also brings a lot 
of insight into Openstack best practices from her experience working on Zaqar, 
where she also is a Core Reviewer.

All Poppy ATC’s, please respond with a +1 or –1.

Thanks

Amit Gandhi
@amitgandhinz
Poppy PTL


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [poppy] Summit Design Session Planning

[Amit Gandhi]

Hi

The summit planning etherpad [0] is now available to continue discussion topics 
for the Poppy design session in Paris (to be held on Tuesday Nov 4th, at 2pm)

The planning etherpad will be kept open until next Thursday, during which we 
will finalize what will be discussed during the Poppy Design session[1].  The 
Poppy team started the planning discussion at todays weekly Poppy meeting[2].

One of the initial design session topics we plan to discuss at the summit is 
how Poppy can provision CDN services over Swift Containers.

I would like to invite any Swift developers who are attending the Kilo Summit 
to attend the Poppy design session, so that we can discuss in detail how this 
feature would work and any issues we would need to consider.


For more information on Poppy (CDN), and the Design Session, please visit the 
Poppy wiki page [3]

[0] https://etherpad.openstack.org/p/poppy-design-session-paris
[1] 
http://kilodesignsummit.sched.org/event/5c9eed173199565ce840100e37ebd754#.VElwU4exE1d
[2] https://wiki.openstack.org/wiki/Meetings/Poppy
[3] https://wiki.openstack.org/wiki/Poppy

Thanks,

Amit Gandhi
Rackspace.

@amitgandhinz on Freenode
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] Request Validation - Stoplight

[Amit Gandhi]

On 10/20/14, 10:38 AM, "Jay Pipes"  wrote:

>On 10/20/2014 10:26 AM, Amit Gandhi wrote:
>> Thanks for the clarification Sam.
>>
>> Its good to know where the mission of the API working group starts and
>> stops.  During the meetup discussions, my understanding was that the
>> working group would recommend the technologies to use while building
>>apis
>> (e.g. Pecan, validation frameworks, etc) and were in the process of
>> looking into tools such as warlock.
>
>Sorry, did I miss something? What meetup discussions are you referring
>to? I'm not aware of any meetings of the API working group so far...

Sorry, I was referring to the local Atlanta Openstack Meetup that happened
last Thursday (mentioned in my initial email that started this thread).

>
> > Hence the recommendation to add
>> another library into the mix for evaluation, based on advise by other
>> stackers in the community.
>>
>> Your response clarifies that the aim of the API working group is just to
>> recommend on standardizing the interfaces from various API's (which I am
>> looking forward to) and not the libraries used to implement that
>>interface.
>
>I don't really think the working group has decided yet what it will be
>producing, with regards to recommendations and what topics it may
>provide guidance on. Heck, AFAIK, we still haven't settled on a day of
>the week and time to hold IRC meetings! ;)

Okay good to know.  That probably explains why I¹m hearing different
things from different people who probably all have different visions of
what the working group is.

>
>> For stackers who are interested in different validation frameworks to
>> implement validation, I recommend checking out Stoplight.
>
>Just my two cents on this particular topic, I think it's more important
>to standardize ways in which our public REST APIs expose the payload
>expectations and response schemas to clients. In other words... we need
>to focus on methods for API discovery. Once you have standardized
>resource URI, request payload, and response schema discovery, then any
>number of validation libraries may be used.

+1

>
>Best,
>-jay
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] Request Validation - Stoplight

[Amit Gandhi]

Thanks for the clarification Sam.

Its good to know where the mission of the API working group starts and
stops.  During the meetup discussions, my understanding was that the
working group would recommend the technologies to use while building apis
(e.g. Pecan, validation frameworks, etc) and were in the process of
looking into tools such as warlock.  Hence the recommendation to add
another library into the mix for evaluation, based on advise by other
stackers in the community.

Your response clarifies that the aim of the API working group is just to
recommend on standardizing the interfaces from various API's (which I am
looking forward to) and not the libraries used to implement that interface.

For stackers who are interested in different validation frameworks to
implement validation, I recommend checking out Stoplight.

Thanks

Amit Gandhi.




On 10/20/14, 9:36 AM, "Michael McCune"  wrote:

>+1
>
>that's a great way to state it Sam.
>
>regards,
>mike
>
>- Original Message -
>> Hi Amit,
>> 
>> Keeping in mind this viewpoint is nothing but my own personal view, my
>> recommendation would be to not mandate the use of a particular
>>validation
>> framework, but to instead define what kind of validation clients should
>> expect the server to perform in general. For example, I would expect a
>> service to return an error code and not perform any action if I called
>> "Create server" but did not include a request body, but the actual
>>manner in
>> which that error is generated within the service does not matter from
>>the
>> client's perspective.
>> 
>> This is not to say the API Working Group wouldn't help you evaluate the
>> potential of Stoplight to meet the needs of a service. To the contrary,
>>by
>> clearly defining the expectations of a service's responses to requests,
>> you'll have a great idea of exactly what to look for in your
>>evaluation, and
>> your final decision would be based on objective results.
>> 
>> Thank you,
>> Sam Harwell
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api] Request Validation - Stoplight

[Amit Gandhi]

Hi API Working Group

Last night at the Openstack Meetup in Atlanta, a group of us discussed how 
request validation is being performed over various projects and how some teams 
are using pecan wsmi, or warlock, jsonschema etc.

Each of these libraries have their own pro’s and con’s.  My understanding is 
that the API working group is in the early stages of looking into these various 
libraries and will likely provide guidance in the near future on this.

I would like to suggest another library to evaluate when deciding this.  Some 
of our teams have started to use a library named “Stoplight”[1][2] in our 
projects.  For example, in the Poppy CDN project, we found it worked around 
some of the issues we had with warlock such as validating nested json correctly 
[3].

Stoplight is an input validation framework for python.  It can be used to 
decorate any function (including routes in pecan or falcon) to validate its 
parameters.

Some good examples can be found here [4] on how to use Spotlight.

Let us know your thoughts/interest and we would be happy to discuss further on 
if and how this would be valuable as a library for API request validation in 
Openstack.


Thanks


Amit Gandhi
Senior Manager – Rackspace



[1] https://pypi.python.org/pypi/stoplight
[2] https://github.com/painterjd/stoplight
[3] 
https://github.com/stackforge/poppy/blob/master/poppy/transport/pecan/controllers/v1/services.py#L108
[4] 
https://github.com/painterjd/stoplight/blob/master/stoplight/tests/test_validation.py#L138

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Introducing Poppy - An Open API for CDN Provisioning

[Amit Gandhi]

Openstack,

My name is Amit Gandhi. A few months ago (just before the Atlanta Summit)
our team started to seek partners who shared an interest in building a
vendor-neutral and open API that leverages existing CDN providers in an
open source friendly way.


Abstract:
OpenStack operators have many choices when incorporating a Content
Delivery Network (CDN) into their infrastructure -- the CDN marketplace
has both tried-and-true vendors and up-and-coming upstarts with innovative
new features.

But these vendors often have highly-customized and proprietary
provisioning APIs. This can be problematic when an operator wishes to
support multiple providers -- or swap out one vendor for another. And
these challenges spill over to developers who become forced into codifying
the CDN instructions for multiple vendors into their applications.

Poppy aims to solve these challenges. Written as a modular,
vendor-neutral API, Poppy incorporates a driver-based approach (similar to
Cinder and Manilla) that allows multiple CDN providers to integrate via a
consistent API. Application developers can write their code once, and
Poppy will handle all the requisite translations behind-the-scenes.
- See more at: https://wiki.openstack.org/wiki/Poppy




To date, we have garnered interest from multiple CDN vendors in the
industry, such as Akamai, Fastly, and MaxCDN. We have started building
provider extensions for Fastly, MaxCDN, and Amazon CloudFront. Soon we
will start on an Akamai provider extension.

Together, we have begun implementing the building blocks of the
provisioning API, named Poppy. It is available on Stackforge
(https://github.com/stackforge/poppy). We are still in the very early
stages of development on the project.

The Poppy team meets every Thursday at 2pm Eastern Time on
#openstack-meeting-alt (https://wiki.openstack.org/wiki/Meetings/Poppy).
We also hang out on the #openstack-poppy channel on Freenode.

We are looking for collaborators from the community to join in this effort
and help guide the design and implementation of this exciting new CDN
provisioning API.

Please feel free to reach out to me or the team on IRC if you have any
questions, and/or are interested in working with us.

Thanks

Amit Gandhi
Senior Manager - Rackspace.


IRC: amitgandhinz on Freenode
EMAIL: amit.gan...@rackspace.com


Useful Links:
- https://wiki.openstack.org/wiki/Poppy

- https://github.com/stackforge/poppy

- https://wiki.openstack.org/wiki/Meetings/Poppy





On 4/16/14, 11:36 AM, "Amit Gandhi"  wrote:

>OpenStack,
>
>Our team is currently seeking partners who share an interest and
>enthusiasm for exploring the possibility of Content Delivery Network (CDN)
>capabilities within the open ecosystem. Our desire is to create a unified
>and open API that leverages existing CDN providers in an open
>source-friendly way.
> 
>
>Today, there are a large number of CDN providers who offer similar CDN
>capabilities with widely-differing APIs. Applications built around these
>current CDN offerings are usually locked into that vendor.  Changing a CDN
>provider typically requires significant software and operational changes
>on the part of the application developer.
>
>We would like to start a dialog with other organizations and individuals
>in the community that would like to work together to solve this common
>problem.  We would like to identify the community needs and flesh out the
>features of an open CDN API that supports multiple CDN providers.
>
>Together, we can build an offering that helps remove vendor lock in to
>existing CDN providers.
>
>When the time is right, this team of interested parties can determine
>where this project should live (e.g. OpenStack), or find the ecosystem
>that makes the most sense.
>
>We are looking for contributors from the community.  Please contact me
>directly for an initial conversation on your needs and interest.  I will
>then set up a community brainstorming session on IRC and we can also
>discuss it at the Atlanta OpenStack Summit.
>
>
>Thanks,
>
>Amit Gandhi
>Rackspace ­ Atlanta
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Seeking interest in an open Content Delivery Network (CDN) API

[Amit Gandhi]

OpenStack,

Our team is currently seeking partners who share an interest and
enthusiasm for exploring the possibility of Content Delivery Network (CDN)
capabilities within the open ecosystem. Our desire is to create a unified
and open API that leverages existing CDN providers in an open
source-friendly way.
 

Today, there are a large number of CDN providers who offer similar CDN
capabilities with widely-differing APIs. Applications built around these
current CDN offerings are usually locked into that vendor.  Changing a CDN
provider typically requires significant software and operational changes
on the part of the application developer.

We would like to start a dialog with other organizations and individuals
in the community that would like to work together to solve this common
problem.  We would like to identify the community needs and flesh out the
features of an open CDN API that supports multiple CDN providers.

Together, we can build an offering that helps remove vendor lock in to
existing CDN providers.

When the time is right, this team of interested parties can determine
where this project should live (e.g. OpenStack), or find the ecosystem
that makes the most sense.

We are looking for contributors from the community.  Please contact me
directly for an initial conversation on your needs and interest.  I will
then set up a community brainstorming session on IRC and we can also
discuss it at the Atlanta OpenStack Summit.


Thanks,

Amit Gandhi
Rackspace ­ Atlanta


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Marconi] Proposal to add Malini Kamalambal to the marconi-core team

[Amit Gandhi]

+1

On 3/21/14, 11:17 AM, "Flavio Percoco"  wrote:

>Greetings,
>
>I'd like to propose adding Malini Kamalambal to Marconi's core. Malini
>has been an outstanding contributor for a long time. She's taken care
>of Marconi's tests, benchmarks, gate integration, tempest support and
>way more other things. She's also actively participated in the mailing
>list discussions, she's contributed with thoughtful reviews and
>participated in the project's meeting since she first joined the
>project.
>
>Folks in favor or against please explicitly +1 / -1 the proposal.
>
>Thanks Malini, it's an honor to have you in the team.
>
>-- 
>@flaper87
>Flavio Percoco


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?

[Amit Gandhi]

If we limited Openstack projects to just one database, is that database (e.g. 
MySQL) going to be the best storage deployment for that job?  Or are there 
cases where other technologies such as Redis, MongoDB, Cassandra, CouchDB, etc 
make more sense?

Marconi has a pluggable storage driver model which allows these other storage 
drivers to be implemented (Redis is on the books).  The operator can then make 
their own informed choice on which backend makes the most sense for them based 
on their needs.

The alternative is that Openstack projects limit themselves to just one option 
(to reduce the deployment stack operators have to be concerned with – for 
example: only MySQL backends allowed), but may (likely) result in reduced 
performance/features/experience.  To me that would be an injustice to the users 
of that cloud.

How do back ends utilized relate to the amount/type/churn of data?  Is the 
blessed database ideal for that job or are there more scalable options? Im not 
saying you can’t scale MySQL, but db’s like Mongo/Cassandra/etc are better 
equipped for it (personal opinion).

I agree that investments in projects like Heat etc will reduce the burden on 
operators that deploy Openstack.


Amit Gandhi
Senior Manager, Rackspace.



From: Stan Lagun mailto:sla...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 20, 2014 at 2:23 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue 
implementation vs a provisioning API?

Kurt,

Your point is that NoSQL solution may be required for innovative project. And 
that is MongoDB. But what if come another amazing project that needs CouchDB, 
neo4j, Riak, (put your favorite NoSQL DB here)? It would be in the same 
position cause everyone would say hey, we already have NoSQL in OpenStack so 
you have to use MongoDB which is not fair. But is also obvious that OpenStack 
cannot demand cloud operators to maintain MySQL, MongoDB, CouchDB, neo4j etc in 
simultaneously

I hate to say that (I happen to be MongoDB fan) but the only way we can 
introduce external dependencies to OpenStack is by making technology that would 
make possible the project to be responsible for deployment and maintenance of 
that dependency (DBMS) rather then cloud operator. It seems to me that the 
right way to introduce MongoDB is to invest in projects like TripleO, Fuel, 
Murano, Heat and Ironic


On Thu, Mar 20, 2014 at 9:09 PM, Gil Yehuda 
mailto:gyeh...@yahoo-inc.com>> wrote:
>To be clear, Marconi does not incorporate any AGPL code itself; pymongo is
Apache2 licensed.

Understood, but here's the rub. Someone else is going to want to build on this 
(which it the point of this open source project). Whereas 'pymongo' is Apache 
licensed, since the copyright holder, MongoDB Inc. declared it as such, the 
authors of the other community drivers (for other language bindings and 
features of MongoDB, etc.) are also of releasing drivers under the Apache or 
BSD licenses too (thinking that's OK to do since no one is telling them 
otherwise). That community is unaware of their legal obligations when creating 
drivers to an AGPL database. Thus if one of those community drivers gets 
intertwined in a court case clarifying their license to be infringing on the 
AGPL terms, we've inadvertently impacted our community. This is a credible risk 
that is difficult for OpenStack to abate, since the problem lies with the way a 
different community chose to operate.

There are three interconnected issues here:
1. The confusion that MongoDB has created in Open Source licensing due to the 
asymmetric control they have on licensing terms.
2. The diligence of Open Stack to remain careful with OpenStack's CLA 
compliance and Apache-friendly terms.
3. The pragmatics of the effect MondgoDB would have onto OpenStack's economic 
viability and legal risks at large.

The first problem is out of scope for this list. But I think people who rely 
upon Open Source for their business ought to understand what MongoDB is doing 
to open source software. The second is, to your point, the issue in this 
conversation. As long as Openstack only use Apache licensed code >>from 
MondgoDB Inc.<< and diligently avoids using any open source contributions from 
any community contributor to the MongoDB ecosystem, then you remain compliant 
the your CLA. But you will have to exclude the rest of the MongoDB community 
(which goes against the spirit of Open Source -- back to the problem #1, which 
is out of scope). As for #3, I think the foundation needs to weigh in on the 
pragmatics here, since this has an economic and legal impact to the entire 
endeavor, not just to persisting data in one component 

Re: [openstack-dev] centralized notifications?

[Amit Gandhi]

Hi Greg,

The Marconi project (OpenStack Queueing and Notifications Service -
https://wiki.openstack.org/wiki/Marconi) has a blueprint currently drafted
to provide notifications to users.

You can read the blueprint here:
https://blueprints.launchpad.net/marconi/+spec/notifications

Note the Marconi blueprint is mostly focused on the delivery aspects of
the notification, and not the creation of the event itself that creates
the notification. Eg Marconi would deliver the email or SMS to a user, but
the failure alert would be generated by the related product or via
ceilometer.

Thanks
Amit Gandhi.



On 1/14/14, 10:05 AM, "Greg Hill"  wrote:

>Is there any project or proposed project for centralizing notifications
>from openstack services to alert tenants when things go wrong (or right)?
> Say, for example, a nova instance failed to finish the build process,
>and the customer wants an email alert when that happens, or a trove
>database fails a backup and they want an SMS sent to some cell number
>when that happens.
>
>Greg
>
>
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [marconi] New meeting time

[Amit Gandhi]

Works for me.

Amit.


From: Kurt Griffiths 
mailto:kurt.griffi...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 25, 2013 at 11:59 AM
To: OpenStack Dev 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [marconi] New meeting time

Hi folks,

To make it easier on our friends joining the project from across the world, I’d 
like to propose moving our weekly meeting time back one hour to 1500 UTC:

http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0

Any objections or alternate suggestions?

---
@kgriffs
Kurt Griffiths
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev