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

[Moshe Levi]

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.

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

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.
 *   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.
 *   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 ?
 *   In both use-cases we should use neutron-ironic notification to make 
sure the port binding was done successfully.

Is my understanding correct?



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

From: Miguel Lavalle 
Sent: Sunday, September 30, 2018 3:20 AM
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

Hi,

Yes, this also matches the recollection of the joint conversation in Denver. 
Please look at the "Ironic x-project discussion - Smartnics" section in 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135032.html

Regards

Miguel



On Thu, Sep 27, 2018 at 1:31 PM Julia Kreger 
mailto:juliaashleykre...@gmail.com>> wrote:
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
__
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] [neutron][stadium][networking] Seeking proposals for non-voting Stadium projects in Neutron check queue

[Miguel Lavalle]

Dear networking Stackers,

During the recent PTG in Denver, we discussed measures to prevent patches
merged in the Neutron repo breaking Stadium and related networking projects
in general. We decided to implement the following:

1) For Stadium projects, we want to add non-voting jobs to the Neutron
check queue
2) For non stadium projects, we are inviting them to add 3rd party CI jobs

The next step is for each project to propose the jobs that they want to run
against Neutron patches.

Best regards

Miguel
__
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

[Miguel Lavalle]

Hi,

Yes, this also matches the recollection of the joint conversation in
Denver. Please look at the "Ironic x-project discussion - Smartnics"
section in
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135032.html

Regards

Miguel



On Thu, Sep 27, 2018 at 1:31 PM Julia Kreger 
wrote:

> 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
>
__
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] [nova][cinder][qa] Should we enable multiattach in tempest-full?

[Matt Riedemann]

Nova, cinder and tempest run the nova-multiattach job in their check and 
gate queues. The job was added in Queens and was a specific job because 
we had to change the ubuntu cloud archive we used in Queens to get 
multiattach working. Since Rocky, devstack defaults to a version of the 
UCA that works for multiattach, so there isn't really anything 
preventing us from running the tempest multiattach tests in the 
integrated gate. The job tries to be as minimal as possible by only 
running tempest.api.compute.* tests, but it still means spinning up a 
new node and devstack for testing.


Given the state of the gate recently, I'm thinking it would be good if 
we dropped the nova-multiattach job in Stein and just enable the 
multiattach tests in one of the other integrated gate jobs. I initially 
was just going to enable it in the nova-next job, but we don't run that 
on cinder or tempest changes. I'm not sure if tempest-full is a good 
place for this though since that job already runs a lot of tests and has 
been timing out a lot lately [1][2].


The tempest-slow job is another option, but cinder doesn't currently run 
that job (it probably should since it runs volume-related tests, 
including the only tempest tests that use encrypted volumes).


Are there other ideas/options for enabling multiattach in another job 
that nova/cinder/tempest already use so we can drop the now mostly 
redundant nova-multiattach job?


[1] http://status.openstack.org/elastic-recheck/#1686542
[2] http://status.openstack.org/elastic-recheck/#1783405

--

Thanks,

Matt

__
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

[Mark Mielke]

On Sat, Sep 29, 2018 at 12:02 PM Ed Leafe  wrote:

> On Sep 28, 2018, at 12:19 PM, Chris Dent  wrote:
> > I don't think placement should be concerned about temporal aspects
> > of traits. If we can't write a web service that can handle setting
> > lots of traits every second of every day, we should go home. If
> > clients of placement want to set weird traits, more power to them.
> >
> > However, if clients of placement (such as nova) which are being the
> > orchestrator of resource providers manipulated by multiple systems
> > (neutron, cinder, ironic, cyborg, etc) wish to set some constraints
> > on how and what traits can do and mean, then that is up to them.
> It is up to the clients to determine how to use Placement. But it is up to
> Placement to give guidance as to how to best use it. If a client wants to
> hack trait names, then they certainly can, and it might work out just fine.
>

It is only up to the clients to determine how to use Placement, if the
Placement team specifies this as an intent. It's very important for users
of the system to be in alignment with the providers of the system to avoid
surprise and complications. Yes, users can hang themselves with enough rope
- but this is a reckless position to hold. Let us say that Placement and
Nova evolve traits according to a roadmap that ends up causing the users to
get stuck on an old release because they have no migration path because
they used the API in a way that was never intended, and never acknowledged.

I'm reading along with interest, and the main issue I see here is what Jay
referred to, which is that there is a process to get well formulated ideas
agreed upon and incorporated, and it does seem like this is a threat to do
something that works without following this process, not because it is
smart, but because it is possible.

