[openstack-dev] [ironic] Meetings cancelled this and next week - resumes November 26th

[Julia Kreger]

Greetings everyone!

We're cancelling this week's meeting and next week's meeting due to the
OpenStack Summit and US holidays the following week where some of our core
reviewers will also be on vacation.

If there are any questions, please feel to ask in #openstack-ironic.

See  you all in IRC.

-Julia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] FIPS Compliance

[Julia Kreger]

On Tue, Nov 6, 2018 at 9:19 AM Joshua Cornutt  wrote:

>
> Another approach would be to make the projects "FIPS aware" where we
> choose the hashing algorithm based on the system's FIPS-enforcing
> state. An example of doing so is what I'm proposing for Django
> (another FIPS-related patch that was needed for OSP 13) -
> https://github.com/django/django/pull/10605
>
>
This was the approach I was thinking. We ideally should allow and enable
evolution, but we would still need the hard "FIPS 140-2" operating mode
flag which would be a hard break for pre-existing clouds whose data and
checksum information had not been updated already. Maybe in any process to
collect community impact information, we could also suggest projects submit
what they perceive an upgrade path to be to take an existing cloud to a
FIPS 140-2 enforcing mode of operation.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] 2019 summit during May holidays?

[Julia Kreger]

On Mon, Nov 5, 2018 at 12:50 PM Dmitry Tantsur  wrote:

>
>
> On Mon, Nov 5, 2018, 20:07 Julia Kreger  wrote:
>
>> *removes all of the hats*
>>
>> *removes years of dust from unrelated event planning hat, and puts it on
>> for a moment*
>>
>> In my experience, events of any nature where convention venue space is
>> involved, are essentially set in stone before being publicly advertised as
>> contracts are put in place for hotel room booking blocks as well as the
>> convention venue space. These spaces are also typically in a relatively
>> high demand limiting the access and available times to schedule. Often
>> venues also give preference (and sometimes even better group discounts) to
>> repeat events as they are typically a known entity and will have somewhat
>> known needs so the venue and hotel(s) can staff appropriately.
>>
>> tl;dr, I personally wouldn't expect any changes to be possible at this
>> point.
>>
>> *removes event planning hat of past life, puts personal scheduling hat on*
>>
>> I imagine that as a community, it is near impossible to schedule
>> something avoiding holidays for everyone in the community.
>>
>
> I'm not taking about everyone. And I'm mostly fine with my holiday, but
> the conflicts with Russia and Japan seem huge. This certainly does not help
> our effort to engage people outside of NA/EU.
>
> Quick googling suggests that the week of May 13th would have much fewer
> conflicts.
>
>
May is also a fairly popular month for weddings... and I've seen wedding
parties book out whole floors of hotel rooms. This complicates room block
negotiations sadly.


>
>> I personally have lost count of the number of holidays and special days
>> that I've spent on business trips over the past four years. While I may be
>> an out-lier in my feelings on this subject, I'm not upset, annoyed, or even
>> bitter about lost times. This community is part of my family.
>>
>
> Sure :)
>
> But outside of our small nice circle there is a huge world of people who
> may not share our feeling and the level of commitment to openstack. These
> occasional contributors we talked about when discussing the cycle length. I
> don't think asking them to abandon 3-5 days of holidays is a productive way
> to engage them.
>
> And again, as much as I love meeting you all, I think we're outgrowing the
> format of these meetings..
>
> Dmitry
>
>
It is funny you mention this because I was wondering something similar, but
possibly for different reasons. I get there needs to be a marketing aspect
to aid in sales and visibility. We need to also work on our local
visibilities and broadcast out what individual projects and the community
is doing on a smaller, more local scale... but I feel very conflicted with
air travel and the state of atmospheric carbon levels.

I wouldn't call my perception outgrowing, but perhaps growing more
ecologically sensitive.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Asking for suggestion of video conference tool for team and webinar

[Julia Kreger]

I don't know how the cost structure works for Bluejeans, but I've found it
works very well for calls with many people on video. I typically have calls
with 14+ people nearly everyone has their video enabled without a problem.
The limiting factor is really if one participant has limited or somewhat
lossy connectivity, but it appears they have been working to make that
experience better.

-Julia

On Tue, Nov 6, 2018 at 5:36 AM Trinh Nguyen  wrote:

> Hi,
>
> I tried several free tools for team meetings, vPTG, and webinars but there
> are always drawbacks ( because it's free, of course). For example:
>
>- Google Hangout: only allow a maximum of 10 people to do the video
>calls
>- Zoom: limits about 45m per meeting. So for a webinar or conference
>call takes more than 45m we have to splits into 2 sessions or so.
>
> If anyone in the community can suggest some better video conferencing
> tools, that would be great. So we can organize better communication for our
> team and the community's webinars.
>
> Many thanks,
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz *
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] FIPS Compliance

[Julia Kreger]

On Tue, Nov 6, 2018 at 5:07 AM Doug Hellmann  wrote:

> Sean McGinnis  writes:
>
> > I'm interested in some feedback from the community, particularly those
> running
> > OpenStack deployments, as to whether FIPS compliance [0][1] is something
> folks
> > are looking for.
> [trim]
>
> I know we've had some interest in it at different times. I think some of
> the changes will end up being backwards-incompatible, so we may need a
> "FIPS-mode" configuration flag for those, but in other places we could
> just switch hashing algorithms and be fine.
>
> I'm not sure if anyone has put together the details of what would be
> needed to update each project, but this feels like it could be a
> candidate for a goal for a future cycle once we have that information
> and can assess the level of effort.
>
> Doug
>
>
+1 to a FIPS-mode. I think it would be fair to ask projects, to over the
course of the next month or three, to evaluate their current standing and
report what they perceive the effort to be.

I think only then we can really determine if it is the right direction to
take for a cycle goal.

-Julia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] 2019 summit during May holidays?

[Julia Kreger]

*removes all of the hats*

*removes years of dust from unrelated event planning hat, and puts it on
for a moment*

In my experience, events of any nature where convention venue space is
involved, are essentially set in stone before being publicly advertised as
contracts are put in place for hotel room booking blocks as well as the
convention venue space. These spaces are also typically in a relatively
high demand limiting the access and available times to schedule. Often
venues also give preference (and sometimes even better group discounts) to
repeat events as they are typically a known entity and will have somewhat
known needs so the venue and hotel(s) can staff appropriately.

tl;dr, I personally wouldn't expect any changes to be possible at this
point.

*removes event planning hat of past life, puts personal scheduling hat on*

I imagine that as a community, it is near impossible to schedule something
avoiding holidays for everyone in the community.

I personally have lost count of the number of holidays and special days
that I've spent on business trips over the past four years. While I may be
an out-lier in my feelings on this subject, I'm not upset, annoyed, or even
bitter about lost times. This community is part of my family.

-Julia

On Mon, Nov 5, 2018 at 8:19 AM Dmitry Tantsur  wrote:

> Hi all,
>
> Not sure how official the information about the next summit is, but it's
> on the
> web site [1], so I guess worth asking..
>
> Are we planning for the summit to overlap with the May holidays? The 1st
> of May
> is a holiday in big part of the world. We ask people to skip it in
> addition to
> 3+ weekend days they'll have to spend working and traveling.
>
> To make it worse, 1-3 May are holidays in Russia this time. To make it
> even
> worse than worse, the week of 29th is the Golden Week in Japan [2]. Was it
> considered? Is it possible to move the days to less conflicting time
> (mid-May
> maybe)?
>
> Dmitry
>
> [1] https://www.openstack.org/summit/denver-2019/
> [2] https://en.wikipedia.org/wiki/Golden_Week_(Japan)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Ironic integration CI jobs

[Julia Kreger]

On Wed, Oct 31, 2018 at 7:38 AM Dmitry Tantsur  wrote:


> [trim]
>


> > Ditto, grenade jobs do not cover our tests at all. Also this is the
> very job we
> > run on other projects (nova, neutron, maybe more), so it will be a
> bit painful
> > to remove it.
> >
> >
> > We run the basic baremetal ops test, which tests deploy. If we're
> already
> > covering the same code paths in other tests (which I feel we are), then
> the test
> > feels redundant to me. I'm not worried about the effort to change the
> job in
> > other gates. We really need to pull agent_ipmitool out of the name if we
> keep it
> > anyway... which still means going through zuul configs.
>
> Do not smoke tests cover rescue with bare metal? Because our jobs do.
>
>
Smoke tests do not as far as I can tell, but I believe we run rescue by
default when our test scenarios execute on our other tempest executing jobs
as well as it is a superset of the main scenario.
Random example testr results:
http://logs.openstack.org/72/614472/1/check/ironic-tempest-dsvm-ipa-partition-redfish-tinyipa/7537b02/testr_results.html.gz
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Ironic integration CI jobs

[Julia Kreger]

On Wed, Oct 31, 2018 at 5:44 AM Dmitry Tantsur  wrote:

> Hi,
>
> On 10/31/18 1:36 AM, Julia Kreger wrote:
> [trim]
> >
> > ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode -
> This job is
> > essentially the same as our grenade mutlinode job, the only difference
> being
> > grenade.
>
> Nope, not the same. Grenade jobs run only smoke tests, this job runs
>
> https://github.com/openstack/ironic-tempest-plugin/blob/master/ironic_tempest_plugin/tests/scenario/test_baremetal_multitenancy.py
>

Ugh, Looking closer, we still end up deploying when the smoke tests run. It
feels like the only real difference between what is being exercised is that
one our explicit test scenario of putting two instances on two separate
networks and validating connectivity is not present between the two. I
guess I'm failing to see why we need all of the setup and infrastructure
when we're just testing pluggable network bits and settings their upon.
Maybe it is a good cantidate for looking at evolving how we handle scenario
testing so we reduce our gate load and resulting wait for test results.

> ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa - This job
> > essentially just duplicates the functionality already covered in other
> jobs,
> > including the grenade job.
>
> Ditto, grenade jobs do not cover our tests at all. Also this is the very
> job we
> run on other projects (nova, neutron, maybe more), so it will be a bit
> painful
> to remove it.
>

We run the basic baremetal ops test, which tests deploy. If we're already
covering the same code paths in other tests (which I feel we are), then the
test feels redundant to me. I'm not worried about the effort to change the
job in other gates. We really need to pull agent_ipmitool out of the name
if we keep it anyway... which still means going through zuul configs.

> [trim]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Ironic integration CI jobs

[Julia Kreger]

With the discussion of CI jobs and the fact that I have been finding myself
checking job status several times a day so early in the cycle, I think it
is time for ironic to revisit many of our CI jobs.

The bottom line is ironic is very resource intensive to test. A lot of that
is because of the underlying way we enroll/manage nodes and then execute
the integration scenarios emulating bare metal. I think we can improve that
with some ansible.

In the mean time I created a quick chart[1] to try and make sense out
overall integration coverage and I think it makes sense to remove three of
the jobs.

ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode - This
job is essentially the same as our grenade mutlinode job, the only
difference being grenade.
ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa - This job
essentially just duplicates the functionality already covered in other
jobs, including the grenade job.
ironic-tempest-dsvm-bfv - This presently non-voting job validates that the
iPXE mode of the 'pxe' boot interface supports boot from volume. It was
superseded by ironic-tempest-dsvm-ipxe-bfv which focuses on the use of the
'ipxe' boot interface. The underlying code is all the same deep down in all
of the helper methods.

I'll go ahead and put this up as a topic for our weekly meeting next week
so we can discuss.

Thanks,

-Julia

[1]: https://ethercalc.openstack.org/ces0z3xjb1ir
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-community] Forum Schedule - Seeking Community Review

[Julia Kreger]

Looks Great, Thanks!

-Julia

PS - Indeed :(

On Tue, Oct 16, 2018 at 4:05 PM Jimmy McArthur  wrote:

> OK - I think I got this fixed.  I had to move a couple of things around.
> Julia, please let me know if this all works for you:
>
>
> https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=Kreger
>
> PS - You're going to have a long week :|
>
> Julia Kreger 
> October 16, 2018 at 4:44 PM
> Greetings Jimmy,
>
> Looks like it is still showing up on the schedule that way. I just
> reloaded the website page and it still has both sessions scheduled for 4:20
> PM local. Sadly, I don't have cloning technology. Perhaps someone can help
> me with that for next year? :)
>
> -Julia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Jimmy McArthur 
> October 16, 2018 at 12:15 PM
> I think you might have caught me while I was moving sessions around.  This
> shouldn't be an issue now.
>
> Thanks for checking!!
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Tim Bell 
> October 16, 2018 at 1:37 AM
> Jimmy,
>
> While it's not a clash within the forum, there are two sessions for Ironic
> scheduled at the same time on Tuesday at 14h20, each of which has Julia as
> a speaker.
>
> Tim
>
> -Original Message-
> From: Jimmy McArthur  
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  
> Date: Monday, 15 October 2018 at 22:04
> To: "OpenStack Development Mailing List (not for usage questions)"
>  ,
> "openstack-operat...@lists.openstack.org"
> 
> 
> , "commun...@lists.openstack.org"
>  
> 
> Subject: [openstack-dev] Forum Schedule - Seeking Community Review
>
> Hi -
>
> The Forum schedule is now up
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
>
> If you see a glaring content conflict within the Forum itself, please
> let me know.
>
> You can also view the Full Schedule in the attached PDF if that makes
> life easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule. No need to let
> us know :)
>
> Cheers,
> Jimmy
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Jimmy McArthur 
> October 15, 2018 at 3:01 PM
> Hi -
>
> The Forum schedule is now up (
> https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
> If you see a glaring content conflict within the Forum itself, please let
> me know.
>
> You can also view the Full Schedule in the attached PDF if that makes life
> easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule.  No need to let
> us know :)
>
> Cheers,
> Jimmy
> ___
> Staff mailing list
> st...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/staff
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-community] Forum Schedule - Seeking Community Review

[Julia Kreger]

Greetings Jimmy,

Looks like it is still showing up on the schedule that way. I just reloaded
the website page and it still has both sessions scheduled for 4:20 PM
local. Sadly, I don't have cloning technology. Perhaps someone can help me
with that for next year? :)

-Julia


On Tue, Oct 16, 2018 at 11:15 AM Jimmy McArthur  wrote:

> I think you might have caught me while I was moving sessions around.  This
> shouldn't be an issue now.
>
> Thanks for checking!!
>
> Tim Bell 
> October 16, 2018 at 1:37 AM
> Jimmy,
>
> While it's not a clash within the forum, there are two sessions for Ironic
> scheduled at the same time on Tuesday at 14h20, each of which has Julia as
> a speaker.
>
> Tim
>
> -Original Message-
> From: Jimmy McArthur  
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  
> Date: Monday, 15 October 2018 at 22:04
> To: "OpenStack Development Mailing List (not for usage questions)"
>  ,
> "openstack-operat...@lists.openstack.org"
> 
> 
> , "commun...@lists.openstack.org"
>  
> 
> Subject: [openstack-dev] Forum Schedule - Seeking Community Review
>
> Hi -
>
> The Forum schedule is now up
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
>
> If you see a glaring content conflict within the Forum itself, please
> let me know.
>
> You can also view the Full Schedule in the attached PDF if that makes
> life easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule. No need to let
> us know :)
>
> Cheers,
> Jimmy
>
>
> ___
> Community mailing list
> commun...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/community
> Jimmy McArthur 
> October 15, 2018 at 3:01 PM
> Hi -
>
> The Forum schedule is now up (
> https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
> If you see a glaring content conflict within the Forum itself, please let
> me know.
>
> You can also view the Full Schedule in the attached PDF if that makes life
> easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule.  No need to let
> us know :)
>
> Cheers,
> Jimmy
> ___
> Staff mailing list
> st...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/staff
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] assigning new liaisons to projects

[Julia Kreger]

On Mon, Oct 8, 2018 at 8:27 AM Doug Hellmann  wrote:

> TC members,
>
> Since we are starting a new term, and have several new members, we need
> to decide how we want to rotate the liaisons attached to each our
> project teams, SIGs, and working groups [1].
>
> Last term we went through a period of volunteer sign-up and then I
> randomly assigned folks to slots to fill out the roster evenly. During
> the retrospective we talked a bit about how to ensure we had an
> objective perspective for each team by not having PTLs sign up for their
> own teams, but I don't think we settled on that as a hard rule.
>
> I think the easiest and fairest (to new members) way to manage the list
> will be to wipe it and follow the same process we did last time. If you
> agree, I will update the page this week and we can start collecting
> volunteers over the next week or so.
>
> Doug
>
> [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
>
>
>
+1, Sounds good. I would just ask that if a TC is member has any
expectation on another member to post  a status update, that they
explicitly reach out and convey that expectation so we minimize confusion.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] bringing back formal TC meetings

[Julia Kreger]

+1 to bringing back formal meetings. A few replies below regarding
time/agenda.

On Fri, Oct 5, 2018 at 5:38 AM Doug Hellmann  wrote:

