Re: [openstack-dev] [oslo][mistral] Mistral expressions package

[Renat Akhmerov]

Ok, thanks for your input.

I’d personally say it’s not really worth it but if Bob wants to do it that’s ok.

Thanks

Renat Akhmerov
@Nokia

On 19 Oct 2017, 12:46 +0700, ChangBo Guo , wrote:
> The dependencies of  mistral expressions package make it hard to be adopted 
> as a module of oslo library,  we need oslo library keep simple.
> we have a adopt process [1]  which is not merged to help guide the adoption 
> process if we agree.  agree with Dough, we can discuss in the Oslo weekly 
> meeting.[2]
>
>
> [1] https://review.openstack.org/312233
> [2] http://eavesdrop.openstack.org/#Oslo_Team_Meeting
>
> > 2017-10-18 12:46 GMT+08:00 Renat Akhmerov :
> > > Hi,
> > >
> > > I’m not too happy about the idea of creating one more subproject within 
> > > Mistral. I don’t even see now what else this new library project managed 
> > > by Mistral team will contain besides this expression utils module. I’m 
> > > also not sure about its name. We already have mistral-lib which was 
> > > created for a different purpose (public APIs for making Mistral 
> > > extensions like actions and YAQL/Jinja functions).
> > >
> > > Just to clarify: the code we’re talking about is really small and stable 
> > > (we haven’t touched it for a while, it just works), and it’s generic so 
> > > it can be reused in many situations by many projects. That’s why we had 
> > > an idea to find a place within one of the Oslo libraries, just to make 
> > > one more package (or even module), for example, in oslo.utils. As far as 
> > > maintaining this code, we could still do that. But anyway, if that’s not 
> > > OK, I’d just suggest we leave it as it is. If this code needs to be 
> > > reused somewhere else outside OpenStack space (like in Bob’s case) may be 
> > > it’s just simpler to create a project on github?
> > >
> > > Thanks
> > >
> > > Renat Akhmerov
> > > @Nokia
> > >
> > > On 10 Oct 2017, 22:11 +0700, Doug Hellmann , wrote:
> > > > Excerpts from HADDLETON, Robert W (Bob)'s message of 2017-10-09 
> > > > 19:41:58 -0500:
> > > > > On 10/9/2017 2:35 PM, Doug Hellmann wrote:
> > > > > > Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
> > > > > > > Hello Oslo team:
> > > > > > >
> > > > > > > The Mistral project has an expressions package [0] that is used to
> > > > > > > evaluate inline expressions using a context. It has a pluggable
> > > > > > > architecture that presently supports Jinja and YAQL expression
> > > > > > > evaluation. It also allows custom functions[1] to provide Python
> > > > > > > implementations of functionality that is then made available to 
> > > > > > > the
> > > > > > > expression evaluation engines.
> > > > > > >
> > > > > > > This functionality was originally developed to support dynamic
> > > > > > > processing within Mistral workflows, but is also very useful in 
> > > > > > > other
> > > > > > > applications that use templates which require runtime evaluation 
> > > > > > > of
> > > > > > > expressions.
> > > > > > >
> > > > > > > I'd like to explore extracting this functionality from mistral to 
> > > > > > > make
> > > > > > > it more widely available with minimal dependencies.
> > > > > > >
> > > > > > > The expressions dependencies are pretty limited:
> > > > > > >
> > > > > > > Jinja2
> > > > > > > oslo.utils
> > > > > > > oslo.log
> > > > > > > stevedore
> > > > > > > yaql
> > > > > > >
> > > > > > > and since 60% are already oslo-maintained packages, it seemed 
> > > > > > > like a
> > > > > > > logical place to start.
> > > > > > >
> > > > > > > I'd appreciate feedback on the topic. There is no real OpenStack
> > > > > > > dependency in the functionality, so maybe a standalone package on 
> > > > > > > pypi
> > > > > > > makes sense.
> > > > > > >
> > > > > > > Thanks for your help,
> > > > > > >
> > > > > > > Bob Haddleton
> > > > > > >
> > > > > > >
> > > > > > > [0] 
> > > > > > > https://github.com/openstack/mistral/tree/master/mistral/expressions
> > > > > > > [1]
> > > > > > > https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63
> > > > > > >
> > > > > > Oslo is a good place for things like this that have no other obvious
> > > > > > home, but if the Mistral team is already managing the code is there 
> > > > > > any
> > > > > > reason they couldn't also manage the library after you pull it out 
> > > > > > of
> > > > > > the service? It's much easier for any project team to manage a 
> > > > > > library
> > > > > > now, and we have several other examples of that pattern already.
> > > > > >
> > > > > > 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
> > > > > Hi Doug:
> > > > >
> > > > > That's probably fine, we're just not sure what the 

Re: [openstack-dev] [oslo][mistral] Mistral expressions package

[ChangBo Guo]

The dependencies of  mistral expressions package make it hard to be adopted
as a module of oslo library,  we need oslo library keep simple.
we have a adopt process [1]  which is not merged to help guide the adoption
process if we agree.  agree with Dough, we can discuss in the Oslo weekly
meeting.[2]


[1] https://review.openstack.org/312233
[2] http://eavesdrop.openstack.org/#Oslo_Team_Meeting

2017-10-18 12:46 GMT+08:00 Renat Akhmerov :

