Re: [openstack-dev] [Ironic] backwards compat issue with PXEDeply and AgentDeploy drivers

driver API or SDK or DDK or whatever we choose to call it . > Please see inline for my thoughts. > > On Tue, Oct 6, 2015 at 5:54 AM, Devananda van der Veen < > devananda@gmail.com> wrote: > >> tldr; the boot / deploy interface split we did broke an out of tree

Re: [openstack-dev] [ironic] Nominating two new core reviewers

++ on both counts! On Thu, Oct 8, 2015 at 2:47 PM, Jim Rollenhagen wrote: > Hi all, > > I've been thinking a lot about Ironic's core reviewer team and how we might > make it better. > > I'd like to grow the team more through trust and mentoring. We should be > able to promote someone to core bas

Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison

Thanks for all your contributions, Ghe! You've done a lot to help keep this project synced with the common libs -- of course, you're welcome back any time. Best Deva On Mon, May 25, 2015, 09:49 Ghe Rivero wrote: > My focus on the Ironic project has been decreasing in the last cycles, so > it's

[openstack-dev] [Ironic] no IRC meeting tonight

Some folks are still traveling (or recovering) from the summit, and today is a holiday in the US, so I'm cancelling tonight's meeting. There are many action items recorded in the etherpads - we'll have a lot to talk about next week! -Devananda _

Re: [openstack-dev] [Nova] Using depends-on for patches which require an approved spec

I think this will help because it separates the judgement of "is this code good enough to land" from the project and release coordination of "should this code land now". I've been floating the idea of separating +2 and +A powers for the same purpose: free up many of the technical reviewers from ha

[openstack-dev] [Ironic] [TC] Discussion: changing Ironic's release model

Hi all, tl;dr; At the summit, the Ironic team discussed the challenges we've had with the current release model and came up with some ideas to address them. I had a brief follow-up conversation with Doug and Thierry, but I'd like this to be discussed more openly and for us (the Ironic dev communi

[openstack-dev] [Ironic] Updates from the Summit

Hello! It's that time - hopefully everyone has recovered from the summit by now and is getting back in the swing of things. I'd like to take a little of everyone's time to summarize the main points we covered while in Vancouver (and record them here for folks who didn't make it, were in other ses

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On Jun 4, 2015 12:00 AM, "Xu, Hejie" wrote: > > Hi, guys, > > I’m working on adding Microversion into the API-WG’s guideline which make sure we have consistent Microversion behavior in the API for user. > The Nova and Ironic already have Microversion implementation, and as I know Magnum https://re

Re: [openstack-dev] [Ironic] When to bump the microversion?

On Jun 4, 2015 8:57 AM, "Monty Taylor" wrote: > > On 06/04/2015 11:27 AM, Dmitry Tantsur wrote: > > On 06/04/2015 05:03 PM, Sean Dague wrote: > >> On 06/04/2015 10:50 AM, Dmitry Tantsur wrote: > >>> On 06/04/2015 04:40 PM, Ruby Loo wrote: > Hi, > > In Kilo, we introduced microversio

Re: [openstack-dev] [Ironic] ENROLL state and changing node driver

On Jun 4, 2015 5:53 AM, "Dmitry Tantsur" wrote: > > Hi! > > While working on the enroll spec [1], I got a thinking: within the new state machine, when should we allow to change a node driver? > > My initial idea was to only allow driver change in ENROLL. Which sounds good to me, but then it will b

Re: [openstack-dev] [Ironic] When to bump the microversion?

On Jun 4, 2015 11:11 AM, "Chris Friesen" wrote: > > On 06/04/2015 10:14 AM, Devananda van der Veen wrote: >> >> >> On Jun 4, 2015 8:57 AM, "Monty Taylor" > >> > So, seriously - let's grow up and start telling people that they do n

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On Jun 5, 2015 4:36 AM, "Sean Dague" wrote: > > On 06/05/2015 01:28 AM, Adrian Otto wrote: > > > >> On Jun 4, 2015, at 11:03 AM, Devananda van der Veen > >> mailto:devananda@gmail.com>> wrote: > >> > >> > >> On

Re: [openstack-dev] [nova] How to microversion API code which is not in API layer

Yes. A new query parameter is a change in the contract, regardless of where the code change lies. -Deva On Jun 12, 2015 6:20 PM, "Chen CH Ji" wrote: > Hi > We have [1] in the db layer and it's directly used by API > layer , the filters is directly from client's input >

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On Wed, Jun 17, 2015 at 7:31 AM Jay Pipes wrote: > On 06/17/2015 06:30 AM, Lucas Alvares Gomes wrote: > >> overlap there rather than competition), how crazy does it sound if we > say > >> that for OpenStack Nova is the compute API and Ironic the Bare Metal > API and > >> so on? Would that be an u

Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic

Hi Jim, Your characterization of this is incomplete. These are not two equal projects proposing the same thing in different ways, and while I very much want to encourage collaboration, I value our community and feel that this was not done in the spirit of that community. To be clear: ironic-webcl

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

Almost all of our discussions so far on this topic have left something out, which Monty pointed out to me last week. I'm following up now because E_TRAVEL... tldr; What we're versioning here are API's, not packages. It's not a question of numbering and dependency ordering, but of communicating sup

Re: [openstack-dev] [Ironic] Proposal to add a new repository

Hi John, Thanks for the excellent summary! I found it very helpful to get caught up. I'd like to make sure I understand the direction ahc is going. A couple questions... I see that ahc is storing its information in swift. That's clever, but if Ironic provided a blob store for each node, would tha

Re: [openstack-dev] [Ironic] Proposal to add a new repository

I'm On Mon, Jun 22, 2015 at 8:19 AM John Trowbridge wrote: > > > On 06/22/2015 10:40 AM, Dmitry Tantsur wrote: > > On 06/22/2015 04:19 PM, Devananda van der Veen wrote: > >> Hi John, > >> > >> Thanks for the excellent summary! I found it very helpf

Re: [openstack-dev] [Ironic] Proposal to add a new repository

Oh - one more thing. If ahc-tools depends on data gathered by enovance/hardware, then I'm not sure it makes sense to import one to openstack/ without the other. -Deva On Mon, Jun 22, 2015 at 5:08 PM Devananda van der Veen < devananda@gmail.com> wrote: > I'm > On Mon, J

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

Sean's point and Dmitri's are similar. There are APIs for projects which do not have official team or "program" names. And some teams may produce more than one forward-facing service. Naming the API based in the team name doesn't make sense. My previous point is that restricting the API name to t

Re: [openstack-dev] [Ironic] Mid-Cycle Sprint

Event signup page is now live -- please RSVP! *https://www.eventbrite.com/e/openstack-ironic-sprint-august-2015-tickets-17533862254 * -Devananda On Thu, Jun 25, 2015 at 8:46 AM Stafford, John Richard wrote: >

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

Dmitry, Feature strings won't work. It only makes things more complex, without addressing the underlying issue. What happens when we change, even in a small way, the API surface exposed by an existing feature? How is that change exposed -- unless we include a version number along with your featur

Re: [openstack-dev] [all] A proposal to separate the design summit

On Mon, Feb 22, 2016 at 7:14 AM, Thierry Carrez wrote: > Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona > Thank you for the excellent write-up, Thierry (and everyone else behind it)! This sounds great to me. > Long long version: > > In a global and virtual community,

Re: [openstack-dev] [all] A proposal to separate the design summit

On Mon, Feb 22, 2016 at 11:51 AM, Walter A. Boring IV wrote: > On 02/22/2016 09:45 AM, Thierry Carrez wrote: > >> Amrith Kumar wrote: >> >>> [...] >>> As a result of this proposal, there will still be four events each year, >>> two "OpenStack Summit" events and two "MidCycle" events. >>> >> >> Ac

Re: [openstack-dev] [ironic] [tripleo] [stable] Phasing out old Ironic ramdisk and its gate jobs