I have a similar dilemma on a different system which has to do with the
proper use of labels in a system like Jira. Jira issue labels are intended
to be more flexible and defined according to user requirements to meet
needs not envisioned by the designers of the issue field schemes. They work
well well for certain ad-hoc uses, but they had side effects and
limitations which make them very poor for many uses. A key one is related
to this discussion, in that you can't easily evaluate only part of a label,
so if you did non-advisable things like to use labels instead of priority,
and you had multiple label values to indicate each priority, you end up
with rather silly evaluations like "label in ('priority_high',
'priority_medium', 'priority_low')". This gets more complex over time and
ends up being a huge burden for whoever inherits such a system. Yes, it was
to solve an original problem - but the smart person would have addressed
this with the issue field scheme and would have prevented this technical
debt burden from existing in the first place.

I think you should push Jay to propose what he thinks a good solution would
be, and start discussing these options. I'm interested in reading more
about these options.

I really don't like the idea of embedding data bits into a single string
that effectively includes both a "key" and a "value" as my own experience
suggests this is a very bad idea.

Myself, I think "traits" are not necessarily boolean. I see "brown hair" as
a human trait. However, if they are not boolean than this invites the need
to evaluate with comparison operators, and this would morph into a much
more complex system.

The idea of passing configuration data in might solve a subset of the cases
- and it might solve your subset. But, I do think there is a more general
solution possible if the requirements warranted the development.

I also want to add that I think traits should not be dynamic things that
change from second to second. The idea of passing temperature information
via traits sounded somewhat ridiculous to me. I think that might have been
the intent of the original poster to present a ridiculous example and hope
people understood. I hope nobody was taking it seriously. :-)

-- 
Mark Mielke 
__
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

[Ed Leafe]

On Sep 28, 2018, at 12:19 PM, Chris Dent  wrote:
> 
> I don't think placement should be concerned about temporal aspects
> of traits. If we can't write a web service that can handle setting
> lots of traits every second of every day, we should go home. If
> clients of placement want to set weird traits, more power to them.
> 
> However, if clients of placement (such as nova) which are being the
> orchestrator of resource providers manipulated by multiple systems
> (neutron, cinder, ironic, cyborg, etc) wish to set some constraints
> on how and what traits can do and mean, then that is up to them.

This.

It is up to the clients to determine how to use Placement. But it is up to 
Placement to give guidance as to how to best use it. If a client wants to hack 
trait names, then they certainly can, and it might work out just fine.

> On Sep 28, 2018, at 8:25 AM, Eric Fried  wrote:
> 
> 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?

The crux here is what one considers "arbitrary". If we as a project state 
"sure, go ahead and use this however you like", we are going to be complicit in 
the technical debt they accumulate, as Jay has referenced with regards to 
Nova's ComputeCapabilities filter.

We want consumers of Placement to write good, solid code that doesn't encourage 
technical debt accumulation. We have no way to prevent bad decisions by others, 
but we should never document that such usages are fine.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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

[Ed Leafe]

On Sep 29, 2018, at 10:40 AM, Jay Pipes  wrote:
> 
>> So here it is. Two of the top influencers in placement, one saying we
>> shouldn't overload traits, the other saying we shouldn't add a primitive
>> that would obviate the need for that. Historically, this kind of
>> disagreement seems to result in an impasse: neither thing happens and
>> those who would benefit are forced to find a workaround or punt.
>> Frankly, I don't particularly care which way we go; I just want to be
>> able to do the things.
> 
> I don't think that's a fair statement. You absolutely *do* care which way we 
> go. You want to encode multiple bits of information into a trait string -- 
> such as "PCI_ADDRESS_01_AB_23_CD" -- and leave it up to the caller to have to 
> understand that this trait string has multiple bits of information encoded in 
> it (the fact that it's a PCI device and that the PCI device is at 
> 01_AB_23_CD).
> 
> You don't see a problem encoding these variants inside a string. Chris 
> doesn't either.
> 
> I *do* see a problem with it, based on my experience in Nova where this kind 
> of thing leads to ugly, unmaintainable, and incomprehensible code as I have 
> pointed to in previous responses.

I think that there is huge difference between the Placement service stating 
"this is how you use this service" and actively preventing others from doing 
dumb things with Placement. If we, as a team, tell others that it is OK to 
manage state, or use a trait name to encode multiple bits of information, then 
others will be more likely to do just that, and end up with an unreadable mess 
around their part of the code that works with placement. The result will be a 
perception among others along the lines of "placement sucks". If we state 
clearly that this is not a good way to work with Placement, and they do so 
anyway, well, that's on them.