> Hi,
>
> I’m not too happy about the idea of creating one more subproject within
> Mistral. I don’t even see now what else this new library project managed by
> Mistral team will contain besides this expression utils module. I’m also
> not sure about its name. We already have mistral-lib which was created for
> a different purpose (public APIs for making Mistral extensions like actions
> and YAQL/Jinja functions).
>
> Just to clarify: the code we’re talking about is really small and stable
> (we haven’t touched it for a while, it just works), and it’s generic so it
> can be reused in many situations by many projects. That’s why we had an
> idea to find a place within one of the Oslo libraries, just to make one
> more package (or even module), for example, in oslo.utils. As far as
> maintaining this code, we could still do that. But anyway, if that’s not
> OK, I’d just suggest we leave it as it is. If this code needs to be reused
> somewhere else outside OpenStack space (like in Bob’s case) may be it’s
> just simpler to create a project on github?
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> On 10 Oct 2017, 22:11 +0700, Doug Hellmann , wrote:
>
> Excerpts from HADDLETON, Robert W (Bob)'s message of 2017-10-09 19:41:58
> -0500:
>
> On 10/9/2017 2:35 PM, Doug Hellmann wrote:
>
> Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
>
> Hello Oslo team:
>
> The Mistral project has an expressions package [0] that is used to
> evaluate inline expressions using a context. It has a pluggable
> architecture that presently supports Jinja and YAQL expression
> evaluation. It also allows custom functions[1] to provide Python
> implementations of functionality that is then made available to the
> expression evaluation engines.
>
> This functionality was originally developed to support dynamic
> processing within Mistral workflows, but is also very useful in other
> applications that use templates which require runtime evaluation of
> expressions.
>
> I'd like to explore extracting this functionality from mistral to make
> it more widely available with minimal dependencies.
>
> The expressions dependencies are pretty limited:
>
> Jinja2
> oslo.utils
> oslo.log
> stevedore
> yaql
>
> and since 60% are already oslo-maintained packages, it seemed like a
> logical place to start.
>
> I'd appreciate feedback on the topic. There is no real OpenStack
> dependency in the functionality, so maybe a standalone package on pypi
> makes sense.
>
> Thanks for your help,
>
> Bob Haddleton
>
>
> [0] https://github.com/openstack/mistral/tree/master/mistral/expressions
> [1]
> https://github.com/openstack/mistral/blob/master/mistral/
> utils/expression_utils.py#L63
>
> Oslo is a good place for things like this that have no other obvious
> home, but if the Mistral team is already managing the code is there any
> reason they couldn't also manage the library after you pull it out of
> the service? It's much easier for any project team to manage a library
> now, and we have several other examples of that pattern already.
>
> 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
>
> Hi Doug:
>
> That's probably fine, we're just not sure what the process should be and
> where the library would land?  Do you have an example that we could use
> as a pattern?
>
> Thanks
>
> Bob
>
>
> The first step is to create the repository with the library code. Then
> you would add that repository to the list managed by the mistral team by
> modifying the project list file in the governance repository.
>
> Any of the project client libraries would work as an example of how to
> set up the CI, governance, and release configuration. I think most of
> the steps are covered in
> https://docs.openstack.org/infra/manual/creators.html as well.
>
> If the code is already isolated well within the mistral repo and you
> want to preserve its history, you may also want to take a look at
> http://git.openstack.org/cgit/openstack/oslo.tools/tree/
> filter_git_history.sh
> as a tool for making the new repository.
>
> I'm happy to help you work out a more detailed plan. Let me know if that
> would be useful.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@l

[openstack-dev] [QA] Meeting Thursday Oct 19th at 8:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Oct 19th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_October_19th_2017_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

__
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] [Congress] Is it possible that congress policy do live-migration

[Eric K]

Hi Houzhian,

Great the see people doing fault tolerance with Congress. That's how
Congress is used in by the OpNFV Doctor project
(https://wiki.opnfv.org/display/doctor)

I just tested the same rule on Pike release and it seems Congress delivered
the correct request to nova. Do you have the Congress and Nova logs that can
help us determine what happened?
Also which version are you on and what environment are you running in?

Cheers!

Eric Kao

From:  houzhian 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Wednesday, October 18, 2017 at 12:51 AM
To:  "openstack-dev@lists.openstack.org" 
Subject:  [openstack-dev] Is it possible that congress policy do
live-migration

>  
>  
> 
> Hey guys, thanks for your efforts on OpenStack Congress, I am very puzzled
> about policy of Congress on recent days and I decided to ask you for some
> help, I am looking forward to your reply.
> 
> openstack congress policy rule create \
> --name live_migrate_vm classification \
> 
> 'execute[nova:servers.live_migrate(vmid,"overcloud-novacompute-1.opnfvlf.org",
> "False","False")] :-
> host_down(host),
> active_instance_in_host(vmid, host)'
> 
> 
> Is this a valid policy? Is there some connection between nova client api and
> execute in congress policy which are allowed to use? I noticed that
> nova pause vmid
> 'execute[nova:servers.pause(vmid)] :- condition' works properly
> nova migrate vmid
> 'execute[nova:servers.pause(vmid)] :- condition' works properly
> there exist nova live-migration vmid
> but I can not add execute[nova:servers.live-migration(vmid,other params
> maybe)] to congress policy, nova:servers.live-migrate(vmid,other params) can
> be added successfuly but it didn't do live migration jobs, nothing happened.I
> am confused about this,
> Am I able to use congress to do some automatic fault recovery like live
> migration?
> 
>
> 发自网易邮箱大师
> 
> 
> __
> 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] Migrating TripleO jobs to native Zuul v3

[David Moreau Simard]

It looks like the best slot for everyone [1] is monday October 23rd @
10:00AM EST (2:00PM UTC).

I'll send invites out, don't forget to start writing down things
you're interested in learning
about in the etherpad [2].

