At the meeting I was not convinced that the name needs to be optional. I
believe is need to be ‘not optional’ and ‘unique’.
My perspective is that a network should be created with a name. It is the
systems responsibility to assign a UUID to it as it will be used by the system
for referring to i
Adding openstack-dev, as all discussion should go on there.
I think we need to be very careful here, as people are championing a
"network type" field, but for two very different use cases that I feel
don't make sense together.
What Salvatore is talking about is a notion of a "public network" that
Hi folks
I'm working on host_route function on quantum.
https://bugs.launchpad.net/quantum/+bug/1022737
https://bugs.launchpad.net/quantum/+bug/1025817
Hopefully, I wanna take this bug also ( Actually fix is same for 1022737)
https://bugs.launchpad.net/quantum/+bug/1008180
By implement this bug
I'll add my vote for network type attribute as well. Nachi's proposal below is
a good example of how this can be used as well.
Thanks,
Kyle
On Jul 17, 2012, at 12:17 PM, Nachi Ueno wrote:
> Hi folks
>
> I'm +1 for a network type attribute, because the simple change can
> support another usecas
Thanks for your feedback.
I am pretty sure more inputs will come into this thread. However, it seems
we agree to keep security groups / L3 / Floating IP / NAT api outside of
the core for Quantum.
Some discussion is instead going on:
1) how public networks should be described: public: { true | fals
Hi folks
I'm +1 for a network type attribute, because the simple change can
support another usecase.
I'm going to implement this rosetta-plugin which can support multiple
types of networks.
https://blueprints.launchpad.net/quantum/+spec/rosetta-plugin
2012/7/17 Sumit Naiksatam (snaiksat) :
> Hi
Hi NetStackers !
I could see that Hastexo [1] and Sebastien Han [1] worked on Nova RA
(Resource Agent) for Pacemaker. I decided to work on Quantum Server RA and
wrote something very close from other agents.
You can directly have a look to my work on my Git [3] or read my blog
article [4].
Let m
Hi All,
I second Gary's suggestion here for a network type attribute. I was curious to
know why we moved away from the kwargs mechanism which we had earlier in the
core API. That made it easier to pass any plugin-specific parameters which need
not be core attributes, and not have to necessarily
On Tue, Jul 17, 2012 at 12:28 AM, Salvatore Orlando wrote:
>
>
> In order to make this happen, it looks like there are just a few bits that
> needs to be agreed upon, and I think they can be summarized as follows:
> - 'name' attributes and whether they should be mandatory. It looks like we
> all ag
On 07/17/2012 10:28 AM, Salvatore Orlando wrote:
Hello people of Quantum!
As the Folsom release approaches, it is time to gather together and
finalize the specification for the v2 API, so that the Openstack-doc
team might cast it in stone for the sake of the Quantum users!
In order to make th
Hi,I thought we agreed to make the name optional and up to user to decide its uniqueness at meeting.ThanksYong Sheng Gong-Salvatore Orlando wrote: -To: openstack-...@lists.openstack.orgFrom: Salvatore Orlando Date: 07/17/2012 03:30PMCc: netstack@lists.launchpad.netSubject: [openstack-dev]
Hello people of Quantum!
As the Folsom release approaches, it is time to gather together and
finalize the specification for the v2 API, so that the Openstack-doc team
might cast it in stone for the sake of the Quantum users!
In order to make this happen, it looks like there are just a few bits tha
12 matches
Mail list logo