> Thierry Carrez  writes:
>
> > Ghanshyam Mann wrote:
> >>    On Fri, 05 Oct 2018 02:47:53 +0900 Jeremy Stanley <
> fu...@yuggoth.org> wrote 
> >>   > On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote:
> >>   > [...]
> >>   > > TC members, please reply to this thread and indicate if you would
> >>   > > find meeting at 1300 UTC on the first Thursday of every month
> >>   > > acceptable, and of course include any other comments you might
> >>   > > have (including alternate times).
> >>   >
> >>   > This time is acceptable to me. As long as we ensure that community
> >>   > feedback continues more frequently in IRC and on the ML (for example
> >>   > by making it clear that this meeting is expressly *not* for that)
> >>   > then I'm fine with resuming formal meetings.
> >>
> >> +1. Time works fine for me, Thanks for considering the APAC TZ.
> >>
> >> I agree that we should keep encouraging the  usual discussion in
> existing office hours, IRC or ML. I will be definitely able to attend other
> 2 office hours (Tuesday  and Wednesday) which are suitable for my TZ.
> >
> > 1300 UTC is obviously good for me, but once we are off DST that will
> > mean 5am for our Pacific Time people (do we have any left ?).
> >
> > Maybe 1400 UTC would be a better trade-off?
>
> Julia is out west, but I think not all the way to PST.
>

My home time zone is PST. It would be awesome if we could hold the meeting
an hour later, but I can get up early in the morning once a month. If we
choose to meet more regularly, then a one hour later start would be more
appreciated if it is not too much of an inconvenience to APAC TC members.
That being said, I do typically get up early, just not 0500 early that
often.


>
> > Regarding frequency, I agree with mnaser that once per month might be
> > too rare. That means only 5-ish meetings for a given a 6-month
> > membership. But that can work if we use the meeting as a formal progress
> > status checkpoint, rather than a way to discuss complex topics.
>
> I think we can definitely manage the agenda to minimize the number of
> complex discussions. If that proves to be too hard, I wouldn't mind
> meeting more often, but there does seem to be a lot of support for
> preferring other venues for those conversations.
>
>
+1 I think there is a point where we need to recognize there is a time and
place for everything, and some of those long running complex conversations
might not be well suited for what would essentially be "review business
status" meetings.  If we have any clue that something is going to be a very
long and drawn out discussion, then I feel like we should make an effort to
schedule individually.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Tenks

[Julia Kreger]

On Wed, Oct 3, 2018 at 9:17 AM Mark Goddard  wrote:

>
>
> On Wed, 3 Oct 2018 at 17:10, James LaBarre  wrote:
>
>> On 10/2/18 10:37 AM, Mark Goddard wrote:
>>
>>
>>
>> On Tue, 2 Oct 2018 at 14:03, Jay Pipes  wrote:
>>
>>> On 10/02/2018 08:58 AM, Mark Goddard wrote:
>>> > Tenks is a project for managing 'virtual bare metal clusters'. It aims
>>> > to be a drop-in replacement for the various scripts and templates that
>>> > exist in the Ironic devstack plugin for creating VMs to act as bare
>>> > metal nodes in development and test environments. Similar code exists
>>> in
>>> > Bifrost and TripleO, and probably other places too. By focusing on one
>>> > project, we can ensure that it works well, and provides all the
>>> features
>>> > necessary as support for bare metal in the cloud evolves.
>>>
>>> How does Tenks relate to OVB?
>>>
>>>
>>> https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html
>>
>>
>> Good question. As far as I'm aware, OVB is a tool for using an OpenStack
>> cloud to host the virtual bare metal nodes, and is typically used for
>> testing TripleO. Tenks does not rule out supporting this use case in
>> future, but currently operates more like the Ironic devstack plugin, using
>> libvirt/KVM/QEMU as the virtualisation provider.
>>
>>
>> I'm presuming, as Tenks is supposed to support multiple hypervisors, that
>> a multi-arch environment would be supported (different node types on
>> different architectures).  Or does this even enter into the consideration?
>>
>
> I think that would be a good feature to consider in future, although it's
> not something that works currently.
>

I think it would be a very important thing to have as we branch out into
different architectures. I would personally love to see an ARM64 CI job. To
actually put that job in place would mean major changes to VM creation
which would be beneficial to put in one place. Long story short, I'm all
for additional spoons.

> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

[Julia Kreger]

On Mon, Oct 1, 2018 at 3:37 PM Jay Pipes  wrote:

> On 10/01/2018 06:04 PM, Julia Kreger wrote:
> > On Mon, Oct 1, 2018 at 2:41 PM Eric Fried  wrote:
> >
> >
> >  > So say the user requests a node that supports UEFI because their
> > image
> >  > needs UEFI. Which workflow would you want here?
> >  >
> >  > 1) The operator (or ironic?) has already configured the node to
> > boot in
> >  > UEFI mode. Only pre-configured nodes advertise the "supports
> > UEFI" trait.
> >  >
> >  > 2) Any node that supports UEFI mode advertises the trait. Ironic
> > ensures
> >  > that UEFI mode is enabled before provisioning the machine.
> >  >
> >  > I imagine doing #2 by passing the traits which were specifically
> >  > requested by the user, from Nova to Ironic, so that Ironic can do
> the
> >  > right thing for the user.
> >  >
> >  > Your proposal suggests that the user request the "supports UEFI"
> > trait,
> >  > and *also* pass some glance UUID which the user understands will
> make
> >  > sure the node actually boots in UEFI mode. Something like:
> >  >
> >  > openstack server create --flavor METAL_12CPU_128G --trait
> > SUPPORTS_UEFI
> >  > --config-data $TURN_ON_UEFI_UUID
> >  >
> >  > Note that I pass --trait because I hope that will one day be
> > supported
> >  > and we can slow down the flavor explosion.
> >
> > IMO --trait would be making things worse (but see below). I think
> UEFI
> > with Jay's model would be more like:
> >
> >openstack server create --flavor METAL_12CPU_128G --config-data
> $UEFI
> >
> > where the UEFI profile would be pretty trivial, consisting of
> > placement.traits.required = ["BOOT_MODE_UEFI"] and object.boot_mode =
> > "uefi".
> >
> > I agree that this seems kind of heavy, and that it would be nice to
> be
> > able to say "boot mode is UEFI" just once. OTOH I get Jay's point
> that
> > we need to separate the placement decision from the instance
> > configuration.
> >
> > That said, what if it was:
> >
> >   openstack config-profile create --name BOOT_MODE_UEFI --json -
> >   {
> >"type": "boot_mode_scheme",
> >"version": 123,
> >"object": {
> >"boot_mode": "uefi"
> >},
> >"placement": {
> > "traits": {
> >  "required": [
> >   "BOOT_MODE_UEFI"
> >  ]
> > }
> >}
> >   }
> >   ^D
> >
> > And now you could in fact say
> >
> >   openstack server create --flavor foo --config-profile
> BOOT_MODE_UEFI
> >
> > using the profile name, which happens to be the same as the trait
> name
> > because you made it so. Does that satisfy the yen for saying it
> once? (I
> > mean, despite the fact that you first had to say it three times to
> get
> > it set up.)
> >
> > 
> >
> > I do want to zoom out a bit and point out that we're talking about
> > implementing a new framework of substantial size and impact when the
> > original proposal - using the trait for both - would just work out of
> > the box today with no changes in either API. Is it really worth it?
> >
> >
> > +1000. Reading both of these threads, it feels like we're basically
> > trying to make something perfect. I think that is a fine goal, except it
> > is unrealistic because the enemy of good is perfection.
> >
> > 
> >
> > By the way, with Jim's --trait suggestion, this:
> >
> >  > ...dozens of flavors that look like this:
> >  > - 12CPU_128G_RAID10_DRIVE_LAYOUT_X
> >  > - 12CPU_128G_RAID5_DRIVE_LAYOUT_X
> >  > - 12CPU_128G_RAID01_DRIVE_LAYOUT_X
> >  > - 12CPU_128G_RAID10_DRIVE_LAYOUT_Y
> >  > - 12CPU_128G_RAID5_DRIVE_LAYOUT_Y
> >  > - 12CPU_128G_RAID01_DRIVE_LAYOUT_Y
> >
> > ...could actually become:
> >
> >   openstack server create --flavor 12CPU_128G --trait $WHICH_RAID
> > --trait
> > $WHICH_LAYOUT
> >
> > No flavor explosion.
> >
> >
> 

Re: [openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

[Julia Kreger]

On Mon, Oct 1, 2018 at 2:41 PM Eric Fried  wrote:

>
> > So say the user requests a node that supports UEFI because their image
> > needs UEFI. Which workflow would you want here?
> >
> > 1) The operator (or ironic?) has already configured the node to boot in
> > UEFI mode. Only pre-configured nodes advertise the "supports UEFI" trait.
> >
> > 2) Any node that supports UEFI mode advertises the trait. Ironic ensures
> > that UEFI mode is enabled before provisioning the machine.
> >
> > I imagine doing #2 by passing the traits which were specifically
> > requested by the user, from Nova to Ironic, so that Ironic can do the
> > right thing for the user.
> >
> > Your proposal suggests that the user request the "supports UEFI" trait,
> > and *also* pass some glance UUID which the user understands will make
> > sure the node actually boots in UEFI mode. Something like:
> >
> > openstack server create --flavor METAL_12CPU_128G --trait SUPPORTS_UEFI
> > --config-data $TURN_ON_UEFI_UUID
> >
> > Note that I pass --trait because I hope that will one day be supported
> > and we can slow down the flavor explosion.
>
> IMO --trait would be making things worse (but see below). I think UEFI
> with Jay's model would be more like:
>
>   openstack server create --flavor METAL_12CPU_128G --config-data $UEFI
>
> where the UEFI profile would be pretty trivial, consisting of
> placement.traits.required = ["BOOT_MODE_UEFI"] and object.boot_mode =
> "uefi".
>
> I agree that this seems kind of heavy, and that it would be nice to be
> able to say "boot mode is UEFI" just once. OTOH I get Jay's point that
> we need to separate the placement decision from the instance configuration.
>
> That said, what if it was:
>
>  openstack config-profile create --name BOOT_MODE_UEFI --json -
>  {
>   "type": "boot_mode_scheme",
>   "version": 123,
>   "object": {
>   "boot_mode": "uefi"
>   },
>   "placement": {
>"traits": {
> "required": [
>  "BOOT_MODE_UEFI"
> ]
>}
>   }
>  }
>  ^D
>
> And now you could in fact say
>
>  openstack server create --flavor foo --config-profile BOOT_MODE_UEFI
>
> using the profile name, which happens to be the same as the trait name
> because you made it so. Does that satisfy the yen for saying it once? (I
> mean, despite the fact that you first had to say it three times to get
> it set up.)
>
> 
>
> I do want to zoom out a bit and point out that we're talking about
> implementing a new framework of substantial size and impact when the
> original proposal - using the trait for both - would just work out of
> the box today with no changes in either API. Is it really worth it?
>
>
+1000. Reading both of these threads, it feels like we're basically trying
to make something perfect. I think that is a fine goal, except it is
unrealistic because the enemy of good is perfection.


>
> By the way, with Jim's --trait suggestion, this:
>
> > ...dozens of flavors that look like this:
> > - 12CPU_128G_RAID10_DRIVE_LAYOUT_X
> > - 12CPU_128G_RAID5_DRIVE_LAYOUT_X
> > - 12CPU_128G_RAID01_DRIVE_LAYOUT_X
> > - 12CPU_128G_RAID10_DRIVE_LAYOUT_Y
> > - 12CPU_128G_RAID5_DRIVE_LAYOUT_Y
> > - 12CPU_128G_RAID01_DRIVE_LAYOUT_Y
>
> ...could actually become:
>
>  openstack server create --flavor 12CPU_128G --trait $WHICH_RAID --trait
> $WHICH_LAYOUT
>
> No flavor explosion.
>

++ I believe this was where this discussion kind of ended up in.. ?Dublin?

The desire and discussion that led us into complex configuration templates
and profiles being submitted were for highly complex scenarios where users
wanted to assert detailed raid configurations to disk. Naturally, there are
many issues there. The ability to provide such detail would be awesome for
those 10% of operators that need such functionality. Of course, if that is
the only path forward, then we delay the 90% from getting the minimum
viable feature they need.

>
> (Maybe if we called it something other than --trait, like maybe
> --config-option, it would let us pretend we're not really overloading a
> trait to do config - it's just a coincidence that the config option has
> the same name as the trait it causes to be required.)
>

I feel like it might be confusing, but totally +1 to matching required
trait name being a thing. That way scheduling is completely decoupled and
if everything was correct then the request should already be scheduled
properly.


> -efried
> .
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

[Julia Kreger]

Greetings, Comments in-line.

Thanks,

-Julia

On Sat, Sep 29, 2018 at 11:27 PM Moshe Levi  wrote:

> Hi Julia,
>
>
>
> I don't mind to update the ironic spec [1]. Unfortunately, I wasn't in the
> PTG but I had a sync meeting with Isuku.
>
>
>
> As I see it there is 2 use-cases:
>
>1. Running the neutron ovs agent in the smartnic
>2. Running the neutron super ovs agent which manage the ovs running on
>the smartnic.
>
>
My takeaway from the meeting with neutron is that there would not be a
neutron ovs agent running on the smartnic. That the configuration would
need to be pushed at all times, which is ultimately better security wise if
the tenant NIC is somehow compromised it reduces the control plane exposure.


>1.
>
>
>
> It seem that most of the discussion was around the second use-case.
>

By the time Ironic and Neutron met together, it seemed like the first use
case was no longer under consideration. I may be wrong, but very strong
preference existed for the second scenario when we met the next day.


>
> This is my understanding on the ironic neutron PTG meeting:
>
>1. Ironic cores don't want to change the deployment interface as
>proposed in [1].
>2. We should  a new network_interface for use case 2. But what about
>the first use case? Should it be a new network_interface as well?
>3. We should delay the port binding until the baremetal is powered on
>the ovs is running.
>   1. For the first use case I was thinking to change the neutron
>   server to just keep the port binding information in the neutron DB. Then
>   when the neutron ovs agent is a live it will retrieve all the baremeal 
> port
>   , add them to the ovsdb and start the neutron ovs agent fullsync.
>   2. For the second use case the agent is alive so the agent itself
>   can monitor the ovsdb of the baremetal and configure it when it up
>4. How to notify that neutron agent successfully/unsuccessfully bind
>the port ?
>   1. In both use-cases we should use neutron-ironic notification to
>   make sure the port binding was done successfully.
>
>
>
> Is my understanding correct?
>
>
> Not quite.

1) We as in Ironic recognize that there would need to be changes, it is the
method as to how that we would prefer to be explicit and have chosen by the
interface. The underlying behavior needs to be different, and the new
network_interface should support both cases 1 and 2 because that interface
contain needed logic for the conductor to determine the appropriate path
forward. We should likely also put some guards in to prevent non-smart
interfaces from being used in the same configuration due to the security
issues that creates.
3) I believe this would be more of a matter of the network_interface
knowing that the machine is powered up, and attempting to assert
configuration through Neutron to push configuration to the smartnic.
3a) The consensus is that the information to access the smartnic is
hardware configuration metadata and that ironic should be the source of
truth for information about that hardware. The discussion was push that as
needed into neutron to help enable the attachment. I proposed just
including it in the binding profile as a possibility, since it is transient
information.
3b) As I understood it, this would ultimately be the default operating
behavior.
4) Was not discussed, but something along the path is going to have to
check and retry as necessary. That item could be in the network_interface
code.
4a) This doesn't exist yet.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [placement] The "intended purpose" of traits

[Julia Kreger]

Eric,

Very well said, I completely agree with you. We should not hold
ourselves back based upon perceptions of original intended purpose.
Things do change. We have to accept that. We must normalize this fact
in our actions moving forward.

That being said, I'm not entirely sure I'm personally fully aware of
the arbitrary restrictions you speak of. Is there thread or a
discussion out there that I can gain further context with?

Thanks!

-Julia
On Fri, Sep 28, 2018 at 6:25 AM Eric Fried  wrote:
>
> It's time somebody said this.
>
> Every time we turn a corner or look under a rug, we find another use
> case for provider traits in placement. But every time we have to have
> the argument about whether that use case satisfies the original
> "intended purpose" of traits.
>
> That's only reason I've ever been able to glean: that it (whatever "it"
> is) wasn't what the architects had in mind when they came up with the
> idea of traits. We're not even talking about anything that would require
> changes to the placement API. Just, "Oh, that's not a *capability* -
> shut it down."
>
> Bubble wrap was originally intended as a textured wallpaper and a
> greenhouse insulator. Can we accept the fact that traits have (many,
> many) uses beyond marking capabilities, and quit with the arbitrary
> restrictions?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Julia Kreger]

On Fri, Sep 28, 2018 at 5:00 AM Jeremy Stanley  wrote:

>
> If memory serves, the biggest challenge around that solution was
> determining who approves such proposals since they still need
> per-project specs for the project-specific details anyway. Perhaps
> someone who has recently worked on a feature which required
> coordination between several teams (but not a majority of teams like
> our cycle goals process addresses) can comment on what worked for
> them and what improvements they would make on the process they
> followed.
> --

This is definitely the biggest challenge, and I think it is one of
those things that is going to be on case by case basis.

In the case of neutron smartnic support with ironic, the spec is
largely living in ironic-specs, but we are collaborating with neutron
folks. They may have other specs that tie in, but that we don't
necessarily need to be aware of. I also think the prior ironic/neutron
integration work executed that way.  My perception with nova has also
largely been similar with ironic's specs driving some changes in the
nova ironic virt driver because we were evolving ironic, as long as
there is a blueprint or something tracking that piece of work so they
have visibility.  At some point, some spec has to get a green light or
be pushed forward first. Beyond that, it is largely a tracking issue
as long as there is consensus.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Julia Kreger]

Greetings!

I suspect the avenue of at least three different specs is likely going
to be the best path forward and likely what will be required for each
project to fully understand how/what/why. From my point of view, I'm
quite interested in this from a Nova point of view because that is the
initial user interaction point for majority of activities. I'm also
wondering if this is virt driver specific, or if it can be applied to
multiple virt drivers in the nova tree, since each virt driver has
varying constraints. So maybe the best path forward is something nova
centric to start?

-Julia

On Thu, Sep 27, 2018 at 10:36 AM Markus Hentsch
 wrote:
>
> Dear OpenStack developers,
>
> we would like to propose the introduction of an encrypted image format
> in OpenStack. We already created a basic implementation involving Nova,
> Cinder, OSC and Glance, which we'd like to contribute.
>
> We originally created a full spec document but since the official
> cross-project contribution workflow in OpenStack is a thing of the past,
> we have no single repository to upload it to. Thus, the Glance team
> advised us to post this on the mailing list [1].
>
> Ironically, Glance is the least affected project since the image
> transformation processes affected are taking place elsewhere (Nova and
> Cinder mostly).
>
> Below you'll find the most important parts of our spec that describe our
> proposal - which our current implementation is based on. We'd love to
> hear your feedback on the topic and would like to encourage all affected
> projects to join the discussion.
>
> Subsequently, we'd like to receive further instructions on how we may
> contribute to all of the affected projects in the most effective and
> collaborative way possible. The Glance team suggested starting with a
> complete spec in the glance-specs repository, followed by individual
> specs/blueprints for the remaining projects [1]. Would that be alright
> for the other teams?
>
> [1]
> http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-09-27-14.00.log.html
>
> Best regards,
> Markus Hentsch
>
[trim]

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][neutron] SmartNics with Ironic

[Julia Kreger]

Greetings everyone,

Now that the PTG is over, I would like to go ahead and get the
specification that was proposed to ironic-specs updated to represent
the discussions that took place at the PTG.

A few highlights from my recollection:

* Ironic being the source of truth for the hardware configuration for
the neutron agent to determine where to push configuration to. This
would include the address and credential information (certificates
right?).
* The information required is somehow sent to neutron (possibly as
part of the binding profile, which we could send at each time port
actions are requested by Ironic.)
* The Neutron agent running on the control plane connects outbound to
the smartnic, using information supplied to perform the appropriate
network configuration.
* In Ironic, this would likely be a new network_interface driver
module, with some additional methods that help facilitate the
work-flow logic changes needed in each deploy_interface driver module.
* Ironic would then be informed or gain awareness that the
configuration has been completed and that the deployment can proceed.
(A different spec has been proposed regarding this.)

I have submitted a forum session based upon this and the agreed upon
goal at the PTG was to have the ironic spec written up to describe the
required changes.

I guess the next question is, who wants to update the specification?

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists!

[Julia Kreger]

In my mind, there is value to having a mailing list for things like
important meetings, but it seems more reasonable to just address such
items as needed. At the same time, I agree with ttx, the separate list
is no longer useful. +1
On Fri, Sep 21, 2018 at 5:24 AM Thierry Carrez  wrote:
>
> Doug Hellmann wrote:
> > I'm inclined to include it and either use a direct mailing or the
> > [tc] tag on the new discuss list to reach TC members, but I would
> > like to hear feedback from TC members and other interested parties
> > before calling that decision made. Please let me know what you think.
>
> +1 -- the separate list has outlived its usefulness.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [election][tc] announcing candidacy

[Julia Kreger]

That is an excellent question John!

The most specific thing that is weighing on my mind is elevating and
supporting contributors. While this is not new, I think we as a
community need to refocus on it because they are very fibers that make
up the fabric of our community and ultimately the electorate.

I also feel that we focus a bit too much on what is new without having
the data to really back it up. With so many project teams and working
groups, it is going to take time for the TC to really digest and
attempt to draw any actionable direction from the health assessment
that has been underway over the past few months.

-Julia
On Tue, Sep 4, 2018 at 2:07 PM John Dickinson  wrote:
>
>
>
> On 4 Sep 2018, at 12:16, Julia Kreger wrote:
>
> > Greetings Stackers!
> >
> > I hereby announce my candidacy for a position on the OpenStack
> > Technical
> > Committee.
> >
> > In many respects I consider myself a maverick, except reality is
> > sometimes
> > entirely different than my own self perception, upon reflection.
> > I find self reflection and introspection to be powerful tools, along
> > with
> > passion and desire for the common good. That desire for the common
> > good
> > is the driving force behind my involvement in OpenStack, which I hope
> > to
> > see as a vibrant and thriving community for years to come.
> >
> > Have things changed? Yes, I think they are ever evolving. I think we
> > can only
> > take the logical paths that we see before us at the time. Does this
> > mean
> > we will make mistakes? Absolutely, but mistakes are also opportunities
> > to learn and evolve as time goes on; which perhaps is an unspoken
> > backbone
> > of our community. The key is that we must not fear change but embrace
> > it.
> >
> > Changing our community for the better is a process we can only take
> > one step at a time, and we must recognize our strength
> > is in our diversity. As we move forward, as we evolve, we need to keep
> > in
> > mind our goals and overall vision. In a sense, these things vary
> > across all
> > projects, but our central community vision and goal helps provide
> > direction.
> >
> > As we continue our journey, I believe we need to lift up new
> > contributors,
> > incorporate new thoughts, and new ideas. Embracing change while
> > keeping our
> > basic course so new contributors can better find and integrate with
> > our
> > community as we continue forward. We need to listen and take that as
> > feedback to better understand other perspectives, for it is not only
> > our singular personal perspective which helps give us direction,
> > but the community as a whole.
> >
> > For those who do not know me well my name is Julia Ashley Kreger.
> > Often
> > I can be found on IRC as TheJulia, in numerous OpenStack related
> > channels.
> > I have had the pleasure of serving the community this past year on the
> > Technical Committee. I have also served the ironic community quite a
> > bit
> > during my time in the OpenStack community, which began during the Juno
> > cycle.
> >
> > I am the current Project Team Lead for the Ironic team. I began
> > serving in that capacity starting with the Rocky cycle. Prior,
> > I served as the team's release liaison. You might have seen me as one
> > of those crazy people advocating for standalone usage. Prior lives
> > included deploying and operating complex systems, but that is enough
> > about me.
> >
> > Ultimately I believe I bring a different perspective to the TC and it
> > is for
> > this, and my many strong beliefs and experiences, I feel I am well
> > suited
> >
> > to serve the community for another year on the Technical Committee.
> >
> > Thank you for your consideration,
> >
> > Julia
> >
> > freenode: TheJulia
> > Twitter: @ashinclouds
> > https://www.openstack.org/community/members/profile/19088/julia-kreger
> > http://stackalytics.com/?release=all_id=juliaashleykreger
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Julia,
>
> Do you have any specific examples of new ideas you are wanting to
> propose or advocate for, should you be re-elected?
>
> --John
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [election][tc] announcing candidacy

[Julia Kreger]

Greetings Stackers!

I hereby announce my candidacy for a position on the OpenStack Technical
Committee.

In many respects I consider myself a maverick, except reality is sometimes
entirely different than my own self perception, upon reflection.
I find self reflection and introspection to be powerful tools, along with
passion and desire for the common good. That desire for the common good
is the driving force behind my involvement in OpenStack, which I hope to
see as a vibrant and thriving community for years to come.

Have things changed? Yes, I think they are ever evolving. I think we can only
take the logical paths that we see before us at the time. Does this mean
we will make mistakes? Absolutely, but mistakes are also opportunities
to learn and evolve as time goes on; which perhaps is an unspoken backbone
of our community. The key is that we must not fear change but embrace it.

Changing our community for the better is a process we can only take
one step at a time, and we must recognize our strength
is in our diversity. As we move forward, as we evolve, we need to keep in
mind our goals and overall vision. In a sense, these things vary across all
projects, but our central community vision and goal helps provide direction.

As we continue our journey, I believe we need to lift up new contributors,
incorporate new thoughts, and new ideas. Embracing change while keeping our
basic course so new contributors can better find and integrate with our
community as we continue forward. We need to listen and take that as
feedback to better understand other perspectives, for it is not only
our singular personal perspective which helps give us direction,
but the community as a whole.

For those who do not know me well my name is Julia Ashley Kreger. Often
I can be found on IRC as TheJulia, in numerous OpenStack related channels.
I have had the pleasure of serving the community this past year on the
Technical Committee. I have also served the ironic community quite a bit
during my time in the OpenStack community, which began during the Juno
cycle.

I am the current Project Team Lead for the Ironic team. I began
serving in that capacity starting with the Rocky cycle. Prior,
I served as the team's release liaison. You might have seen me as one
of those crazy people advocating for standalone usage. Prior lives
included deploying and operating complex systems, but that is enough
about me.

Ultimately I believe I bring a different perspective to the TC and it is for
this, and my many strong beliefs and experiences, I feel I am well suited

to serve the community for another year on the Technical Committee.

Thank you for your consideration,

Julia

freenode: TheJulia
Twitter: @ashinclouds
https://www.openstack.org/community/members/profile/19088/julia-kreger
http://stackalytics.com/?release=all_id=juliaashleykreger

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Bringing the community together (combine the lists!)

[Julia Kreger]

I fully support merging the lists proposed, as well as the interop-wg
list that Chris Hodge proposed. I look forward to the day when cross
posting is no longer a necessary evil.

-Julia
On Thu, Aug 30, 2018 at 10:04 AM Jeremy Stanley  wrote:
>
> The openstack, openstack-dev, openstack-sigs and openstack-operators
> mailing lists on lists.openstack.org see an increasing amount of
> cross-posting and thread fragmentation as conversants attempt to
> reach various corners of our community with topics of interest to
> one or more (and sometimes all) of those overlapping groups of
> subscribers. For some time we've been discussing and trying ways to
> bring our developers, distributors, operators and end users together
> into a less isolated, more cohesive community. An option which keeps
> coming up is to combine these different but overlapping mailing
> lists into one single discussion list. As we covered[1] in Vancouver
> at the last Forum there are a lot of potential up-sides:
>
> 1. People with questions are no longer asking them in a different
> place than many of the people who have the answers to those
> questions (the "not for usage questions" in the openstack-dev ML
> title only serves to drive the wedge between developers and users
> deeper).
>
> 2. The openstack-sigs mailing list hasn't seem much uptake (an order
> of magnitude fewer subscribers and posts) compared to the other
> three lists, yet it was intended to bridge the communication gap
> between them; combining those lists would have been a better
> solution to the problem than adding yet another turned out to be.
>
> 3. At least one out of every ten messages to any of these lists is
> cross-posted to one or more of the others, because we have topics
> that span across these divided groups yet nobody is quite sure which
> one is the best venue for them; combining would eliminate the
> fragmented/duplicative/divergent discussion which results from
> participants following up on the different subsets of lists to which
> they're subscribed,
>
> 4. Half of the people who are actively posting to at least one of
> the four lists subscribe to two or more, and a quarter to three if
> not all four; they would no longer be receiving multiple copies of
> the various cross-posts if these lists were combined.
>
> The proposal is simple: create a new openstack-discuss mailing list
> to cover all the above sorts of discussion and stop using the other
> four. As the OpenStack ecosystem continues to mature and its
> software and services stabilize, the nature of our discourse is
> changing (becoming increasingly focused with fewer heated debates,
> distilling to a more manageable volume), so this option is looking
> much more attractive than in the past. That's not to say it's quiet
> (we're looking at roughly 40 messages a day across them on average,
> after deduplicating the cross-posts), but we've grown accustomed to
> tagging the subjects of these messages to make it easier for other
> participants to quickly filter topics which are relevant to them and
> so would want a good set of guidelines on how to do so for the
> combined list (a suggested set is already being brainstormed[2]).
> None of this is set in stone of course, and I expect a lot of
> continued discussion across these lists (oh, the irony) while we try
> to settle on a plan, so definitely please follow up with your
> questions, concerns, ideas, et cetera.
>
> As an aside, some of you have probably also seen me talking about
> experiments I've been doing with Mailman 3... I'm hoping new
> features in its Hyperkitty and Postorius WebUIs make some of this
> easier or more accessible to casual participants (particularly in
> light of the combined list scenario), but none of the plan above
> hinges on MM3 and should be entirely doable with the MM2 version
> we're currently using.
>
> Also, in case you were wondering, no the irony of cross-posting this
> message to four mailing lists is not lost on me. ;)
>
> [1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
> [2] https://etherpad.openstack.org/p/common-openstack-ml-topics
> --
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments

[Julia Kreger]

Greetings everyone,

It looks like the most agreeable time on the doodle[1] seems to be
Tuesday September 4th at 13:00 UTC. Are there any objections to using
this time?

If not, I'll go ahead and create an etherpad, and setup a bluejeans
call for that time to enable high bandwidth discussion.

-Julia
[1]: https://doodle.com/poll/y355wt97heffvp3m

On Mon, Aug 27, 2018 at 9:53 AM Julia Kreger
 wrote:
>
> Greetings everyone!
>
> We in Ironic land would like to go into the PTG with some additional
> thoughts, requirements, and ideas as it relates to distributed and
> geographically distributed deployments.
>
[trim]

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Inquiry about an opportunity to do a thesis project in collaboration with a OpenStack project.

[Julia Kreger]

Greetings!

Welcome to the community!

Your interests seem to span quite a bit of the OpenStack community, so
I think it might be a good idea for you possibly look at the
individual teams that interest you the most, and reach out to those
teams and engage in discussion from there.

What may be a good idea is to look at the Rocky cycle release
highlights[1] as they provide high level summaries and what the
recently added features were for each project as part of this past
development cycle. We're just now starting the Stein cycle, so now is
really the perfect time to join in.

-Julia

[1]: https://releases.openstack.org/rocky/highlights.html
On Thu, Aug 30, 2018 at 9:31 AM Aniketh Gireesh
 wrote:
>
> Hi,
>
> I am Aniketh Girish, a Junior year Computer Science Engineering student at 
> the Amrita University, Kerala, India. I’m writing to you to inquire about the 
> possibility to do my thesis project in accordance with the OpenStack 
> community and a project in the community.
>
> I had initiated to contribute towards OpenStack a few months back. I took 
> some time off since I was selected to participate in Google Summer of code 
> with GNU Linux organization. For the last few months, I have been mainly 
> focusing on implementing and learning about advanced internet protocols. My 
> primary interest leans towards network security, with a particular interest 
> in the Networking protocol and cloud computing infrastructures.
>
> A selected project in my field of interest would be when, I was selected as a 
> Google Summer of Code 2018, where I am working on the project Wget2 under GNU 
> Linux organisation. This project involves adding support for DNS over HTTPS 
> in Wget2. DNS over HTTPS(DoH) is a web protocol that argues for sending DNS 
> requests and receiving DNS responses via HTTPS connections, hence providing 
> query confidentiality. Therefore to provide such a name resolution, I devised 
> a library where I implemented the DNS protocol by facilitating the library to 
> create the DNS packet/request, queried A, , CNAME records and implemented 
> the DoH protocol by parsing the DNS wire format from the HTTPS response body.
>
> It is about time for me to look for a promising bachelor thesis project in my 
> field of interest. I would like to know if there are any possibilities for me 
> to work together with OpenStack in a project as a part of my thesis research.
>
> Hope to hear back soon.
>
> Cheers.
> --
> Aniketh Girish
> Member at FOSS@Amrita
> Amrita University
> Github | GitLab | Blog | Website
>
> "For the Love of Code."
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] proposing metalsmith for inclusion into ironic governance

[Julia Kreger]

On Mon, Aug 27, 2018 at 9:09 AM Dmitry Tantsur  wrote:
> I would like propose the metalsmith library [1][2] for inclusion into the bare
> metal project governance.