[1]: https://beta.doodle.com/poll/hfkcgrahwskm2ggv
[2]: https://etherpad.openstack.org/p/migrating-tripleo-zuulv3

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Mon, Oct 16, 2017 at 11:08 AM, David Moreau Simard  wrote:
> Hi,
>
> Unless you've been hiding under a rock (which is totally
> understandable), you know that Zuul v3 is here.
>
> Zuul v3 can be seen as a hindrance as of late because it's been
> messing up with the gate jobs or preventing your patches to merge,
> etc.
> Hopefully, the "legacy" Zuul v3 jobs are all fixed up now and things
> are able to merge without too much troubles.
> I'm here to tell you that Zuul v3 is in fact awesome and I'd like
> TripleO to benefit from all it's glory ASAP.
>
> I encourage everyone, not just people typically involved in CI, to
> take a read at the Zuul v3 migration guide [1].
> Zuul v3 opens a lot of opportunities to streamline, improve and
> simplify the CI of TripleO in upstream.
>
> I'd like to open up an informal "ask me anything" regarding what's
> implied in properly migrating TripleO jobs to "native" Zuul v3 and
> have set up an etherpad to start collecting questions [2].
> We could do a recorded Bluejeans session sometime early next week.
> I've set up a Doodle, please tell us what time would work best for you [3].
>
> Paul Belanger and I will be there to answer questions from a Zuul v3
> and upstream infrastructure perspective.
>
> We might also have questions for you !
> For example, how do we plan on keeping jobs "compatible" between
> review.openstack.org and review.rdoproject.org ?
>
> Thanks !
>
> [1]: https://docs.openstack.org/infra/manual/zuulv3.html
> [2]: https://etherpad.openstack.org/p/migrating-tripleo-zuulv3
> [3]: https://doodle.com/poll/hfkcgrahwskm2ggv
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]

__
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] [infra][all] Decommissioning Zuul v2

[James E. Blair]

Hi,

At the infra meeting[1] yesterday, there was general agreement that we have
likely passed the point at which we would consider a rollback to Zuul
v2, and will iterate forward on any further issues (as we have been
doing since Sunday).

We plan on freezing the Zuul v2 config[2] now, and keep it and the Zuul
v2 servers around until next week, at which point we will tag
project-config (for easy historical reference), start deleting the Zuul
v2 content, and delete the servers.

If this sounds premature, please let us know.

Thanks,

Jim

[1] 
http://eavesdrop.openstack.org/meetings/infra/2017/infra.2017-10-17-19.00.html
[2] zuul/layout.yaml and jenkins/ in the project-config repository

__
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] Issue with Zuul v3 / Gerrit / TripleO Jobs

[David Moreau Simard]

This was confirmed to be a client-side javascript issue in Gerrit
earlier this week [1].

[1]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-10-16.log.html#t2017-10-16T12:51:40

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Wed, Oct 18, 2017 at 2:30 PM, Emilien Macchi  wrote:
> Since we migrated to Zuul v3 and Zuul is now the default user which
> vote in Gerrit, we now have a bug with jobs running in the 'check' and
> the 'check-tripleo' pipeline.
> Jobs finish in the 'check' pipeline and report their status and then
> jobs finish in the 'check-tripleo' pipeline, overwriting/discarding
> the results from the 'check' pipeline.
> In v2, the check pipeline results were 'additive' but not in v3, it seems.
>
> It might be some javascript display in Gerrit but we haven't figured out.
>
> Which means... please be careful when you review and check both
> pipelines results and not the latest one displayed in Gerrit. Please
> scroll-down to the comments to see first pipeline results as well, so
> we make sure we're not merging patches that didn't pass some
> non-voting jobs (specially the ones in check-tripleo).
>
> Thank you,
> --
> Emilien Macchi
>
> __
> 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] [tripleo] Issue with Zuul v3 / Gerrit / TripleO Jobs

[Emilien Macchi]

Since we migrated to Zuul v3 and Zuul is now the default user which
vote in Gerrit, we now have a bug with jobs running in the 'check' and
the 'check-tripleo' pipeline.
Jobs finish in the 'check' pipeline and report their status and then
jobs finish in the 'check-tripleo' pipeline, overwriting/discarding
the results from the 'check' pipeline.
In v2, the check pipeline results were 'additive' but not in v3, it seems.

It might be some javascript display in Gerrit but we haven't figured out.

Which means... please be careful when you review and check both
pipelines results and not the latest one displayed in Gerrit. Please
scroll-down to the comments to see first pipeline results as well, so
we make sure we're not merging patches that didn't pass some
non-voting jobs (specially the ones in check-tripleo).

Thank you,
-- 
Emilien Macchi

__
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][tc] TC Candidates: what does an OpenStack user look like?

[Zane Bitter]

On 17/10/17 14:16, Doug Hellmann wrote:

Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400:

On 14/10/17 11:47, Doug Hellmann wrote:

Even the rewritten question can be answered
legitimately using several different personas by people with a bit
of experience.  I have worked at a public cloud provider and two
distributors with a wide range of customers, and I use OpenStack
clouds myself. I hope that all of that background feeds into my
contributions.


Yes, that's great. I think most people would agree that there's a
threshold somewhere between 'several' and 'infinity' beyond which we've
crossed over into platitudes though.


Maybe. On the other hand, TC members aren't elected to represent
specific constituencies, so there's something to be said for taking each
case as it comes and considering the users impacted by that case.


Right, so we all agree that what we *don't* want is TC candidates saying 
"I'm here to represent the interests of user community X against those 
of evil user community Y", all of the X users voting for X candidates 
and not Y candidates, and then the elected X members voting to block 
anything that only benefits Y, and vice-versa. Obviously every step of 
that process is an unmitigated disaster.


So of course each TC member should consider the all of the users 
impacted by any decision on a case-by-case basis. However, even if we're 
only thinking purely about reactive decision-making, it's still often 
not easy to know *which* users are impacted by any particular decision 
unless you have someone in the room who has a deep familiarity with that 
use case. That's why I'd like to see candidates saying something like "I 
spend a lot of time thinking about user community X and if anything came 
up that affected their use cases I'm pretty sure I'd spot it". So that I 
can vote to optimise the diversity of Xs represented, where X might be 
e.g. web developers, devops teams, scientific researchers, vSphere 
migrants, multi-cloud users, NFV, the next 
Facebook/Twitter/Snapchat/Netflix, mobile app or IoT backend developers, 
kubernetes users, or something I haven't even thought of.