So we shouldn't enforce anything about trait names except the custom namespace 
and the length. If other service want to be overly clever and try to overload a 
trait name, it's up to them to deal with the resulting mess. But in no way 
should we *ever* encourage, even tacitly, this approach.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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

[Jay Pipes]

On 09/28/2018 04:36 PM, Eric Fried wrote:

So here it is. Two of the top influencers in placement, one saying we
shouldn't overload traits, the other saying we shouldn't add a primitive
that would obviate the need for that. Historically, this kind of
disagreement seems to result in an impasse: neither thing happens and
those who would benefit are forced to find a workaround or punt.
Frankly, I don't particularly care which way we go; I just want to be
able to do the things.


I don't think that's a fair statement. You absolutely *do* care which 
way we go. You want to encode multiple bits of information into a trait 
string -- such as "PCI_ADDRESS_01_AB_23_CD" -- and leave it up to the 
caller to have to understand that this trait string has multiple bits of 
information encoded in it (the fact that it's a PCI device and that the 
PCI device is at 01_AB_23_CD).


You don't see a problem encoding these variants inside a string. Chris 
doesn't either.


I *do* see a problem with it, based on my experience in Nova where this 
kind of thing leads to ugly, unmaintainable, and incomprehensible code 
as I have pointed to in previous responses.


Furthermore, your point isn't that "you just want to be able to do the 
things". Your point (and the point of others, from Cyborg and Ironic) is 
that you want to be able to use placement to pass various bits of 
information to an instance, and placement wasn't designed for that 
purpose. Nova was.


So, instead of working out a solution with the Nova team for passing 
configuration data about an instance, the proposed solution is instead 
to hack/encode multiple bits of information into a trait string. This 
proposed solution is seen as a way around having to work out a more 
appropriate solution that has Nova pass that configuration data (as is 
appropriate, since nova is the project that manages instances) to the 
virt driver or generic device manager (i.e. Cyborg) before the instance 
spawns.


I'm working on a spec that will describe a way for the user to instruct 
Nova to pass configuration data to the virt driver (or device manager) 
before instance spawn. This will have nothing to do with placement or 
traits, since this configuration data is not modeling scheduling and 
placement decisions.


I hope to have that spec done by Monday so we can discuss on the spec.

Best,
-jay

__
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] [goal][python3] week 7 update

[Doug Hellmann]

Doug Hellmann  writes:

> Doug Hellmann  writes:
>
>> == Things We Learned This Week ==
>>
>> When we updated the tox.ini settings for jobs like pep8 and release
>> notes early in the Rocky session we only touched some of the official
>> repositories. I'll be working on making a list of the ones we missed so
>> we can update them by the end of Stein.
>
> I see quite a few repositories with tox settings out of date (about 350,
> see below). Given the volume, I'm going to prepare the patches and
> propose them a few at a time over the next couple of weeks.

Zuul looked bored this morning so I went ahead and proposed a few of the
larger batches of these changes for the Charms, OpenStack Ansible, and
Horizon teams. TripleO also has quite a few, but since we know the gate
is unstable I will hold off on those for now.

There will be more patches when there is CI capacity again.

Doug

__
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] [os-upstream-institute] Find a slot for a meeting to discuss - ACTION NEEDED

[Ildiko Vancsa]

Hi Training Team,

Based on the votes on the Doodle poll below we will have our ad-hoc meeting 
__next Friday (October 5) 1600 UTC__.

Hangouts link for the call: 
https://hangouts.google.com/call/BKnvu7e72uB_Z-QDHDF2AAEI

If you’re available for the Berlin training as mentor and haven’t signed up on 
the wiki yet please do so: 
https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions#Berlin_Crew

Please let me know if you have any questions.

Thanks,
Ildikó