I am +1 to this. I think this is a logical inclusion to Ironic's
governance, and overall benefits the ecosystem by allowing greater
choice and ability to leverage ironic.

Thanks Dmitry!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments

[Julia Kreger]

Greetings everyone!

We in Ironic land would like to go into the PTG with some additional
thoughts, requirements, and ideas as it relates to distributed and
geographically distributed deployments.

As you may or may not know, we did take a first step towards
supporting some of the architectures needed with conductor_groups this
past cycle, but we have two very distinct needs that have been
expressed with-in the community.

1) Need to federate and share baremetal resources between ironic
deployments. A specification[1] was proposed to try and begin to
capture what this would look like ironic wise. At a high level, this
would look like an ironic node that actually consumes and remotely
manages a node via another ironic deployment. Largely this would be a
stand-alone user/admin user deployment cases, where hardware inventory
insight is needed.

2) Need to securely manage remote sites with different security
postures, while not exposing control-plane components as an attack
surface. Some early discussion into this would involve changing
Conductor/IPA communication flow[2], or at least supporting a
different model, and some sort of light weight intermediate middle-man
service that helps facilitate the local site management.

With that in mind, we would like to schedule a call for sometime next
week where we can kind of talk through and discuss these thoughts and
needs in real time in advance of the PTG so we can be even better
prepared. We are attempting to identify a time with a doodle[3].
Please select a time and date, so we can schedule something for next
week.

Thanks,

-Julia

[1]: https://review.openstack.org/#/c/560152/
[2]: https://review.openstack.org/212206
[3]: https://doodle.com/poll/y355wt97heffvp3m

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][bifrost][sushy][ironic-inspector][ironic-ui][virtualbmc] sub-project/repository core reviewer changes

[Julia Kreger]

Greetings everyone!

In our team meeting this week we stumbled across the subject of
promoting contributors to be sub-project's core reviewers.
Traditionally it is something we've only addressed as needed or
desired by consensus with-in those sub-projects, but we were past due
time to take a look at the entire picture since not everything should
fall to ironic-core.

And so, I've taken a look at our various repositories and I'm
proposing the following additions:

For sushy-core, sushy-tools-core, and virtualbmc-core: Ilya
Etingof[1]. Ilya has been actively involved with sushy, sushy-tools,
and virtualbmc this past cycle. I've found many of his reviews and
non-voting review comments insightful and willing to understand. He
has taken on some of the effort that is needed to maintain and keep
these tools usable for the community, and as such adding him to the
core group for these repositories makes lots of sense.

For ironic-inspector-core and ironic-specs-core: Kaifeng Wang[2].
Kaifeng has taken on some hard problems in ironic and
ironic-inspector, as well as brought up insightful feedback in
ironic-specs. They are demonstrating a solid understanding that I only
see growing as time goes on.

For sushy-core: Debayan Ray[3]. Debayan has been involved with the
community for some time and has worked on sushy from early on in its
life. He has indicated it is near and dear to him, and he has been
actively reviewing and engaging in discussion on patchsets as his time
has permitted.

With any addition it is good to look at inactivity as well. It saddens
me to say that we've had some contributors move on as priorities have
shifted to where they are no longer involved with the ironic
community. Each person listed below has been inactive for a year or
more and is no longer active in the ironic community. As such I've
removed their group membership from the sub-project core reviewer
groups. Should they return, we will welcome them back to the community
with open arms.

bifrost-core: Stephanie Miller[4]
ironic-inspector-core: Anton Arefivev[5]
ironic-ui-core: Peter Peila[6], Beth Elwell[7]

Thanks,

-Julia

[1]: http://stackalytics.com/?user_id=etingof=marks
[2]: http://stackalytics.com/?user_id=kaifeng=marks
[3]: http://stackalytics.com/?user_id=deray=marks=all
[4]: http://stackalytics.com/?metric=marks=all_id=stephan
[5]: http://stackalytics.com/?user_id=aarefiev=marks
[6]: http://stackalytics.com/?metric=marks=all_id=ppiela
[7]: 
http://stackalytics.com/?metric=marks=all_id=bethelwell=ironic-ui

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Julia Kreger]

This is sad news to read, but completely understandable!

Thank you for all of your excellent work on Ironic, and should time
and focus ever make sense later down the road for you to rejoin
ironic-core, know you'll be welcomed back.

Thanks again!

-Julia

On Tue, Aug 21, 2018 at 8:38 AM, John Villalovos
 wrote:
> Good morning Ironic,
>
> I have come to realize that I don't have the time needed to be able to
> devote the attention needed to continue as an Ironic core.
>
> I'm hopeful that in the future I will work on Ironic or OpenStack again! :)
>
> The Ironic (and OpenStack) community has been a great one and I have really
> enjoyed my time working on it and working with all the people. I will still
> be hanging around on IRC and you may see me submitting a patch here and
> there too :)
>
> Thanks again,
> John
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] ironic-staging-drivers: what to do?

[Julia Kreger]

Greetings fellow ironicans!

As many of you might know an openstack/ironic-staging-drivers[1]
repository exists. What most might not know is that it was
intentionally created outside of ironic's governance[2].

At the time it was created ironic was moving towards removing drivers
that did not meet our third-party CI requirement[3] to be in-tree. The
repository was an attempt to give a home to what some might find
useful or where third party CI is impractical or cost-prohibitive and
thus could not be officially part of Ironic the service. There was
hope that drivers could land in ironic-staging-drivers and possibly
graduate to being moved in-tree with third-party CI. As our community
has evolved we've not stopped and revisited the questions.

With our most recent release over, I believe we need to ask ourselves
if we should consider moving ironic-staging-drivers into our
governance.

Over the last couple of releases several contributors have found
themselves trying to seek out two available reviewers to merge even
trivial fixes[4]. Due to the team being so small this was no easy
task. As a result, I'm wondering why not move the repository into
governance, grant ironic-core review privileges upon the repository,
and maintain the purpose and meaning of the repository. This would
also result in the repository's release becoming managed via the
release management process which is a plus.

We could then propose an actual graduation process and help alleviate
some of the issues where driver code is iterated upon for long periods
of time before landing. At the same time I can see at least one issue
which is if we were to do that, then we would also need to manage
removal through the same path.

I know there are concerns over responsibility in terms of code
ownership and quality, but I feel like we already hit such issues[5],
like those encountered when Dmitry removed classic drivers[6] from the
repository and also encountered issues just prior to the latest
release[7][8].

This topic has come up in passing at PTGs and most recently on IRC[9],
and I think we ought to discuss it during our next weekly meeting[10].
I've gone ahead and added an item to the agenda, but we can also
discuss via email.

-Julia

[1]: 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n4571
[2]: 
http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/README.rst#n16
[3]: 
https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-party-ci.html
[4]: https://review.openstack.org/#/c/548943/
[5]: https://review.openstack.org/#/c/541916/
[6]: https://review.openstack.org/567902
[7]: https://review.openstack.org/590352
[8]: https://review.openstack.org/590401
[9]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27
[10]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] The state of the ironic universe - August 6th, 2018

[Julia Kreger]

News!
=
In the past month we released ironic 11.0 and now this week we expect
to release ironic 11.1.

With 11.1, ironic has:

* The ``deploy_steps`` framework in order to give better control over
what consists of a deployment.
* BIOS settings management interfaces for the ``ilo`` and ``irmc``
hardware types.
* Ramdisk deploy interface has merged. We await your bug reports!
* Conductors can now be grouped into specific failure domains with
specific nodes assigned to those failure domains. This allows for an
operator to configure a conductor in data center A to manage only the
hardware in data center A, and not data center B.
* Capability has been added to the API to allow driver interface
values to be reset to the conductor default values when the driver
name is being changed.
* Support for partition images with ppc64le hardware has merged.
Previously operators could only use whole disk images on that
architecture.
* Out-of-band RAID configuration is now available with the ``irmc``
hardware type.
* Several bug fixes related to cleaning, PXE, and UEFI booting.

In slightly depressing news the ``xclarity`` hardware type has been
deprecated. This is due to the fact the third-party CI for the
hardware type has not yet been established. The team working on the
hardware type is continuing to work on getting CI up and running, and
we expect to rescind the deprecation in the next release of ironic.

Stein Planning
--

Our Stein planning etherpad[0] has had some activity and we have
started to started to place procedural -2s on major changes which will
impact the Rocky release. Expect these to be removed once we've
released Ironic 11.1.

Recent New Specifications
=

* Support for SmartNICs[1]

* Rework inspector boot mangement[2]

Specifications starting to see activity
===

* Make IPA to ironic API communication optional[3]

* Cleanhold state to enable cleaning steps collection [4]

Recently merged specifications
==

* Owner information storage[5]

* Direct Deploy with local HTTP server[6]



[0]: https://etherpad.openstack.org/p/ironic-stein-ptg

[1]: https://review.openstack.org/582767

[2]: https://review.openstack.org/589230

[3]: https://review.openstack.org/#/c/212206

[4]: https://review.openstack.org/507910

[5]: https://review.openstack.org/560089

[6]: https://review.openstack.org/504039

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Stein PTG Planning Etherpad

[Julia Kreger]

Greetings everyone,

A few weeks ago I created an etherpad[1] to begin discussion of ideas
and thoughts for items to discuss during the PTG. I've raised this
during our meetings, but not yet raised it to the mailing list.

If you are interested, please feel free to add discussion items,
comment, or provide additional context if it is something you care
about. Please do so by August 23rd.

Thanks!
-Julia

[1]: https://etherpad.openstack.org/p/ironic-stein-ptg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [FFE] Teach ironic about ppc64le boot requirements

[Julia Kreger]

Given that the ironic-lib version in question is already in
upper-constraints, I think it may be fine. Realistically we do want
people to be running the latest version of ironic-lib when deploying
anyway. That being said, I'm +1 for this, however we need a second
ironic-core to be willing to review this over the next few days.

On Mon, Jul 30, 2018 at 1:55 PM, Michael Turek
 wrote:
> I would like to request a FFE for this RFE
> https://storyboard.openstack.org/#!/story/1749057
>
> The implementation should be complete and is currently passing CI, but does
> need more reviews. I'd also like to test this locally ideally.
>
> pros
> ---
> - Improves ppc64le support
>
> cons
> ---
> - Bumps ironic-lib version for both IPA and Ironic
>
> risk
> ---
> - There are other deployment methods for ppc64le, including wholedisk and
> netboot. However, this feature is desired to improve parity between x86 and
> ppc64le for tripleo. The feature should not affect any current working
> deployment methods, but please review closely.
>
> Please let me know if you'd like more detail on this or have any questions!
> Thanks!
>
> -Mike  Turek
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][pt][election] Announcing candidacy for Ironic PTL

[Julia Kreger]

Greetings!

I have been truly amazed by our accomplishments of the last six months and
I wish to continue this momentum. As such I am announcing my candidacy and
self nomination for the position of Ironic PTL.

I promise to continue the application of irony. This past cycle has been
very eye opening for me and has taught me a lot about the community at large
and the challenges they face. My passion has not wavered and I wish to
continue enhancing ironic's capabilities.

Operators are central to our community, and we need to continue
enhancements that help operators but at the same time we need to
revisit our old ideas and plans.

In a sense we have already started to do this and we need to continue it.
Efforts such as splitting iPXE out of PXE make lots of sense and better
enables mixed hardware and even architecture fleets to co-exist.

My vision for this next cycle is to setup ironic to become the the
defacto API driven hardware provisioning toolkit. This will naturally
mean some more work and we will need to continue with our momentum and focus
on enablement and performance enhancements to improve the user experience.

Thank you for your consideration.

Julia Kreger (TheJulia)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Correction: "mid-cycle" call Tuesday, July 17th - 12:00 PM UTC

[Julia Kreger]

Greetings everyone!

In my rush to get the email sent, I somehow put the wrong time on the email.

The correct date and time is Tuesday, July 17th, at 12:00 UTC.

-Julia


On Tue, Jul 10, 2018 at 12:28 PM, Julia Kreger
 wrote:
> Fellow ironicans!
>
> Lend me your ears!  With the cycle quickly coming to a close, we
> wanted to take a couple hours for high bandwidth discussions covering
> the end of cycle for Ironic, as well as any items that need to be
> established in advance of the PTG.
>
> We're going to use bluejeans[1] since it seems to work well for
> everyone, and I've posted a rough agenda[2] to an etherpad. If there
> are additional items, please feel free to add them to the etherpad.
>
> -Julia
>
> [1]: https://bluejeans.com/437242882/
> [2]: https://etherpad.openstack.org/p/ironic-rocky-midcycle

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] "mid-cycle" call Tuesday, July 17th - 3 PM UTC

[Julia Kreger]

Fellow ironicans!

Lend me your ears!  With the cycle quickly coming to a close, we
wanted to take a couple hours for high bandwidth discussions covering
the end of cycle for Ironic, as well as any items that need to be
established in advance of the PTG.

We're going to use bluejeans[1] since it seems to work well for
everyone, and I've posted a rough agenda[2] to an etherpad. If there
are additional items, please feel free to add them to the etherpad.

-Julia

[1]: https://bluejeans.com/437242882/
[2]: https://etherpad.openstack.org/p/ironic-rocky-midcycle

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] The state of the ironic universe - July 2nd, 2018

[Julia Kreger]

The state of the ironic universe

This month we're trying a new format to keep those interested updated
on what is going on in ironic. The intent is for our weekly updates to
now take the form of a monthly newsletter to cover highlights of what
is going on in the ironic community. If you have something to add in
the future, please feel free to reach out and we can add it to the
next edition.

News!
=
- Long deprecated 'classic' ('pxe_*', 'agent_*) drivers are being
removed. They will not be present in the next major version of ironic.
- Ironic now has support to return nodes from maintenance state when
BMC connectivity is restored from an outage.
- BIOS configuration caching and setting assertion interface has
merged and vendors are working on their implementations.

From OpenInfra Days China!
--
* Users in china are interested in ironic!
* Everything from small hundreds to thousands, basic OS installation
to super computing use cases!
* The larger deployments are encountering some of the scale issues
larger operators have experienced in the past.
* The language barrier is making it difficult to grasp the finer
details of: Deployment error reporting/troubleshooting and high
availability mechanics.
* Some operators are interested in the ability to "clone" or "backup"
an ironic node's contents in order to redeploy elsewhere and/or
restore the machine state.
* Many operators wishing to contribute felt that they were unable to
because "we are not [a] big name", that they would be unable to gain
traction or build consensus by not being a major contributor already.
In these discussions, I stressed that we all have similar, if not the
same, problems that we are trying to solve. Julia wrote a recent
SuperUser post about this.[1]

From the OpenStack Summit
-
Operator interests vary, but there are some common problems that
operators have or are interested in solving.

Attestation/Security Integration

Some operators and deployers seek to strengthen their security posture
via the use of TPMs, registration and attestation of status with
attestation servers. In a sense, think of it as profile enforcement of
bare metal. An initial specification [2] has been posted to try and
figure out some of the details and potential integration points.

Firmware Management (Version Discovery/Assertion)
~
Operators are seeking more capabilities to discover the current
version of firmware on a particular bare metal node and then possibly
take corrective action through ironic in order to update the firmware.

The developer community does not presently have a plan to tackle this
challenge, however doing so moves us closer to being a sort of
attestation service.

RAID prior to deploy and Software RAID
~~
One of the frequent asks is for support for enabling the assertion of
RAID configuration prior to deployment. Naturally this is somewhat
problematic as this task CAN greatly extend the deployment time.
Presently deployment steps[6] are anticipated to enable these
sorts of workflows.

Additionally the ask for Software RAID support seems to be ramping up.
This is not a simple task for us to achieve, but conceivably it might
take the same shape as hardware raid presently does, just with
appropriate interface mechanisms during the deployment process. There
are several conundrums, and the community needs to better understand
desired cases before development of a solution can take place.

Serial Console Logging
~~
Numerous operators expressed interest in having console logging
support. This last seems to have been worked on last year[3] and
likely needs a contributor to pick back up and champion it forward.

Hardware CMDB/Asset Discovery/Recording and Tracking

While not directly a problem of deploying bare metal directly,
information about hardware is needed to tie in tasks such as repairs,
warranty, tax accounting, and so on and so forth. Often these problems
becomes "solved" by disparate processes tracking information in
several different places. There is a growing ask for something in the
community to aid in this effort. Jokingly, we've already kind of come
up with a name, but the current main ironic developer community
doesn't have time to take on this challenge.

The most viable path forward for interested operators is likely to
detail the requirements and begin working together to implement
something with integration with ironic.

Rack Awareness/Conductor Locality
~
Ironic is working on conductor locality, in terms of pinning specific
bare metal nodes to specific ironic conductors. We hope that this
functionality will be available in the final Rocky release.[4]

Burn-in Tests
~
Operators expressed interest in having the capability to use ironic as
part of 

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Julia Kreger]

Back to the topic of nitpicking!

