There is something that isn't clear to me from your patch and based on your
description of the workflow below. It sounds like you are following the basic
L3 to ToR topology so each rack is a broadcast domain. If that’s the case, each
rack should be a Neutron network and the mapping should be bet
On Mon, Nov 9, 2015 at 1:39 PM, Shraddha Pandhe
wrote:
> Thats great. L3 layer network model is definitely one of our most important
> requirements. All our go-forward deployments are going to be L3. So this is
> a big deal for us.
I think we're on a good path to getting this figured out over the
Hi Carl,
Please find me reply inline
On Mon, Nov 9, 2015 at 9:49 AM, Carl Baldwin wrote:
> On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe <
> spandhe.openst...@gmail.com> wrote:
>>
>> We have a similar requirement where we want to pick a network thats
>> accessible in the rack that VM belongs
ned object model model then it will
> be better. Having random json blobs passed around is going to cause
> problems.
>
> From: "Armando M."
> Reply-To: OpenStack List
> Date: Wednesday, November 4, 2015 at 11:38 PM
> To: OpenStack List
> Subject: Re: [openstac
> On Nov 5, 2015, at 1:24 PM, Shraddha Pandhe
> wrote:
>
> Hi,
>
> I agree with all of you about the REST Apis.
>
> As I said before, I had to bring up the idea of JSON blob because based on
> previous discussions, it looked like neutron community was not willing to
> enhance the schemas fo
On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe wrote:
>
> We have a similar requirement where we want to pick a network thats
> accessible in the rack that VM belongs to. We have L3 Top-of-rack, so the
> network is confined to the rack. Right now, we are achieving this by naming
> physical networ
Wednesday, November 4, 2015 at 11:38 PM
To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db
tables
On 4 November 2015 at 13:21, Shraddha Pandhe
mailto:spandhe.openst...@gmail.com>> wrote:
Hi Salv
Replies inline.
On Fri, Nov 6, 2015 at 1:48 PM, Salvatore Orlando
wrote:
> More comments inline.
> I shall stop trying being ironic (pun intended) in my posts.
>
:(
>
> Salvatore
>
> On 5 November 2015 at 18:37, Kyle Mestery wrote:
>
>> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes wrote:
>>
usage questions)
> *Reply To: *OpenStack Development Mailing List (not for usage questions)
> *Subject: *Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in
> ipam db tables
>
> Bumping this up :)
>
>
> Folks, does anyone else have a similar requirement to ours? Ar
More comments inline.
I shall stop trying being ironic (pun intended) in my posts.
Salvatore
On 5 November 2015 at 18:37, Kyle Mestery wrote:
> On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes wrote:
>
>> On 11/04/2015 04:21 PM, Shraddha Pandhe wrote:
>>
>>> Hi Salvatore,
>>>
>>> Thanks for the feed
lopment Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db
tables
Bumping this up :)
Folks, does anyone else have a similar requirement to ours? Are folk
Bumping this up :)
Folks, does anyone else have a similar requirement to ours? Are folks
making scheduling decisions based on networking?
On Thu, Nov 5, 2015 at 12:24 PM, Shraddha Pandhe <
spandhe.openst...@gmail.com> wrote:
> Hi,
>
> I agree with all of you about the REST Apis.
>
> As I said
Hi,
I agree with all of you about the REST Apis.
As I said before, I had to bring up the idea of JSON blob because based on
previous discussions, it looked like neutron community was not willing to
enhance the schemas for different ipam dbs. Entire rationale behind
pluggable IPAM is to provide fl
On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes wrote:
> On 11/04/2015 04:21 PM, Shraddha Pandhe wrote:
>
>> Hi Salvatore,
>>
>> Thanks for the feedback. I agree with you that arbitrary JSON blobs will
>> make IPAM much more powerful. Some other projects already do things like
>> this.
>>
>
> :( Actua
On Thu, Nov 05, 2015 at 11:55:50AM -0500, Jay Pipes wrote:
> On 11/04/2015 04:21 PM, Shraddha Pandhe wrote:
> >Hi Salvatore,
> >
> >Thanks for the feedback. I agree with you that arbitrary JSON blobs will
> >make IPAM much more powerful. Some other projects already do things like
> >this.
>
> :( A
On 11/04/2015 04:21 PM, Shraddha Pandhe wrote:
Hi Salvatore,
Thanks for the feedback. I agree with you that arbitrary JSON blobs will
make IPAM much more powerful. Some other projects already do things like
this.
:( Actually, though "powerful" it also leads to implementation details
leaking d
I don't know if this would make more sense. Let's assume that
we add arbitrary blobs(ABs) to IPAM even every neutron object. What
would happen? People can do anything via those APIs. Any new
attribute even the whole model could be passed through those
so-called ABs. Except the architecture issues,
Shraddha Pandhe wrote:
On Wed, Nov 4, 2015 at 3:12 PM, Kevin Benton mailto:blak...@gmail.com>> wrote:
>If we add our own database for internal stuff, we go back to the
same problem of allowing bad design.
I'm not sure I understand what you are saying here. A JSON blob that
onl
On Wed, Nov 4, 2015 at 3:12 PM, Kevin Benton wrote:
> >If we add our own database for internal stuff, we go back to the same
> problem of allowing bad design.
>
> I'm not sure I understand what you are saying here. A JSON blob that only
> one driver knows how to interpret is worse than a vendor t
>If we add our own database for internal stuff, we go back to the same
problem of allowing bad design.
I'm not sure I understand what you are saying here. A JSON blob that only
one driver knows how to interpret is worse than a vendor table. They both
are specific to one driver but at least with a
On Wed, Nov 4, 2015 at 1:38 PM, Armando M. wrote:
>
>
> On 4 November 2015 at 13:21, Shraddha Pandhe
> wrote:
>
>> Hi Salvatore,
>>
>> Thanks for the feedback. I agree with you that arbitrary JSON blobs will
>> make IPAM much more powerful. Some other projects already do things like
>> this.
>>
On 4 November 2015 at 13:21, Shraddha Pandhe
wrote:
> Hi Salvatore,
>
> Thanks for the feedback. I agree with you that arbitrary JSON blobs will
> make IPAM much more powerful. Some other projects already do things like
> this.
>
> e.g. In Ironic, node has driver_info, which is JSON. it also has
Hi Salvatore,
Thanks for the feedback. I agree with you that arbitrary JSON blobs will
make IPAM much more powerful. Some other projects already do things like
this.
e.g. In Ironic, node has driver_info, which is JSON. it also has an
'extras' arbitrary JSON field. This allows us to put any inform
Arbitrary blobs are a powerful tools to circumvent limitations of an API,
as well as other constraints which might be imposed for versioning or
portability purposes.
The parameters that should end up in such blob are typically specific for
the target IPAM driver (to an extent they might even identi
If you have custom data you want to keep for your driver, you should create
your own database tables to track that information. For example, the reference
driver creates its own tables to track its data in ipam* tables.
John
On Nov 4, 2015, at 3:46 PM, Shraddha Pandhe
mailto:spandhe.openst...@
Hi folks,
I have a small question/suggestion about IPAM.
With IPAM, we are allowing users to have their own IPAM drivers so that
they can manage IP allocation. The problem is, the new ipam tables in the
database have the same columns as the old tables. So, as a user, if I want
to have my own logi
26 matches
Mail list logo
