+1 on new migration script. Just to be consecutive.
Andrew.
On Wed, Jan 29, 2014 at 2:17 PM, Trevor McKay wrote:
> Hi Sergey,
>
> In https://review.openstack.org/#/c/69982/1 we are moving the
> 'main_class' and 'java_opts' fields for a job execution into the
> job_configs['configs'] dictiona
On Jan 29, 2014, at 12:04 PM, Russell Bryant wrote:
> On 01/29/2014 12:45 PM, Daniel P. Berrange wrote:
>> I was thinking of an upgrade path more akin to what users got when we
>> removed the nova volume driver, in favour of cinder.
>>
>> https://wiki.openstack.org/wiki/MigrateToCinder
>>
>>
Hi Irena,
With your reply, and after taking a close look at the code, I think that I
understand it now.
Regarding the cli change:
neutron port-create –binding:profile type=dict vnic_type=direct
following the neutron net-create —provider:physical_network as an example,
--binding:* can be tre
Hi Bob,
that's a good find. profileid as part of IEEE 802.1br needs to be in
binding:profile, and can be specified by a normal user, and later possibly
the pci_flavor. Would it be wrong to say something as in below in the
policy.json?
"create_port:binding:vnic_type": "rule:admin_or_network_owner"
On 01/29/2014 05:44 PM, Robert Li (baoli) wrote:
> Hi Bob,
>
> that's a good find. profileid as part of IEEE 802.1br needs to be in
> binding:profile, and can be specified by a normal user, and later possibly
> the pci_flavor. Would it be wrong to say something as in below in the
> policy.json?
>
On Wed, Jan 29, 2014 at 2:42 PM, Jarret Raim wrote:
>
> All,
>
> Barbican, the key management service for OpenStack, requested incubation
> before the holidays. After the initial review, there were several issues
> brought up by various individuals that needed to be resolved
> pre-incubation. At t
On 1/29/14, 4:21 PM, "Justin Santa Barbara" wrote:
>* the API for asymmetric keys (i.e. keys with a public and private
>part) has not yet been fleshed out
That's correct. We are working with folks from HP and others on the
blueprints to implement asymmetric support. Our hope is to have it done
f
I'd be happy to remove it for now. As I said, this is a staging location to
allow us to test that our docs generation process is working, it is not
documented anywhere and no one is using it. I just wanted to show that the
team is working on moving things over.
Jarret
From: Anne Gentle
Reply-To
A question about this bug:
https://bugs.launchpad.net/ceilometer/+bug/1061817
In the billing program we are currently writing we've partly accounted
for resetting of values in a given period for the cumulative metrics,
but since we need high accuracy especially for metrics like
network.incomin
On 29 January 2014 23:50, Robert Kukura wrote:
> On 01/29/2014 05:44 PM, Robert Li (baoli) wrote:
> > Hi Bob,
> >
> > that's a good find. profileid as part of IEEE 802.1br needs to be in
> > binding:profile, and can be specified by a normal user, and later
> possibly
> > the pci_flavor. Would it
Jarret Raim wrote:
>>I'm presuming that this is our last opportunity for API review - if
>>this isn't the right occasion to bring this up, ignore me!
>
> I wouldn't agree here. The barbican API will be evolving over time as we
> add new functionality. We will, of course, have to deal with backwar
Folks:
We’ve decided to cancel tomorrows IRC meeting. If you have
action items around the POC we’re all working on, please
continue down that path for now. We’ll sync up for a meeting
the following week again.
Thanks!
Kyle
___
OpenStack-dev mailing list
Hi,
The Solver scheduler code is committed with the new solver_scheduler driver,
and a reference implementation of a PULP based solver – hosts_pulp_solver.
The code is ready now for further review, now that the JENKINS build has
succeeded.
This is an initial commit and there will be future e
Sorry I forgot to include the review link -
https://review.openstack.org/#/c/46588/
—Yathi.
On 1/29/14, 3:52 PM, "Yathiraj Udupi (yudupi)"
mailto:yud...@cisco.com>> wrote:
Hi,
The Solver scheduler code is committed with the new solver_scheduler driver,
and a reference implementation of a PUL
I've noticed a few code reviews for new Heat resource types -
particularly Neutron resource types - where folks are struggling to find
the appropriate way to model the underlying API in Heat. This is a
really hard problem, and is often non-obvious even to Heat experts, so
here are a few tips th
On 30 January 2014 10:29, Sean Dague wrote:
>> would (worker-N) be sufficient? Or do you want *'s/x's specifically?
>
> So if we had worker-N we could play with a filter above that layer to do
> UI formatting.
>
> Realistically I had a stream with enough metadata, and preferably a
> solid parsin
On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote:
> I've noticed a few code reviews for new Heat resource types -
> particularly Neutron resource types - where folks are struggling to find
> the appropriate way to model the underlying API in Heat. This is a
> really hard problem, and is ofte
On 29/01/14 19:40, Jay Pipes wrote:
On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote:
I've noticed a few code reviews for new Heat resource types -
particularly Neutron resource types - where folks are struggling to find
the appropriate way to model the underlying API in Heat. This is a
real
On Wed, 2014-01-29 at 20:03 -0500, Zane Bitter wrote:
> On 29/01/14 19:40, Jay Pipes wrote:
> > On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote:
> >> I've noticed a few code reviews for new Heat resource types -
> >> particularly Neutron resource types - where folks are struggling to find
> >>
On 01/29/2014 07:27 PM, Robert Collins wrote:
> On 30 January 2014 10:29, Sean Dague wrote:
>
>
>>> would (worker-N) be sufficient? Or do you want *'s/x's specifically?
>>
>> So if we had worker-N we could play with a filter above that layer to do
>> UI formatting.
>>
>> Realistically I had a st
Hello,
The deadline for icehouse comes really quickly and I understand that there
are a lot of work todo, but I would like get your attention about live
migration bug targeted
for icehouse-3 and with a code already in review.
- https://bugs.launchpad.net/nova/+bug/1271780
When block live migrat
While looking at gate failures trying to improve our classification
rate I stumbled across this:
http://logs.openstack.org/50/67850/5/gate/gate-ceilometer-python26/8fd55b6/console.html
It appears that ceilometer is pulling in the nova repo
(http://git.openstack.org/cgit/openstack/ceilometer/tree/
Hi Bob,
Those are all good questions. But as with nova VM flavor, could profileid
be created by the admin, and then used by normal users? For the Icehouse
release, we won't have time to develop the profileid management API. I
think that next release we should have it available. Personally, I don't
On Thu, Jan 30, 2014 at 4:34 AM, Russell Bryant wrote:
> On 01/29/2014 12:45 PM, Daniel P. Berrange wrote:
> > I was thinking of an upgrade path more akin to what users got when we
> > removed the nova volume driver, in favour of cinder.
> >
> > https://wiki.openstack.org/wiki/MigrateToCinder
>
On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh wrote:
> So if nova-network doesn't go away this has implications for the V3 API as
> it currently doesn't support
> nova-network. I'm not sure that we have time to add support for it in
> icehouse now, but if nova-network is
> not going to go awa
Yes, you need create new migration script. Btw, we already have started doing
this.
The first example was when Jon added ‘neutron’ param to the ‘job_execution’
object:
https://review.openstack.org/#/c/63517/17/savanna/db/migration/alembic_migrations/versions/002_add_job_exec_extra.py
Regards,
Al
Today Savanna has two provisioning engines, heat and old one known as 'direct'.
Users can choose which engine will be used by setting special parameter in
'savanna.conf'.
I have an idea to give an ability for users to define provisioning engine
not only when savanna is started but when new cluste
Hi folks,
We'll be having the Savanna team meeting as usual in #openstack-meeting-alt
channel.
Agenda:
https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_January.2C_30
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140130T18
P.S. The main topic wil
I think depending on use-case it can be accomplished.
The steps we have been thinking at Y!
1. Take offline APIs & nova-compute (so new/existing VMs can't be
scheduled/modified) -- existing running VMs will not be affected.
2. Save/dump nova database.
3. Translate nova database entries into corre
On 29/01/14 10:17 -0800, Georgy Okrokvertskhov wrote:
Hi Angus,
Let me share my view on this. I think we need to distinguish implementation
and semantics. Context means that you provide an information for method but
method will not keep or store this information. Method does not own context
but
Hi folks,
As part of preparations for graduation from incubation [0], I've contacted
OpenStack Foundation Marketing team to ensure that everything is ok with
our program and project names from their point of view. Thanks for Lauren
Sell for providing info.
Thetus Corporation already use 'Savanna'
Please see inline
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Thursday, January 30, 2014 1:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
On 29 January 2014 23:50, Robert Kukura
mai
Hi all,
The [state-management] project team holds a weekly meeting in
#openstack-meeting on thursdays, 2000 UTC. The next meeting is tommorow,
2014-01-30!!!
As usual, everyone is welcome :-)
Link: https://wiki.openstack.org/wiki/Meetings/StateManagement
Taskflow: https://wiki.openstack.org
Zane Bitter writes:
> As I said, figuring this all out is really hard to do, and the
> existing resources in Heat are by no means perfect (we even had a
> session at the Design Summit devoted to fixing some of them[1]). If
> anyone has a question about a specific model, feel free to ping me or
>
Alexander,
What is the purpose of exposing this to user side? Both engines must do
exactly the same thing and they exist in the same time only for transition
period until heat engine is stabilized. I don't see any value in proposed
option.
Andrew.
On Wed, Jan 29, 2014 at 8:44 PM, Alexander Igna
On 29 January 2014 23:13, Vishvananda Ishaya wrote:
> I see the process as going something like this:
>
> * Migrate network data from nova into neutron
> * Turn off nova-network on the node
> * Run the neutron l3 agent and trigger it to create the required bridges
> etc.
> * Use ovsctl to remove
Hi, any feedback on this?
If there is not, and it does seem right, I will go on adding the
documentation of this parameter to the agent config files.
Best Regards,
Miguel Ángel.
- Original Message -
> From: "Miguel Angel Ajo Pelayo"
> To: "OpenStack Development Mailing List (not for
101 - 137 of 137 matches
Mail list logo