I virtually sat down with Doug today and we hammered out the positive
aspects that we feel like are the things that we as a community want
to see as part of reviews coming out of this effort. The principles
change[1] in governance has been updated as a result.

I think we are at a point where we have to state high level
principles, and then also update guidelines or other context providing
documentation to re-enforce some of items covered in this
discussion... not just to educate new contributors, but to serve as a
checkpoint for existing reviewers when making the decision as to how
to vote change set. The question then becomes where would such
guidelines or documentation best fit? Should we explicitly detail the
cause/effect that occurs? Should we convey contributor perceptions, or
maybe even just link to this thread as there has been a massive amount
of feedback raising valid cases, points, and frustrations.

Personally, I'd lean towards a blended approach, but the question of
where is one I'm unsure of. Thoughts?

-Julia

[1]: https://review.openstack.org/#/c/570940/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Julia Kreger]

I don't feel like anyone is proposing to end the use of -1's, but that
we should generally be encouraging, accepting, and trusting. That
means if there are major gaps or issues, then the use of a -1 is
perfectly valid because it needs more work. We also need to be mindful
of context as well, and in the grand scheme not try for something
perfect as many often do. This *does* mean we land something that
needs to be fixed later or reverted later, but neither are things we
should fear. We can't let that fear control us.

There are also the qualifiers of "does this help" or "does this harm",
and neither are nitpicks to me. That is also going to vary from
project to project, and even more so case by case based upon the item
being evaluated. That is where the context is important. Perhaps we
need to also, as the community evolves, consider mindfulness. Granted,
mindfulness is hard and can be even harder with elevated stress. Maybe
this is where we should also pitch something like "Stacker Cruises"
with an intermediate forced vacation for everyone. :)

On Wed, May 30, 2018 at 6:11 AM, Dmitry Tantsur  wrote:
> Hi,
>
> This is a great discussion and a great suggestion overall, but I'd like to
> add a grain of salt here, especially after reading some comments.
>
> Nitpicking is bad, no disagreement. However, I don't like this whole
> discussion to end up marking -1's as offense or aggression. Just as often as
> I see newcomers proposing patches frustrated with many iterations, I see
> newcomers being afraid to -1.
>
> In my personal experience I have two remarkable cases:
> 1. A person asking me (via a private message) to not put -1 on their patches
> because they may have problems with their managers.
> 2. A person proposing a follow-up on *any* comment to their patch, including
> important ones.
>
> Whatever decision the TC takes, I would like it to make sure that we don't
> paint putting -1 as a bad act. Nor do I want "if you care, just follow-up"
> to be an excuse for putting up bad contributions.
>
> Additionally, I would like to have something saying that a -1 is valid and
> appropriate, if a contribution substantially increases the project's
> technical debt. After already spending *days* refactoring ironic unit tests,
> I will -1 the hell out of a patch that will try to bring them back to their
> initial state, I promise :)
>
> Dmitry
>
>
> On 05/29/2018 03:55 PM, Julia Kreger wrote:
>>
>> During the Forum, the topic of review culture came up in session after
>> session. During these discussions, the subject of our use of nitpicks
>> were often raised as a point of contention and frustration, especially
>> by community members that have left the community and that were
>> attempting to re-engage the community. Contributors raised the point
>> of review feedback requiring for extremely precise English, or
>> compliance to a particular core reviewer's style preferences, which
>> may not be the same as another core reviewer.
>>
>> These things are not just frustrating, but also very inhibiting for
>> part time contributors such as students who may also be time limited.
>> Or an operator who noticed something that was clearly a bug and that
>> put forth a very minor fix and doesn't have the time to revise it over
>> and over.
>>
>> While nitpicks do help guide and teach, the consensus seemed to be
>> that we do need to shift the culture a little bit. As such, I've
>> proposed a change to our principles[1] in governance that attempts to
>> capture the essence and spirit of the nitpicking topic as a first
>> step.
>>
>> -Julia
>> -
>> [1]: https://review.openstack.org/570940
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Julia Kreger]

On Tue, May 29, 2018 at 7:42 PM, Zane Bitter  wrote:
[trim]
> Since I am replying to this thread, Julia also mentioned the situation where
> two core reviewers are asking for opposite changes to a patch. It is never
> ever ever the contributor's responsibility to resolve a dispute between two
> core reviewers! If you see a core reviewer's advice on a patch and you want
> to give the opposite advice, by all means take it up immediately - with *the
> other core reviewer*. NOT the submitter. Preferably on IRC and not in the
> review. You work together every day, you can figure it out! A random
> contributor has no chance of parachuting into the middle of that dynamic and
> walking out unscathed, and they should never be asked to.
>

Absolutely agree! In the case that was in mind where it has happened
to me personally, I think it was 10-15 revisions apart, so it becomes
a little hard to identify when your starting to play the game of "make
the cores happy to land it". It is not a fun game for the contributor.
Truthfully it caused me to add the behavior of intentionally waiting
longer between uploads of new revisions... which does not help at all.

The other conundrum is when you disagree and the person has left a -1
which blocks forward progress and any additional reviews since it gets
viewed as "not ready", which makes it even harder and slower to build
consensus. At some point you get into "Oh, what formatting can I
change to clear that -1 because the person is not responding" mode.

At least beginning to shift the review culture should help many of these issues.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Julia Kreger]

On Tue, May 29, 2018 at 3:16 PM, Jay S Bryant  wrote:
>
>
> On 5/29/2018 2:06 PM, Artom Lifshitz wrote:
>> Yeah, I feel like we're all essentially in agreement that nits (of the
>> English mistake of typo type) do need to get fixed, but sometimes
>> (often?) putting the burden of fixing them on the original patch
>> contributor is neither fair nor constructive.
>
> I am ok with this statement if we are all in agreement that doing follow-up
> patches is an acceptable practice.
>
It does feel like there is some general agreement. \o/

Putting my Ironic hat on, we've been trying to stress that follow-up
patches are totally acceptable and encouraged. Follow-up patches seem
to land faster in the grand scheme of things and allow series of
patches to move forward in the mean time which is important when a
feature may be spread across 10+ patches

As for editing just prior to approving, we have learned there can be
absolutely no delay between that edit being made and the patch
approved to land. In essence patches would begin to look like only a
single core reviewer had approved the change they just edited even if
the prior revision had a second core approving the prior revision.. In
my experience, the async nature of waiting for a second core to
sign-off on your edits incurs additional time for nitpicks to occur
and a patch to be blocked.

Sadly putting the burden on the person approving changes to land is a
bit much as well. I think anyone should be free to propose a follow-up
to any patch, at least that is my opinion and why I wrote the
principles change as I did.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][all] A culture change (nitpicking)

[Julia Kreger]

During the Forum, the topic of review culture came up in session after
session. During these discussions, the subject of our use of nitpicks
were often raised as a point of contention and frustration, especially
by community members that have left the community and that were
attempting to re-engage the community. Contributors raised the point
of review feedback requiring for extremely precise English, or
compliance to a particular core reviewer's style preferences, which
may not be the same as another core reviewer.

These things are not just frustrating, but also very inhibiting for
part time contributors such as students who may also be time limited.
Or an operator who noticed something that was clearly a bug and that
put forth a very minor fix and doesn't have the time to revise it over
and over.

While nitpicks do help guide and teach, the consensus seemed to be
that we do need to shift the culture a little bit. As such, I've
proposed a change to our principles[1] in governance that attempts to
capture the essence and spirit of the nitpicking topic as a first
step.

-Julia
-
[1]: https://review.openstack.org/570940

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

[Julia Kreger]

On Tue, May 22, 2018 at 5:41 PM, Brian Haley  wrote:
> On 05/22/2018 04:57 PM, Jay Pipes wrote:
[trim]

> I read this the other way - the goal is to get all the forked code from
> StarlingX into upstream repos.  That seems backwards from how this should
> have been done (i.e. upstream first), and I don't see how a project would
> prioritize that over other work.

There is definitely value to be gained for both projects in terms of a
different point of view that might not have been able to play out in
the public community, but since we're dealing with squashed commits of
changes, it is really hard for us to delineate history/origin of code
fragments, and without that it makes it near impossible for projects
to even help them reconcile their technical debt because of that and
the lacking context surrounding that. It would be so much more
friendly to the community if we had stacks of patch files that we
could work with git.

>> I'm truly wondering why was this even open-sourced to begin with? I'm as
>> big a supporter of open source as anyone, but I'm really struggling to
>> comprehend the business, technical, or marketing decisions behind this
>> action. Please help me understand. What am I missing?
>
>
> I'm just as confused.

Can I add myself to the list of confused people wanting to understand
better? I can see and understand value, but context and understanding
as to why as I mentioned above is going to be the main limiter for
interaction.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Proposing Mark Goddard to ironic-core

[Julia Kreger]

Greetings everyone!

I would like to propose Mark Goddard to ironic-core. I am aware he recently
joined kolla-core, but his contributions in ironic have been insightful and
valuable. The kind of value that comes from operative use.

I also make this nomination knowing that our community landscape is
changing and that we must not silo our team responsibilities or ability to
move things forward to small highly focused team. I trust Mark to use his
judgement as he has time or need to do so. He might not always have time,
but I think at the end of the day, we’re all in that same boat.

-Julia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Meeting week of May 21st cancelled

[Julia Kreger]

All,

The ironic meeting next week is cancelled as we will have some
attendees in Vancouver for the summit and forum. The next meeting will
be May 28th.

I have updated the wiki[1] page accordingly.

-Julia

[1]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][stable] Re-adding Jim Rollenhagen to ironic stable maintenance team?

[Julia Kreger]

On Fri, May 11, 2018 at 8:20 AM, Dmitry Tantsur  wrote:
> Hi,
[trim]
>> If there are no objections, I'll re-add him next week.
>
>
> I don't remember if we actually can add people to these teams or it has to
> be done by the main stable team.
>
I'm fairly sure I'm the person who deleted him from the group in the
first place :(   As such, I think I has the magical powers... maybe
;)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][stable] Re-adding Jim Rollenhagen to ironic stable maintenance team?

[Julia Kreger]

Greetings folks,

Is there any objection if we re-add Jim to the ironic-stable-maint
team?  He was a member prior to his brief departure and I think it
would be good to have another set of hands that can approve the
changes as three doesn't seem like quite enough when everyone is busy.

If there are no objections, I'll re-add him next week.

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Ironic Status Updates

[Julia Kreger]

On Mon, May 7, 2018 at 4:34 PM, Doug Hellmann  wrote:

> As a consumer of team updates from outside of the team, I do find
> them valuable.

Ditto, if I have time to read them.


> I think having a regular email update like that is a good communication
> pattern we've started to establish with several teams, and I'm going
> to ask the TC to help find ways to make those updates more visible
> for folks who want to stay informed but can't spend the time it
> takes to read all of the messages on the mailing list (blogs, RSS,
> twitter, etc.).
>
> So, I hope the Ironic team can find a volunteer (or several to share
> the work?) to step in and continue with summaries in some form.
>

I suspect finding a replacement is going to be a little hard for anything that
is more than a ten to fifteen minute commitment per week. Perhaps if there was
some sort of unified way that might make things easier and we could then
all coalesce in terms of update format, amount of pertinent information
versus noise.

I'm totally on-board for something easy, I'm also just not sure email has
the same impact as it once did. Anyway, things to discuss in the hallway track
at the summit. :)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Julia Kreger]

On Wed, May 9, 2018 at 5:10 PM, Casey Bodley  wrote:
>
> On 05/09/2018 11:40 AM, Casey Bodley wrote:
>>
>>
>> On 05/09/2018 11:22 AM, Matthew Thode wrote:
>>>
>>> python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw
>>> tempurls.  That is, there was no official support, but it still worked.
>>>
>>> In 3.2.0 (specifically the linked commit(s)) tempurls were validated to
>>> require /v1/account/container/object, which does not work with radosgw
>>> as it expects /v1/container/object.  This means that radosgw tempurls
>>> fail to work, which further means that radosgw will stop working for
>>> things like ironic.

What is the value in the validation of the URL path as such? It seems
like the client shouldn't really care as to the precise format of the
end user supplied URL as long as the server returns the expected
response.

>>> I can see the point that swiftclient should not care about ceph not
>>> fully implementing the swift spec and not supporting the radosgw url
>>> syntax, but it seems like a step back.  If this is not fixed then things
>>> like ironic will not work with radosgw for Ocata and above (as that's
>>> when this change was made).  We'd need to wait for either ceph to fix
>>> this and support the account part of the url (probably just dropping it)
>>> or have people fork python-swiftclient to 'fix' it.
>>>
>>> I'm not sure what the right answer is...

I'm personally -1 to pinning swiftclient as that will introduce
headaches if someone tries to install ironic along side anything that
expects a newer client or vise-versa.

I agree it seems like a step back, to which I'm curious about the
value of having the check. The forth option is for ironic to abruptly
drop all related code and support for radosgw temp urls, but that too
would be a setback and negative for OpenStack in general.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][ironic] hacking 1.1.0 released and ironic CI gates failing pep8

[Julia Kreger]

About two hours ago, we started seeing Ironic CI jobs failing pep8
with new errors[1]. For some of our repositories, it just seems to be
a couple of lines that need to be fixed. On ironic itself, supporting
this might have us dead in the water for a while to fix the code in
accordance with what hacking is now expecting.

That being said, dtantsur and dhellmann have the perception that new
checks are supposed to be opt-in only, yet this new hacking appears to
have at W605 and W606 enabled by default as indicated by discussion in
#openstack-release[2].

Please advise, it seems like the release team ought to revert the
breaking changes and cut a new release as soon as possible.

-Julia

[1]: 
http://logs.openstack.org/87/557687/4/check/openstack-tox-pep8/75380de/job-output.txt.gz#_2018-05-08_14_46_47_179606
[2]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2018-05-08.log.html#t2018-05-08T16:30:22

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Ironic Status Updates

[Julia Kreger]

Greetings everyone,

For some time, Rama Yeleswarapu (rama_y) has been graciously sending
out a weekly update for Ironic to the mailing list. We found out late
last week that this contributor would be unable to continue to do so.
While discussing this and searching for a volunteer, we came up with
two important questions that we determined should have some answers.

The first being. Is anyone finding a weekly email useful for Ironic?

The second being: If it is useful, would there be an alternative
format that may be even more useful? Largely it is presently a
copy/paste of our general purpose whiteboard. Perhaps a stream of
consciousness or commentary to convey the delta from week to week?

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Monthly bug day?

[Julia Kreger]

On Mon, Apr 23, 2018 at 12:04 PM, Michael Turek
 wrote:

> What does everyone think about having Bug Day the first Thursday of every
> month?

All for it!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

[Julia Kreger]

>
> This looks like some behavior that has been pulled out as part of pbr 4
> (version 3 is being used in the stable branch). Perhaps we want to
> update the pbr constraint there to use the newer version?
>

And it looks like doing that for stable/queens, at least from an
ironic-inspector point of view[1], fixes the issue for the branch. The
funny thing is, our ironic-inspector stable/pike -> stable/queens test
job fails on stable/pike as well now, with the same failure [2]. That
being said, we did observe during troubleshooting this issue last week
that the pep8 dist-info was present, however the actual module
contents were not present, which is why we worked around the issue
forcing the module to be re-installed.

We also had this occur today on an ironic stable/queens backport
triggered grenade job when keystone was being upgraded [3].

If the answer is update the upper constraint, from my point of view, I
suspect we're going to want to consider doing it across the board.

Of course, the real question is what changed, that is causing test
machines to think pep8 is present... :(

[1]: https://review.openstack.org/#/c/562384/
[2]: 
http://logs.openstack.org/84/562384/2/check/ironic-inspector-grenade-dsvm/59f0605/logs/grenade.sh.txt.gz#_2018-04-18_21_53_20_527
[3]: 
http://logs.openstack.org/14/562314/1/check/ironic-grenade-dsvm/2227c41/logs/grenade.sh.txt.gz#_2018-04-18_16_55_00_456

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] baremetal firmware lifecycle management

[Julia Kreger]

One of the topics that came up at during the Ironic sessions at the
Rocky PTG was firmware management.

During this discussion, we quickly reached the consensus that we
lacked the ability to discuss and reach a forward direction without:

* An understanding of capabilities and available vendor mechanisms
that can be used to consistently determine and assert desired firmware
to a baremetal node. Ideally, we could find a commonality of two or
more vendor mechanisms that can be abstracted cleanly into high level
actions. Ideally this would boil down to something a simple as
"list_firmware()" and "set_firmware()". Additionally there are surely
some caveats we need to understand, such as if the firmware update
must be done in a particular state, and if a particular prior
condition or next action is required for the particular update.

* An understanding of several use cases where a deployed node may need
to have specific firmware applied. We are presently aware of two
cases. The first being specific firmware is needed to match an
approved operational profile. The second being a desire to perform
ad-hoc changes or have new versions of firmware asserted while a node
has already been deployed.