> On 2018. Sep 23., at 14:29, Ildiko Vancsa  wrote:
> 
> Hi Training Team,
> 
> With the new workshop style training format that is utilizing the Contributor 
> Guide we have less work with the training material side and we have less 
> items to discuss in the form of regular meetings.
> 
> However, we have a few items to go through before the upcoming training in 
> Berlin to make sure we are fully prepared. We also have Florian from City 
> Network working on the online version of the training that he would like to 
> discuss with the team.
> 
> As the current meeting slot is very inconvenient in Europe and Asia as well I 
> put together a Doodle poll to try to find a better slot if we can. As we have 
> people all around the globe all the slots are inconvenient to a subset of the 
> team, but if we can agree on one for one meeting it would be great.
> 
> Please vote on the poll as soon as possible: 
> https://doodle.com/poll/yrp9anbb7weaun4h
> 
> When we have the full list of mentors for the Berlin training I will send out 
> a separate poll for one or two prep calls. If you’re available for the 
> training and not signed up on the wiki yet please sign up: 
> https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions#Berlin_Crew
> 
> Please let me know if you have any questions.
> 
> Thanks and Best Regards,
> Ildikó
> 
> 


__
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

[Mark Goddard]

On Fri, 28 Sep 2018 at 22:07, melanie witt  wrote:

> On Fri, 28 Sep 2018 15:42:23 -0500, Eric Fried wrote:
> > On 09/28/2018 09:41 AM, Balázs Gibizer wrote:
> >>
> >>
> >> On Fri, Sep 28, 2018 at 3:25 PM, 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?
> >>
> >> How far are we willing to go? Does an arbitrary (key: value) pair
> >> encoded in a trait name like key_`str(value)` (e.g. CURRENT_TEMPERATURE:
> >> 85 encoded as CUSTOM_TEMPERATURE_85) something we would be OK to see in
> >> placement?
> >
> > Great question. Perhaps TEMPERATURE_DANGEROUSLY_HIGH is okay, but
> > TEMPERATURE_ is not. This thread isn't about setting
> > these parameters; it's about getting us to a point where we can discuss
> > a question just like this one without running up against:
> >
> > "That's a hard no, because you shouldn't encode key/value pairs in
> traits."
> >
> > "Oh, why's that?"
> >
> > "Because that's not what we intended when we created traits."
> >
> > "But it would work, and the alternatives are way harder."
> >
> > "-1"
> >
> > "But..."
> >
> > "-1"
> I think it's not so much about the intention when traits were created
> and more about what UX callers of the API are left with, if we were to
> recommend representing everything with traits and not providing another
> API for key-value use cases. We need to think about what the maintenance
> of their deployments will look like if traits are the only tool we provide.
>
> I get that we don't want to put artificial restrictions on how API
> callers can and can't use the traits API, but will they be left with a
> manageable experience if that's all that's available?
>
> I don't have time right now to come up with a really great example, but
> I'm thinking along the lines of, can this get out of hand (a la "flavor
> explosion") for an operator using traits to model what their compute
> hosts can do?
>
> Please forgive the oversimplified example I'm going to try to use to
> illustrate my concern:
>
> We all agree we can have traits for resource providers like:
>
> * HAS_SSD
> * HAS_GPU
> * HAS_WINDOWS
>
> But things get less straightforward when we think of traits like:
>
> * HAS_OWNER_CINDER
> * HAS_OWNER_NEUTRON
> * HAS_OWNER_CYBORG
> * HAS_RAID_0
> * HAS_RAID_1
> * HAS_RAID_5
> * HAS_RAID_6
> * HAS_RAID_10
>

I think the numbers are a  red herring here. RAID levels include a limited
set of combinations, of which only a handful are frequently used. It's not
the same as the temperature example, which is a continuous range of
numbers. That said, a key:value encoding could work well for RAID.

* HAS_NUMA_CELL_0
> * HAS_NUMA_CELL_1
> * HAS_NUMA_CELL_2
> * HAS_NUMA_CELL_3
>
> I'm concerned about a lot of repetition here and maintenance headache
> for operators. That's where the thoughts about whether we should provide
> something like a key-value construct to API callers where they can
> instead say:
>
> * OWNER=CINDER
> * RAID=10
> * NUMA_CELL=0
>
> for each resource provider.
>
> If I'm off base with my example, please let me know. I'm not a placement
> expert.
>
> Anyway, I hope that gives an idea of what I'm thinking about in this
> discussion. I agree we need to pick a direction and go with it. I'm just
> trying to look out for the experience operators are going to be using
> this and maintaining it in their deployments.
>
> Cheers,
> -melanie
>
>
>
>
>
>
>
>
>
>
>
>
>
> __
> 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] [placement] The "intended purpose" of traits

[Mark Goddard]

To add some context around what I suspect is the reason for the most recent
incarnation of this debate, many Ironic users have a requirement to be able
to influence the configuration of a server at deploy time, beyond the
existing supported mechanisms. The classic example is hardware RAID - the
ability to support workloads with different requirements is important,
since if you're paying for bare metal cloud resources you'll want to make
sure you're getting the most out of them. Another example that comes up is
hyperthreading - often this is disabled for HPC workloads but enabled for
HTC.