Possible tangent: I've always enjoyed this article (about the 
Sapir-Whorf hypothesis): 
http://www.nytimes.com/2010/08/29/magazine/29language-t.html
tl;dr Anybody can think about anything, regardless of the language they 
speak (i.e. Sapir-Whorf is wrong). But there are things in every 
language that you can't *not* think about, and they're different for 
different languages.


I want to maximise the set of things the TC, collectively, can't not 
think about.



Suffice to say that nobody should take my example here as anything more
than a rationale for the importance of user-centred design.


How much "design" do you think the TC is doing as a governance group?


It varies between different levels of abstraction.

At the code level, none.

At the level of setting the broad technical direction of the project, 
not as much as I'd like. But y'all did pass 
https://governance.openstack.org/tc/resolutions/20170317-cloud-applications-mission.html 
for me (thanks!) so definitely not nothing. There are other 
less-directly-relevant examples like adding etcd to the list of base 
services too.


At the level of deciding what projects OpenStack consists of, and 
therefore what sort of cloud you can build with it (that is to say, what 
you can _use_ it for)... that's _entirely_ within the TC's purview.


At an even higher level of abstraction, deciding what OpenStack is and 
what the Foundation is for, the TC has at least a significant role in 
giving input to the board and delegated authority to make decisions in 
some areas. Notably, discussions at this level often occur face-to-face 
at TC-only events, or at board meetings where non-members aren't 
entitled to speak, and which few people can and even fewer people do 
attend. (I've given up a few Sunday afternoons before OpenStack Summits 
that I could have spent exploring exciting foreign cities to watch the 
joint TC-Board meeting, but the probability of my manager giving my 
budget for a special trip to a board meeting to just listen is exactly 
zero.) I'm not complaining about that, but it does make it important 
that TC members themselves are capable of representing a wide range of 
interests - it's not always the case that expertise will be pulled in 
from the wider community automatically.


Anyway, those are all design problems in my view.

cheers,
Zane.

__
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] [Congress] Is it possible that congress policy do live-migration

[Tim Hinrichs]

Adding [Congress] to the subject line for proper filtering...

Congress lets you execute most of the Nova client API calls.  You use the
same arguments you would use for the Nova client.  Here are the docs for
the live-migration API: scroll down to live-migrate.

https://docs.openstack.org/python-novaclient/latest/reference/api/novaclient.v2.servers.html

Congress doesn't let you pass in keyword args like host="foo" (others will
correct me if that's changed recently), so you will need to figure out what
non-keyword arguments live-migration allows you to pass.  It wasn't clear
to me from the docs.

Tim

On Wed, Oct 18, 2017 at 12:53 AM houzhian  wrote:

>
> Hey guys, thanks for your efforts on OpenStack Congress, I am very puzzled
> about policy of Congress on recent days and I decided to ask you for some
> help, I am looking forward to your reply.
>
> openstack congress policy rule create \
> --name live_migrate_vm classification \
> 'execute[nova:servers.live_migrate(vmid,"
> overcloud-novacompute-1.opnfvlf.org","False","False")] :-
> host_down(host),
> active_instance_in_host(vmid, host)'
>
>
> Is this a valid policy? Is there some connection between nova client api
> and execute in congress policy which are allowed to use? I noticed that
> nova pause vmid
> 'execute[nova:servers.pause(vmid)] :- condition' works properly
> nova migrate vmid
> 'execute[nova:servers.pause(vmid)] :- condition' works properly
> there exist nova live-migration vmid
> but I can not add execute[nova:servers.live-migration(vmid,other params
> maybe)] to congress policy, nova:servers.live-migrate(vmid,other params)
> can be added successfuly but it didn't do live migration jobs, nothing
> happened.I am confused about this,
> Am I able to use congress to do some automatic fault recovery like live
> migration?
>
> 发自网易邮箱大师
>
> __
> 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] [gnocchi] Redis for storage backend

[gordon chung]

On 2017-10-18 12:15 PM, Yaguang Tang wrote:
> 
> We launched 300vms and each vm has about 10 metrics, OpenStack cluster 
> have 3 controllers and 2 compute nodes(ceph replication is set to 2).

seems smaller than my test, i have 20K metrics in my test

> 
> what we want to archive is to make all metric measures data get 
> processed as soon as possible, metric processing delay is set to 10s, 
> and ceilometer polling interval is 30s.

are you batching the data you push to gnocchi? in gnocchi4.1, the redis 
driver will (attempt to) process immediately, rather than cyclically 
using the metric processing delay.

> 
> when the backend of incoming and storeage is set to ceph, the average of 
> "gnocchi status"
> shows that there are around 7000 measures waiting to be process, but 
> when changing incoming and storage backend to Redis, the result of 
> gnocchi status shows unprocessed measures is around 200.

i should clarify, having a high gnocchi status is not a bad thing, ie, 
if you just send a large spike of measures, it's expected to jump. it's 
bad if never shrinks.

that said, how many workers do you have? i have 18 workers for 20K 
metrics and it takes 2minutes i believe? do you have debug enable? how 
long does it take to process metric?

when i tested gnocchi+ceph vs gnocchi+redis, i didn't see a very large 
difference in performance (redis was definitely better though). maybe 
it's your ceph environment?

> 
> we try to add more metricd process on every controller nodes, to improve 
> the performance of
> calculate and writing speed to storage backend but  have little effect.

performance should increase (relatively) proportionally. ie. if you 2x 
metricd, you should perform (almost) 2x quicker. if you add 5% more 
metricd, you should perform (almost) 5% quicker.

cheers,

-- 
gord
__
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] [gnocchi] Redis for storage backend