Naturally any insight that can be shared will help the community to
best model the interaction so we can determine next steps and
ultimately implementation details.

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Moving Ironic meeting time

[Julia Kreger]

Greetings everyone!

In an effort to have our meeting be a little friendlier to
contributors in Japan and India, we agreed today [0] to move our
meeting time up two hours to 1500 UTC.

The appropriate change [1] has been submitted to the irc-meetings repository.

Please let me know if you have any questions or concerns.

Thanks!

-Julia

[0]: 
http://eavesdrop.openstack.org/meetings/ironic/2018/ironic.2018-03-19-17.00.log.html#l-274
[1]: https://review.openstack.org/#/c/554361/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Adding "not docs" banner to specs website?

[Julia Kreger]

I'm all for the idea, although that may be because I've been been one
of the people in the past attempting to assist people who have found
specs, and who are are confused or frustrated. I believe it is because
some people latch on to the highly technical design documents when
they can't find $complex thing in $complex documentation easily.

-Julia

On Mon, Mar 19, 2018 at 7:57 AM, Jim Rollenhagen  
wrote:
> Ironic (and surely other projects) have had to point out many times that
> specs are a point in time design discussion, and not completed
> documentation. It's obviously too much work to go back and update specs
> constantly.
>
> What do folks think about a banner at the top of the specs website (or each
> individual spec) that points this out? I'm happy to do the work if we agree
> it's a good thing to do. My suggested wording:
>
> "NOTE: specifications are a point-in-time design reference, not up-to-date
> feature documentation."
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


On Mon, Mar 19, 2018 at 7:57 AM, Jim Rollenhagen  
wrote:
> Ironic (and surely other projects) have had to point out many times that
> specs are a point in time design discussion, and not completed
> documentation. It's obviously too much work to go back and update specs
> constantly.
>
> What do folks think about a banner at the top of the specs website (or each
> individual spec) that points this out? I'm happy to do the work if we agree
> it's a good thing to do. My suggested wording:
>
> "NOTE: specifications are a point-in-time design reference, not up-to-date
> feature documentation."
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] TLS by default

[Julia Kreger]

On Wed, Mar 14, 2018 at 4:52 AM, Dmitry Tantsur  wrote:
> Just to clarify: only for public endpoints, right? I don't think e.g.
> ironic-python-agent can talk to self-signed certificates yet.
>
>

For what it is worth, it is possible for IPA to speak to a self signed
certificate, although it requires injecting the signing private CA
certificate into the ramdisk or iso image that is being used. There
are a few other options that can be implemented, but those may also
lower overall security posture.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] PTG Summary

[Julia Kreger]

The Ironic PTG Summary - The blur(b) from the East

In an effort to provide visibility and awareness of all the things
related to Ironic, I've typed up a summary below. I've tried to keep
this fairly generalized with enough context and convey action items or
the instances of consensus where applicable. It goes without saying
that the week went by as a complete blur. We had to abruptly change
our schedule around, some fine detailed topics were missed. A special
thanks to Ruby Loo for taking some time to proof read this for me.

-Julia

-

From our retrospective:

As seems to be the norm with retrospectives, we did bring up a number
of issues that slowed us down, hindered us, or hindered the ability to
move faster. A great deal of this revolved around specifications, and
the perceptions that tend to occur.

Action Items:

* Jroll will bring up for discussion if we can update the theme for
rendered specs documentation to highlight that the specs are points in
time references for design, and are not final documentation.
* TheJulia will revise our specification template to attempt to be
more clear about *why* we are asking the questions, also to suggest
but not require proof of concept code

After our retrospective, we spoke about things that can improve our
velocity. This sort of discussion tends to always come up, and focused
on community cultural aspects of revising/helping land code. The
conclusion we quickly came to was that communication or context of the
contributor is required. One of the points raised, that we did not get
to, was that we should listen to contributor's perceptions, which
really goes back to communication.

As time went on, we shifted gears to a high level status of ironic,
and there are some items to take away:

* Inspector, at a high level, could use some additional work and
contributors. Virtual media boot support would be helpful, and we may
look at breaking some portions out and moving them into ironic.
Additional High Availability work may be needed, at the same time it
may not be needed. Entirely to be determined.

* Ironic-ui presently has no active contributors, but is stable. Major
risk right now is a breaking change coming from Horizon, which was
also discussed earlier in the week with Horizon. Will add testing such
that horizon's gate triggers ironic-ui testing and raises visibility
to breaking changes.

* Ironic itself got a lot completed this cycle, and we should expect
quite a bit this cycle in terms of clean-up from deprecation.

* Networking-baremetal received a good portion of work this cycle due
to routed networks support. \o/

* Networking-generic-switch seems to be in a fairly stable state at
this point. Some trunk awareness has been added, as well as some new
switches and bug fixes.

* Bifrost has low activity, but at the same time we're seeing new
contributors fix issues or improve things, which is a good sign.

* Sushy got authentication and introspection support added this cycle.
We discussed that we may want to consider supporting RAID (in terms of
client actions), as well as composable hardware.

After statuses, we shifted into discussing the future.

We started the entire discussion of the future with a visioning
exercise to help frame the future, so we were all using the same words
and had the same scope in mind when discussing the future of Ironic.
One thing worth noting is upfront there was a lot of alignment, but we
sometimes were just using slightly different words or concepts. Taking
a little more time to reconcile those differences allowed us to relate
additional words to the same meaning. Truly this set the stage for all
of the other topics, and gave us the common reference point to grasp
if what we were talking about made sense. Expect Jroll to send out an
email to the mailing list to summarize this further, and from this
initial discussion we will likely draft a formal vision document that
will allow us to continue having the same reference point for
discussions. Maybe one day your light bulb will be provisioned with
Ironic!

Deploy Steps

In terms of the future, we again returned to the concept of breaking
up deployments into a series of steps. Without going deep into detail,
this is a very large piece of functionality and would help solve many
problems and desires that exist today, especially where some operators
wish things like deploy-time raid, or to flash firmware as part of the
baremetal node provisioning process. This work is also influenced by
traits, because traits can map to actions that need to be performed
automatically. In the end, we agreed to take a small step, and iterate
from there. Specifically adding a deploy steps framework and splitting
our current deploy process into two logical steps.

Location Awareness

"Location awareness" as we are calling it, or possibly better stated
as "conductor to node affinity" is a topic that we again revisited.
This is important as many operators desire a single pane of glass for
their 

Re: [openstack-dev] [horizon][ptg] Horizon PTG Highlights

[Julia Kreger]

On Tue, Mar 6, 2018 at 2:08 PM, Ivan Kolodyazhny  wrote:

> Horizon needs to fix integration tests
>
> Ironic UI team wants to have their integration tests based on Horizon tests

Not exactly. There are multiple goals, with the central end goal of
preventing breaking changes in horizon from breaking ironic-ui
horribly. This gives Horizon improved feedback as to if major changes
are good or not, and reduces our overall cost to maintain. What we
want and intend is to get a working integration test job in the
ironic-ui repository that is triggered when a change is proposed in
the horizon repository.

Thanks!

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Cancelling this week’s ironic meeting - Next meeting February 12th

[Julia Kreger]

Greetings everyone!

Given the weather impact upon travel out of Dublin the end of this last
week (and this week at this point...), we’re going to cancel today’s
meeting.

The rough list of priorities for this week:

* Rocky Priorities - Expect a patch to be proposed in the next 24 hours.
* Rescue testing patches
* Pickup graphical console specs and patches in order to get a list going

I want to thank everyone that attended the PTG and those that held the fort
down while many of us were busy last week. I’ll ping contributors
individually regarding items that need more definition to proceed into this
cycle as the week goes on.

Otherwise, have a wonderful week everyone!

-Julia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Polling for new meeting time?

[Julia Kreger]

On Mon, Mar 5, 2018 at 1:48 AM Dmitry Tantsur  wrote:

> On 03/04/2018 09:46 PM, Zhipeng Huang wrote:
> > Thx Julia,
> >
> > Another option is instead of changing meeting time, you could establish a
> > tick-tock meeting, for example odd weeks for US-Euro friendly times and
> even
> > weeks for US-Asia friendly times.
>
> We tried that roughly two years ago, and it did not work because very few
> people
> showed up on the APAC time. I think the goal of this poll is to figure out
> how
> many people would show up now.


Exactly, the overlap is critical to understand. My preference is to try and
keep one meeting time. If there are no good times, then we might want to
consider something like office hours, but we will need to adapt planning
and coordination. I’m not sure I’ve had enough coffee yet to think about
that further. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Polling for new meeting time?

[Julia Kreger]

On Mon, Mar 5, 2018 at 1:47 AM Dmitry Tantsur  wrote:

>
> > Please don't feel the need to select times that would be burdensome to
> > yourself. This is only to gather information as to the time of day
> > that would be ideal for everyone. All times are set as UTC on the
> > poll.
>
> Are you sure? I'm asking because the last time I checked Doodle created all
> polls in some specific time, defaulting to your local time. Then for each
> participant it converts the times to their local time. E.g. for me the
> time span
> is 1am to to 12am Berlin time (UTC+1), is it what you expected?
>

If memory serves, it is user preference based upon prior usage, although I
created it in UTC.

I guess I kind of forgot that they automatically do timezone adjustment
now. It should do the right thing. And people should set their time zone
and times accordlying.

>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Polling for new meeting time?

[Julia Kreger]

Greetings everyone!

As our community composition has shifted to be more global, the
question has arisen if we should consider shifting the meeting to be
more friendly to some of our contributors in the APAC time zones.
Alternatively this may involve changing our processes to better plan
and communicate, but the first step is to understand our overlaps and
what might work well for everyone.

I have created a doodle poll, from which I would like understand what
times would ideally work, and from there we can determine if there is
a better time to meet.

The poll can be found at: https://doodle.com/poll/6kuwixpkkhbwsibk

Please don't feel the need to select times that would be burdensome to
yourself. This is only to gather information as to the time of day
that would be ideal for everyone. All times are set as UTC on the
poll.

Once we have collected some data, we should expect to discuss during
our meeting on the 12th.

Thanks everyone!

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic][Bifrost] Manually enrolling a node

[Julia Kreger]

> No valid host was found. Reason: No conductor service registered which
> supports driver agent_ipmitool. (HTTP 400)
>
> I can't see anything helpful in the logs. What driver should I be using for
> bifrost? agent_ipmitool seems to be enabled in ironic.conf.

Weird, I'm wondering what the error is in the conductor log. You can
try using "ipmi" for the hardware type that replaces
agent_ipmitool/pxe_ipmitool.

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Re-adding Jim Rollenhagen to ironic-core

[Julia Kreger]

As time goes on it is natural for corporate interests to ebb and flow.
Sometimes this comes as a new side project which complements
OpenStack. Sometimes it is a negative hit where several contributors
are abruptly in search of new jobs. Sadly, I think there is some
normalcy to that. What we do often experience is the reverse reverse
where someone has left[0] and later returns to the community.

Since Jim has resumed working on Ironic[1], I think it naturally makes
sense to add Jim back to ironic-core. This has come up for discussion
several times amongst the ironic-core members over the past two months
since Jim returned, including at the PTG. Every member of ironic-core
has expressed positive feedback to re-adding Jim.

In less than two months, Jim has resumed reviewing[2] and contributing
to ongoing discussions in the community. He has expressed a desire to
help and there is no reason we should deny him the ability.

I will re-add Jim to ironic-core sometime this week if there are no objections.

If anyone objects, please do so promptly.

-Julia

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118036.html
[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2017-12-06.log.html#t2017-12-06T17:24:39
[2] http://stackalytics.com/report/contribution/ironic/90

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Julia Kreger]

Hey Vasyl!

This is saddening news, but thank you for letting us know. It has been a
pleasure working with you!

I’ve gone ahead and removed you from ironic-core.

Until next time!

-Julia

On Fri, Feb 23, 2018 at 2:02 AM Vasyl Saienko  wrote:

> Hey Ironic community!
>
> Unfortunately I don't work on Ironic as much as I used to any more, so i'm
> stepping down from core reviewers.
>
> So, thanks for everything everyone, it's been great to work with you
> all for all these years!!!
>
>
> Sincerely,
> Vasyl Saienko
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] evening gathering at the PTG

[Julia Kreger]

Greetings Ironicers!

Thanks to derekh, we have a reservation for our evening gathering at the
PTG!

We will be gathering at Fegan’s Pub on Tuesday the 27th at 7 PM.

146 Drumcondra Rd Lower
Drumcondra, Dublin 9
http://faganspub.ie

If anyone is interested in joining us that has not previously let us know,
please let us know so we can update our reservation.

Thanks,
-Julia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] PTG Planning Etherpad

[Julia Kreger]

Greetings fellow Ironic humanoids!

We have had a planning etherpad [1] up for a couple weeks collecting ideas.

If you plan on attending the Ironic sessions at the PTG, please post
any additional ideas as well as feedback for the other ideas. We also
need an idea of interest for the purposes of prioritization, so a +1
on items you feel is important will help us create an agenda.

If you will not be attending the PTG and have an item that requires
discussion, please feel free to add items and provide feedback. If
there is a particular item that you feel needs the attention of the
Ironic team, make sure that you provide additional context as to why
an item is important, and any references that may help context.

I will rank the items by priority, and generate a reasonable agenda
from the ideas this coming Friday the 16th. Items added after 5 PM UTC
on the Friday the 16th may not make the agenda.

Thanks,

-Julia

[1] https://etherpad.openstack.org/p/ironic-rocky-ptg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Nominating Hironori Shiina for ironic-core

[Julia Kreger]

Since all of our ironic cores have replied and nobody has stated any
objections, I guess it is time to welcome Hironori to the team! I will
make the changes in gerrit after coffee.

Thanks everyone!

-Julia

On Fri, Feb 9, 2018 at 7:13 AM, Sam Betts (sambetts)  wrote:
> +1
>
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Rocky PTL candidacy

[Julia Kreger]

Hi Everybody!

I am hereby announcing my candidacy and self nomination for the
Rocky cycle ironic PTL position.

I'm fairly certain most of you know me by this point and know how
much I care about the community as well as our efforts to automate
the deployment and configuration of baremetal infrastructure.

For those of you who do not yet know me, I've been involved in
OpenStack since the beginning of the Juno cycle, and have been working
with the ironic community since the beginning of the Kilo cycle.

I am very passionate about ironic, but I recognize that there is more
work to be done, new directions to head in, and challenges to conquer.

My vision is for ironic to be utilized in more use cases outside of
what we have typically seen as our primary user. It is necessary to
expand on existing relationships and to build new relationships going
forward.

My hope is for us to continue to grow as a community. While we have
had set backs like all projects, we still have massive potential.

Thank you for your consideration,

Julia Kreger (TheJulia)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Nominating Hironori Shiina for ironic-core

[Julia Kreger]

I would like to nominate Hironori Shiina to ironic-core. He has been
working in the ironic community for some time, and has been helping
over the past several cycles with more complex features. He has
demonstrated an understanding of Ironic's code base, mechanics, and
overall community style. His review statistics are also extremely
solid. I personally have a great deal of trust in his reviews.

I believe he would make a great addition to our team.

Thanks,

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] FFE request for deprecating python-oneviewclient from OneView interfaces

[Julia Kreger]

Circling back to this,

Since Dmitry and myself agreed to continue reviewing this work, I
believe we have implicitly agreed to grant this FFE and continue to
land this work. Should anyone disagree, please reply indicating as
such. I will also bring this up during our weekly meeting that is in
about an hour.

-Julia

On Tue, Jan 23, 2018 at 8:57 AM, Ricardo Araújo  wrote:
> Hi,
>
> I'd like to request an FFE for deprecating python-oneviewclient and
> introduce python-hpOneView in OneView interfaces [1]. This migration was
> performed in Pike cycle but it was reverted due to the lack of a CA
> certificate validation in python-hpOneView (available since 4.4.0 [2]).
>
> As the introduction of the new lib was already merged [3], following changes
> are in scope of this FFE:
> 1. Replace python-oneviewclient by python-hpOneView in power, management,
> inspect and deployment interfaces for OneView hardware type [4]
> 2. Move existing ironic related validation hosted in python-oneviewclient to
> ironic code base [5]
> 3. Remove python-oneviewclient dependency from Ironic [6]
>
> By performing this migration in Queens we will be able to concentrate
> efforts in maintaining a single python lib for accessing HPE OneView while
> being able to enhance current interfaces with features already provided in
> python-hpOneView like soft power operations [7] and timeout for power
> operations [8].
>
> Despite being a big change to merge close to the end of the cycle, all
> migration patches have received core reviewers attention lately and a few
> positive reviews. They're also passing in both the community and UFCG
> OneView CI (running deployment tests with HPE OneView). Postponing this will
> be a blocker for the teams responsible for maintaining this hardware type
> and both python libs for the next cycle.
>
> dtantsur and TheJulia have kindly agreed to keep reviewing this work during
> the feature freeze window, if it gets an exception.
>
> Thanks,
> Ricardo (ricardoas)
>
> [1] - https://bugs.launchpad.net/ironic/+bug/1693788
> [2] - https://github.com/HewlettPackard/python-hpOneView/releases/tag/v4.4.0
> [3] - https://review.openstack.org/#/c/523943/
> [4] - https://review.openstack.org/#/c/524310/
> [5] - https://review.openstack.org/#/c/524599/
> [6] - https://review.openstack.org/#/c/524729/
> [7] - https://review.openstack.org/#/c/510685/
> [8] - https://review.openstack.org/#/c/524624/
>
> Ricardo Araújo Santos -
> www.lsd.ufcg.edu.br/~ricardo
>
> M.Sc in Computer Science at UFCG - www.ufcg.edu.br
> Researcher and Developer at Distributed Systems Laboratory -
> www.lsd.ufcg.edu.br
> Paraíba - Brasil
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[Julia Kreger]