We've had a plan to support deploy-time configuration that has existed for
a few cycles. It began with adding support for traits [1] in Queens, and
continued with the deploy steps framework [2] in Rocky. At the Stein PTG we
had a lot of support [3] for finishing the job by implementing the deploy
templates [4] spec that is currently in review.

At a very high level, deploy templates allow us to map a reuired trait
specified on a flavor to a set of deploy steps in ironic. These deploy
steps are based on the existing cleaning steps framework that has existed
in ironic for many releases, and should feel familiar to users of ironic.
This scheme is conceptually quite simple, which I like.

After a negative review on the spec from Jay on Thursday, I added a design
to the alternatives section of the spec that I thought might align better
with his view of the world. Essentially, decouple the scheduling and
configuration - flavors may specify required traits as they can today, but
also a more explicit list of names or UUIDs of ironic deploy templates. I'm
still not sure how I feel about this. Architecturally it's cleaner, and is
more flexible but from a usability perspective feels a little clunky.

There was a discussion [5] in ironic's IRC yesterday that I missed, in
which Jay offered to write up an alternative spec that uses glance metadata
[6]. There were some concerns about adding a hard requirement on glance for
the standalone use case, but we may be able to provide an alternative
solution analogous to manual cleaning that fills that gap.

I'm certainly interested to see what Jay comes up with. If there is a
better way of doing this, I'm all ears. That said, this is something the
ironic community has been wanting for a long time now, and I can't see us
waiting for a multi-cycle feature to land in nova, given that deploy
templates currently requires no changes in nova.

[1]
http://specs.openstack.org/openstack/ironic-specs/specs/10.1/node-traits.html
[2]
https://specs.openstack.org/openstack/ironic-specs/specs/11.1/deployment-steps-framework.html
[3] https://etherpad.openstack.org/p/ironic-stein-ptg-goals
[4] https://review.openstack.org/#/c/504952/
[5]
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-09-28.log.html#t2018-09-28T14:22:57
[6] https://docs.openstack.org/glance/pike/user/metadefs-concepts.html

On Sat, 29 Sep 2018 at 03:15, Alex Xu  wrote:

> Sorry for append another email for something I missed to say.
>
> Alex Xu  于2018年9月29日周六 上午10:01写道：
>
>>
>>
>> Jay Pipes  于2018年9月29日周六 上午5:51写道：
>>
>>> On 09/28/2018 04:42 PM, Eric Fried wrote:
>>> > On 09/28/2018 09:41 AM, Balázs Gibizer wrote:
>>> >> On Fri, Sep 28, 2018 at 3:25 PM, 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?
>>> >>
>>> >> How far are we willing to go? Does an arbitrary (key: value) pair
>>> >> encoded in a trait name like key_`str(value)` (e.g.
>>> CURRENT_TEMPERATURE:
>>> >> 85 encoded as CUSTOM_TEMPERATURE_85) something we would be OK to see
>>> in
>>> >> placement?
>>> >
>>> > Great question. Perhaps TEMPERATURE_DANGEROUSLY_HIGH is okay, but
>>> > TEMPERATURE_ is not.
>>>
>>> That's correct, because you're encoding >1 piece of information into the
>>> single string (the fact that it's a temperature *and* the value of that
>>> temperature are the two pieces of information encoded into the single
>>> string).
>>>
>>> Now that there's multiple pieces of information encoded in the string
>>> the reader of the trait string needs to know h

Re: [openstack-dev] [docs][charms] Updating Deployment Guides indices of published pages

[Andreas Jaeger]

On 9/27/18 10:04 AM, Frode Nordahl wrote:

Hello docs team,

What would it take to re-generate the indices for Deployment Guides on 
the published Queens [0] and Rocky [1] docs pages?


It seems that the charms project has missed the index for those releases 
due to some issues which now has been resolved [2].  We would love to 
reclaim our space in the list!


0: https://docs.openstack.org/queens/deploy/
1: https://docs.openstack.org/rocky/deploy/
2: 
https://review.openstack.org/#/q/topic:enable-openstack-manuals-rocky-latest+(status:open+OR+status:merged)


We found the problem - you updated the build job to use bionic but 
nobody updated the publish one. This is fixed now since 
https://review.openstack.org/#/c/606147/ is merged.


All should be fine again,
Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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