Nisha,
If it was an unrelated bug, you would need to "recheck" the patch. [0]
However, it looks this failure is a direct result of your patch. See the
nova-compute log here:
http://logs.openstack.org/12/141012/10/check/check-tempest-dsvm-ironic-pxe_ssh/45807b1/logs/screen-n-cpu.txt.gz#_2015-01-2
Hi all,
I've just pushed a draft schedule for Ironic's design sessions to sched.org. If
your proposal was refused, don't take it personally - It was tough to
schedule considering that we had 18 proposals and only 4 slots.
Our Tuesday sessions will necessarily focus on project-wide topics rather
t
Hi all,
We've all been pretty lax about the amount of detail that we put in commit
messages some times, and I'd like to change that as we start Juno
development. Why? Well, just imagine that, six months from now, you're
going to write a document describing *all* the changes in Juno, just based
on
Hi all,
Just a reminder that May 5th is our next scheduled meeting day, but I
probably won't make it, because I'll be just getting back from one trip and
start two consecutive weeks of conference travel early the next morning.
Chris Krelle (nobodycam) has offered to chair that meeting in my absenc
François,
Can you clarify by way of a CLI example what exactly you mean by "nova
hypervisor id"? I'm not sure if you mean the instance uuid, compute
host id, service id, or something else.
I'll assume you mean the nova instance uuid, in which case, you can
get the Ironic node uuid from "nova show
François,
Can you clarify by way of a CLI example what exactly you mean by "nova
hypervisor id"? I'm not sure if you mean the instance uuid, compute
host id, service id, or something else.
I'll assume you mean the nova instance uuid, in which case, you can
get the Ironic node uuid from "nova show
there is no running
> instances.
> This is why I need to get the Ironic node UUID from a Nova Hypervisor ID...
>
> "http://ironic:6385/v1/nodes?instance_uuid=blablabla"; is not a perfect
> solution : without running instances, you cannot retrieve the node UUID...
&
Hi all!
I've linked the etherpads from the wiki and the sched.org entries, but I'm
guessing not everyone noticed that, so I'd like to draw attention to our
session's etherpads ahead of the summit.
Ironic Python Agent -- an effort, led by rackspace, to give Ironic a much
more featureful deploy/ra
Since many folks are flying home this weekend, and will probably need a few
days to recover from the conference, we're going to skip this Monday's
meeting.
We all got a lot of design and planning done during the week, so stay tuned
to the mailing list for some discussions/announcements!
Regards,
Hi all,
As with several other projects, and as discussed at the summit, Ironic is
moving to a formal / specs-based design process. The reasons for this have
been well summarized in previous email threads in other projects [*], but
in short, it's because, until now, nearly all our blueprints lacked
On Mon, May 19, 2014 at 12:58 AM, 严超 wrote:
>
> Hi, All :
> Ironic is a project for us to control bare metal better. Is there
any horizon implementation for ironic to use ironic api and function easyly?
>
> Best Regards！
> Chao Yan
The Tuskar UI team is working on a UI for Ironic as well.
ke to see additional hard requirements that will be
> added to drivers called out (e.g. a 'Driver Impact' section).
>
> -Rob
>
> On 19 May 2014 10:03, Devananda van der Veen
> wrote:
> > Hi all,
> >
> > As with several other projects, and as discuss
Hi Kevin!
I had a few conversations with folks at the summit regarding this. Broadly
speaking, yes -- this integration would be very helpful for both discovery
and network/tenant isolation at the bare metal layer.
I've left a few comments inline
On Mon, May 19, 2014 at 3:52 PM, Kevin Benton
I'd like to bring up the topic of drivers which, for one reason or another,
are probably never going to have third party CI testing.
Take for example the iBoot driver proposed here:
https://review.openstack.org/50977
I would like to encourage this type of driver as it enables individual
contrib
Just a quick heads up to everyone -- the tempest-dsvm-virtual-ironic job is
now fully voting in both check and gate queues for Ironic. It's also now
symmetrically voting on diskimage-builder, since that tool is responsible
for building the deploy ramdisk used by this test.
Background: We discussed
Hi all!
This is a follow-up to several summit discussions on
how-do-we-deprecate-baremetal, a summary of the plan forward, a call to
raise awareness of the project's status, and hopefully gain some interest
from folks on nova-core to help with spec and code reviews.
The nova.virt.ironic driver li
Hi all!
I'd like to nominate Dmitry (dtantsur) to ironic-core. He's been very
active in Ironic over the last few months, in particular finding and fixing
bugs and adding support for CentOS and Fedora. His reviews have been
insightful and generally match the direction that the core team is going.
O
I think there may be an old Neutron bug causing the log message you're
referencing, but that's not causing the virtual-ironic job to fail -- the
console.html log in the bug you linked indicates a known issue in our API.
Here's the bug I filed about it last week:
https://bugs.launchpad.net/ironic/+
Hi all!
It's that time again -- time to look at the core team and see if any
changes are in order. Over the last month, we've continued to see an
increase in the size of the review queue, and folks are (understandably)
getting frustrated at how long it is taking to land any changes. We have
had an
The specs repo is now available here:
https://github.com/openstack/ironic-specs
Reviews for specs can be found here:
https://review.openstack.org/#/q/project:openstack/ironic-specs,n,z
I've updated all Ironic's blueprints on Launchpad to "definition: new" and
"direction: needs approval". Plea
While I appreciate the many ideas being discussed here (some of which we've
explored previously and agreed to continue exploring), there is a
fundamental difference vs. what I propose in that spec. I believe that what
I'm proposing will be achievable without any significant visible changes in
the A
On Wed, May 28, 2014 at 11:42 PM, Robert Collins
wrote:
> Is there any wiggle room on those dates? As James Polley says, PyCon
> AU (and the Openstack miniconf, which I'm organising with JHesketh)
> overlap significantly - and I can't be in two places at once.
>
> However July 21-25th would be tot
Hi Jaromir,
I agree that the midcycle meetup with TripleO and Ironic was very
beneficial last cycle, but this cycle, Ironic is co-locating its sprint
with Nova. Our focus needs to be working with them to merge the
nova.virt.ironic driver. Details will be forthcoming as we work out the
exact detail
On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh <
joshua.hesk...@rackspace.com> wrote:
> On 5/29/14 8:52 AM, James E. Blair wrote:
>
>> Devananda van der Veen writes:
>>
>> Hi all!
>>>
>>> This is a follow-up to several summit discussions on
>
On Wed, May 28, 2014 at 8:14 PM, Jander lu wrote:
> Hi, guys, I have two confused part in Ironic.
>
>
>
> (1) if I use nova boot api to launch an physical instance, how does nova
> boot command differentiate whether VM or physical node provision? From
> this article, nova bare metal use "Placemen
Hi all!
I'd like to draw attention to our list of open bugs:
https://bugs.launchpad.net/ironic/+bugs
And ask that, if you have a bug assigned to you, please ensure you're
actively working on it. If you're not, please un-assign yourself from the
bug so it becomes visible / available to others. Y
We are in the process of proposing the nova.virt.ironic driver to the
Nova tree, where it really belongs. Specs are here:
https://review.openstack.org/#/c/95024/
https://review.openstack.org/#/c/95025/
While that work is ongoing, any significant new features / changes in
the nova.virt.ironic driv
On Wed, Jun 4, 2014 at 6:51 AM, 严超 wrote:
> Yes, but when you assign a "production" image to an ironic bare metal node.
> You should provide ramdisk_id and kernel_id.
> Should the ramdisk_id and kernel_id be the same as deploy images (aka the
> first set of k+r) ?
> You didn't answer me if the two
here is only devstack with
> ironic(http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html)
>
> is there any docs about how to deploy Ironic on production physical node
> enviroment?
>
> thx
>
>
>
> 2014-05-30 1:49 GMT+08:00 Devananda van der Veen :
>>
>
ChaoYan,
Are you asking about using vmware as a test platform for developing
Ironic, or as a platform on which to run a production workload managed
by Ironic? I do not understand your question -- why would you use
Ironic to manage a VMWare cluster, when there is a separate Nova
driver specifically
Quick update for those who are following along but may not be on IRC right now.
The gate (not just ours -- the gate for all of openstack, which Ironic
is a part of) is having issues right now. See Sean's email for details
on that, and what you can do to help
http://lists.openstack.org/pipermail
Hi all!
Ironic will be holding our mid-cycle meetup co-located with Nova. This
will be between July 28 and 30 in Beaverton, OR (near Portland). We
will mostly do our own thing in a separate room, but will have
meetings with Nova to discuss the interaction/integration between Nova
and Ironic.
Plea
I have just announced the Ironic mid-cycle in Beaverton, co-located
with Nova. That's the "main one" for Ironic.
However, there are many folks working on both TripleO and Ironic, so I
wouldn't be surprised if there is a (small?) group at the TripleO
sprint hacking on Ironic, even if there's nothin
I think some things are broken in the oslo-incubator db migration code.
Ironic moved to this when Juno opened and things seemed fine, until
recently when Lucas tried to add a DB migration and noticed that it didn't
run... So I looked into it a bit today. Below are my findings.
Firstly, I filed th
tly on MySQL and SQLite AFAIK).
>
> Thanks,
> Roman
>
> [1] https://review.openstack.org/#/c/33236/
> [2] https://blueprints.launchpad.net/nova/+spec/db-api-tests-on-all-backends
>
> On Sat, Jun 7, 2014 at 10:27 PM, Mike Bayer wrote:
>>
>> On Jun 6, 2014, at 8:
On Mon, Jun 9, 2014 at 10:49 AM, Jay Pipes wrote:
> On 06/09/2014 12:50 PM, Devananda van der Veen wrote:
>>
>> There may be some problems with MySQL when testing parallel writes in
>> different non-committing transactions, even in READ COMMITTED mode,
>> due to InnoDB
Hi all!
Dmitry called it to my attention last week that we lacked any official
guidelines on bug tags, and I've just gotten around to following up on
it. I've created an official list in launchpad and added that to the
OpenStack bug tag tags list wiki page here:
https://wiki.openstack.org/wiki/B
Last week, we tried to fix a bug in the way that Nova's baremetal and
ironic drivers are using the HostManager / HostState classes --
they're incorrectly reporting capabilities in an older fashion, which
is not in use any more, and thus not exposing the node's "stats" to
the scheduler. The fix actu
milar here:
https://git.openstack.org/cgit/openstack-infra/nodepool/tree/nodepool/tests/__init__.py#n71
Regards,
Devananda
On Mon, Jun 9, 2014 at 12:58 PM, Mike Bayer wrote:
>
> On Jun 9, 2014, at 1:08 PM, Mike Bayer wrote:
>
>>
>> On Jun 9, 2014, at 12:50 PM, Devananda van der Veen
>
On Tue, Jun 10, 2014 at 1:23 AM, Flavio Percoco wrote:
>> Against:
>>
>> • Makes it hard for users to create applications that work across
>> multiple
>>clouds, since critical functionality may or may not be available in a
>> given
>>deployment. (counter: how many users need cross-cloud c
Ironic has a simple lock mechanism for nodes to ensure that, if the
hash ring rebalances while an operation is in progress, the second
conductor doesn't trample on the work that the first conductor is
doing until it's finished (and releases the lock).
Right now, it's got a simple DB backing. We've
All,
Feature freeze for Ironic is now in effect, and the icehouse-3
milestone-proposed branch has been created:
http://git.openstack.org/cgit/openstack/ironic/log/?h=milestone-proposed
I have bumped to the next cycle any blueprints which were targeted to
Icehouse but not yet completed, and tempo
All,
The Ironic team has been discussing the need for a "deploy agent" since
well before the last summit -- we even laid out a few blueprints along
those lines. That work was deferred and we have been using the same deploy
ramdisk that nova-baremetal used, and we will continue to use that ramdisk
With the feature freeze in effect and our driver blocked from the Nova tree
for this release cycle, last week we moved our driver into the Ironic tree
in this patch set:
https://review.openstack.org/#/c/78002/
This allows Nova to load the "ironic" virt driver by importing the
"ironic.nova.virt.ir
For those looking at Pecan/WSME'fying the agent, some scaffolding was
recently added to Pecan which may interest you.
https://review.openstack.org/#/c/78682/
-Deva
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.
On Mar 10, 2014 4:57 AM, "John Garbutt" wrote:
>
> On 9 March 2014 16:04, Devananda van der Veen
wrote:
> > With the feature freeze in effect and our driver blocked from the Nova
tree
> > for this release cycle, last week we moved our driver into the Ironi
+1 to the idea.
However, I think we should discuss whether the rescue interface is the
appropriate path. It's initial intention was to tie into Nova's rescue
interface, allowing a user whose instance is non-responsive to boot into a
recovery mode and access the data stored within their instance. I
On Tue, Mar 18, 2014 at 12:22 AM, Zhongyue Luo wrote:
> Hi,
>
> If I were to implement a new BM driver then should I propose a BP to
> Ironic rather than Nova? We are currently writing a driver internally using
> nova-baremetal. My understanding is that nova-baremetal will only merge
> critical bu
On Tue, Mar 18, 2014 at 12:24 PM, Robert Collins
wrote:
> On 15 March 2014 13:07, Devananda van der Veen
> wrote:
> > +1 to the idea.
> >
> > However, I think we should discuss whether the rescue interface is the
> > appropriate path. It's initial inte
Let me start by saying that I want there to be a constructive discussion
around all this. I've done my best to keep my tone as non-snarky as I could
while still clearly stating my concerns. I've also spent a few hours
reviewing the current code and docs. Hopefully this contribution will be
benefici
": "value111", ...}
> Implementation:
> ext_mgr.map(lambda ext: ext.name == "power", lambda ext: ext.obj(data))
>
> What do you guys think of having just plain (not tree like) bunch of
> drivers?
>
>
> Vladimir Kozhukalov
>
>
> On M
I haven't gotten to my email back log yet, but want to point out that I
agree with everything Robert just said. I also raised these concerns on the
original ceilometer BP, which is what gave rise to all the work in ironic
that Haomeng has been doing (on the linked ironic BP) to expose these
metrics
On Mon, Mar 31, 2014 at 8:47 AM, David Kranz wrote:
> I was reviewing some ironic changes that are more than a week old and do
> not have any reviews from the ironic team. Having at least one review from
> the ironic team would be very helpful.
>
Hi David,
I think it'd be great to get reviewers
On the ceilometer integration front, I think that, over the course of
Icehouse, the proposed Ironic driver API for gathering metrics was fleshed
out and agreed upon internally. I am hoping that work can be completed
early in Juno, at which point we'll be looking to Ceilometer to start
consuming it.
Hi!
Jaromir reminded me that I should jot down some ideas about a Horizon tab
for Ironic in advance of the summit, so we can get the conversations
started and some ideas flowing I've done that here:
https://etherpad.openstack.org/p/ironic-ui
Cheers,
Devananda
___
On Tue, Apr 1, 2014 at 11:09 AM, Devananda van der Veen <
devananda@gmail.com> wrote:
> Hi!
>
> Jaromir reminded me that I should jot down some ideas about a Horizon tab
> for Ironic in advance of the summit, so we can get the conversations
> started and some ideas flowi
For those interested in translations, I'd like to jot down a few notes from
the last few days' work to get i18n'd strings into Ironic before our RC.
Hopefully some of this will be helpful to someone out there -- it's been a
learning experience for me :)
Quick background:
- the project was set up w
On Tue, Apr 1, 2014 at 10:19 AM, Solly Ross wrote:
> Hello All,
>
> As OpenStack Marconi grows, I think it's time we addressed the question on
> everyone's mind:
> why isn't the project called OpenStack Macaroni?
>
> There are several compelling reasons to change Marconi's name to Macaroni:
>
> 1
Hi all!
I'd like to announce my candidacy for the Bare Metal Provisioning (Ironic)
PTL position.
I've been involved with bare metal provisioning for the last two years,
before it was even in Nova. I led the work on nova.virt.baremetal driver
throughout Grizzly and Havana cycles, and at the Havana
Hello everyone,
Ironic published its first Icehouse release candidate yesterday. The list of
bugs fixed since feature freeze and the RC1 tarball are available at:
https://launchpad.net/ironic/icehouse/icehouse-rc1
Unless release-critical issues are found that warrant a release
candidate respin,
Hi Matt!
I've looked into this a bit now, too, and don't have a conclusive answer as
to how (or even whether) it's working today.
Instead, I'd like to point out that Ironic is aiming to deprecate
nova.virt.baremetal and nova.scheduler.baremetal_host_manager, in favor of
nova.virt.ironic and nova.
On Fri, Apr 4, 2014 at 5:19 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> On the other hand, it is easy to imagine a situation when you want to run
> agent on every node of your cluster after installing OS. It could be useful
> to keep hardware info consistent (for example, many har
On Sun, Apr 6, 2014 at 10:44 AM, Tim Bell wrote:
>
> From my understanding, Trove is due to graduate in the Juno release.
>
>
Since I didn't see it called out elsewhere in this thread yet, I'd like to
point out that Trove graduated at the end of the Havana cycle and should be
included in the inte
In case it isn't clear to others, or in case I've misunderstood, I'd like
to start by rephrasing the problem statement.
* It is possible to use Ironic to deploy an instance of ironic-conductor on
bare metal, which joins the same cluster that deployed it.
* This, or some other event, could cause th
As March has come to a close, and Juno is open for development, I would
like to look at our review stats and see if the core review team should be
adjusted to reflect current activity. Also, since I believe that our
development pace needs to accelerate, I would like to increase the size of
the team
On Wed, Apr 9, 2014 at 9:01 AM, Stig Telfer wrote:
> > -Original Message-
> > From: Matt Wagner [mailto:matt.wag...@redhat.com]
> > Sent: Tuesday, April 08, 2014 6:46 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Ironic][Agent]
>
On Tue, Apr 8, 2014 at 3:04 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Guys, thank you very much for your comments,
>
> I thought a lot about why we need to be so limited in IPA use cases. Now
> it much clearer for me. Indeed, having some kind of agent running inside
> host OS is
Hi all!
The deadline for summit session proposals (April 20th) is approaching! If
you have a topic that you'd like to discuss, please submit it to
summit.openstack.org. We'll be going over the proposals in the weekly
meeting on 4/21 (and the following week, if need be), and will, if
necessary, m
Hi all,
The discussion of blueprint review has come up recently for several
reasons, not the least of which is that I haven't yet reviewed many of the
blueprints that have been filed recently.
My biggest issue with launchpad blueprints is that they do not provide a
usable interface for design ite
I would like to announce my candidacy for the Technical Committee this
term.
Background
=
I began working on OpenStack more than two years ago. Initially, I focused
on improving Nova's database API and led the Nova DB team in that cleanup
effort for a time. As much of that work was finis
On Tue, Apr 22, 2014 at 10:52 AM, Clint Byrum wrote:
> Excerpts from David Shrewsbury's message of 2014-04-22 10:16:42 -0700:
> > Hi,
> >
> > I'm working on implementing rebuild() in the nova.virt.ironic driver so
> > that we can support the --preserve-ephemeral option. I have a design
> > questi
Hi!
When a project is using oslo.messaging, how can we change our default
rpc_thread_pool_size?
---
Background
Ironic has hit a bug where a flood of API requests can deplete the RPC
worker pool on the other end and cause things to break in very bad ways.
Apparently, nova-cond
On Apr 22, 2014 11:51 AM, "Jim Rollenhagen" wrote:
> Hi folks! Deva and I talked a bit more about the agent driver last night,
> and I wanted to give everyone a quick status update on where we stand with
> merging the agent driver into Ironic itself.
>
> First off, we’ve taken all of the agent dr
On Wed, Apr 23, 2014 at 12:19 PM, Devananda van der Veen <
devananda@gmail.com> wrote:
> On Apr 22, 2014 11:51 AM, "Jim Rollenhagen"
> wrote:
>
>> Hi folks! Deva and I talked a bit more about the agent driver last night,
>> and I wanted to give every
On Mon, Apr 21, 2014 at 3:52 AM, Gopi Krishna Saripuri <
saripurig...@outlook.com> wrote:
>
> I'm trying to deploy ironic with devstack. I'm following the instructions
> @ http://docs.openstack.org/developer/ironic/dev/dev-
> quickstart.html#deploying-ironic-with-devstack.
>
> It is failing to sta
On Mon, Sep 22, 2014 at 12:33 PM, Doug Hellmann wrote:
>
> On Sep 22, 2014, at 3:11 PM, Tim Bell wrote:
>
>>
>> On 22 Sep 2014, at 20:53, Doug Hellmann wrote:
>>
>>>
>>> On Sep 19, 2014, at 6:29 AM, Thierry Carrez wrote:
>>>
Monty Taylor wrote:
> I've recently been thinking a lot about
On Mon, Sep 22, 2014 at 2:27 PM, Doug Hellmann wrote:
>
> On Sep 22, 2014, at 5:10 PM, Devananda van der Veen
> wrote:
>
>> One of the primary effects of integration, as far as the release
>> process is concerned, is being allowed to co-gate with other
>> integra
On Tue, Sep 23, 2014 at 8:40 AM, Doug Hellmann wrote:
>
> On Sep 22, 2014, at 8:05 PM, Devananda van der Veen
> wrote:
>
>> On Mon, Sep 22, 2014 at 2:27 PM, Doug Hellmann wrote:
>>>
>>> On Sep 22, 2014, at 5:10 PM, Devananda van der Veen
>>>
On Mon, Sep 22, 2014 at 7:51 AM, Jay S. Bryant
wrote:
>
> On 09/21/2014 07:37 PM, Matt Riedemann wrote:
>>
>> When I'm essentially +2 on a change but for a small issue like typos in
>> the commit message, the need for a note in the code or a test (or change to
>> a test), I've been doing those mys
On Mon, Sep 22, 2014 at 5:47 PM, Zane Bitter wrote:
> On 22/09/14 17:06, Joe Gordon wrote:
>>
>> If 50,000 messages per second doesn't count as small-to-moderate then
>> Zaqar
>> does not fulfill a major SQS use case.
>
>
> It's not a drop-in replacement, but as I mentioned you can recreate the SQ
I've taken a bit of time out of this thread, and I'd like to jump back
in now and attempt to summarize what I've learned and hopefully frame
it in such a way that it helps us to answer the question Thierry
asked:
On Fri, Sep 19, 2014 at 2:00 AM, Thierry Carrez wrote:
>
> The underlying question b
Hi all,
I would like to announce my candidacy for the PTL role of the Bare Metal
Provisioning program.
I have been the PTL of Ironic since I began the project at the Havana summit,
and I am partly to blame for the baremetal driver that Ironic was forked from.
(If you've touched that code, you wil
On Thu, Sep 25, 2014 at 7:13 PM, Tom Fifield wrote:
> On 26/09/14 03:35, Morgan Fainberg wrote:
>> -Original Message-
>> From: John Griffith
>> Reply: OpenStack Development Mailing List (not for usage questions)
>> >
>> Date: September 25, 2014 at 12:27:52
>> To: OpenStack Development Ma
On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann wrote:
> As promised at this week’s TC meeting, I have applied the various blog posts
> and mailing list threads related to changing our governance model to a series
> of patches against the openstack/governance repository [1].
>
> I have tried to in
On Fri, Oct 3, 2014 at 11:18 AM, Chris Friesen
wrote:
> On 10/03/2014 11:38 AM, Chris Dent wrote:
>>
>> On Fri, 3 Oct 2014, Joe Gordon wrote:
>
>
Many of those services expect[1] to be able to send notifications (or
be polled by) ceilometer[2]. We've got an ongoing thread about the need
So a bit of background here. This began from thinking about functional
dependencies, and pondering whether a map of the dependency graph of
our projects could inform our gating structure, specifically to
encourage (or dare I say, actually force) all of us (the project
teams) to become more cognizan
On Fri, Oct 3, 2014 at 6:25 AM, Anne Gentle wrote:
>
>
> On Fri, Oct 3, 2014 at 8:07 AM, Doug Hellmann wrote:
>>
>>
>> On Oct 3, 2014, at 12:46 AM, Joe Gordon wrote:
>>
>>
>> On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen
>> wrote:
&g
Gordon > <mailto:joe.gord...@gmail.com>> wrote:
>>
>>>
>>> On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen
>>> mailto:devananda@gmail.com>> wrote:
>>>
>>> On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann
&
On Fri, Oct 3, 2014 at 9:05 AM, Jay Pipes wrote:
> On 10/03/2014 10:06 AM, Chris Dent wrote:
>>
>> On Fri, 3 Oct 2014, Anne Gentle wrote:
>>
>>> I'm reading and reading and reading and my thoughts keep returning to,
>>> "we're optimizing only for dev." :)
>>
>>
>> Yes, +many.
>
>
> plus infinity.
(shamelessly copying Thierry's email template)
Hello everyone,
Ironic just published its first Juno release candidate.
The list of fixed bugs and the RC1 tarball are available at:
https://launchpad.net/ironic/juno/juno-rc1
Unless release-critical issues are found that warrant a release
candidate
On Fri, Oct 3, 2014 at 1:33 PM, Eoghan Glynn wrote:
>
>
>> So a bit of background here. This began from thinking about functional
>> dependencies, and pondering whether a map of the dependency graph of
>> our projects could inform our gating structure, specifically to
>> encourage (or dare I say,
On Fri, Oct 3, 2014 at 2:13 PM, Chris Friesen
wrote:
> On 10/03/2014 02:33 PM, Eoghan Glynn wrote:
>>
>>
>>
>>> So a bit of background here. This began from thinking about functional
>>> dependencies, and pondering whether a map of the dependency graph of
>>> our projects could inform our gating s
On Wed, Oct 8, 2014 at 12:07 PM, Ben Nemec wrote:
> On 10/08/2014 12:53 PM, Robert Collins wrote:
>> Ironic actually polls things till they worked, at least in the IPMI
>> codepaths, so we should be able to do something there. However,
>> Devananda was very concerned about having an openstack driv
Hi all!
We've had one release critical bug discovered in the past week, and so
today an RC2 candidate was published. A tarball of that is available
at:
https://launchpad.net/ironic/+milestone/juno-rc2
This fixed the following bug:
Hash ring is stale after new conductor added
https://bugs.la
As hopefully everyone is aware by now, the format of this summit will
be somewhat different from previous summits. Monday will be dedicated
to an Ops Summit, and Tuesday is dedicated to cross-project
discussions. Wednesday and Thursday are project-specific design
tracks, and on Friday projects have
Hi all,
I was reminded in the Ironic meeting today that the words "hardware
discovery" are overloaded and used in different ways by different
people. Since this is something we are going to talk about at the
summit (again), I'd like to start the discussion by building consensus
in the language tha
On Tue, Oct 21, 2014 at 11:26 AM, Adam Lawson wrote:
> I fully and wholeheartedly agree that inventory management is out of scope
> of Ironic. But I have a small suggestion:
>
> We'd do well as a community to adopt/evangelize an informal rule which I
> enforce at work (because I see this happen a
Chris,
All the best on your next adventure - you'll be missed here!
-Deva
On Wed, Oct 22, 2014 at 10:37 AM, Chris Behrens wrote:
> Hey all,
>
> Just wanted to drop a quick note to say that I decided to leave Rackspace to
> pursue another opportunity. My last day was last Friday. I won’t have m
On Wed Nov 12 2014 at 2:41:27 PM Chuck Carlino
wrote:
> Hi,
>
> I'm working on the neutron side of a couple of ironic issues, and I need
> some help. Here are the issues.
>
>1. If a nic on an ironic server fails and is replaced by a nic with a
>different mac address, neutron's dhcp serv
Lucas, Thanks for bringing this up (both in Paris and here). I'm strongly
in favor of these changes as well. We discussed this during the meeting
today [1], to which I offer the following summary:
- move the status reporting to the etherpad [2]
-- take one (1) minute at the start of the meeting fo
101 - 200 of 361 matches
Mail list logo