[Yaguang Tang]

Hi Gordon,

We launched 300vms and each vm has about 10 metrics, OpenStack cluster have
3 controllers and 2 compute nodes(ceph replication is set to 2).

what we want to archive is to make all metric measures data get processed
as soon as possible, metric processing delay is set to 10s, and ceilometer
polling interval is 30s.

when the backend of incoming and storeage is set to ceph, the average of
"gnocchi status"
shows that there are around 7000 measures waiting to be process, but when
changing incoming and storage backend to Redis, the result of gnocchi
status shows unprocessed measures is around 200.

we try to add more metricd process on every controller nodes, to improve
the performance of
calculate and writing speed to storage backend but  have little effect.

On Fri, Oct 13, 2017 at 9:03 PM, gordon chung  wrote:

>
>
> On 2017-10-13 03:37 AM, Julien Danjou wrote:
> > On Fri, Oct 13 2017, Yaguang Tang wrote:
> >
> >> I see the latest Gnocchi support using Redis as a storage backend, I am
> >> testing performance of Redis and Ceph, it seems using Redis as storage
> >> backend we can achieve  more realtime metric
> >> data, gnocchi status shows there is always few metric to process.
> >>
> >> Is Redis a recommend storage backend ?
> >
> > Redis is recommended as an incoming measures backend, not really as a
> > storage – though it really depends on the size of your installation.
> >
> > Up until 4.0 version, Gnocchi process metrics every
> > $metricd.metric_processing_delay seconds. With version 4.1 (to be
> > released), the Redis incoming driver has a more realtime processing
> > delay which avoids having to poll for incoming data.
> >
>
> what Julien said :)
>
> redis as a storage driver really depends on how you setup persistence[1]
> and how much you trust it[2].
>
> would love to see your redis vs ceph numbers compared to mine[3] :)
>
> [1] https://redis.io/topics/persistence
> [2] https://aphyr.com/posts/283-jepsen-redis
> [3] https://medium.com/@gord.chung/gnocchi-4-introspective-a83055e99776
> (tested part of 4.1 optimisations)
>
> cheers,
>
> --
> gord
> __
> 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
>



-- 
Tang Yaguang
__
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] PCI pass through settings on a flavor without aliases on the API nodes

[Yaguang Tang]

Hi Van,

You can try to create a pci-passthrough port with PCI info, then create vm
using that port  without any alias.

On Wed, Oct 18, 2017 at 11:27 PM, Eric Fried  wrote:

> Robert-
>
> No.
>
> Some day, once generic device management is baked, there will be.
> Depending how your favorite virt driver decides to model things, one
> could envision a flavor with extra specs like:
>
> resources:SRIOV_NET_PF:1
> trait:CUSTOM_PCI_VENDORID_8086=required
> trait:CUSTOM_PCI_PRODUCTID_154D=required
>
> In the meantime, it's especially useful to get this kind of
> feedback
> from ops so we can ensure we're meeting the right requirements as we
> design things.  Please reach out if you want to discuss further.
>
> Thanks,
> Eric Fried (efried)
>
> On 10/18/2017 09:56 AM, Van Leeuwen, Robert wrote:
> > Hi,
> >
> >
> >
> > Does anyone know if it is possible to set PCI pass through on a flavor
> > without also needing to set the alias on the nova API nodes as mentioned
> > here:
> > https://docs.openstack.org/nova/pike/admin/pci-passthrough.html
> >
> >
> >
> > E.G you need to set in nova.conf:
> >
> > [pci]
> >
> > alias = { "vendor_id":"8086", "product_id":"154d ",
> > "device_type":"type-PF", "name":"a1" }
> >
> >
> >
> > Then you can set the flavor:
> >
> > openstack flavor set m1.large --property "pci_passthrough:alias"="a1:2"
> >
> >
> >
> >
> >
> > E.g. I would be fine with just setting the PCI vendor/product on the
> > flavor instead of also needing to set this at the api node
> >
> > So something like:
> >
> > openstack flavor set m1.large –property “pci_passthrough:vendor”=”8086”
> >  “pci_passthrough:device”=”154d:1”
> >
> >
> >
> > Thx,
> >
> > Robert  van Leeuwen
> >
> >
> >
> > ___
> > OpenStack-operators mailing list
> > openstack-operat...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
> __
> 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
>



-- 
Tang Yaguang
__
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] PCI pass through settings on a flavor without aliases on the API nodes

[Eric Fried]

Robert-

No.

Some day, once generic device management is baked, there will be.
Depending how your favorite virt driver decides to model things, one
could envision a flavor with extra specs like:

resources:SRIOV_NET_PF:1
trait:CUSTOM_PCI_VENDORID_8086=required
trait:CUSTOM_PCI_PRODUCTID_154D=required

In the meantime, it's especially useful to get this kind of feedback
from ops so we can ensure we're meeting the right requirements as we
design things.  Please reach out if you want to discuss further.

Thanks,
Eric Fried (efried)

On 10/18/2017 09:56 AM, Van Leeuwen, Robert wrote:
> Hi,
> 
>  
> 
> Does anyone know if it is possible to set PCI pass through on a flavor
> without also needing to set the alias on the nova API nodes as mentioned
> here:
> https://docs.openstack.org/nova/pike/admin/pci-passthrough.html
> 
>  
> 
> E.G you need to set in nova.conf:
> 
> [pci]
> 
> alias = { "vendor_id":"8086", "product_id":"154d ",
> "device_type":"type-PF", "name":"a1" }
> 
>  
> 
> Then you can set the flavor:
> 
> openstack flavor set m1.large --property "pci_passthrough:alias"="a1:2"
> 
>  
> 
>  
> 
> E.g. I would be fine with just setting the PCI vendor/product on the
> flavor instead of also needing to set this at the api node
> 
> So something like:
> 
> openstack flavor set m1.large –property “pci_passthrough:vendor”=”8086”
>  “pci_passthrough:device”=”154d:1”
> 
>  
> 
> Thx,
> 
> Robert  van Leeuwen
> 
> 
> 
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