Responding to your points out of order, since that makes more sense to me right now ... Since currently DIB claims to be backwards compatible, we just need to > leave master backwards compatible with Kilo and Liberty Ironic, which > means not deleting the bash ramdisk element. If Ironic wants to r

Re: [openstack-dev] [ironic] Nominating Julia Kreger for core reviewer

Very happy and welcoming +1 from me! On Thu, Mar 24, 2016 at 1:37 PM, Villalovos, John L < john.l.villalo...@intel.com> wrote: > +1 for me. Julia has been an awesome resource and person in the Ironic > community :) > > John > > -Original Message- > From: Jim Rollenhagen [mailto:j...@jimro

[openstack-dev] [Ironic] mid cycle etherpad

Hi folks! I've tossed up an etherpad for folks at (or not at) the mid cycle sprints to share ideas and such. This might seem last-minute (and it is). I don't have a specific agenda -- aside from what's on launchpad, what's on gerrit, and what's on your mind. Really, I'd like us to make progress t

Re: [openstack-dev] [Ironic] Stepping down from Ironic Core

Robert, Thank you for all your input and insight over the last two years. Our architectural discussions have been invaluable to me and helped shape Ironic into what it is today. All the best, Devananda On Tue Feb 24 2015 at 4:26:54 PM Robert Collins wrote: > Like with TripleO, I've not been pu

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

I know I'm arriving late to this thread, but I want to chime in with a resounding "yes!" to this approach. We've held to a fairly strict policy around maintaining compatibility within the driver API since early on, and we'll continue to do that as we add new interfaces (see the new ManagementInter

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

On Sun, Mar 1, 2015 at 8:45 AM, Clint Byrum wrote: > Excerpts from Gary Kotton's message of 2015-03-01 02:32:37 -0800: >> Hi, >> I am just relaying pain-points that we encountered in neutron. As I have >> said below it makes the development process a lot quicker for people >> working on external d

[openstack-dev] [Ironic] Thinking about our python client UX

Hi folks, Recently, I've been thinking more of how users of our python client will interact with the service, and in particular, how they might expect different instances of Ironic to behave. We added several extensions to the API this cycle, and along with that, also landed microversion support

[openstack-dev] [Ironic] proposing rameshg87 to ironic-core

Hi all, I'd like to propose adding Ramakrishnan (rameshg87) to ironic-core. He's been consistently providing good code reviews, and been in the top five active reviewers for the last 90 days and top 10 for the last 180 days. Two cores have recently approached me to let me know that they, too, fin

[openstack-dev] [Ironic] documenting our core review team policies

As the title says, I've gone ahead and written up our core review team policies, and posted it here: https://wiki.openstack.org/wiki/Ironic/CoreTeam Why now, you may ask? In the interests of full disclosure, we (the current ironic-core team) had a private discussion recently about adding a new m

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 12:12 PM Lauren Sell wrote: > Dissolving the integrated release without having a solid plan and > replacement is difficult to communicate to people who depend on OpenStack. > We’re struggling on that front. > > That said, I’m still optimistic about project structure reform

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 12:00 PM Jeremy Stanley wrote: > On 2015-03-10 14:42:18 -0400 (-0400), Russell Bryant wrote: > [...] > > As to specific tags, I refer back to this: > > > > http://governance.openstack.org/reference/incubation- > integration-requirements.html > > > > We worked pretty hard t

Re: [openstack-dev] [Ironic] proposing rameshg87 to ironic-core

all agree, why wait a week?), I'd like to officially welcome him to the core team. -Devananda On Tue, Mar 10, 2015 at 10:03 AM David Shrewsbury wrote: > +1 > > On Mar 9, 2015, at 6:03 PM, Devananda van der Veen < > devananda@gmail.com> wrote: > > Hi all, >

[openstack-dev] [Ironic][FFE] secure boot support in iLO drivers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, This feature [0] enables secure boot mode for hardware which supports UEFI. Ironic added support for UEFI in Juno. This is an incremental improvement, allowing those users to benefit more from their hardware's security features. After this morni

Re: [openstack-dev] [Ironic][FFE] secure boot support in iLO drivers

woops! thanks... -Devananda On Thu, Mar 19, 2015 at 10:04 AM, Ramakrishnan G wrote: > > Corrected [1] is below (link for pxe_ilo patch review): > > [1] https://review.openstack.org/#/c/154808/ > > On Thu, Mar 19, 2015 at 10:24 PM, Devananda van der Veen > wrote: >&g

Re: [openstack-dev] [Ironic] [RFC/FFE] Finishing state machine work for Kilo

Hi! The situation you describe is the same that concerned me with regards to stable/juno compatibility. As soon as the client library started passing a version header by default, it exposed Kilo changes to all users. Anyone testing from trunk would have experienced that when 99ab landed. I ju

[openstack-dev] [Ironic] PTL Candidacy

Hi all, I'd like to announce my candidacy as PTL for Ironic for the Liberty cycle. I've been involved in OpenStack since the Essex cycle, and have served as PTL for Ironic since I started the project at the Havana summit. As the project has matured, my day-to-day activity within the project has ch

Re: [openstack-dev] [all] Kilo stable branches for "other" libraries

Thierry, You left out python-ironicclient, which isn't a surprise as it isn't actually listed in Nova's requirements.txt file. I don't have a link handy to cite the previous discussions, but Nova felt that it was not appropriate to list a driver's dependency in their project's requirements file.

Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools

On Wed, Apr 8, 2015 at 7:38 AM Chris Friesen wrote: > On 04/07/2015 11:35 PM, Michael Davies wrote: > > I agree with Jim R's suggestion - it's really up to the consumer as to > what they > > want to do. Having said that... > > > > I think that any consumer wants to use the latest version of the

Re: [openstack-dev] [Ironic] ironic-specs open for Liberty!

Jay, Thanks for staying on top of updating & opening Liberty specs, and for all your help with specs during Kilo! -Deva On Fri, Apr 10, 2015 at 10:40 AM Jay Faulkner wrote: > Hi, > > Just a note to let you know Liberty specs are open for Ironic. > > Template Changes > > There are two

Re: [openstack-dev] [tripleo] [ironic] Where to keep discover images

I'm wondering Rather than have a static config, could the DiscoverdInspect interface handle setting up the TFTP config, pulling those images from Glance, etc, when a node is moved into the "inspect" state (assuming such integration was desired by the cloud operator)? -Deva On Fri, Apr 10, 201

Re: [openstack-dev] [tripleo] [ironic] Where to keep discover images

ting. > Anyway, nice idea for an improvement! > > Dmitry > > > 2015-04-14 22:27 GMT+02:00 Devananda van der Veen : >> >> I'm wondering Rather than have a static config, could the >> DiscoverdInspect interface handle setting up the TFTP config, pulling &g

[openstack-dev] TC Non-Candidacy

Hi all, I would like to announce my non-candidacy for the TC this term. To be clear, I'm not running for a seat on the TC right now, but I hope you will read this anyway. Background = I ran for a seat on the Technical Committee twelve months ago, on a platform that consisted of two poin

Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side

FWIW, we enumerated the use-cases and expected behavior for all combinations of server [pre versions, older version, newer version] and client [pre versions, older version, newer version, user-specified version], in this "informational" spec: http://specs.openstack.org/openstack/ironic-specs/specs

[openstack-dev] [Ironic] how about those alternating meeting times?

At the Paris summit, we discussed and eventually agreed to try out alternating meeting times. So, for the last ~6mo, each week our IRC meeting has alternated between Monday evening and Tuesday morning UTC (10am PT and 10pm PT Mondays). I'd like us to review how well this has - or has not - worked,

Re: [openstack-dev] [Ironic] how about those alternating meeting times?

sday: 9 Total lines in IRC during the meetings by day: Monday: 3793 Tuesday: 2475 Unique attendees per day: Monday: total: 54 - cores: 9 Tuesday: total: 32 - cores: 5 On Mon, May 11, 2015 at 10:21 AM Devananda van der Veen < devananda@gmail.com> wrote: > At the P

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