> And actually I almost think the holiday time is the best time since the
> fewest number of people are going to care. But maybe I'm wrong. I do wonder
> if nobody is around to watch a 3rd Party CI for two weeks, how likely is it
> to still be working when they get back?
>
> I'm not vehemently opposed to delaying, but somewhat opposed.
>
> Thoughts?

I agree and disagree of course. :)  Arkady raises a good point about
availability of people, and the simple fact is they will be broken if
nobody is around to fix them. That being said, the true measurement is
going to be if third party CI shows the commits to remove the folders
as passing. If they pass, ideally we should proceed with removing them
sooner rather than later to avoid confusion. If they break after the
removal of the folders but still ultimately due to the removal of the
folders, we have found a bug that will need to be corrected, and we
can always temporarily revert to restore the folders in the mean time
until people return.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Booting IPA from cinder: Was: Summary of ironic sessions from Sydney

[Julia Kreger]

Greetings Michael,

I believe It would need to involve multiple machines at the same time.

I guess there are two different approaches that I think _could_ be
taken to facilitate this:

1) Provide a facility to use a specific volume as the "golden volume"
to boot up for IPA, and then initiate copies of that volume. The
downside that I see is the act of either copying the volume, or
presenting a snapshot of it that will be deleted a little later. I
think that is really going to depend on the back-end, and if the
backend can handle it or not. :\

2) The other possibility that I'm wondering is if we boot machines to
a read-only "golden volume", with a bootloader and a ramdisk that ends
up switching root over to a file stored on the filesystem being
mounted via the loopback. It seems evil, but I think it should work
just fine and does not involve as much network traffic as copying all
of the contents of a huge ramdisk over the wire into RAM. Of course,
then the problem is keeping kernels/drivers in sync...

I guess the question becomes, what is more appealing from an operator
standpoint, in terms of care and feeding. I suspect #2 would involve
some very specific ramdisk modifications, which may not improve the
hurdle being encountered with iterating with drivers faster.

I can't help but wonder if the headache is building an image with dib,
uploading it, then updating the node driver_info, and then deploying
to that node again.

Maybe if we could have dib write a fully formed image out to an iscsi
target... Maybe that might make the world moderately happy?

The more I think about it, the more I like #1 from a simplicity
standpoint that we could iterate upon, we would just likely have to
classify the feature as "very experimental" and stress operational
behavior issues that would/could arise, and maybe at some point
provide some tunable behavior settings as we better understand needs.

-Julia

On Wed, Nov 22, 2017 at 6:45 PM, Michael Still  wrote:
> Thanks for this summary. I'd say the cinder-booted IPA is definitely of
> interest to the operators I've met. Building new IPAs, especially when
> trying to iterate on what drivers are needed is a pain so being able to
> iterate faster would be very useful. That said, I guess this implies booting
> more than one machine off a volume at once?
>
> Michael
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Question about pxe_ssh drivers

[Julia Kreger]

On Tue, Nov 21, 2017 at 10:59 AM, Waines, Greg
 wrote:
> i am now thinking that perhaps i am thinking of a USE CASE that is NOT the
> typical IRONIC USE CASE.

\o/

> i.e.
>
> I think the ‘typical’ IRONIC USE CASE is that there are a pool of physical
> servers
> that are available to run requested Instances/Images on.
>
>
> However,
>
> the USE CASE that i am thinking of is where there are ‘DEDICATED’ physical
> servers
>
> deployed for specific purposes where I was thinking of using IRONIC to
> manage the Images running on these servers.
>
> ( This is for say a Industrial / Control type scenario )
>
> ( It’s sort of using IRONIC as simply a generic boot server ... of bare
> metal servers )

As it stands, your assessment of the typical use case is correct. But
at the same time, we do and have seen some operators directly use
ironic to deploy dedicated servers, in either a directly orchestrated
against ironic's API process. Largely the use cases have been managed
services/lab environments in data centers where machines may need to
be rebuilt or redeployed fairly often.

I believe it would be possible, at least conceptually with power
control, as ironic expects to check and be able to assert power
control state. Part of this behavior can be disabled, or human driven
with a button push, but from experience, it is much easier to be able
to remotely tell something to cycle power.

Operating with-in Ironic's management framework without modifying the
process or concepts, I guess in an industrial/controls scenario, we
would likely end up with some sort of PLC integrated power driver,
with enough configuration for each baremetal node to potentially
control power. The closest thing we have to that right now is an SNMP
power driver (https://docs.openstack.org/ironic/pike/admin/drivers/snmp.html).
The SNMP power driver is intended for use with power distribution
units where the outlet's power can be turned on/off remotely.

> Any comments on whether it makes sense to do this with Ironic ?

I think it comes down to the needs as it relates to automating such a
deployment process, or possibly more clearly defining the deployment
process as you would see.


> Is there an alternative OpenStack project to do this sort of thing ?

People do use bifrost to build a standalone ironic installation to
kind of do things along these lines. Bifrost is not intended to be for
long-lived management of machines, but it does now support hooking up
keystone as well, so it could be a nice happy median, and we're always
happy to accept patches to bifrost that solves someone's problem.

> ( in my use case, the end user is already using OpenStack in a traditional
> sense for
>   VMs on compute nodes ... but would like to extend the solution to manage
> images
>   on bare metal servers )

Totally viable, either with or without nova, depending on the process
that needs to be fulfilled. One thing worth noting with baremetal
hardware is the security implications that do exist. Ironic's API is
built around the concept that the user is not a normal user, but an
administrative user. I'd personally love to change that with time, but
it is far from a simple undertaking in a generic sense.

Going back to the previous question of reset functions and, ironic
actually turns the power off, and then back on to perform a reset.
With cases like wake-on-lan, there is nothing that can be done. I
believe that driver might just not attempt to do anything, hence my
comment about maybe some sort of PLC power driver, or perhaps the SNMP
driver.

As for is anything deployed immediately upon enroll, ironic presently
does not do that as it expects you to step through the state machine
so the node passes through cleaning. If your hardware or use case does
not need or require cleaning, then you can run through the process
quite quickly with a script or an ansible playbook (which is exactly
what bifrost does for CI testing)

Hope this helps!

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Julia Kreger]

On Tue, Nov 14, 2017 at 9:16 AM, Pavlo Shchelokovskyy
 wrote:
> As a core in n-g-s myself I'm happy with either 1) or 2), but not really
> fond of 3) as it kind of stretches the networking-baremetal scope too much
> IMHO.

Personally, I'm happy with 1 or 2. I personally think we might as well
lean towards 1 from a standpoint that we've had operators bring up
using n-g-s, and while we as a community predicate that it is not
intended for production use, and they are aware of that, they need
something that works for their baremetal deployment scenario. Given
the common usage, it just seems logical to me that we go for option 1.
Especially since we already have a fairly good practice in Ironic of
not approving things in sub-project that we do not understand.

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Summary of ironic sessions from Sydney

[Julia Kreger]

Greetings ironic folk!

Like many other teams, we had very few ironic contributors make it to
Sydney. As such, I wanted to go ahead and write up a summary that
covers takeaways, questions, and obvious action items for the
community that were raised by operators and users present during the
sessions, so that we can use this as feedback to help guide our next
steps and feature planning.

Much of this is from my memory combined with notes on the various
etherpads. I would like to explicitly thank NobodyCam for reading
through this in advance to see if I was missing anything at a high
level since he was present in the vast majority of these sessions, and
dtantsur for sanity checking the content and asking for some
elaboration in some cases.

-Julia



Ironic Project Update
=

Questions largely arose around use of boot from volume, including some
scenarios we anticipated that would arise, as well as new scenarios
that we had not considered.

Boot nodes booting from the same volume
---

From a technical standpoint, when BFV is used with iPXE chain loading,
the chain loader reads the boot loader and related data from the
cinder (or, realistically, any iSCSI volume). This means that a
skilled operator is able to craft a specific volume that may just turn
around and unpack a ramdisk and operate the machine solely from RAM,
or that utilize an NFS root.

This sort of technical configuration would not be something an average
user would make use of, but there are actual use cases that some large
scale deployment operators would make use of and that would provide
them value.

Additionally, this topic and the desire for this capability also come
up during the “Building a bare metal cloud is hard” talk Q

Action Item: Check the data model to see if we prohibit, and consider
removing the prohibition against using the same volume across nodes,
if any.

Cinder-less BFV support
---

Some operators are curious about booting Ironic managed nodes without
cinder in a BFV context. This is something we anticipated and built
the API and CLI interfaces to support this. Realistically, we just
need to offer the ability for the data to be read and utilized.

Action Item: Review code and ensure that we have a some sort of no-op
driver or method that allows cinder-less node booting. For existing
drivers, it would be the shipment of the information to the BMC or the
write-out of iPXE templates as necessary.

Boot IPA from a cinder volume
-

With larger IPA images, specifically in cases where the image contains
a substantial amount of utilized or tooling to perform cleaning,
providing a mechanism to point the deployment Ramdisk to a cinder
volume would allow more efficient IO access.

Action Item: Discuss further - Specifically how we could support as we
would need to better understand how some of the operators might use
such functionality.

Dedicated Storage Fabric support


A question of dedicated storage fabric/networking support arose. For
users of FibreChannel, they generally have a dedicated storage fabric
by the very nature of separate infrasturcture. However, with ethernet
networking where iSCSI software initiators are used, or even possibly
converged network adapters, things get a little more complex.

Presently, with the iPXE boot from volume support, we boot using the
same interface details for the neutron VIF that the node is attached
with.

Moving forward, with BFV, the concept was to support the use of
explicitly defined interfaces as storage interfaces, which could be
denoted as "volume connectors" in ironic by type defined as "mac". In
theory, we begin to get functionality along these lines once
https://review.openstack.org/#/c/468353/ lands, as the user could
define two networks, and the storage network should then fall to the
explicit volume connector interface(s). The operator would just need
to ensure that the settings being used on that storage network are
such that the node can boot and reach the iSCSI endpoint, and that a
default route is not provided.

The question then may be, does Ironic do this quietly for the user
requesting the VM or not, and how do we document the use such that
operators can conceptualize it. How do we make this work at a larger
scale? How could this fit or not fit into multi-site deployments?

In order to determine if there is more to do, we need to have more
discussions with operators.

Action items:

* Determine overall needs for operators, since this is implementation
architecture centric.
* Plan forward path form there, if it makes sense.

Note: This may require more information to be stored or leveraged in
terms of structural or location based data.

Migration questions from classic drivers to Hardware types
--

One explicit question from the operator community was if we intended
to perform a 

Re: [openstack-dev] Upstream LTS Releases

[Julia Kreger]

On Sun, Nov 12, 2017 at 4:03 AM, Thomas Goirand  wrote:
> Instead of thinking "this will be more work", why don't you think of the
> LTS as an opportunity to only release OpenStack Chef for the LTS? That'd
> be a lot less work indeed, and IMO that's a very good opportunity for
> you to scale down.

+1000

Having worked downstream, I've personally spent far too much time on
forked stable branches trying to keep them in a sane/healthy state.
Our current model just encourages all of that work to happen
downstream in the dark in varying divergent ways. Even if a minor
fraction from each downstream team is freed to interact upstream, that
will help all of us working upstream regardless of what organization
we come from.

We should also keep in mind that this does present the opportunity for
an improved feedback loop. If we have an LTS branch that we receive a
huge patch on, that is an opportunity to reflect on why, and ask "What
did we miss or not understand originally?"

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

[Julia Kreger]

Sorry! A little late to the discussion with how busy I was last week.
Replies/thoughts in-line with trimmed text.


>> When I tried it I got this
>> [  370.704896] dracut-initqueue[387]: Warning: iscistart: Could not
>> get list of targets from firmware.
>>
>> perhaps we could alter iscistart to not complain if there are no
>> targets attached and just continue, then simply always have
>> rd.iscsi.firmware=1 in the kernel param regardless of storage type
>

For those that haven't been following IRC discussion, Derek was kind
enough to submit a pull request to address this in dracut.


> I think we can fix ironic (the PXE boot interface) to pass this flag when
> using boot-from-volume, what do you think?

Not exactly. We perform iPXE sanhook attachments which causes iPXE to
speak iSCSI once we trigger boot. We have no means to pass kernel
arguments. We could rewrite the way the interface works to work more
like traditional linux netbooting where the linux kernel/ramdisk are
loaded up and arguments get passed on the kernel command line, but
then we are really Linux specific instead of booting whatever is on
the filesystem.

The other case to consider is outside our specific boot-from-volume
scenario. What if an operator chose to use a SAN system outside of
OpenStack's knowledge or control for root filesystems, and a parameter
is needed by the booting OS to see the storage hardware. If we don't
provide a mechanism, then the operator has no choice but to drive the
usage of highly specific "known-good" images for their baremetal cloud
tenants.

[trim]

 So can we reconsider the proposal to add kernel parameters there? It
 could
 be a settable argument (driver_info/kernel_args), and then the IPA could
 set
 the parameters properly on the image. Or any other option is welcome.
 What are your thoughts there?
>>>
>>>
>>>
>>> Well, we could probably do that *for IPA only*. Something like
>>> driver_info/deploy_image_append_params. This is less controversial than
>>> doing that for user instances, as we fully control the IPA boot. If you
>>> want
>>> to work on it, let's start with a detailed RFE please.
>>>

I believe the reason we avoided providing the ability to pass
parameters to the deployed image when a partition image is used, was
because we wanted whatever was written to be pristine and unmodified
until it first booted, but I don't think the argument holds with the
way we presently operate by mounting [1] and placing a grub-config
file [2]. Regardless of what we do on the filesystem, we still end up
changing filesystem metadata in this process because it is a
read/write mount for root partition that has been written out.

Personally, It _feels_ like it wouldn't add much complexity to add a
file to /etc/grub.d or content to /etc/defaults/grub to facilitate
allowing an operator to pass standardized kernel parameters when
needed for their environment. Such a capability would realistically
help ease use of TripleO Overcloud deployments as well as bare metal
instance users when partition images are used. Of course, there is no
real option for a whole disk image to support doing such.

-Julia

[1]: 
http://git.openstack.org/cgit/openstack/ironic-python-agent/tree/ironic_python_agent/extensions/image.py#n94
[2]: 
http://git.openstack.org/cgit/openstack/ironic-python-agent/tree/ironic_python_agent/extensions/image.py#n136

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

[Julia Kreger]

Greetings Yolanda!

I guess I'm slightly not clear. In fact, I may be slightly even more
confused since we've discussed this directly. Thinking out loud, there are
two different scenarios of booting from iSCSI.

1) Human created/assigned/associated LUN off of a SAN which we want a node
to boot from, and that LUN lives onward as the "storage" for the node.

2) Cinder facilitated LUN off of $something that we want a node to boot
from. This largely would be the logic we added this past cycle to support
either booting via iPXE to iSCSI, or in the case of the iRMC driver, to set
the HBA to boot/attach from specific volumes.

I think your largely bringing up the first case when we speak of booting
from iSCSI. If not, then we technically haven't reached the point where we
are explicitly supporting hardware HBA use, but no time like the present!

Since there are many things here, I think we need to make sure we are
contextually on the same page. If any of this is wrong, please correct me:

* You deploying a partition/filesystem image.
* Ironic is partitioning and executing the installation of grub.
* The scenario where your operating requires the boot loader command line
to be updated with specific arguments.
* Part of the problem is the ramdisk initialization where it is only honors
arguments in your specific case.
* Ironic does not presently provide a mechanism to append standard kernel
arguments outside of netboot. Example from ages ago that many may remember,
having to add ``noapic`` in some cases with a SMP kernel is to be used.

I believe it makes sense to have some sort of mechanism to append to the
default list in this case. There is the ansible deploy driver, but it seems
like that might be overkill for setting boot loader parameters, and Ironic
is explicitly executing grub-isntall.