__
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] [policy] AWS IAM session

[Lance Bragstad]

Now that we have some good feedback on the doodle, it looks like we have
two sessions that will work for everyone. One is October 25th from 15:00
- 16:00 UTC and the other is also the 25th from 16:00 - 17:00.

Let's shoot to meet at *15:00 UTC* on *October 25th* and if the meeting
goes over, we have time allocated for that. Would anyone like a formal
calendar invite? If so, I can send one out. The etherpad [0] will act as
our "schedule", but we'll likely just work through the cases we've
documented.

Thanks!

[0] https://etherpad.openstack.org/p/analyzing-other-policy-systems


On 10/16/2017 08:45 AM, Lance Bragstad wrote:
> Sending out a gentle reminder to vote for time slots that work for you
> [0]. We'll keep the poll open for a few more days, or until we reach
> quorum. Thanks!
>
> [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu
>
> On 10/11/2017 01:48 PM, Lance Bragstad wrote:
>> Oh - one note about the doodle [0]. All proposed times are in UTC, so
>> just keep that in mind when selecting your availability.
>>
>> Thanks!
>>
>> [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu
>>
>> On 10/11/2017 01:44 PM, Lance Bragstad wrote:
>>> In today's policy meeting we went through and started prepping for
>>> the session. Relevant information has been captured in the etherpad [0].
>>>
>>> We're going to hold the meeting using *Google* *Hangouts*. I'll
>>> update the etherpad with a link to the hangout once we settle on a
>>> date. If you plan on attending, please *vote* *for* *available*
>>> *times* [1]. I've proposed a bunch of time slots (4 each day for the
>>> next two weeks) to try and find a time that works for everyone.
>>> People from US, AU, and EU will be trying to attended, so we're not
>>> going to find a perfect time for everyone. Having said that, *we're
>>> going to record the session*.
>>>
>>> Most of what we talked about in the meeting today uncovered the need
>>> to go over the basics of AWS IAM. That should be something we can do
>>> with a free account, which I'm going to sign up for. If we need more
>>> time we can have another session or look at options for upgrading
>>> the account.
>>>
>>>
>>> [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems
>>> [1] https://doodle.com/poll/ntkpzgmcv3k6v5qu
>>>
>>> On 10/09/2017 04:23 PM, Lance Bragstad wrote:
 I've put a scheduling session on the books for the next policy
 meeting [0][1]. Advertising it here since folks who want to be
 involved have responded to the thread.

 Let's use this meeting time to iron out account details and figure
 out what exactly we want to get out of the session.


 [0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
 [1] https://etherpad.openstack.org/p/keystone-policy-meeting

 On 10/05/2017 02:24 AM, Colleen Murphy wrote:
> On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad
> mailto:lbrags...@gmail.com>> wrote:
>
> Hey all,
>
> It was mentioned in today's keystone meeting [0] that it would
> be useful
> to go through AWS IAM (or even GKE) as a group. With all the
> recent
> policy discussions and work, it seems useful to get our eyes
> on another
> system. The idea would be to spend time using a video
> conference/screen
> share to go through and play with policy together. The end
> result should
> keep us focused on the implementations we're working on today,
> but also
> provide clarity for the long-term vision of OpenStack's RBAC
> system.
>
> Are you interested in attending? If so, please respond to the
> thread.
> Once we have some interest, we can gauge when to hold the
> meeting, which
> tools we can use, and setting up a test IAM account.
>
> Thanks,
>
> Lance
>
> [0]
> 
> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119
> 
> 
>
> Please count me in.
>
> Colleen
>
>
> __
> 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

>>>
>>
>



signature.asc
Description: OpenPGP digital signature
__
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] [docs] Documentation meeting Thursday

[Petr Kovar]

Hi all,

The docs meeting will continue tomorrow, Thursday at 16:00 UTC in
#openstack-meeting, as scheduled. For more details, and the agenda, see the 
meeting page:

https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Cheers,
pk

__
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] [oslo][mistral] Mistral expressions package

[Doug Hellmann]

Excerpts from Renat Akhmerov's message of 2017-10-18 11:46:46 +0700:
> Hi,
> 
> I’m not too happy about the idea of creating one more subproject within 
> Mistral. I don’t even see now what else this new library project managed by 
> Mistral team will contain besides this expression utils module. I’m also not 
> sure about its name. We already have mistral-lib which was created for a 
> different purpose (public APIs for making Mistral extensions like actions and 
> YAQL/Jinja functions).
> 
> Just to clarify: the code we’re talking about is really small and stable (we 
> haven’t touched it for a while, it just works), and it’s generic so it can be 
> reused in many situations by many projects. That’s why we had an idea to find 
> a place within one of the Oslo libraries, just to make one more package (or 
> even module), for example, in oslo.utils. As far as maintaining this code, we 
> could still do that. But anyway, if that’s not OK, I’d just suggest we leave 
> it as it is. If this code needs to be reused somewhere else outside OpenStack 
> space (like in Bob’s case) may be it’s just simpler to create a project on 
> github?

I'm not sure why you think it would be less of a burden for you to
maintain the library under oslo than mistral, but I was presenting an
alternative not a strong objection to having oslo take on the library.

If the library has no dependencies on libraries like oslo.config,
then we would want to leave "oslo" or "mistral" out of the name to
encourage adoption outside of openstack. So, think about whatever
name you might have used for that github repository.

It seems like the next step is to get more of the oslo team involved
in the conversation to see whether they are willing to take
responsibility for a new repository. Maybe one of you can add it
to the meeting agenda for next week?

Dogu


> 
> Thanks
> 
> Renat Akhmerov
> @Nokia
> 
> On 10 Oct 2017, 22:11 +0700, Doug Hellmann , wrote:
> > Excerpts from HADDLETON, Robert W (Bob)'s message of 2017-10-09 19:41:58 
> > -0500:
> > > On 10/9/2017 2:35 PM, Doug Hellmann wrote:
> > > > Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
> > > > > Hello Oslo team:
> > > > >
> > > > > The Mistral project has an expressions package [0] that is used to
> > > > > evaluate inline expressions using a context. It has a pluggable
> > > > > architecture that presently supports Jinja and YAQL expression
> > > > > evaluation. It also allows custom functions[1] to provide Python
> > > > > implementations of functionality that is then made available to the
> > > > > expression evaluation engines.
> > > > >
> > > > > This functionality was originally developed to support dynamic
> > > > > processing within Mistral workflows, but is also very useful in other
> > > > > applications that use templates which require runtime evaluation of
> > > > > expressions.
> > > > >
> > > > > I'd like to explore extracting this functionality from mistral to make
> > > > > it more widely available with minimal dependencies.
> > > > >
> > > > > The expressions dependencies are pretty limited:
> > > > >
> > > > > Jinja2
> > > > > oslo.utils
> > > > > oslo.log
> > > > > stevedore
> > > > > yaql
> > > > >
> > > > > and since 60% are already oslo-maintained packages, it seemed like a
> > > > > logical place to start.
> > > > >
> > > > > I'd appreciate feedback on the topic. There is no real OpenStack
> > > > > dependency in the functionality, so maybe a standalone package on pypi
> > > > > makes sense.
> > > > >
> > > > > Thanks for your help,
> > > > >
> > > > > Bob Haddleton
> > > > >
> > > > >
> > > > > [0] 
> > > > > https://github.com/openstack/mistral/tree/master/mistral/expressions
> > > > > [1]
> > > > > https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63
> > > > >
> > > > Oslo is a good place for things like this that have no other obvious
> > > > home, but if the Mistral team is already managing the code is there any
> > > > reason they couldn't also manage the library after you pull it out of
> > > > the service? It's much easier for any project team to manage a library
> > > > now, and we have several other examples of that pattern already.
> > > >
> > > > 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
> > > Hi Doug:
> > >
> > > That's probably fine, we're just not sure what the process should be and
> > > where the library would land?  Do you have an example that we could use
> > > as a pattern?
> > >
> > > Thanks
> > >
> > > Bob
> >
> > The first step is to create the repository with the library code. Then
> > you would add that repository to the list managed by the mistral team by
> > modifying the project list file in the gover

Re: [openstack-dev] Unified Limits work stalled - next steps, need for new leadership

[Sean Dague]

That sounds great, thank you! Let's synchronize on IRC to do a quick
bootstrapping about where I think the next steps are, then you all can
run with it.

-Sean

On 10/17/2017 11:31 PM, 王玺源 wrote:
> HI Sean,
>   I think that we(Lance and I) from Huawei are willing to take over and
> continue this feature. I hope that we can get some information and
> suggestion from you. Such as: what’s the progress now? What should I do
> now? IMHO, the main work now is to update and polish these two specs[1],
> right? I'll continue to update them if no objection.
>  
> Thanks.
> 
> 
> [1]: https://review.openstack.org/#/c/441203
>  https://review.openstack.org/#/c/455709
> 
> 2017-09-08 3:18 GMT+08:00 Sean Dague  >:
> 
> This is an email that's probably overdue, but time gets away from
> all of us. Coming out of Atlanta and even Boston we were pushing
> pretty hard on a new approach to unify limits, as well as building
> the infrastructure to have hierarchical limits possible in OpenStack
> (keystone merged spec -
> 
> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.html
> 
> )
> 
> However, this effort pretty much as run out of gas, and really needs
> a new driver (or set of drivers) to make forward progress. My
> current set of responsibilities doesn't really make it possible for
> me to own driving this (though I will be happy to help others). That
> seems to also be true of many of the others that were engaged.
> 
> This is going out in advance of the PTG in case any developer(s), or
> organizations feel that hierarchical limits are a priority for them,
> and would be willing to step up there. If so please feel free to
> reach out, and we can carve out some PTG time in helping a new push
> organize here.
> 
> However, without new leadership here, the current plan is to just
> put the effort to rest.
> 
>         -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> 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
> 


-- 
Sean Dague
http://dague.net

__
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][out-of-tree drivers] Breaking change to ComputeDriver.spawn and friends

[Eric Fried]

Correct - and you don't *need* to use the param yet if you don't want
to.  Here's what we're doing in nova-powervm [1].  (It won't pass our CI
until the Nova change is merged - we don't have Depends-On working.)

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

On 10/17/2017 08:18 PM, Chen CH Ji wrote:
> Thanks for sharing this info, I already keep an eye on this change and
> understand the reason,
> so if I understand this correctly, out of tree driver only need
> 'allocations' to be added for spawn and rebuild function and up to the
> driver to use it, correct?
> 
> Best Regards!
> 
> Kevin (Chen) Ji 纪 晨
> 
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
> 
> Inactive hide details for Eric Fried ---10/18/2017 04:07:25
> AM---Out-of-tree virt driver maintainers, please keep an eye on [1]Eric
> Fried ---10/18/2017 04:07:25 AM---Out-of-tree virt driver maintainers,
> please keep an eye on [1], which will force you to update the s
> 
> From: Eric Fried 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 10/18/2017 04:07 AM
> Subject: [openstack-dev] [nova][out-of-tree drivers] Breaking change to
> ComputeDriver.spawn and friends
> 
> 
> 
> 
> 
> Out-of-tree virt driver maintainers, please keep an eye on [1], which
> will force you to update the signature of your spawn and rebuild
> overrides.  See the commit message for the whys and wherefores, and let
> me know if you have any questions.
> 
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_511879&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=8oX5g02pZ4Ix5m6E7QSmfcothpbtEouRYL0QxNGYv9M&s=W6Y0oep8w6Gkm_LMDQQb3ISzmAwzMEUej7uIP6wPpGo&e=
> 
> Thanks,
> Eric Fried (efried)
> .
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=8oX5g02pZ4Ix5m6E7QSmfcothpbtEouRYL0QxNGYv9M&s=oD7yXwwFk6qjyA_YLNpc_ZCPqChdsni1Q7G08p_TXZI&e=
> 
> 
> 
> 
> 
> 
> __
> 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] [stable][mistral] Asking for stable branch policy exception

[Brad P. Crochet]

On Wed, Oct 18, 2017 at 12:34 AM Renat Akhmerov 
wrote:

> Dougal,
>
> I forgot to mention that explicitly but, yes, #1 is needed only not to
> break the sequence of migrations. We can manually fix the migration number
> in #2 just for stable/pike but I somewhat don’t like the idea of having
> different migration numbers in different branches.
>
> It’s a good news that we’re not going to break TripleO.
>
> Thanks
>
>
My thought is take both. Not backporting the migration will break future
upgrades. We have literally been in this situation before.

Brad


>
> Renat Akhmerov
> @Nokia
>
> On 17 Oct 2017, 20:21 +0700, Dougal Matthews , wrote:
>
>
>
> On 17 October 2017 at 09:19, Renat Akhmerov 
> wrote:
>
>> Hi,
>>
>> We have two patches in Mistral that we need to back port to stable/pike.
>> However, they are against of stable branch management policy because they
>> slightly change the DB schema. The patches are the following:
>>
>>1. https://review.openstack.org/#/c/512528/
>>2. https://review.openstack.org/#/c/512256/
>>
>>
>> #2 is a critically important fix that fixes a problem of decreasing
>> Mistral performance when DB becomes heavy (has lots of execution objects).
>> This is a blocker issue for us (Nokia) preventing us using Mistral in
>> production. It also seriously optimizes performance in general.
>>
>> So hereby I'm asking your advice on what we can do in this situation. Can
>> we merge these patches if we make sure that we don't break anyone in the
>> community? For example, TripleO.
>>
>
> As far as I am aware, this wont be a problem for TripleO. These patches
> are both additive (new db column and new db index).
>
> The first patch (512528) is only a candidate for backport to avoid
> breaking the migration history order, it isn't otherwise needed in Pike.
> How is this normally handled in other projects? i.e. we need to backport
> migration 24 to Pike, but 23 is in master only. I assume this problem has
> came up before and been solved, but I can't find any examples.
>
>
>
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>> __
>> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] containerized undercloud in Queens

[milanisko k]

út 17. 10. 2017 v 17:14 odesílatel Dan Prince  napsal:

> On Tue, 2017-10-17 at 11:46 +, milanisko k wrote:
> >
> > How about the shared container? Wouldn't it be better not have to
> > rely on t-h-t especially if we're "scheduling" (and probably
> > configuring) the services as a single logical entity?
>
> The containers architecture for Pike and Queens is very much oriented
> around preserving the way we deployed the services already on
> baremetal... but moving them into containers. So for Ironic inspector

we had 2 services (2 systemd scripts) both living in separate
> containers. Do the the shared nature of this architecture with regards
> to network and host access this works fine.
>

Unless new features, such as  the inspector support for routed/relayed
DHCP/PXE traffic (or spine&leaf network topology), come  into the question.
For this case, as well as for the HA case (with non-overlapping dnsmasq
DHCP pools), the trick with host access won't work alone anymore as the
dnsmasq and inspector need to change each other's (configuration) state. I
guess that old patch needs to address this somehow.


> In the future as we move towards Kubernetes rearchitecting the services
> so they work better in containers is totally fine. If the services are
> that tightly coupled then why not just have one launch the other?


That's my point of view as well.

Then they could live in the single container and have a common launch point.
>

What I'd like to achieve with the supervisord inside of the shared
container as, besides other things, inspector and dnsmasq have to
start/fail together in the HA and spine-leaf-support case.


> Seems fine to me, but certainly isn't a requirement to get these up and
> running in the current architecture.
>

But if addressed right now would save some effort in the future while, as a
bonus, getting us the cool features sooner.

Would you mind testing the containerised undercloud with the inspector
dnsmasq PXE filter patch chain[1] applied?


Thanks,
milan

[1]
https://review.openstack.org/#/q/topic:rebasing_filter+(status:open+OR+status:merged)



>
>
> > Also would allow us to get rid of iptables and better encapsulate the
> > inspector services.
>
> __
> 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] Is it possible that congress policy do live-migration

[houzhian]

Hey guys, thanks for your efforts on OpenStack Congress, I am very puzzled about policy of Congress on recent days and I decided to ask you for some help, I am looking forward to your reply.openstack congress policy rule create \--name live_migrate_vm classification \'execute[nova:servers.live_migrate(vmid,"overcloud-novacompute-1.opnfvlf.org","False","False")] :-host_down(host),active_instance_in_host(vmid, host)'Is this a valid policy? Is there some connection between nova client api and execute in congress policy which are allowed to use? I noticed that     nova pause vmid    'execute[nova:servers.pause(vmid)] :- condition' works properly    nova migrate vmid    'execute[nova:servers.pause(vmid)] :- condition' works properlythere exist nova live-migration vmidbut I can not add execute[nova:servers.live-migration(vmid,other params maybe)] to congress policy, nova:servers.live-migrate(vmid,other params) can be added successfuly but it didn't do live migration jobs, nothing happened.I am confused about this,Am I able to use congress to do some automatic fault recovery like live migration?





发自网易邮箱大师





__
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