In ironic, we have use asciiflow several times quite successfully in the spec process. We also maintain in-tree docs with .PNG graphics, and versioning those has been a bit of a pain. They were originally taken out of slide decks, and served their purpose, but really ought to be in a different for

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

Woops. I missed most of this thread in my last reply. I'm all for using open standard formats and versioning them. However. Not being a graphical artist myself, I have found the learning curve on some of those tools daunting, eg. inkscape, which means I'm far less likely to update a graphic in a f

Re: [openstack-dev] [ironic] why do we need setting network driver per node?

We spent the majority of today's weekly IRC meeting [1] discussing the finer points of this question. I agreed to post a summary of those to the list (it's below the break). tldr; * we don't know if network_interface should behave like other hardware interfaces, but... * we need to come to an agr

Re: [openstack-dev] [ironic] [nova] [neutron] get_all_bw_counters in the Ironic virt driver

On 07/28/2016 05:40 PM, Brad Morgan wrote: > I'd like to solicit some advice about potentially implementing > get_all_bw_counters() in the Ironic virt driver. > > https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L438 > Example Implementation: > https://github.com/openstack/nova/

Re: [openstack-dev] [ironic] network_interface, defaults, and explicitness

On 08/01/2016 05:10 AM, Jim Rollenhagen wrote: > Hey all, > > Our nova patch for networking[0] got stuck for a bit, because Nova needs > to know which network interface is in use for the node, in order to > properly set up the port. > > The code landed for network_interface follows the following

[openstack-dev] [Ironic] v2 API - request for feedback on "problem description"

Hi all, Today's ironic-v2-api meeting was pretty empty, so I am posting a summary of our subteam's activity here. I have taken the midcycle notes about our API's current pain points / usability gaps, and written them up into the format we would use for a spec's "Problem Description", and posted t

Re: [openstack-dev] [ironic] static Portgroup support.

On 08/09/2016 01:28 AM, Vasyl Saienko wrote: > Hello Ironic'ers! > > We've recorded a demo that shows how static portgroup works at the moment: > > Flat network scenario: https://youtu.be/vBlH0ie6Lm4 > Multitenant network scenario: https://youtu.be/Kk5Cc_K1tV8 Awesome! Thank you for creating & s

Re: [openstack-dev] [ironic] Driver composition defaults call

On 08/11/2016 10:37 AM, Julia Kreger wrote: > Yesterday as a group (jroll, rloo, dtantsur, matt128, devananda, > vdrok, and myself) discussed defaults for driver composition. > > The options we discussed were: > > * The existing specification[0] - Global and hardware_type > default_FOO_interfac

Re: [openstack-dev] [ironic] Driver removal policies - should we make it softer?

I like this approach more than the current "you're in or you're out". +1 --deva On Mon, Aug 22, 2016 at 7:02 AM Vladyslav Drok wrote: > +1 from me then :) > > On Mon, Aug 22, 2016 at 4:52 PM, Jim Rollenhagen > wrote: > >> On Mon, Aug 22, 2016 at 8:01 AM, Vladyslav Drok >> wrote: >> > On Fri,

Re: [openstack-dev] [ironic] Next API meeting cancelled

Considering I'm the only one currently working on it / bringing up new topics, I think biweekly is a better match to the pace I'm working on this. However, I hope that changes after the summit / once we start implementing these changes. --d On 09/22/2016 08:38 AM, Jim Rollenhagen wrote: > We dec

Re: [openstack-dev] [ironic] [infra] RFC: consolidating and extending Ironic CI jobs

On 10/12/2016 05:01 AM, Dmitry Tantsur wrote: > Hi folks! > > I'd like to propose a plan on how to simultaneously extend the coverage of our > jobs and reduce their number. > > Currently, we're running one instance per job. This was reasonable when the > coreos-based IPA image was the default,

[openstack-dev] [ironic] [API] Evolving our REST API

Hi all, We discussed a little at the last summit, and discussed further at the midcycle [1], about how we might go about remedying some of the frustrations and missing functionality in our API, and I volunteered to work on it during the Newton cycle. As I looked at all of the feedback we collect

<    1   2   3   4