I think the only reason we've resisted in supporting updating the defaults
file the past is because it would mean explicitly writing data to the grub
defaults file on the filesystem, I suspect our comfort level with
supporting that now may be different. In hindsight, considering we
essentially already support this with netboot but not local boot with a
partition image, I think we should add support for appending default
parameters.

Thoughts?

-Julia


On Mon, Oct 16, 2017 at 2:06 AM, Yolanda Robla Mota 
wrote:

> Hi
> Recently i've been helping some customers in the boot from ISCSI feature.
> So far everything was working, but we had a problem when booting the
> deployment image.
> It needed specifically a flag rd.iscsi.ibft=1 rd.iscsi.firmware=1 in the
> grub commands. But as the generated deployment image doesn't contain these
> flags, ISCSI was not booting properly. For other hardware setups, different
> flags may be needed.
> The solution was to manually execute a virt-customize on the deployment
> image to hardcode these parameters.
> I wonder if we can add some feature in Ironic to support it. We have
> discussed about kernel parameters several times. But at this time, it
> affects ISCSI booting. Not having a way in Ironic to customize these
> parameters forces to manual workarounds.
> So can we reconsider the proposal to add kernel parameters there? It could
> be a settable argument (driver_info/kernel_args), and then the IPA could
> set the parameters properly on the image. Or any other option is welcome.
> What are your thoughts there?
>
> Thanks
>
> --
>
> Yolanda Robla Mota
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
> 
>
> C/Avellana 213
>
> Urb Portugal
>
> yrobl...@redhat.comM: +34605641639
> 
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Julia Kreger]

Greetings Flavio,

My perception is that if we need to encourage the spreading of task, roles,
responsibility amongst many. In other words, encourage building trust.
Building trust should hopefully foster a personal sense of investment
and responsibility, hopefully resulting in further diversity as time goes by
improving contributor retention.

That being said, I think step zero would be an assessment of what data is
available and the identification of what is missing from the puzzle.

-Julia

On Fri, Oct 13, 2017 at 5:45 AM, Flavio Percoco  wrote:
> Greetings,
>
> Some of you, TC candidates, expressed concerns about diversity and
> inclusiveness
> (or inclusivity, depending on your taste) in your candidacy. I believe this
> is a
> broad, and some times ill-used, topic so, I'd like to know, from y'all, how
> you
> think we could make our community more inclusive. What areas would you
> improve
> first?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][election] Question for the candidates

[Julia Kreger]

On Thu, Oct 12, 2017 at 12:42 PM, Clay Gerrard  wrote:
[trim]
> To candidates:
>
> Would you please self select a change (or changes) from
> https://github.com/openstack/governance/ in the past ~12 mo or so where they
> thought the outcome or the discussion/process was particular good and
> explain why you think so?

The one thing that really sticks out to me is the vision statement [1]
by the TC.
Not just because such things are scary, but that the process to reach
a vision really
forces the entire group to reach a mutual understanding. I think that
the exercise of
writing the vision was worthwhile, largely because one can't see where
one is going,
without understanding where one is presently.

[1]: https://review.openstack.org/#/c/453262

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][election] Question for the candidates

[Julia Kreger]

On Thu, Oct 12, 2017 at 11:38 AM, Ed Leafe  wrote:
> In the past year or so, has there been anything that made you think “I wish 
> the TC would do something about that!” ? If so, what was it, and what would 
> you have wanted the TC to do about it?

There have been some great replies thus far, possibly the best so far
is Emilien's reply.

That being said, I have felt like many of our problems are
fundamentally a lack of trust.
I don't think it is a misplaced lack of trust, but more sub-optimal
behaviors that have
impacted the way we work in order to maintain control. In reality none
of us are really
"in control." All we can do is try to row in the same general
direction in order to reach
a mutually agreeable outcome.

I would like to see the TC encourage reflection upon the path taken by
each project
for mutual understandings of mission and direction to be reached
inside of each project.
Hopefully through that, we can build trust, and possibly undo some of
the negative impact
that highly focused agendas have had on our community.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][election] TC candidacy

[Julia Kreger]

Greetings Stackers!

I would like to submit my candidacy for the Technical Committee.

I have been involved with the OpenStack community since the Juno cycle and
interested in OpenStack while I worked as an engineer supporting data center
hosting operations. My experience having bridged these worlds means that I
understand the life of an operator and the thought process of a developer.
I care deeply about the success of OpenStack and believe that it is vital
for the the marketplace and open innovation.

I believe we have been excellent at building social and process complexity
to our own detriment. I feel that we need to evaluate and reconsider why we
do the things we do. I feel that we need better stand-alone usage cases and
usage. A shorter feedback loop with those different use cases would also help
us iterate faster as our software could then be consumed more easily.

It is true containers have taken over the limelight with many companies,
as they have shifted their resources away from OpenStack. I feel that we
must not forget that infrastructure and the underlying building blocks have
a place as well. It is also upon us to advocate for that as community
building is our strongest avenue to spread the word of OpenStack.

Many may know me as TheJulia on IRC. I've largely worked on Ironic and to a
lesser extent TripleO far off in the past. I'm one of those people that keeps
odd hours and tries to help others, as I feel strongly about supporting our
community and its users. I feel that this in turn supports ourselves and
helps us in the long term. I believe strongly in developing contributors and
also plainly admitting when I just don't know the answer to a question.
At the same time, I'm happy to help investigate and try to understand.

While we have navigated to this point with the hype curve, we need to set
our future course with a variety of thoughts and experiences. Combined with
my strong feelings about our community and overall mission, I feel that I
would be a good addition to the TC.

Thank you for your consideration,
Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Proposing Shivanand Tendulker for ironic-core

[Julia Kreger]

> I would like to propose Shivanand (stendulker) to the core team.
+1

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [tc][nova][ironic][mogan] Evaluate Mogan project

[Julia Kreger]

[...]
>> The short explanation which clicked for me (granted it's probably an
>> oversimplification, but still) was this: Ironic provides an admin
>> API for managing bare metal resources, while Mogan gives you a user
>> API (suitable for public cloud use cases) to your Ironic backend. I
>> suppose it could have been implemented in Ironic, but implementing
>> it separately allows Ironic to be agnostic to multiple user
>> frontends and also frees the Ironic team up from having to take on
>> yet more work directly.
>
>
> ditto!
>
> I had a similar question at the PTG and this was the answer that convinced
> be
> may be worth the effort.
>
> Flavio
>

For Ironic, the question did come at the PTG up of tenant aware
scheduling of owned hardware, as in Customer A and B are managed by
the same ironic, only customer A's users should be able to schedule on
to Customer A's hardware, with API access control restrictions such
that specific customer can take action on their own hardware.

If we go down the path of supporting such views/logic, it could become
a massive undertaking for Ironic, so there is absolutely a plus to
something doing much of that for Ironic. Personally, I think Mogan is
a good direction to continue to explore. That being said, we should
improve our communication of plans/directions/perceptions between the
teams so we don't adversely impact each other and see where we can
help each other moving forward.

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] [ironic-ui] Proposing Anup Navare (anupn) for ironic-ui-core

[Julia Kreger]

Greetings fellow stackers!

I would like to propose adding Anup Navare to ironic-ui-core. Anup has
been involved with ironic-ui this past cycle as well as various other
areas across ironic which gives me further confidence in making this
proposal.

I have already informally polled the existing ironic-ui-core members,
to which everyone has responded positively. If there are no
objections, I'll make the change in one week.

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Team dinner at the PTG?

[Julia Kreger]

I did some searching around yesterday near the venue for places to
eat. The area is very spread out, but
http://coloradopubco.com/stapleton-caseys/ is with-in walking
distance. I spoke with some of the staff, and they said they were good
with large groups, and that Mondays is somewhat hit or miss regarding
being busy or not.

I've been thinking it might be best for us to descend upon the bar,
and kind of go from there, but I'll call and see if they they can do
reservations. That being said, the space really doesn't lend it's self
to a large reservation. There is also a sushi restaurant next door as
an alternative.

-Julia

On Mon, Aug 28, 2017 at 4:07 PM,   wrote:
> Great. See you all there.
>
> -Original Message-
> From: Dmitry Tantsur [mailto:dtant...@redhat.com]
> Sent: Monday, August 28, 2017 1:07 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [ironic] Team dinner at the PTG?
>
> And the final day is Monday, Sep 11th. See you there! :)
>
> On 08/23/2017 03:46 PM, Dmitry Tantsur wrote:
>> Hi folks!
>>
>> We're trying to organize an informal team meeting at some place,
>> probably with burgers and beer, in Denver. Note that it won't be sponsored.
>>
>> Please vote in the Doodle https://doodle.com/poll/nvavg9ab9ebq2e4v
>> about the days you're available.
>>
>> If you're local, we need you help finding a good place to go. Please
>> ping Julia
>> (TheJulia) or myself (dtantsur) on IRC if you're willing to help.
>>
>> Thanks,
>> Dmitry
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] pike release

[Julia Kreger]

Greetings everyone!

As some of you may have noticed, we released ironic 9.0.0 today. But
wait! There is more!

We triggered this release due to a number of issues, one of which was
that we learned that we needed the stable/pike branch for our grenade
jobs to execute properly. This was not done previously because
Ironic’s release model is incompatible with making release candidate
releases.

Once we’ve confirmed that our grenade testing is passing, we will back
port patches we had previously approved, but that had not landed, from
master to stable/pike.

As a result, please anticipate Ironic’s official Pike release for this
cycle to be 9.1.0, if the stars, gates, and job timeouts align with
us.

If there are any questions, please feel free to stop by
#openstack-ironic. We have also been keeping our general purpose
whiteboard[1] up to date, you can see our notes regarding our current
plan starting at line 120, and notes regarding gate failures and
issues starting at line 37.
Thanks!

-Julia

[1]: https://etherpad.openstack.org/p/IronicWhiteBoard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] I want to use nova api to attach volume to ironic node

[Julia Kreger]

Greetings!

This work is presently underway, although is largely an effort in
Ironic as we must orchestrate volume attachments and detachments
with-in the lifecycle of the machine. We presently have weekly status
meetings[1] which happens to occur in approximately 3 hours,  and we
have an Etherpad[2] tracking our present status and the patches
related to this effort. I've included two additional links to the
Ironic specifications [3][4] related to this subject.

Please feel free to reach out to the ironic team, or visit us in
#openstack-ironic if you have any questions.

-Julia

[1]: http://eavesdrop.openstack.org/#Ironic_Boot_from_Volume_meeting
[2]: https://etherpad.openstack.org/p/Ironic-BFV
[3]: 
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/volume-connection-information.html
[4]: 
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/boot-from-volume-reference-drivers.html

2017-07-06 5:42 GMT-04:00 王俊 :
> Hi,all:
>
>  my customer want use nova api attach volume to the node, cause they
> are afraid of oneday the node storage is useless, is somebody has a plan to
> provide this?
>
> 保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] no ironic-ui meeting today

[Julia Kreger]

Greetings my ironic cohorts!

It seems everyone is busy this week and we have nothing really to
discuss during today's ironic-ui meeting. As such, today's meeting is
cancelled.

Talk to everyone next week or on #openstack-ironic.

Thanks!

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Ironic-UI review requirements - single core reviews

[Julia Kreger]

All,

In our new reality, in order to maximize velocity, I propose that we
loosen the review requirements for ironic-ui to allow faster
iteration. To this end, I suggest we move ironic-ui to using a single
core reviewer for code approval, along the same lines as Horizon[0].

Our new reality is a fairly grim one, but there is always hope. We
have several distinct active core reviewers. The problem is available
time to review, and then getting any two reviewers to be on the same,
at the same time, with the same patch set. Reducing the requirements
will help us iterate faster and reduce the time a revision waits for
approval to land, which should ultimately help everyone contributing.

If there are no objections from my fellow ironic folk, then I propose
we move to this for ironic-ui immediately.

Thanks,

-Julia

[0]: 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/113029.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] no ironic weekly meetings next week

[Julia Kreger]

All,

Following up for our fearless PTL, the Ironic meetings next week are
cancelled due to the Summit and the schedule of various participants.
This comprises the Team meeting that would be on May 8th, the UI
meeting on May 9th, and the Boot from Volume meeting on May 11th.

As always, you can find us in #openstack-ironic if there are any
questions or concerns.

Thank you, and have a wonderful week everyone!

-Julia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Resigning as a core reviewer

[Julia Kreger]

For me, sad is an understatement. It would be a lie if I denied tears
at the moment. My brain keeps going back to the sudden tackle hug
milliseconds after NobodyCam and BadCub introduced me to the Ironic
team at the Paris summit. Seeing and having had a chance to work with
a friend that I've had for much longer than OpenStack has been a
thing, has been a pleasure and an honor.

Jay, you will be truly missed.  Please don't be a stranger though.
OpenStack is not just a community, at the end of the day it is a
family. Likely, the largest, weirdest, close knit, and argumentative
family that any of us have ever had the pleasure to be part of. Take
care of yourself, and keep your grill ready for when I get a chance to
stop by in your neck of the woods. :)

-Julia

On Wed, Apr 26, 2017 at 3:42 PM, Jay Faulkner  wrote:
> Hi all,
>
>
> As most of you know, I'm no longer being paid to work on OpenStack Ironic.
> Working with you all has been an amazing part of my career, an I've learned
> more than you'll ever know. I'll still be in #openstack-ironic, willing to
> answer any questions about something I'm an expert in. However, as I won't
> be actively participating in the project, or reviewing code anymore, I'd
> like to request my core reviewer access be removed.
>
>
> Thanks for everything! I wish for nothing but the best for everyone in the
> OpenStack community who have always treated me with kindness and patience.
>
>
> Sincerely,
>
> Jay Faulkner
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [stable] ironic-stable-maint update proposal

[Julia Kreger]

On Thu, Apr 27, 2017 at 10:21 AM, Dmitry Tantsur  wrote:

> 1. Add Ruby Loo (rloo) to the group.

+1

> 2. Remove Jay Faulkner (sigh..) per his request at [2].

+1 to the sigh.

>
> 3. Remove Devananda (sigh again..)
+1 *more sighs*

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] New mascot design

[Julia Kreger]

I love it! +1

Thank you!

-Julia

On Fri, Mar 10, 2017 at 11:28 AM, Heidi Joy Tretheway <
heidi...@openstack.org> wrote:

> Hi Ironic team,
> Here’s an update on your project logo. Our illustrator tried to be as true
> as possible to your original, while ensuring it matched the line weight,
> color palette and style of the rest. Thanks for your patience as we worked
> on this! Feel free to direct feedback to me; we really want to get this
> right for you.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Boot from Volume meeting?

[Julia Kreger]

On Wed, Mar 1, 2017 at 3:10 PM, Jim Rollenhagen  wrote:
> On Wed, Mar 1, 2017 at 9:07 AM, Dmitry Tantsur  wrote:
[trim]
>> Speaking of which, I propose the networking subteam to start (continue?)
>> having their own meeting as well. There is a lot of stuff going on that is
>> hard to catch up with.
>
>
> We stopped that meeting because it had turned into a status update. We just
> rolled it back up into the usual subteam updates.
>
> I'd like to leave it to the folks working on that to decide if they need a
> meeting to keep up with everything.

In retrospect, it feels like the networking integration work will be
something that we will never completely close out as being a topic of
regular discussion.  Part of me wishes we could efficiently share a
larger flex time block, but I feel that it  would quickly become a bit
of a logistical headache at the beginning of a cycle.

That being said, I'll propose a new meeting/meeting time.
Accordingly, I've created a doodle poll [0], with options leaning
toward Thursday/Friday.

-Julia

[0] http://doodle.com/poll/qwhnpqazmf7fn5ik

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Boot from Volume meeting?

[Julia Kreger]

Greetings fellow ironic humanoids!

As many have known, I've been largely attempting to drive Boot from
Volume functionality in ironic over the past two years.  Largely, in a
slow incremental approach, which is in part due to how I perceived it
to best fit into the existing priorities when the discussions started.

During PTG there was quite the interest by multiple people to become
involved and attempt to further Boot from Volume forward this cycle. I
would like to move to having a weekly meeting with the focus of
integrating this functionality into ironic, much like we did with the
tighter neutron integration.

I have two reasons for proposing a new meeting:

* Detailed technical status updates and planning/co-ordination would
need to take place. This would functionally be noise to a large number
of contributors in the ironic community.

* Many of these details would need need to be worked out prior to the
first part of the existing ironic meeting for the weekly status
update. The update being a summary of the status of each sub team.

With that having been said, I'm curious if we could re-use the
ironic-neutron meeting time slot [0] for this effort.  That meeting
was cancelled just after the first of this year [1].  In it's place I
think we should have a general purpose integration meeting, that could
be used as a standing meeting, specifically reserved at this time for
Boot from Volume work, but could be also by any integration effort
that needs time to sync-up in advance of the existing meeting.

-Julia

[0] 
http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/meetings/ironic-neutron-integration-meeting.yaml
[1] http://lists.openstack.org/pipermail/openstack-dev/2017-January/109536.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev