On Thu, Jun 27, 2013 at 10:51 PM, Rahul Sharma wrote:
> Hi Aaron,
>
> Thanks for the CLI. I have a query related to that. I have a multinode
> openstack-deployment. To allow all the ports of VM accessible from outside,
> I need to add a rule "*TCP port-range 1-65535 Allow*" using Horizon
> dashboa
On Thu, Jun 27, 2013 at 05:49:00PM -0700, Clint Byrum wrote:
> On 2013-06-27 16:28, Jamie Lennox wrote:
> >On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote:
> >>On 27 June 2013 04:55, Adam Young wrote:
> >>>Right now Keystone provides so called bearer tokens: This
> >>>means that whoever
>
On 06/27/2013 07:05 PM, John Garbutt wrote:
I haven't seen any plans to change this.
The way I see it, the states make most sense for resize, which is the
end-user facing operation.
Personally I see migrate as a more admin focused operation.
So to help simplify the code, I am OK with slightly c
Thanks Aaron for your kind help. It worked. Is there any doc which lists
all the possible commands and their usage for quantum? because --help
doesn't help in identifying all the parameters, is there any reference
which one can use to get the complete command syntax?
-Regards
Rahul Sharma
On Fri
The detail parameters are described in the API reference. It is the best
document to know the parameters'detail at the moment.
http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html
In general options of quantum command can be mapped to API attributes one
to one.
Aki
I am not sure its worth the extra calls.
Hopefully once we have live-migrate and cold-migrate/resize refactor
done we can add a new single API that better combines the different
approaches, which should remove the confusion.
Thinking about it, that should sove the issue about the different states
Interesting, thanks for trying that. I think this is the time people
"feel" the most.
It should help set expectations on how long it will take to get your
change into trunk. It seems, on average, to take two weeks.
Hopefully it is useful to spot reviews that are proving tricky to get
in, and they
Thierry Carrez wrote:
> Thierry Carrez wrote:
>> A script will automatically and regularly align "series goal" with
>> "target milestone", so that the series and milestone views are
>> consistent (if someone sets target milestone to "havana-3" then the
>> series goal will be set to "havana").
>
>
On Thu, Jun 27, 2013 at 11:35 PM, Adam Young wrote:
> On 06/27/2013 08:43 AM, Davanum Srinivas wrote:
>
>> Lance, Doug,
>> Looks like eventlet.patcher.is_monkey_**patched(thread) is a reasonable
>> check to switch to to a thread-local implementation.
>>
>
> Doesn't it make more sense to have anyt
On Fri, Jun 28, 2013 at 12:12 PM, Russell Bryant
wrote:The results are much better than I was
afraid of. On average across
all
> projects, patches waiting for review have an age of just under 14 days
> since they were first posted. Nova is below average, sitting at an
> average of just over 10 d
Hi,
The following is a list of API extensions for which there are no plans to
port. Please shout if you think any of them needs to be!
baremetal_nodes.py
os_networks.py
networks_associate.py
os_tenant_networks.py
virtual_interfaces.py
createserverext.py
floating_ip_dns.py
floating_ip_pools.py
flo
On Fri, Jun 28, 2013 at 10:12 AM, Steven Hardy wrote:
> Obviously long-term a keystone native way to sign requests would be great,
> and could be used by Heat, and e.g Swift which has it's own method for
> generating pre-signed URLs.
fyi: only when you are using the temporary url feature you are
Hi, I would like to get some input on what kind of rating rules engine we
could use for BS.
Basically there are two alternatives as we see it now:
Drools as a service besides the Python components in BS using
https://github.com/droolsjbpm/drools-wb as a UI and interact with it as a
webservice
Pyth
On 06/27/2013 10:45 PM, Simo Sorce wrote:
On Thu, 2013-06-27 at 17:49 -0700, Clint Byrum wrote:
On 2013-06-27 16:28, Jamie Lennox wrote:
On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote:
On 27 June 2013 04:55, Adam Young wrote:
Right now Keystone provides so called bearer tokens: This
On 19/06/13 15:51 +0200, Thierry Carrez wrote:
Thoughts ?
Although it is not an integrated project - not even incubated - we've
been doing this for Marconi as well and it's been quite a pain. Also,
I've been following how Glance's blueprints have evolved and again,
I've noticed how hard it is
On 25/06/13 11:03 +0800, Zhongyue Luo wrote:
Hi team
I'm currently trying to move the generate_sample.sh script in nova to oslo.
Before pushing the patch to gerrit, I wanted to give the output directory a
default value if it was not stated so I was wondering where projects put their
sample conf
I'd like to reminder all Neutron contributors that if you are not the assignee
for a bug, you should be consulting the assignee before you consider
reassigning the bug to yourself or others. Failing to do so is not only
disrespectful, but may also result in unnecessary work. It could be that t
On 06/27/2013 10:35 AM, Thierry Carrez wrote:
Adam Young wrote:
Right now Keystone provides so called bearer tokens: This means that whoever
has a token can do whatever the token entitles him to do. If I
manage to get somebody's token I can do whatever this person is able to do.
Right. Tokens
Aaron,
Because the create create_subnet API is the one that enables/disables the
DHCP:
quantum subnet-create--enable_dhcp False
Besides, the CIDR is actually the information that is sent to the DHCP to
locate IP Addresses.
Thanks,
Edgar
From: Aaron Rosen
Reply-To: OpenStack List
Thanks Mark!
Edgar
From: Mark McClain
Reply-To: OpenStack List
Date: Monday, June 24, 2013 7:04 AM
To: OpenStack List
Subject: Re: [openstack-dev] [Networking] Allocation of IPs
Here's the blueprintÂ
https://blueprints.launchpad.net/quantum/+spec/configurable-ip-allocation
On Jun 21,
Since I will be gone next week, and I know you want to move on with
this, just wanted to confirm that I am OK with Henry's approach.
I would like to suggest that we contemplate doing to inheritance
mechanism at assignment time as opposed to token creation time as an
optimization. What would t
Hey I made the list!
https://review.openstack.org/#/c/25355/
Just wanted to point out for nova in longest-waiting reviews based on
first revision:
1. 94 days, 12 hours, 49 minutes - https://review.openstack.org/25355
(PowerVM resize and migrate test cases)
This one is a bit skewed beca
On 26/06/13 12:55 -0400, Adam Young wrote:
Glance:
- Uses httplib for communication
- Uses keystoneclient within cli
- Checks that socket is patched before importing eventlet for httplib.
FWIW, we're working on the migration to requests.
Cheers,
FF
--
@flaper87
Flavio Percoco
__
On 06/28/2013 01:55 AM, Rahul Sharma wrote:
Thanks Aaron for your kind help. It worked. Is there any doc which lists
all the possible commands and their usage for quantum? because --help
doesn't help in identifying all the parameters, is there any reference
which one can use to get the complete c
Folks,
I appreciate that there is a strong awareness within the dev community to
ensure that OpenStack gets easier and easier to be deployed, upgraded and
maintained, however I would like to invite core reviewers to think (even)
harder about the implications that changes to config files may have f
On 06/28/2013 08:24 AM, Christopher Yeoh wrote:
> How about time since first revision or -1 applied (but not including -1s
> by Jenkins due to gate flakiness), whichever is shorter. That eliminates
> non trivial rebases which I've found are often required after about 7
> days but doesn't push out t
On 06/28/2013 01:26 PM, Armando Migliaccio wrote:
Folks,
I appreciate that there is a strong awareness within the dev community
to ensure that OpenStack gets easier and easier to be deployed, upgraded
and maintained, however I would like to invite core reviewers to think
(even) harder about the
On 06/28/2013 12:18 PM, Matt Riedemann wrote:
> Hey I made the list!
>
> _https://review.openstack.org/#/c/25355/_
>
> Just wanted to point out for nova in longest-waiting reviews based on
> first revision:
>
>
> 1.94 days, 12 hours, 49 minutes
> - _https://review.openstack.org/25355_ (
Hi Adam
if you do it at role assignment time, I think the newly assigned role
should be marked as implicit/inherited to differentiate it from an
explicitly assigned role. In this way, if the inheritance is
subsequently removed, then the inherited assignment can also be deleted
at the same tim
Hi Edgar,
I'm still not following. In your original question you asked how to you
create a port and not allocate an ip address to it at all so that you can
leverage a real dhcp server to do that. In order to do that you can create
a network without a subnet but then you loose the ipam info in quan
Hi Adam,
It's a valid debatethe thing I would add is that we should make the way
group roles are handled consistently with whatever we do for inherited roles.
Group roles are a kind of inheritance (i.e. because I am a member of Group X, I
inherit all the role assignments that Group X has..
review response time matches up to accepted practices in infosec for
quantifying risk exposure in terms of incident response times.
so this is actually a suggest best practice in other areas.
-matt
On Fri, Jun 28, 2013 at 10:30 AM, Russell Bryant wrote:
> On 06/28/2013 12:18 PM, Matt Riedeman
Russell,
I have some crazy Idea, about how to make reviewing more stable.
And how to avoid old patches at all.
"Old" means that last update was more then N days ago.
If there are patches that are older then N days:
we just hide "review" button for all patches except old patches.
When they are re
Aaron,
You are totally right, the point is that I don't want to loose the IPAM info
in Neutron because that is the moment when the backend plugin deploys a new
DHCP server into the Virtual Networking Infrastruture. So, every time that a
user creates a subnet and enables DHCP our plugin deploys a n
On 06/28/13 at 10:01pm, Christopher Yeoh wrote:
Hi,
The following is a list of API extensions for which there are no plans to
port. Please shout if you think any of them needs to be!
baremetal_nodes.py
os_networks.py
networks_associate.py
os_tenant_networks.py
virtual_interfaces.py
createserver
On 2013-06-26 12:07, Rosa, Andrea (HP Cloud Services) wrote:
Hi all,
What happens if a greenthread, after acquiring a lock (not external),
it dies?
For example:
A thread is performing the "do_terminate_instance", it has the lock
and before terminating the process it dies, what happens at the
Hi all,
The latest version of python-barbicanclient is now available via pip. You can
get it using: pip install python-barbicanclient
This version includes the new command line interface, keep. Here's its
documentation:
https://github.com/cloudkeep/python-barbicanclient/wiki/Command-Line-Clien
Gotcha, The part that was confusing was:
>Could it be possible to add a flag to disable the allocation for the IP?
>If the "no allocation" flag is enabled, all ports will have an empty value
for IPs.
So what you are looking to do is to provide the IP address from the plugin
and not the db_base cl
On 06/28/2013 03:46 PM, Andrew Laski wrote:
> On 06/28/13 at 10:01pm, Christopher Yeoh wrote:
>> Hi,
>>
>> The following is a list of API extensions for which there are no plans to
>> port. Please shout if you think any of them needs to be!
>>
>> baremetal_nodes.py
>> os_networks.py
>> networks_ass
Got it!!! I knew it could be possible..
Thanks,
Edgar
From: Aaron Rosen
Reply-To: OpenStack List
Date: Friday, June 28, 2013 2:19 PM
To: OpenStack List
Subject: Re: [openstack-dev] [Networking] Allocation of IPs
Gotcha, The part that was confusing was:
>Could it be possible to add a f
On 06/28/2013 03:44 PM, Boris Pavlovic wrote:
> Russell,
>
> I have some crazy Idea, about how to make reviewing more stable.
> And how to avoid old patches at all.
>
> "Old" means that last update was more then N days ago.
>
> If there are patches that are older then N days:
> we just hide "
I guess the other question is: is this the right approach?
I think your use case may be beneficial to other plugins, so in my view
having a plugin-specific override is not the best fit.
On Fri, Jun 28, 2013 at 2:42 PM, Edgar Magana wrote:
> Got it!!! I knew it could be possible..
>
> Thanks,
>
Actually, the implementation for that method in our case will just simple
return an empty value (if that is possible) because I can't tale which IP
address the DHCP will assign.
I could tell the DHCP server which IP assign to the specific MAC but I could
not have that kind of functionality.
After t
I think he's got enough +1...but here's mine:
+1
On Thu, Jun 27, 2013 at 3:10 AM, Bob Ball wrote:
> +1 from me too.
>
> From: Russell Bryant [rbry...@redhat.com]
> Sent: 26 June 2013 16:09
> To: OpenStack Development Mailing List
> Subject: [openstack-de
On 06/28/2013 05:43 PM, Russell Bryant wrote:
> On 06/28/2013 03:44 PM, Boris Pavlovic wrote:
>> Russell,
>>
>> I have some crazy Idea, about how to make reviewing more stable.
>> And how to avoid old patches at all.
>>
>> "Old" means that last update was more then N days ago.
>>
>> If there a
On Fri, Jun 28, 2013 at 7:31 AM, Christopher Yeoh wrote:
> Hi,
>
> The following is a list of API extensions for which there are no plans to
> port. Please shout if you think any of them needs to be!
>
What does "no plans to port" mean for people already using Floating IPs and
Cloudpipe via API
Hi Russell
Your tool is awesome.
I have also two idea (I believe it's not crazy :P ).
1) Show LOC of the review
Long patch takes long time..
2) Show priority of the review
If it shows priority of the review, it wil be more useful, because
we should work on the order of the priorities.
The prior
47 matches
Mail list logo
